Category Archives: SaaS

What Would the Acquisition of SalesForce Mean to the Procurement Market?

Who Cares?

While the doctor and the maverick see eye-to-eye on a lot of issues, and that’s why they have been collaborating on the new Spend Matters CPO site because there are important messages that are just not being communicated by the new press at large, the doctor believes that the impact this acquisition will have on the Procurement market, as summarized in yesterday’s post on “what would the acquisition of salesforce mean to the procurement market” by the maverick, is not as important as the maverick seems to believe it is.

While the acquisition of SalesForce is an important topic, it’s no more important than the acquisition of any non-Procurement technology vendor. (While some SRM vendors use the platform, one has to remember that it is, at its core, a CRM platform). It’s (primarily) upstream, while Procurement is primarily downstream. While the processes should connect, they are still distinct and, unless you are in the middle of a negotiation, there’s no reason to even think about it as a Procurement issue.

The real issue is what does the acquisition of SalesForce mean to the technology market, and the market at large?

And while the doctor knows that he’s not just stirring the pot but the entire honeycomb on this subject, it’s a subject that needs to be addressed. So what does it really mean?

Simply put, too big to succeed!

One of the biggest problems with the technology market is that the misconception that bigger is better, and too big to fail, is a reality. The whole point of big was to benefit from economies of scale. But economies of scale have a limit. A single factory with a single production line can only produce so much going 24 hours a day. To go beyond that, you have to add another production line, or even another factory. If you do so, and you only reach half of the capacity, you don’t have the same economy of scale on the overage.  The biggest economy of scale was when you were at full capacity on the one line.

In other words, if you expand faster than demand, you waste time, money, and resources. This situation is bad, but the situation that occurs in an acquisition is much worse. Not only do you have more capacity, but you have a huge debt load as a result of the acquisition. So you are paying more to produce, and then you are paying even more to service the debt that you took on to produce more than you needed to.

But even this situation isn’t as bad as the situation where you are talking about technology companies that don’t produce physical goods, don’t have demand that typically rises with population increase or market growth, and have valuations that are many multiples of annual revenue — not profit, revenue. And we all know that the misconception that the product has already been built and the residual cost of sale is minimal is incorrect. Software has to be maintained, debugged, and constantly improved in order to be saleable to the mass market. That is costly. Whereas a product has a single production cost, possibly a single repair cost under warranty, and possibly a single reclamation or disposal cost, that’s it. The cost for each product is essentially one-time, whereas the cost of software is continual and adds up everyday it is in use.

As a result, you have software that typically:

  • cost millions to build
  • costs millions to maintain

and now you want to

  • add millions to the cost just so you can change ownership and assign a different name

It doesn’t make a lot of sense. Especially when you are talking about the acquisition of an 800 lb gorilla which already has a (relatively) complete solution. In this situation the acquirer is essentially admitting that either

  • its solutions are totally inadequate and it wasted millions of its customers dollars on its solutions (versus realizing that it has some good solutions, is missing a few key elements, and just needs to acquire a few point solutions from smaller vendors to fill the holes) or
  • it has no inherent capability to enter the space (and maybe it shouldn’t be entering the space to begin with).

And the acquiree is essentially admitting that

  • it cannot maintain (rapid) growth on its own anymore (which may not be bad if it’s the dominant player and has a very large recurring revenue and could continue to increase profitability with improved efficiency) or
  • it’s shareholders are greedy and impatient and don’t care what’s best for their customers and just want a quick payout.

