The Many Reasons Why SAP's TCO Claims Are Not True

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

SAP makes exaggerated TCO claims without providing evidence.
We cover how SAP presents its TCO story.

Introduction

TCO or total cost of ownership is the total cost of owning and operating an application.

TCO means making a model that accounts for the different cost categories. I have written the only book on enterprise software TCO. Many software vendors propose TCO, but when you review their models, they leave many costs out.

In my book Enterprise Software TCO, I break the costs of enterprise software into:

Acquisition Costs
Implementation Costs
Hardware Costs
Maintenance Costs

While researching the book Enterprise Software TCO, I had to perform a literature review of the areas. I have to say, and this following quotation was amusing to read…

“SAP AG’s pioneering initial efforts developing a single-vendor TCO model will yield benefits that, while not as broad as those intended by the early multi-vendor TCO studies, would be all the more valuable by virtue of their comprehensiveness and completeness.” – Rethinking TCO: Towards a More Viable and Useful Measure of IT Costs

Why Would SAP Want Their TCO Accurately Calculated?

This quotation was amusing because SAP has the highest TCO of all the applications. That is the entire enterprise software solution architecture for a company. The last thing SAP — or any other large vendor wants, is an actual TCO analysis of its products. SAP, Oracle, IBM’s products are all implemented by the major consulting companies focused on implementing long and complex projects — to maximize their billing revenue.

The fact is that no software vendor that is primarily implemented by a major consulting company can have a low TCO; it is inconsistent with the business model of both large consulting companies and large software vendors. I quote directly from Enterprise Software TCO below.

Why Would a Major Consulting Company Want TCO Accurately Calculated?

“A lack of proper TCO is behind many poor decisions, as are many consulting companies. Consulting companies don’t share the economic benefit of good decisions on the part of their clients and therefore are not primarily incentivized to promote good decision making in their clients. Instead they are incentivized on billing hours. And this means introducing things that the company does not currently have, or does do not currently do. As I previously stated, a lack of proper TCO has been partially responsible for the overuse of both ERP and outsourcing.”

SAP’s Presentation on TCO

SAP’s presentation on SAP TCO is very straightforward. According to SAP, any new product they introduce reduces SAP TCO over the previous product it replaces. SAP never presents any evidence for lowered SAP TCO, but of all the vendors in enterprise software, they talk about it the most. This is interesting because SAP is not known for having a low TCO. The primary reason why Deloitte, Accenture, IBM, and others recommend SAP, even when the particular application in question does not meet their customer’s requirements very well, is to make more money on SAP implementations than any other software. They always have some excuse for doing this (it is important to stick with SAP, integration costs will be lower, SAP’s functionality is weak now, but it is growing).

But regardless of the reason they give, the big consulting companies always prefer implementing SAP over all other alternatives. But if you won’t implement SAP, they also have an Oracle practice. But if you don’t want to implement SAP or Oracle, you will generally hear that your purchase is not to their taste.

The Reality of SAP TCO

SAP applications are complicated and high in maintenance overhead, which maximizes billing hours for the consulting companies. Consulting companies have a conflict of interest when it comes to TCO. They want their customers to buy applications with the highest implementation costs because those costs are revenues for the consulting companies.

I have spent a lot of time developing TCO calculators. However, whenever I do something in SAP, it is always far more difficult to do that “thing” than any other application. As implementation and maintenance are by far the highest costs of enterprise software, it is hard to see how this does not directly translate to a higher TCO.

What is the TCO of a Failed Implementation?

The TCO of a failed application, an application that either barely goes live (and is little used) or is never brought live, is the highest. SAP could have lowered the TCO of its customers by not releasing any of these applications, but they preferred the extra revenues. SAP could have made its existing applications easier to integrate into, thus lowering their customer’s TCO. But SAP preferred to use the difficulty in integration to push their customers to buy more “pre-integrated” SAP products. Time and again, when SAP has had the option of lowering their customers TCO or maximizing their revenues. Let us review some of the major factors in this area.

SAP Decision #1: Introducing Far Too Many Products

SAP could have lowered the TCO of its customers by not releasing any of these applications and focusing on their core product. But they preferred the extra revenues of diversifying into things that they weren’t any good at and then using the integration back to the SAP ERP system to push out vendors that had superior applications.

SAP Decision #2: Making Integration Difficult

SAP could have made its existing applications easier to integrate into, thus lowering their customer’s TCO. But SAP preferred to use the difficulty in integration to push their customers to buy more “pre-integrated” SAP products. Time and again, when SAP has had the option of lowering their customer’s TCO or maximizing their revenues, SAP has chosen the latter.

It is difficult to imagine any software vendor with as many either failed implementations or implementations that are life but barely used as SAP.

This is because SAP has the most difficulty in implementing applications in the enterprise software space. I say this as an SAP consultant who has worked on projects since 1997. Software companies do not publish their failures, so there is no way of knowing the different software vendors’ actual failure rates. So for those asking for data, it needs to be acknowledged that it is not available. But I write this based upon seeing many SAP accounts over many years.

