- SAP uses the false assumptions of best practices to control accounts.
- Best practices assumptions damage the project from beginning to end.
SAP lists best practices in several areas on its website. I have included the following screenshot of best practices from this web page.
Here, SAP claims that because they are so big, all best practices are included in their software. Secondly, they propose that customers who use best practices have been able to reduce consulting costs by 50 percent and reduce mistakes.
But, wait one second; aren’t best practices simply inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? What constitutes a best practice implementation? This is all extremely confusing, as well as logically inconsistent.
SAP’s Confusion on the Topic of Best Practices
It brings up the question “what exactly are best practices in SAP?” Here is another quotation on the topic of best practices.
“SAP Best Practices Based Upon Netweaver—SAP Best Practices provide a toolset that helps IT and functional project team members to quickly deploy functionality in SAP solutions—from SAPNetWeaver, to core SAP applications. The toolset comprises a mix of step-by-step instructions, preconfi guration, sample master data, code samples (where applicable) and end-user training—organized by technical or business scenarios that you might want to implement in your landscape. Below you will find the SAP Best Practice versions that support the implementation of SAP NetWeaver components.” — SAP
In this quotation, SAP classifies best practices as a toolset or accelerator made up of instructions, pre-confi guration and sample master data. But let’s back up a few steps here and take just one example. What do best practices have to do with the master data samples? Best practices are supposed to be business process functionality that is in the system naturally. Master data should be kept up to date and validated with the business, which I suppose could be said to be a best practice; this is not something you can bake into the application unless you mean to make the software transparent and easy to use. In that case you are enabling a best practice; you are not modeling a best practice yourself. Overall, SAP’s best practice seems more like a jumpstart toolkit that contains a combination of things that are best practices. The paragraph goes on to say that there is a NetWeaver component to best practices.
How can this be?
NetWeaver is comprised of the infrastructure components of SAP, so what do these have to do with business process functionality best practices? I suppose one could say that their infrastructure follows best practices, with the business, software, toolkits and infrastructure software all based upon best practices. SAP hammers away at this theme throughout their documentation, but because they apply it to everything they do, it begins to sound like unsupported conjecture— and that is the best-case scenario.
Confusion on Best Practices by SAP
The worst-case scenario is that SAP employs marketers who can’t keep their story straight and have limited English and logic foundations. Also one questions how serious SAP is about their NetWeaver best practices because, when I reviewed this material, all of their links to supporting content on the web page were broken.
The answer to these questions?
SAP just does not know; they are confused themselves as to how to use the term “best practices.” SAP simply smears the term, like cream cheese on a bagel, on almost everything they do. With SAP, simply calling standard SAP documentation a “best practice” will somehow (magically) allow projects to go live much more quickly. In this case a best practice is an incantation. It’s difficult to take a vendor seriously when they are so undisciplined as to the use of their terminology. SAP fi nishes off the proposal by declaring that best practices enable SAP implementations to go live in 4.2 months. This is not true; in all my years working with SAP I have never seen any SAP module go live in 4.2 months. This is another problem with credibility: SAP implementations are measured in years—not months—and anyone who works in SAP knows this. So where is this number coming from, and what module is SAP talking about? Where is the evidence for this? No evidence is ever presented.
The Negative Effect of Best Practice Claims on Projects
If only best practice claims ended when the software was sold, that would be one thing; however, the conversations regarding best practices pass from sales to the consultants who are supposed to make good on these claims during the implementation. When you repeatedly tell a customer that they will get best practices in every dimension if they buy your software, unfortunately they don’t forget this. As with any promise that can’t be fulfilled, SAP consultants are put in a diffi cult position. I would know—I have been one of these consultants. On many of my projects, the term “best practice” becomes a punch line. The individuals in the implementing company come to realize that there is no such thing as best practices. Jokes such as, “But wait…it’s okay because it has best practices,” or, “All we need on this project is just more best practices!” are quite common. Because the marketing and salespeople don’t actually work on projects or with software, they do not know this. After realizing that they had been bamboozled by SAP Sales (accompanied by a healthy dose of cynicism about best practices), I heard senior members of my client declare, “We don’t want to hear anything more about best practices.” In the implementation phase, best practices lose all credibility.
Non-ERP Uses of the Term “Best Practices”
SAP is certainly not the only company that uses the term “best practices” as a marketing construct for the purposes of business development. Consultants from large consulting fi rms also like to use the term, and use it in a way that is almost always misleading. I once worked with a consultant who created a custom adjustment for a safety stock problem in a way that was completely inadvisable: I would consider it to be a worst practice. He then proposed that weekly delivery frequency was best practice. He essentially suggested that any technique that he wanted to employ was a best practice. On this project, I learned that twice-a-week delivery was a best practice; who knew that how frequently a product is delivered could be a best practice? It isn’t. Consulting companies are constantly using the term “best practices” to sell work. However, as with best practice claims made by ERP vendors, no evidence exists that what the consultants promote as a best practice is, in fact, that and this is because they have no evidence; it’s an opinion. It’s one thing to say that this or that is one’s opinion from experience. But it’s something else to gusset up this opinion as a best practice—with zero evidence—simply because one would like to have their opinion carry more weight. It is also common to hear from the client that the consulting company did not seem to offer best practices once they were on the project. The reason is simple enough: once one gets into the details of the actual recommendation, they look a whole lot less like “best practices” than they did from a distance.
Criticizing Pre-existing Systems
Best practices have been very useful to ERP vendors as a way of giving them permission to criticize a potential customer’s pre-existing systems. Sales and marketing is about changing perceptions to encourage a purchasing decision. One way of doing this is to increase the purported virtues of the item to be purchased (in this case, the ERP system). Another way is to lower the perceived value of the customer’s current item. Using the term “legacy” to describe all previous systems, and the term “best practices” to describe ERP systems, is highly effective and an impressive feat of rhetoric because it ignores the important fact that the legacy system had been customized for the business requirements, while the ERP system had not. Essentially ERP vendors appealed to a central concept: how things are done in other organizations must be better than how things are done in the potential customer’s company. This is a reversal of the “not invented here,” philosophy which proposes, “anything not invented here.” This is explained in the following quotation:
“ ‘Don’t assume newer is necessarily better,’ advised Project Manager Ellen Harmon of the Washington State Community and Technical Colleges Center for Information Services. Harmon considers her existing legacy system to be just another, older ERP. ‘We actually have an ERP that has been developed over the last 18 to 20 years for specifi c clients, and because of that, this ERP is very focused on these particular client needs.’ The case is the same at other universities.‘Their legacy systems have been developed to meet their specific needs and are tailored to their environment,’ said Harmon. ‘An ERP vendor might say your system is old, and therefore is bad, and we will sell you this new system. But it is a legacy system, too.’ ” — Promise of ERP System
This quotation brings up an interesting question: what is the defi nition of “legacy”? An ERP vendor may be selling a system that has an older code base than the “legacy” system it is replacing. Interestingly, the designs of many of the ERP applications sold today are extremely dated, and yet they are never referred to as “legacy.” To a software salesman, other people’s systems are legacy, but your systems are never legacy. One might ask why this is the case. The reason is not hard to determine. “Legacy” is a term of propaganda that is applied to systems that the designator would prefer to denigrate as a pretext for proposing another system. If you work in ERP Sales, then all pre-existing systems in the companies to which you would like to sell your ERP software are legacy. The ERP system you are selling—no matter how dated—is never referred to as legacy. Therefore the term “legacy” has two meanings: the actual definition (“an old method, technology, computer system or application program”) and the real meaning—any system that you would like to replace. However, many decision makers missed an important detail of infrastructure technology management, as explained in the following quotation:
“IT analysts estimate that the cost to replace business logic is about fi ve times that of reuse, and that’s not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits—they always have, and they always will. New software may increase the risk of system failures and security breaches.” — Wikipedia
Many companies relearned this fact about computer systems. Many of the cost overruns of ERP systems were related to replacing business logic.
Best practices have been a deep well that ERP vendors have repeatedly drawn from in order to support multiple objectives. ERP vendors do not attempt to hire professional researchers to validate their claims regarding best practices because a) most of what they are proposing is simply how their software works—and is not a best practice, and b) customers generally don’t question the best practice claims made by ERP vendors. Generally all that is needed to convince companies that a software vendor has best practices is if the software vendor has marketing documentation that declares the existence of best practices, and if that software vendor is generally successful selling its software and has signifi cant brand recognition.
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.
The Real Story on ERP
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion