As expected, Siemens renewed its maintenance contract with SAP, ending rampant speculation that the German industrial giant and one of SAP’s largest customers was going the third party maintenance route.
But if you’re SAP, or any enterprise software company, this is merely a temporary lull in a battle that will inevitably change the enterprise software market and the issue of maintenance and support with it.
The larger battle still to be engaged is about the overall issue of total cost of ownership, of which maintenance costs are one of many components. SAP’s ability to keep Siemens on board its maintenance regime doesn’t absolve SAP of the obligation to better define, and deliver, a lower TCO model to Siemens and every other customer. Working on this TCO issue will, in the long run, make it clear that maintenance costs – in fact, the overall issue of the size of the check paid to vendors for every deal – are just one part of defining the value, and cost, of the vendor/customer relationship.
Looking at TCO instead of just cost is important for many reasons, one of which is that many of the proponents of drastically lowering third party maintenance, and an overall re-architecting of the vendor/customer relationship, take the perspective that enterprise software is another item for the procurement department to obtain at the lowest cost possible. This “lowest bidder” approach is admired by bean-counters everywhere, even though lowest cost doesn’t always translate to best value, or optimal total cost of ownership either. We’ve seen this in government procurement, and in our own consumer experiences as well: just because you get the best price doesn’t mean you get the best product or service. This rule works in enterprise software as well.
While I don’t disagree that many many customers have paid too much for their enterprise software, the fact that bad deals abound doesn’t mean that blowing up the model in favor of a lowest bidder approach is the solution. I happen to think there’s a better way.
In fact, and here is where I start to part company with some of my colleagues in the analyst community, the problem with the third party maintenance problem is that it tends to look at the software acquisition and consumption process as a series of discrete financial events, each one of which has an intrinsic value that is a) knowable at the time of procurement, and b) subject to the kinds of economic analysis that procurement people tend to use to describe the relative value of two different possible choices.
I maintain that enterprise software isn’t this simple – and that the reason a company like Siemens decided to renew its maintenance contract with SAP is that there is more to the Siemens/SAP relationship than the simple dollars and euros equations that allow many in our industry to call into question the value of maintenance, software licenses, and services.
What more is there? That’s where a more complex discussion about TCO comes into play, and that’s where SAP and its competitors have fallen short in the market.
Importantly, when a company signs on with an SAP or Oracle, they do so with multiple goals in mind, only one of which may be “lowest cost”. Indeed, that goal may be foremost in the CIO or CFO’s mind, but for many line of business users, lowest cost is irrelevant to getting the job done. Discussing issues like maintenance costs feed into the needs of the buyer, for whom lowest cost is the goal, but that discussion has little or no relevance to the line of business user, who is looking at his or her P&L and wondering how the hell they’re going to get the job done, software costs be damned.
The problem with the TCO of enterprise software from an issue standpoint is that it has many components, only some of which are subject to the kind of quantitative analysis that can be applied to maintenance costs. TCO includes business value, particularly for the LOB, a class of user long-neglected in these discussions. It includes competitive value, insofar as well-designed enterprise software can be an important component in the competitive position of a company. It includes long-term cost analysis – what is the cost of upgrades, what is the cost of new innovations, the cost of changing IT to meet future business needs – that add some complexity to a pure, procurement-centered, cost-equation.
TCO also has to take into consideration what I call IT-IQ: how savvy is the consuming company in understanding its business processes and their realization in enterprise software. For the company with a low IT-IQ, paying a lot for a lot of maintenance may be the only way to consume the software. For the higher-IQ company, there may be some mutual value in discounting maintenance costs for this class of user.
It is some version of this analysis that surely went through the minds of Siemens, aided no doubt by high-level assurances from SAP that the TCO of the overall relationship between the two companies would be worth the cost. What SAP needs to do next is expand those assurances to the market as a whole, and do so in a way that adds essential nuance and color to an issue that has been over-simplified by the maintenance cost discussion. I think in the end some maintenance costs may have to go down, but I can’t see any vendor doing so until the full TCO issue is understood, analyzed, and presented to the market.
At which point we’ll stop talking about the horrors of an industry-wide average 22 percent maintenance cost and start the real discussion about the relative TCO between the different vendors. And may the company with the best TCO win.
This is a great blog post. Are you planning to move this show to Twitter ?
A post this size would be about 500 tweets, not sure anyone wants that 🙂
Good analysis. One sentence doesn’t quite make sense though – you say “the reason a company like Siemens decided to renew its third party maintenance contract with SAP”. But SAP does not provide third-party maintenance to its own systems. I think the sentence should read “the reason a company like Siemens decided to renew its maintenance contract with SAP”.
Charles,
Thanks for the ad hoc editing services. I’d fire the copy-editor responsible for the lapse if only I had one 🙂
Josh