SAP Decision #3: Giving Up Control In Return for Recommendation by Corrupt Consulting Firms

The large consulting companies have built their business model around SAP and extended the SAP implementations to maximize their billing hours. SAP made a strategic decision quite some time ago to let the consulting companies control the speed of implementation recommended by the major consulting firms, regardless of the fit between the application and the client’s need.

However, this is because the TCO of their products isis increased by the consulting firms’ needs, which is predominant.

SAP’s Implementations take Significantly Longer than Best of Breed Implementations

SAP Complexity #1: Overly Complex Software

SAP’s software is tough to understand and is highly encapsulated. SAP has so many settings that allow the system to behave differently. Extended time must be spent in both learning the settings and understanding the interactions between the configuration. The statement that SAP is filled with “best practices” is incorrect because a best practice approach prescribes that the system defines specific ways of doing things when SAP follows the “comprehensive approach.” This includes a seemingly unlimited number of ways of configuring the system.

SAP Complexity #2: SAP’s Enormous Scope of Products

SAP’s marketing and product management strategy are to cover functionality as broadly as possible so they can always say “we have it.” This same development approach spans across applications, as I observe the same thing in different product lines, such as SAP BW. This is one reason SAP’s TCO is probably headed even higher in the future. What will eventually bring SAP down is when it becomes so complicated that their applications are no longer maintainable. Or when a major technology shift, such as SaaS, impacts the enterprise software market that undermines SAP’s natural monopolistic advantages.

However, the synopsis on this topic is that product management is writing checks that development cannot cash. Testing each functionality area to ensure (part of what I do, by the way) imposes more work and more time on the implementation.

SAP Resources Are More Expensive

There is nothing controversial about this statement; it is well-known in IT circles.

SAP Has a Higher Manpower Support Requirement

Getting back to the topic of application complexity and fragility, SAP only takes more resources to maintain. I recently had to work was one method, which was part of the functionality that did work but stopped working as of the release SCM 7.0.

First, the problem that cropped up due to this need to be diagnosed and explained (we did not find out about the broken functionality but perceived it through system problems. Once discovered, this functionality had to be changed to a method that did work, and the business had to invest time creating a new policy to work with the changed functionality. This was course expensive and time-consuming.

Integration is Overrated as a Cost

The cost differences between SAP and a best of breed application are quite large. The frequently used argument that the company wants an integrated solution cannot reasonably justify a decision to select SAP. I have not broken out the integration separately, as it is built into the consulting costs, but an adapter or even a few hundred thousand dollars would not tip the TCO in SAP favor.

Also, SAP CIF SAP CIF maintenance (the middleware that connects R/3 to APO) is vastly underrated. With my experience and with developing custom adapters for connecting best-of-breed planning applications to SAP, I have become firmly convinced that the cost of maintaining the CIF is more than the cost of developing and maintaining a custom adapter. The CIF, which connects up APO to SAP ERP, is unacceptably problematic.

Implication for ROI

According to most publicly available studies, around 1/2 of projects have a positive return on investment. However, this greatly depends upon the TCO of the solution and the application’s functionality that can be leveraged. SAP planning modules are expensive compared to alternative solutions and deliver a lower functionality level than the best-of-breed solution. Consequently, they have a lower ROI and a lower percentage of positive ROI projects. However, the industry’s incorrect perception is just the opposite; that SAP is a safe vendor to choose.

Outsourced Support to Reduce Costs?

Companies now often outsource a portion of their support to India, so one might imagine that the support costs listed here could be reduced.

This is another frequently held assumption but does not prove out in reality. A good rule of thumb is that while the India-based resource is about 1/4rth as expensive, it takes more than twice as many individuals to get close to the same amount of support work done.

Secondly, there must always be at least one in the country resource. Thirdly, this is a mess to manage. There are not only language and time barriers, but it appears some of the companies providing these resources are double-booked the same resource on multiple clients. I have been dealing with this issue for several years now, and I have to read notes from the support team, which is not spelled properly because of language barriers.

Outsource operations generally lack good professional management, and the client resources end up having to take over support organization tasks. I am not sure outsourced support works for any area very well, but it particularly unsuited to complex systems such as planning applications. When support is outsourced, the quality of support drops precipitously, and anyone in IT knows this. I provide a full treatment of the pitfalls in outsourcing SAP APO support in this article.

Implications of the Analysis

Indeed, other analyses with different assumptions will have different results. However, the TCO differential is so high between SAP and a best of breed solution that it’s hard for me to envision any analysis where SAP has close to the same TCO as a best of breed solution.

This means tTCO cannot justify SAP’s planning products TCO and that companies must be able to obtain something from SAP that they cannot obtain from a best of breed application. Companies should be conscious of the significant premium they are paying for SAP TCO.

Go to top

Conclusion

To reasonably discuss SAP TCO, one must set up an agreed-upon method on SAP TCO, and the entity that performs the TCO calculation must be unbiased. SAP, or any other software vendor, or a consulting company that makes its money by implementing that particular software does not qualify.

The Many Reasons Why SAP’s TCO Claims Are Not True