- Companies normally implement too much SAP complexity.
- We use examples from SAP ECC and SAP APO where companies implement too much functionality.
It is a common thing for SAP implementations to be overrun with complexity. But there is such a thing as an appropriate level of complexity. That is a level of complexity that the overall implementing company and those that work at the implementing company can absorb.
SAP ECC and SAP APO as Examples
SAP ECC is well known to be one of the largest bundles of functionality that one can buy in an application. However, SAP normally stuffs all of its applications with large amounts of functionality. SAP APO has an enormous functionality footprint. However, one could argue that there is too much in SAP APO.
Advanced functionality is a double-edged sword because if the advanced functionality is not properly implemented, then the customer is worse off versus having used a simpler approach.
There are options to use easier or more advanced functionality in all of the APO modules, and I routinely recommend to clients that they start off with the less complex functionality. However, everyone seems to like the new “new sexy” even if they lack the internal resources to pull the implementation off.
SAP is different than other software vendors in that the functionality has a higher variability in quality than in other vendors. Therefore testing and picking the functionality to be used is more important than in any other software vendor I have analyzed.
Yet, many factors work against taking this more scientific approach.
Incentives to Choose the Sexy Over the Practical Functionality
The number of entities pushing towards less practical implementations is quite significant.
- Consultants who are external to the company like to push the most complex solutions as it most often means the most consulting dollars.
- Many internal IT employees want to put the most sophisticated and complicated methods on their resume so that they will be more marketable.
- Executives decision makers tend to be optimists, so the brew is created for implementing too much complexity.
Example From the Field
I recently consulted with a company that had never been able to get MRP work and instead used the ERP systems to “record” what they had done rather than plan anything in advance. MRP is the simplest form of supply planning.
This same company decided to go forward with an implementation of SNP, which is a more advanced form of supply planning, and unsurprisingly they bombed the implementation.
Injecting Reality into IT Decision Making
When reading books or articles that explain a functionality I notice that there is a clear orientation to describe the functionality only in terms of its benefits. However, nearly all functionality implies some type of overhead, and a company can only activate so many areas of functionality within an application because there are limited resources on projects, and planners and planning departments have a limited capacity to learn and apply various functionality.
I was recently reading a book on SAP APO, and in the book one area of esoteric and difficult to configure functionality was trotted out after another, and I began thinking
“The author can’t possibly believe that clients will be able to implement most of these can he?”
Of course, that is the problem when an author also works for SAP, and the book is treated as much as a sales device as it is a mechanism to explain how to use SAP software. In SAP consulting /implementation is entirely subordinate to sales and marketing. This is the problem with software vendors that are under the heavy pressure of continually making earnings numbers — it moves most of the power in the organization to those that can make the short-term numbers.
What is the Maximum Tolerable Functionality?
This “maximum tolerable functionality” level is quite evident when one reviews APO implementations that have been live for years. In every case that I have reviewed, the company implemented some functionality that they were unable to maintain, and thus the functionality fell into disuse or was no longer active in the solution at the time I did the review.
Misperceptions About SAP’s Functionality
This is a problem I run into quite a bit at clients. Clients sometimes hire on a consultant to try to see if they can get SAP APO to do something they have not yet been able to get it to do. This request typically goes in two different directions:
- In many cases, a company is simply attempting to enlarge its use of the application and to configure areas that have not yet been configured, that were skipped during the initial implementation due to time constraints. In these cases, the company’s attempt to get more from SAP may work out.
- In other cases, a company is bringing in someone new to attempt to get functionality working that has already had several people look at it, that has already had OSS notes opened for it, and has been researched, but the people who have worked in it have run into a software limitation. In this case, it’s rare that a new person comes along and gets it to work because it is software, not knowledge related.
The problem I often run into is that several attempts have been made to get the APO, or the BW, or CRM, or PLM, etc.. to do something, and the actual issue is that SAP’s module is just not either very good at it, or the functionality that is promised is simply defective. At a recent client when I recommended an alternate solution that was a high fit with the company’s requirements, I was told that “we want to make sure we are getting the most out of SAP.”
- PP/DS lacks the functionality for process industry manufacturing
- DP has not had real consensus collaborative forecasting functionality
- DP does not manage attributes or perform top-down forecasting very well.
- DP cannot optimize forecast parameters (Alpha, Beta, and Gamma) except during the best fit procedure, but almost no one runs the best fit in production.
- SNP does not perform inventory optimization
- SNP does not fair share the way companies want unless the stars and dates align
Many parts of SAP do not work as clients think they do. That is simply a fact, clients have a hard time accepting it, but that is the truth of the matter, and I have extensively documented some of the areas that I have run into that do not work as advertised in various articles in sub-blogs at scmfocus.com. I often deal with clients post-go-live, and the perspective post-implementation looks a lot different than when all the promises are being made at the beginning of the implementation. At the end of the implementation and years into using the application, all that is really left is bringing in SAP Platinum Consultants, who most often cannot solve the issue, or develop some convenient excuse as to why the promised functionality should not have to work in the client environment. This can lead to seemingly endless recursive conversations with a person with little SAP knowledge, assigned to the SAP OSS Note system, who has difficulty writing or understanding English. It’s quite depressing actually.
What to Do?
There are so many things that SAP SCM (and BW, CRM, PLM, etc..) does not do, that it’s important to recognize that and learn on applications that can actually perform the necessary functionality. Trying to get more out of SAP, can often mean not getting the business requirements met, but spending quite a lot of money recursively trying to get SAP to do something, that another best of breed vendor can do in its sleep (all of the examples listed above can be provided without issue by best of breed vendors). Using a best of breed vendor to augment a solution does not mean pulling out the original solution.
Implementations can be made more successful by implementing the simpler functionality. This means listening less to advisors who all have financial incentives to recommend the more complexity.
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 SAP Project Management Content
I cover more details of how to reduce project risk in the following book.
Enterprise Software Risk Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model