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:
- 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.
- 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.
- 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.
- 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?
- 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.
- 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.
- 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.
The Truth of Best Practices in SAP
Best practices have been pitched as a central premise for SAP marketing efforts for some time. SAP is not the only company to do this. As I described in an earlier article, IBM, as well as many other consulting companies, present the idea of best practices, primarily as a way to get business and as a way to control the implementation.
“I once worked with a consultant at IBM who created a custom fix for a safety stock problem in a way that was really a worst practice, and then proposed that weekly delivery frequency was “best practice.” IBM also promised a large number of best practices from their “vault in Armonk,” however, one of the major complaints of the client is that IBM did not seem to offer any, even though this was a major focus of the overall sales presentation to the client.”
Therefore IBM consultants often use the term “best practices” to get their way on configuration decisions. However, IBM does not offer the best practices that it has supposedly picked up from all its experience to its clients, although IBM salespeople say that they do.
Who Makes These Best Practice Claims and Why?
Best practice claims are made by SAP Marketing and Sales. Best practices that are described by SAP should be categorized as a sales technique. They have no validity on an actual project. The way to evaluate enterprise software is whether it has specific functionality that addresses the needs or business requirements.
Using the term best practices simply interferes with this analysis and places a false schema on top of the analysis that needs to be done. SAP Sales and Marketing is now simply smearing the term, like cream cheese on a bagel on almost anything do with SAP, including calling standard SAP documentation a “best practice” that will somehow, (magically?) allow projects to go live much more quickly. The SAP presentation finishes off by declaring that best practice enable SAP implementations go live in 4.2 months, which is not only not the average, but in all my years working with SAP I have never seen any SAP module go live in 4.2 months anywhere at anytime.
The Effect of Best Practice Claims on Projects
Another problem is that SAP’s best practice claims puts SAP consultants in a difficult bind. This is true whenever one is asked to justify something which is untrue. SAP consultants arrive on projects with these enormous and false best practice claims placed on the software. The consultants are then forced to explain that one still has to gather requirements and determine what parts of the requirements can be covered by standard SAP functionality and which cannot. That is all of the best practice claims made by SAP sales and marketing do not change what must occur on the project.
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.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
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