The Evidence for SAP Best Practices Claims

What This Article Covers

  • How SAP uses the Term “SAP Best Practices?”
  • The Evidence that SAP Software is Not in Fact Best Practice in many Areas
  • Best Practices as a False Construct

Are best practices always in SAP software. 

Considering the SAP Best Practices Claims in Light of Their Actual Software R&D

I have worked in SAP APO since 2002 and never found anything in APO that did not exist in other vendors before SAP putting it into APO. Cost optimization, allocation, the statistical forecasting methods used by DP, in fact, everything in all the modules has been adopted by other vendors. However, if we broaden out the search for novel functionality to ERP, we can see that MRP and DRP were well established before SAP adopted them. There is nothing new in SAP BW either. In fact, SAP is one of the few vendors that partner with smaller software companies so they can specifically both co-opt their technology and build their products from it. So SAP has copied its functionality from everywhere.

However, I don’t think that is what SAP means when they refer to best practices.

Evidence That SAP Software Is Not Based on Best Practices

It’s clear that SAP primarily relied upon its customer base to justify best practice claims. Secondly, there are many areas of SAP that I am aware of that are not best practices. Here are some examples:

  1. SAP APO SPP uses DRP functionality to perform something called inventory balancing. However, DRP is no longer the best approach to performing this business process. The best practice is to use multi-echelon functionality. DRP plans all facilities as if they are independent of one another, which is a less accurate method of planning, and not an accurate reflection of reality. However, the problem is that SAP APO does not have it, while several best of breed vendors do.
  2. SAP APO DP has very few examples of implementations using the characteristic based planning functionality. This is because it is so difficult to configure that it almost never is. It is also very weak in attribute forecasting. It is so infrequently used that one could question if DP is an attribute-based forecasting tool. I have used an application called Demand Works Smoothie that allows the entry of attributes into different columns in an import spreadsheet or database table. This allows for extremely easy to change attributes, something that is unheard of in SAP APO DP.
  3. SAP APO SNP only has one method by which to use service level to control stocking levels, which is dynamic safety stock. However, that is no longer the best practice. The best practice is to us inventory optimization, which SAP does not have, but best of breed vendors do have.
  4. BW has neither the ability to quickly make changes to the underlying data structures to support changes in the business nor the ability to provide best practice analytics. SAP would probably say that they have fixed this issue with the purchase of Business Objects. However, Business Objects also lacks best practices in this regard compared to competitors such as Tableau. Secondly, SAP claimed to have a best practice data warehouse back when they only owned BW. So if they already had all the data warehouse best practices, then why did they buy Business Objects again?
  5. PP/DS uses cost-based optimization and heuristics for developing the plan. However, neither one of these approaches is a best practice currently. Cost based optimization has failed to find success as an effective way of performing production planning and scheduling, and heuristics while better than purely manual methods are of low average effectiveness. Currently, the best practice in production planning and detailed scheduling is performing time or duration based optimization. However, SAP lacks this functionality. Other vendors have moved ahead of them, and SAP is offering old less effective technology to its clients and pretending it’s on the leading edge.

These are just a sampling. The areas in which SAP software does not have best practices just goes on and on.

Best Practices as a False Construct

The idea that SAP contained best practices was never true. SAP often offered many ways to configure a system, so SAP contradicted itself as this would have to be called best practices, or multiple best practices per process. There are many ways of doing things that aren’t even very good practices much less “best.” My conclusion of SAP’s best practices is that they are just a marketing concept that looks good in powerpoint presentations. The less you know about SAP; the more best practices seem like they may exist in SAP.

The fundamental problem with the concept of best practices is there can be not final agreement as to what a best practice isn’t a best practice. Secondly, when SAP or any vendor for that matter declares that they have all the best practices, it must be understood that this is a self-bestowed title. Self-bestowed titles don’t have any meaning. It would be like me naming myself the best dancer in Atlanta. But at least there is some competition I could enter to prove such a thing. There is no best practices competition that is held and no official body that approves certain practices over other practices and names them “best.”

I am still waiting for the software vendor to advertise the fact that they only have the worst practices in their software.

Therefore, part of the reason that SAP used the term legacy was to criticize the existing systems of their customers and to do so without specifically analyzing any of them. And SAP’s solution?

Well, this is two-fold.

  1. In as many cases as possible simple eliminate the in-house software and move to SAP’s “best practices.” In SAP’s considered opinion, none of them were necessary as SAP’s software did everything correctly anyway, and anything the customer had come up with was the wrong way of doing it. This was true even if SAP did not have the specialized functionality that was developed over what was in many cases decades by the customer.
  2. Port all the logic from open programming languages to their ABAP programming language.

SAP gets our Golden Pinnochio Award for false claims with its repeated claims around best practices. 

Conclusion

SAP uses unsupported marketing concepts for business development in several major categories of their message to companies, but best practices might be the most effective. First of all the statement does not hold up against any analysis of SAP software, and second, it’s dangerous to assume that any software vendor is telling the truth regarding the idea that they have all the best ways of doing things already programmed into their business logic, so you don’t have to worry or question. Secondly, SAP is not clear as to what best practices are themselves and does not even take the time to keep the links on the topics updated.

Accessing Honest Information on SAP

  • Want honest information about SAP?

    We can help you independently verify the information provided by major consulting companies and answer your SAP questions. Our work together can remain confidential too.

    Just fill out the form below and we'll be in touch asap.

References

Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

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.

Chapters

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

http://help.sap.com/bp_dm604/BBlibrary/General/SAP_Best_Practices_overview_EN.pdf

Who is the Most Accurate Source on SAP?

Want to find out? See... A Study into The Accuracy of SAP

Leave a Reply 0 comments