How SAP’s TCO Compares for SAP APO Service Parts Planning

Background and Motivation for the 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. In fact the entire process for repeatedly selecting expensive and lower functionality software from the major monopoly vendors turns out not to be based on the main comparison points of software. 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 primarily 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. 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 applications that are weak or have unreliable functionality to compete with vendors that have excellent and reliable functionality.

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 a number of 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 SPP and a best-of-breed service parts planning vendor. This is just the service parts planning analysis. Here are links to the others.

http://www.scmfocus.com/productionplanningandscheduling/2011/08/09/what-if-you-paid-nothing-for-sap-software-how-saps-tco-compares-for-production-planning/

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. I do not perform any similar analysis for other popular enterprise areas such as ERP or analytics.

Why the Best of  Breed Vendor is Not Named

I am not trying to recommend any one vendor in this analysis, so naming the vendor I used would be a distraction. The main point is that SAP’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’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 greatly. In addition, 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 clearly designed to not 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.

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 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. (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 generally are not required to provide any evidence, but simply say something like “SAP support best practices.”) So something that shows SAP’s TCO being 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.

Analysis Assumptions

There are a number of 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 very good reasons for this, which I get into later in this post. However, for both SAP and the best-of-breed vendor, I have included a range, and the estimated TCO for each in terms of 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. 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.

Total Cost of Ownership

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

  1. SAP’s software is very difficult 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 spend in both understanding the settings and understanding the interactions between the settings. The statement that SAP is filled with “best practices,” is actually 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.
  2. 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 is 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.
  3. The large consulting companies have built their business model around SAP and extend 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 in order 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

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

SAP Has the Highest Manpower Support Requirement

  1. 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 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 change 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.

SPP in Particular

Of the four different planning areas that I have created TCO comparisons for, SPP is a special case as it is an immature product with significant needs for on site development. For this reason I have given it the longest implementation timeline of any SAP planning product. It also estimate its support load to be higher than the other SAP planning products because of maturity issues combined with the extra effort to support the custom development that must accompany any SPP project.

Secondly, SPP projects are very risky due to SPP’s lack of maturity. Therefore, the long timeline included here does not include the likelihood of walking away from the implementation at any time during the project.

Integration is Overrated as a Cost

The cost differences between SAP and a best of breed application are enormous, 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. For more on the CIF, see this post.

http://www.scmfocus.com/sapplanning/2011/05/19/why-i-no-longer-recommend-using-the-cif/

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 within the application that can be leveraged. SAP planning modules are so expensive compared to alternative solutions, and deliver a lower functionality level than 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 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 India based resource are 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 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 actually double 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 are 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.

Generally, I am not sure outsourced support works for any area very 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.

Conclusion

If you confront SAP and large consulting firms to require a good TCO analysis, be prepared for a dispute on the true cost of their software and time required to go live. However, its critical to make your decisions based on actual observations at multiple account, 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 much 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.

 

 

 

Advertisements

2 thoughts on “How SAP’s TCO Compares for SAP APO Service Parts Planning

  1. Pingback: The Surprising Story on the Returns of Supply Chain Software

  2. Pingback: The False Dichotomy of SAP DP or Spreadsheets

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s