Neither situation is good for either party. Nor does it make sense for any of the de facto tech giants who would likely acquire SalesForce to do so. None of the six AMIGOS (Amazon, Microsoft, IBM, Google, Oracle, and SAP) should acquire SalesForce. Here’s why.

  • Amazon
    They are an online e-commerce giant, with inherent ability to be a commodity supplier to large enterprises. They are not a software provider and beyond insuring quality, and receipt of goods, would not benefit from CRM. Sure the Force.com platform would allow them to offer even more apps, but they can already offer Android apps and sell online software, so it’s not a huge leap in capability.
  • Microsoft
    They already have huge back office suites that they have made huge investments in, including investments to port these suites to the cloud. Plus, their focus, and strength*, is back-office apps. They’d be taking a huge-write off on existing technology and would have to rewrite a lot for a whole new platform. They already run on Windows and Mac, that power the vast majority of office desktops, so why do they need the Force.com?
  • IBM
    IBM already has platforms for just about everything, including Alliance for CRM, have heavily invested in Watson, and need to keep building on the workflow and integration platforms they spearheaded in the early naughts.
  • Google
    the doctor will admit that it almost makes sense for Google, but Google’s market, and expertise, is apps, and it is still learning how to make money off of enterprise apps. It’s not ready for SalesForce, would have to let it run as a completely separate division, and take a huge hit to its balance sheet to pull of the acquisition. And while it’s the one company that could probably pull of a successful integration in a reasonable timeline without bleeding blood red everywhere, it would likely be quite a divergence from its other projects.
  • Oracle
    Oracle has too many CRM platforms as it is (with Siebel, PeopleSoft, CRM on Demand, and integration to about a dozen other platforms) and needs to continue to integrate and build on what it has. What makes Oracle strong, and great, is that it has always believed in eating it’s own dog food (while Microsoft ran off of third party databases even after SQL Server was released and has demoed Windows software releases on MacBooks on more than one occasion), but even Oracle can only integrate its acquisitions so fast. It’s still catching up on acquisitions past (and it took about 3 years to integrate the majority of Sun applications into its “single instance view”), so just imagine the effort to do a true end-to-end integration of SalesForce. Plus, it’s still a database / ERP company and with SAP so aggressively pursuing its marketshare in the US, with IBM and Microsoft still aggressively pursuing its global market, and with some companies (still) proclaiming that non-relational or in-memory databases can be faster and better for the average application, it has to focus on winning that fight.
  • SAP
    SAP is an ERP company with a very heavy focus on SRM, as evidenced by the huge amount of money it has dropped on Procurement, T&E, and Supply Management vendors over the past few years. This is where it has to focus to not only break-even on its acquisitions, but generate future value. And it still has a lot of integration to do. A lot.

the doctor‘s sure not everyone will agree with him, especially since people seem to get a little blind when such big numbers start flying around, but someone has to start putting this in perspective.

And now to put up the tarps in expectation of the reactionary mud-slinging from third parties not inclined to think deeply about the issue.

* And yes, the doctor cringes when he says this because most of their software, in his view, while standard, is sub-par — but they are the de facto solution and their Office apps, when you cut through the clutter (and the ribbon), work very well.

Best Practice Technology Vendor Selection for True Multi-Nationals

2012

  1. RFX: You’re Asking for the Wrong Information
  2. RFX: You’re Not Asking for the Right Information
  3. RFX: You’re Missing the Most Important Point
  4. Open the Doors for a Truly Successful RFP
  5. Stuck with an ERP? You Do Have Options!

2015 Reprise

  1. RFX: You’re Asking for the Wrong Information
  2. RFX: You’re Not Asking for the Right Information
  3. RFX: You’re Missing the Most Important Point
  4. Open the Doors for a Truly Successful RFP
  5. Stuck with an ERP? You Do Have Options!

Good Strategies for Microsoft AND Big Software Co. Enterprise Renewals

A guest post earlier this month over on Spend Matters on “5 Mistakes to Avoid When Renewing a Microsoft Enterprise Agreement in 2015” had some good tips not just for Microsoft Enterprise Agreement renewals but Big Software Co. Renewals in general.

The major pieces of advice generalize as follows:

Waiting until the last minute for renewal negotiations.

While this may have worked in the past, the bigger providers have smartened up. They have learned that it’s not the month or quarter or the year, but profit that matters, and will wait a month to get more profit when they are sitting on a huge cash reserve. Also, they have learned that if you wait until the last minute, you probably haven’t identified any other options, and even if you did, would not have time to implement another option and it’s you they have over a barrel, not the other way around. In addition, as per the article, there are only so many sales people and, unless you are a really big customer, if the sales people are busy, they may not get to you before the licenses expire and the systems lock up.

An over focus on price and an under focus on terms and conditions.

Price is important, but, as per the article, so is matching the service offering to the organizational need. Not only do you not want to over subscribe, and end up with a large number of unused licenses, but you don’t want to subscribe for products that don’t meet organizational needs either. But this isn’t the most important thing — it’s the fine print. If organizational needs are in flux, the last thing the organization wants to be is locked into a multi-year agreement or a minimum license count, with a huge penalty if the organization tries to end the agreement early. Similarly, the organization wants to understand the full cost of a cloud service and, if additional bandwidth or CPU usage costs can be added on during periods of intensive usage, this needs to be understood as well.

