- SAP’s TCO is always the highest of any application in any category in which SAP competes.
- In this analysis, we compared SAP versus an unnamed best of breed solution and set the SAP license costs to zero.
- We also cover why integration is such an overrated cost as part of the overall TCO calculation.
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. This is the primary approach of the major consulting firms. That is they are more focused on maximizing their bottom line than in actual software selection.
The main comparison points of enterprise software are the TCO and the application’s functionality. Companies look for solutions from vendors that they are already working with. Then allow the issue of integration to play a primary decision-making role. They ignore TCO (most tend to make decisions without knowing the estimated TCO). Instead of focusing more on initial software acquisition cost. And then de-emphasize the functionality comparison between applications.
A primary way this is done is by having executives, who don’t work with enterprise applications perform the functionality observation through a controlled demo environment. And by marginalizing the users, removing them from the decision-making process. This allows for the selection of weak applications in perpetuity.
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 SAP APO implementation, as well as the costs of maintaining SAP APO. I also work with some best-of-breed vendors. Because I had access to information from several necessary sources and was able to make times estimations based upon personal experience, I decided to perform a total cost analysis between PP/DS and a best of breed production planning and scheduling 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 in which I have first-hand knowledge, which is demand planning, supply planning, service parts planning and production planning and scheduling.
Why the Best of Breed Comparison Vendor is Not Named
I am not attempting to recommend anyone vendor in this analysis, so naming the vendor I used would be a distraction. The main point is that SAP APO’s TCO is in an entirely different cost category. Essentially any best-of-breed vendor I selected would generally compare similarly. Some will be a bit more expensive and some a bit less so, but no best of breed vendor will come anywhere close to SAP APO’s TCO.
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 price fluctuates significantly between customers.
- SAP keeps its price listing secret, and even when you have it, it is still difficult to determine (we had add improvements to the calculation). And then there are also discounts that can’t be predicted.
- The costs may be bundled with other software. In terms of 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 independently calculate a price while 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.
SAP’s Next Level TCO
When I performed the analysis, even without SAP APO’s 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 APO in 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. So something that shows SAP’s TCO is higher than anything else will be considered biased. Therefore, to counteract this concern, 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 main focus of the comparison and that other costs predominated in the TCO. Therefore, free software can end up being not the best decision.
Assumptions of the Analysis
There are many 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 good reasons for this, which I get into later in this post. 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. Not being able to meet perfection should not get in the way of attempting estimation. One way or another, these types of analyses must be performed. I always think it’s better to take a shot at estimation rather than to throw one’s hands up and say its unknowable.
This TCO analysis has been permanently moved to this article. Since this article was first published, we broadened out the application or TCO method to online TCO calculators of 53 different applications.
Total Cost of Ownership Factors
According to this estimate, SAP has a higher total cost of ownership than the best of breed application I compared it against. Having worked in SAP as long as I have, I intuitively I knew it 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 complicated 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 understanding the settings and understanding the interactions between the settings. The statement that SAP is filled with “best practices,” is incorrect, because a best practice approach prescribes that the system define 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.
- Of all the applications I work with, none approach SAP in the number of areas of their applications that don’t work. This includes functionality that never worked, beta functionality that is still listed in the release notes as functional, and functionality that did work at one time but was broken by an upgrade or other cross-application factor. In fact, no one even comes close. SAP’s marketing strategy is 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 further up in the future. However, this results in product management 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 extending 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 Some of the Most Expensive in IT
- There is nothing controversial about this statement; it is well-known in IT circles.
SAP Has the Highest Manpower Support Requirement
- Getting back to the topic of application complexity and fragility, SAP simply 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 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 in creating a new policy to work with the changed functionality. This was course expensive and time-consuming.
Why Integration is Overrated as a Cost in Enterprise Software
The cost differences between SAP and a best of breed application are enormous. The frequently used argument, which 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 costing 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 Implication for ROI in Enterprise Software
According to most publicly available studies, around 1/2 of projects have a positive return on investment. This depends upon the TCO of the solution and the functionality within the application that can be leveraged.
Outsourced Support to Reduce SAP Costs?
Companies now often outsource a portion of their support to India. 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 India based resource is about 1/4rth as expensive. And 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 country resource. Thirdly, this is a mess to manage. There are not only language and time barriers. It appears some of the companies providing these resources are doubled book 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. Outsource operations lack good professional management. The client resources end up having to take over support organization tasks.
Generally, I am not sure outsourced support works for any area well. But it particularly unsuited to complex systems such as planning applications. Generally, when support is outsourced, the quality of support drops precipitously, and anyone in IT knows this.
Implications of the Analysis
Certainly, 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 is difficult 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 in TCO.
SAP and the major consulting firms have fantasy numbers concerning how long SAP projects take, and I have yet to see a TCO comparison between SAP and best of breed solutions provided by a major consulting firm. However, it’s critical to make the TCO estimates 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 possible here to bring the real world data to my estimates, and I even stacked the deck for SAP by removing all license costs, but SAP still came up with a higher TCO.
By the way, this was also true in the other application areas I analyzed. The real world data shows across the board that SAP is significantly more expensive in total costs of ownership than best-of-breed solutions.
Search Our Other Production Planning and Scheduling Content
Constrained Production and Supply Book
How Constrained Supply and Production Planning Works
Getting the Real Story
- The different resources available in APO, how production resources differ from supply planning resources, and the role resources and other significant constraints play in constraint-based planning.
- How constraints integrate across the supply planning and production planning applications.
- The areas of disconnect between supply and production planning applications, and between SNP and PP/DS in particular.
- The difference between unconstrained (or infinite) planning and constraint-based planning.
- The benefits of constraint-based planning and how it differs from capacity leveling.
- Various types of demand, and how backward and forwards were scheduling work.
- The benefits of using production constraints in the supply planning system, and how SNP and PP/DS can be synchronized to produce the desired output.
- The methods that can do constraint-based planning in SNP and PP/DS–heuristics, CTM, and optimization–and how to configure these methods.
- The difference between hard and soft constraints, and how to plan using multiple constraints.
- Chapter 1: Introduction
- Chapter 2: Understanding the Basics of Constraints in Supply and
Production Planning Software
- Chapter 3: Integrating Supply and Production Software with Constraints
- Chapter 4: Constraint-based Methods in APO
- Chapter 5: Resources
- Chapter 6: Capacity-constraining Vendors/Suppliers
- Chapter 7: The Disconnection Points Between Supply Planning and
- Chapter 8: Conclusion