How SAP’s TCO Compares for SAP APO Production Planning

What This Article Covers

  • Background and Motivation for the Research.
  • The Basis for the Estimation.
  • The Scope of the Analysis in to Software and Software Companies.
  • Why the Best of Breed Comparison Vendor is not Named.
  • Why SAP License Costs are Set to Zero.
  • Analysis Assumptions.
  • The TCO Spreadsheet.
  • Why Integration is Overrated as a Cost.
  • ROI Implications of this Analysis.
  • Outsourced Support to Reduce SAP Costs?

TCOBestofBreed

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. This is the primary approach of the major consulting firms. that 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 the costs of maintaining SAP 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 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 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 any one 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 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 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 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 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 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. 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.

TCO Spreadsheet

This TCO analysis has been permanently moved to SoftwareDecision.org. Since this article was first published, Software Decisions now performs all TCO analysis and TCO analysis has been moved from the SCM Focus site.

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.

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, 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.

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 are 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 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. 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 on the basis of 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.

Conclusion

SAP and the major consulting firms have fantasy numbers with respect to 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, its critical to make the TCO estimates 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 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.

References

CONSTRAINED

Constrained Supply and Production Planning in SAP APO

How Constrained Supply and Production Planning Works

Constraint-based planning generates something that is appealing to all manufacturers: a feasible supply and production plan. However, constraint-based planning software was first implemented over twenty years ago, and yet few companies (as a percentage that all that have tried) have mastered constraint-based planning.

Getting the Real Story

This book provides the background information, detailed explanations, step-by-step examples, and real-life scenarios to assist a company in becoming proficient at constraint-based planning, along with valuable information about what SAP APO can do for supply and production planning in reality, rather than just in theory. Here you will learn about resources-the mechanism for constraining the plan in APO and for determining the feasibility of the plan-and how constrained supply and production planning work together (and how they don’t).
In addition, this book talks about constraint-based planning at the supplier level: can a vendor’s production be capacity-constrained?
By reading this book, you will learn:
  • The different resources available in APO, how production resources differ from supply planning resources, and the role resources and other important 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 backwards and forwards 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.

Chapters

  • 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
    Production Planning
  • Chapter 8: Conclusion

Comments are closed