Treating negotiations as a one-time event.

The buying organization may set-and-forget the three year renewal until thirty (30) months, or more, have passed, but the vendor will be analyzing the contract, and usage, every quarter and looking for ways to extend the offering as soon as possible. The organization needs to monitor its usage as well to be able to make an informed counter to a vendor who indicates that the company is nearing capacity in licenses, computing power, etc. when it is still 20% away from maxing anything out and only increasing in usage at 1% a month.

Not being audit ready.

Chances are your Big Enterprise Software Vendor has an audit clause in the contract for any licenses installed on premise. And chances are that if the organization has not had an audit in the last couple of years, that, unless the organization agrees to the default renewal (which will often be for more licenses than required at a higher rate), that the customer will be audited for usage. The organization should do it’s own software (license) audits on at least an annual basis and keep detailed records. Not only will it have the data to dispute any claims to the contrary made by the vendor, but it will be able to make sure it remains in compliance at all times.

Enterprise software is costly. But it doesn’t have to be a spend sinkhole.

Integration Point: A Global Content Provider

When we last covered Integration Point (in 2008 and 2010), we discussed their solutions for customs, security, and product classification; for free / secure trade zones and for regulatory compliance.

We talked about how their SaaS solutions helped companies with product classification under HS codes, advance notification (as required by 10+2), denied party screening (through integration with the US denied party lists), free trade / special economic zones (and identification of associated agreements), and the creation of necessary documents as well as the creation of surveys to determine if the supply base was compliant.

It was a good all-around solution, but it wasn’t a one-stop shop. While the import and export management solutions were extensive, the supply chain compliance solutions were limited; free trade was primarily ECCN, entry visibility, and country of origin; there was no automatic HS or country of origin classification; and content was primarily limited to HS/HTS codes, common import documentation, custom compliance documentation, and FTA summaries.

However, recognizing that their entire solution was dependent on good content, Integration Point, which now has twenty (20) offices across six (6) continents (and which promises an Antartica office as soon as the penguins start trading), started working on a Content Repository ten years ago and over the last decade has grown that content repository into a Global Content Repository with relevant trade data for over 185 countries. This include HS Codes, Tariff Schedules, Import/Export documentation requirements, rulings, free trade agreements, free trade and special economic zones, customs compliance programs, denied parties, sanctions and embargoes, and relevant trade acts, such as Lacey. The repository, which is maintained by a team of over 200 people globally, contains millions of base documents and millions of codings and mappings and is updated daily.

Daily updates is a critical part of a trade content repository. While some countries only update their tariff schedules a few times a year, others update their schedules monthly, and some update their schedules weekly (or more as Brazil once updated its schedules 80 times in one year). In addition, as trade relations improve or break down between countries, new trade restrictions / sanctions / embargoes are created almost overnight, denied parties get added to the list daily, and new regulations and rulings also come out on a daily basis. Correct classification, coding, and documentation is the difference between trouble-free trade and having your shipment held up for days, weeks, or months. And not shipping a restricted product to a denied party is the difference between smooth sailing and being federally investigated and fined millions of dollars. In both cases, your logistics and trade managers can only insure properly documented, legal, trade if they are on the ball with up-to-date data.

Since Integration Point has a global team, Integration Point, which sells access to its content repository as well as its trade management solutions on a subscription basis, is able to keep its repository current, which is no mean feat considering there have been over 2M updates to HS classifications alone on a global basis so far this year and over 1M updates to the import / export document database were required to capture regulation updates, trade agreement updates, form updates, and new rulings.

Integration Point now has one of the best and most complete Global Content Solutions out there and should be included in your list of content solution providers as you endeavour to get your compliance under control because Content is a Cornerstone of Compliance.

Plus, based on this content, Integration Point is now able to offer innovative solutions around country of origin determination, product classification, tariff analysis, and supply chain costing. We will cover these in future posts in early 2015.

10 Mistakes You Make When You Try To Build a Private Cloud

