How to Best Understand SAP’s TCO Claims

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 view, software vendors cannot help customers come to a TCO because they have a conflict of interest on this topic.

I have written the only book on enterprise software TCO and performed thorough research on the topic.

My conclusion is that most of the entities that talk about TCO, like software vendors and consulting companies don’t want their customers to know the TCO. In fact, while many software vendors propose TCO, 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 doing research for the book Enterprise Software TCO, I had to perform a literature review of the areas. I have to say, 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

What Does SAP Say About its TCO?

Even though SAP seems to take more of the IT budget of its customers every year, with each new product release, SAP reflexively states that the new items “reduces TCO.” SAP hired the research analyst Forrester, which created a study that we have analyzed that actually does not say that SAP HANA reduces TCO. Instead, it stated that SAP HANA might reduce TCO. None of Forrester’s work was based on speaking with real customers and only based on speaking with SAP.

When SAP used the study for marketing, they stated that the Forrester study had demonstrated a reduced TCO for S/4HANA. S/4HANA is a separate product from HANA. As soon as SAP began to say this, SAP’s consulting partner also began saying it, even though there was never any evidence for it. In fact, in reality, due to factors ranging from the fact that HANA was the most expensive database in the market to the maturity issues with HANA, the database has in our estimation the higher TCO than the database it was replacing (in most cases Oracle), but the highest TCO of any database used for the purposes that HANA is directed towards.

Why SAP Has No Idea What it is Talking About with TCO

SAP actually does no TCO studies, and with good reason. For example, SAP is the most recommended software applications by the largest consulting companies precisely because SAP has the highest TCO versus alternate vendors, and a part of this TCO is SAP’s very high implementation costs, which serve as the revenues for SAP consulting companies.

Therefore, SAP does not know what the TCO is for its earlier applications or the TCO of its later applications. What is known is that SAP has the highest TCO of any vendor in each of the application categories that we have calculated.

This is the type of information that can be used against SAP. We have extensive calculators for SAP as well as competing applications available.

Why Would SAP Want TCO Accurately Calculated?

This quotation was amusing because SAP has the highest TCO of all the applications, which I studied in the book and I have performed TCO analysis for all the major software categories — 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, which are focused on implementing long and complex projects — in order to maximize their billing revenue. And it should be understood that most of the money is going to the senior members of the consulting companies. For whatever the rate, Deloitte, Accenture, etc.. pull about 2/3rds of the billing rate for compensation for the senior members of the company and to pay expenses, only about 1/3 of the rate is actually paid to the consultants that do the work — and the senior members manage and organize but essentially do no work. It is a highly elitist and inefficient system, which is made even more elitist when outsourcing is involved. It is at its heart labor exploitation. How can such an inefficient and wasteful system, which results in such bad software being selected result in a low TCO?

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 pretty much any new product they introduce reduces SAP TCO over the previous product that 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. Which is interesting, because SAP is not known for having a low TCO. In fact, a primary reason why Deloitte, Accenture, IBM and others recommend SAP, even when the particular application in question does not meet the requirements of their customer very well is that they can make more money on SAP implementations than any other software. Now 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, they 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.

SAP applications are complicated and high in maintenance overhead, and this 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 that have the highest amount of 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 in 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.

The Illusion of Lower SAP TCO

SAP receives benefits from continually talking about lowering TCO but never actually doing so. In fact, the TCO of SAP applications has been steadily rising as SAP moved into software categories where it brought uncompetitive products. This includes business intelligence, advanced planning, MDM, CRM, etc. The TCO of a failed application, that is an application that either barely goes

The TCO of a failed application, that is an application that either barely goes live (and is little used) or is never brought live is the highest of all. 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 to, 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,

  • Now, 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 could have made its existing applications easier to integrate to, 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, SAP has chosen the latter.

It is difficult to imagine any software vendor that has as many either failed implementations or implementations that are live but barely used than SAP. This is because SAP has the most difficult to implement applications in the enterprise software space. I say this as a SAP consultant who has worked on projects since 1997. Software companies do not publish their failures, so there is no way of knowing the actual failure rate of the different software vendors. So for those asking for data, it needs to be acknowledged that it is not available. But I write this based

This is because SAP has the most difficult to implement applications in the enterprise software space. I say this as a SAP consultant who has worked on projects since 1997. Software companies do not publish their failures, so there is no way of knowing the actual failure rate of the different software vendors. 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’s Implementations take Significantly Longer than Best of Breed Implementations

  1. SAP’s software is tough to understand and is highly encapsulated. SAP has so many settings that allow the system to behave in different ways that extensive 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 in fact, SAP follows the “comprehensive approach.” This includes a seemingly unlimited number of ways of configuring the system.
  2.  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 long story short on this topic is that product management is writing checks that development cannot cash. Testing each area of functionality to ensure (part of what I do by the way) imposes more work and more time on the implementation.
  3. The large consulting companies have built their business model around SAP and extended the time of SAP implementations to maximizes their billing hours. SAP made a strategic decision quite some time ago to let the consulting companies control the speed of implementation to be recommended by the major consulting firms, regardless of the fit between the application and the client need.

SAP Resources Are More Expensive

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

SAP Has a Higher Manpower Support Requirement

  1. Getting back to the topic of application complexity and fragility, SAP only takes more resources to maintain. Something I recently had to work with 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 needed 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, and the frequently used argument, that the company wants an integrated solution, cannot reasonably be used to 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 of even a few hundred thousand dollars would not tip the TCO in SAP favor. Also, the maintenance of the SAP CIF (the middleware that connects R/3 to APO) is vastly underrated. 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 functionality of the application that can be leveraged. SAP planning modules are so expensive compared to alternative solutions, and deliver a lower functionality level than the best-of-breed solution, that as a natural consequence they have a lower ROI and a lower percentage of positive ROI projects. However, the incorrect perception in the industry is just the opposite; that SAP is the 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 end up having to read notes from the support team which is not spelled properly because of language barriers.

Outsource operations 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 analysis 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 that SAP’s planning products cannot be justified by 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 cognizant of the significant premium they are paying for SAP TCO.

Conclusion

SAP customers should view claims by SAP regarding SAP TCO with great skepticism. The only report I am aware of that SAP has that is related to TCO was where SAP funded Forrester to provide a forecast of the SAP TCO of HANA. This report is so filled with errors and rosy projections and is not based on any actual projects that it qualifies as nothing more than marketing material.

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 Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP TCO Content

References

https://docs.google.com/viewer?url=http%3A%2F%2Fwww.eaconsult.com%2Farticles%2FRethinkingTCO.pdf

TCO Book

TCO3

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
Chapters
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making