What This Article Covers
- Background and Motivation for the Research in SAP TCO.
- The Basis for the Estimation.
- The Scope of the SAP TCO Analysis.
- Why the Best of Breed Comparison Vendor is not Named.
- Why SAP License Costs are Set to Zero.
- Analysis Assumptions.
- Why Integration is Overrated as a Cost.
- ROI Implications of this Analysis.
- Outsourced Support to Reduce SAP TCO?
Background and Motivation for the SAP TCO Research
When I am often told about the reasons for decisions to go with software that I am familiar with, the logic often does not seem to make sense.
The main comparison points of enterprise software are the TCO and the application’s functionality. However, companies primarily look for solutions from vendors that they are already working with and then allow the issue of integration to play a primary decision-making role. Therefore, they essentially ignore TCO (most tend to make decisions without knowing the estimated TCO), focusing more on initial software acquisition cost, and de-emphasize the functionality comparison between applications
The Basis for Estimation
I visit clients often post go-live on SAP APO and have developed a good sample of companies. I know the typical length of an APO implementation, as well the costs of maintaining APO. I also work with some best-of-breed vendors. Because I had access to information from several important sources and was able to make times estimations based on personal experience, I decided to perform a total cost analysis between SNP and a best of breed supply planning vendor.
The Scope of the Analysis
This analysis is limited to the major planning applications. I have developed estimates for costs of APO modules versus best-of-breed applications for the areas which I have first-hand knowledge, which is demand planning, supply planning, service parts planning and production planning and scheduling.
Why SAP License Costs are Set to Zero
SAP license costs are difficult to determine. There is little doubt they have some of the highest average license costs in the enterprise market, but their application pricing dramatically fluctuates. Additionally, the pricing ‘s hard to determine for one application because it may be bundled with other software. Regarding publicly available rates, SAP has a government price sheet. However, the price sheet is based on an arcane point system that is designed not to allow anyone to calculate a price independently, but at the same time meeting the US government requirement that they have a price sheet. I worked with this sheet for around an hour and a half, and then realized, it was not meant to be deciphered.
SAP license costs are shrouded in mystery. However, when I performed the analysis, even without SAP license costs, I found SAP TCO costs to be so high that even without any license costs or SAP support costs (which are based upon the license costs) the best of breed vendors were still easily beating SAP TCO in all the application areas.
Secondly, any article which does not rank SAP as #1 in whatever it is being compared with is open to immediate criticism. (In fact, the easiest way to have a soft life in IT is to skip any analysis and declare SAP the victor. In doing this, you are not required to provide any evidence, but simply say something like “SAP supports best practices.”) On the other hand, one can denigrate best of breed applications on the most feeble grounds and receive glowing reviews. However, criticize SAP, and you can expect criticism in return. Therefore, to counteract this concern with bias, I decided to tilt the playing field in SAP’s direction by making all of the license costs free. So this analysis assumes you never had to pay anything for SAP’s software or their support. Doing this does one other thing, it emphasizes the point that the license cost should not be the primary focus of the comparison and that other costs predominated in the TCO. Therefore, free software can end up being not the best decision.
There are some assumptions in this analysis. One of the most important is the duration of the implementation. This is one of the trickier things to set. Software companies tend to deemphasize this number, which is why I had to use my experience to adjust the results to what I have seen. SAP implementations take the longest of any enterprise vendor, and there are excellent reasons for this, which I get into later in this article.
However, for both SAP and the best-of-breed vendor, I have included a range and the estimated TCO for each regarding implementation is based upon an average. There is no perfect analysis of this type that can be created because of all the different variables. However, not being able to attain perfection should not get in the way of attempting estimation. This is logically correct, but also one way or another, these types of analyses must be performed, and I always think it’s better to take a shot at estimation rather than to throw one’s hands up and say its unknowable.
The TCO Analysis
This TCO analysis has been permanently moved to this link.
According to this estimate, the SAP TCO is higher than the best of breed application I compared it against. Having worked in SAP as long as I have, I intuitively I knew the SAP TCO would be higher, but even I was surprised by how much higher it was. Here are some of the reasons.
SAP’s Implementations take Significantly Longer than Best of Breed Implementations
- SAP’s software is tough to understand and is highly encapsulated. SAP has so many settings which 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.
- 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.
- 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
- 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. 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.
If you confront SAP and large consulting firms and ask for a proper SAP TCO analysis, be prepared for a dispute on the true cost of their software and time required to go live. It is critical to make your decisions based on actual observations at multiple accounts. As I have in this article, and not based on hypothetically sales estimates from their sales team on how fast a solution can be brought live.
I have done the best job I could to bring the real world data to my estimates, and I even stacked the deck for SAP by removing all license costs, but the SAP TCO is still higher. By the way, this was also true in the other application areas I analyzed. The real world data shows across the board that SAP TCO is significantly higher than best-of-breed solutions.
I cover TCO in detail in the following book.
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.
- 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