VentureBeat recently ran a great article on 5 Mistakes You’re Making When You Try to Build a Private Cloud that did a great job of covering 5 mistakes you make, but why stop there? SI can easily come up with 10 mistakes, more if it gives the issue a second thought. So, since some of you still don’t believe that The Cloud is Filled with Hail, let’s review the VentureBeat 5 and throw 5 more into the mix to see if that’s enough to convince you that The Cloud is Not a Magic Mirror — especially when you take a do-it-yourself approach!

VentureBeat’s 5 Mistakes of a Private Cloud are:

1. You believe the cloud will solve all your problems.

With so many vendors touting it, you believe that a cloud must be the answer, so why not control your own? There are a host of reasons, including those that will be discussed in response to the other wrong assumptions, but the most important thing to remember is that not all applications are good candidates for the cloud. Applications that are intermittent, that run full tilt, or that spike unexpectedly are not always good cloud candidates — public or private.

2. You think everyone will automatically love the idea.

You keep hearing that clouds bring agility, adaptability, and actionable data — so you think that you can convince everyone else to fall in love with the cloud too because you believe that these are reasons to fall in love with the cloud. A cloud is as adaptable as the software that drives it, as actionable as the data you can get into it, and as agile as your organization — if it takes 3 months to get a product to market using the best processes you can come up with, it takes 3 months to get that product to market — cloud or no cloud.

3. You think it’s cool.

Clouds aren’t cool (although the rain they bring may cool you off). And unless you are in the business of selling “cool” technology (i.e. private clouds to suckers who buy private clouds), the last thing you should be basing a business decision on is the “cool” factor. You buy technology to solve your problems, not because it’s cool.

4. You think you will succeed in boiling the ocean.

A private cloud is a huge IT project similar to trying to replace 3 ERPs across your global organization that have been entrenched for 10 years across 3 continents in one fell swoop while trying to add 4 modules you never had before. It’s like trying to boil the ocean with a single giant magnifying glass — brave, maybe even visionary, but ultimately stupid.

5. You think your plan will fit the organization.

The typical private cloud relies on converged infrastructure (CI) stacks which break down the typical organization walls of application teams, server teams, network teams, and storage teams. How many Global 3000 organizations have one single version of the truth across the enterprise? Maybe the few dozen organizations that successfully achieved enterprise wide deployments of SAP and Oracle?

That’s just the beginning. Here are 5 more mistakes courtesy of SI:

6. You think a private cloud will be cheaper than a public cloud.

You might think that a cloud is a fluffy magic box that can be obtained with a handful of magic beans that you can get by trading a simple cow, but that’s about as far from reality as you can get. Clouds require hardware, software, dedicated network connectivity, and power. Lots of power. You will need backup generators in addition to a wall of UPS units (to keep the machines humming until the generators kick in), multiple fibre connections, racks of machines and storage area networks, and a lot of specialized software. And, instead of sharing the cost, you get to pay for it all — as well as the staff to build it and maintain it 100% — 24/7/365.

7. You think all modern technology was built for the cloud.

A lot of software is, but not all — and chances are that a lot of the software you are using, even if still under maintenance, was not built for the cloud. So, you’ll have to update your current software and migrate your current data stores while you are at it.

8. You think it is the best way to interact with your trading partners and the private clouds you wrongly assume they have.

The cloud is connective, but only if it is shared. Otherwise, it’s just one massive local area network that needs to talk with other massive local area networks used by your trading partners. Clouds don’t create connectivity – data interchange standards do, and you don’t need clouds for that!

9. You think you can secure it better than the experts.

Hi Ho, Hi Ho.
It’s off to work we go!
We block the ports and tune the firewall
In our ‘Net the whole day through
We block the ports and tune the firewall
It’s what we like to do
It ain’t no trick
To lock down quick
If ya block the port
With a sniffer on a ‘NIC
In the ‘Net …

And you can block every port, patch every firewall, and sniff every ‘NIC, but the reality is, your network is only as secure as the weakest link — which is probably the software you’re using and the ports you need to have open. Which you don’t know how to protect because your IT staff is struggling to patch your firewall, scan the ports, and upgrade SSL before the heartbleed bug bleeds you dry of your corporate secrets. When it comes to security, you need true security experts — and you’re not going to have them in house.

10. You think the cloud can actually be secured.

The only way to truly secure a network is to unplug it. So if you think you have a hope in Hades of securing your private cloud …