- 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.
Understanding the Presentation of SAP Best Practices
It’s important to understand how SAP presents best practices to client. To enhance this understanding here are some screenshots from SAP’s own presentations. I was actually was very surprised in what I found from this presentation because what is presented here by SAP has no relationship to what actually occurs on SAP implementations.
Here you can see SAP proposing that SAP best practices can reduce the adjustments necessary to the software. In an implementation, a company brings its requirements, and then those that the software cannot meet are either removed from scope, or they are accommodated with an enhancement or by buying another application (SAP never recommends the second option, which is buying another application, but nearly always pushes the client in the direction of an enhancement, and enhancement that is written in ABAP, even though in many cases a non-SAP coding platform may be better.
Not Doing A Proper Software Selection
The presentation of SAP best practices is a method for SAP sales to lull their potential clients into not performing a thorough comparison of their business requirements versus what SAP software can do, versus what competing applications can do. I have written on many occasions that the enterprise software market is very inefficient with most companies selecting the wrong software for their needs and I described for demand planning software in this article. One reason for this is that companies do not perform a thorough software selection, and another reason is that they rely upon biased and corrupt consulting companies like Accenture or IBM that have long-standing relationships with vendors that they recommend to clients no matter what the fit is with the client’s requirements. This is why large consulting companies are incapable of performing an honest software selection as I described in this article.
In essence, what SAP is doing is asking its potential clients to forget doing a proper comparison of different enterprise software, and simply trust their statement that all the best practices exist in SAP in any case, “so what the point of actually performing a software selection?”
SAP Best Practices and SAP’s Marketing Machine
On some projects, through the years I have noticed the term “SAP best practices” used by SAP quite frequently. In the beginning, It always struck me as a bit curious, but on the other hand, I never gave it much thought. But only after speaking with a person who analyzes SAP software as well as other vendors did I realized that this is nothing supporting the SAP best practices concept. It is a canard. As I describe in this post, SAP has what I think is the world’s greatest enterprise marketing machine. SAP best practices are part of its strategy for business development. SAP has some marketing concepts that they use for business development to gain, keep and maintain market clients in the marketplace. Best practice is one of these. It’s important to understand that SAP marketing messages work not only to get SAP clients, but also to control the interpretation of their software during implementation and after a go live. However, later on in this article, I will show that SAP is both not based upon best practices, and secondly, in SAP’s documentation, they are confused as to what a best practice is.
How The Term Best Practices is Misused by Large Consulting Firms
SAP is not the only company that uses the term as a marketing construct and for business development. Large consulting firm consultants also like to use the term and use it in a way that is almost always misleading. I once worked as a consultant at IBM who created a custom fix for a safety stock problem in a way that was a worst practice, and then proposed that weekly delivery frequency was “best practice.” This is somewhat amusing as this consultant was so technical he was almost a development resource, and would not know a best practice if it hit him in the head. This is, in fact, my view of most of the IBM consultants that I have met that work in IBM’s SAP practice. IBM consultants in their SAP practice do have good technical skills, but they are essentially lying to clients when it comes to their business knowledge.
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. The only best practices that the client received were made up ones to obtain buy-in on decisions the consultant wanted to go his way. They had nothing to do with a large data sample of companies that showed that one way of doing something was superior to another.
The concept behind best practices is that there is one best way of doing something. That is if a user creates and interacts with a purchase order in a system, there is one best way to view, manage and process that purchase order. SAP claims that their software is built around best practices because they are so large that they can say they have “standardized” their software on the best practice.
The concept is used in multiple ways on accounts:
- To initially sell the software.
- To control the implementation process to guide the client into using the SAP way of doing things.
- To shut down dissension on the part of users.
- To prevent executives from actually analyzing the underlying reasons why users are unhappy with the implementation.
How SAP Uses the Concept of Best Practices
I suppose I don’t spend enough time listening or reading to SAP’s marketing message because it took a conversation with an industry analyst to have it explained to me that SAP hides behind the concept of best practices to defend weaknesses in their software. The basic strategy is that SAP prepares their executives up for complaints about their software by priming their executives to think that any complaints are because the users are resisting the best practices that are in the software. The sentence may be “You may receive push back on the system, but that is a change management issue because your employees are resisting the best practices that are in the software.”
Is SAP in Fact 100% Built on Best Practices? 50%?
The truth is that while there might be some standard processing in parts of SAP software that are in fact best practices, by in large the concept is significantly over-applied, and ends up being somewhat of an excuse by SAP to fend off criticism. The question should be, what evidence is ever presented that SAP software only contains best practices? The answer is that no evidence ever is usually provided, at least when the claim is made orally, which is where it ends in most circumstances. However, you can find several SAP resources on best practices. I have entered a screenshot below of best practices.
As you can see, SAP claims that because they are so big, they have all best practices included. Secondly, they propose that customers who use best practices have been able to reduce consulting by 50% and reduce mistakes. However, wait one second, aren’t best practices naturally inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? Secondly, SAP implementations are the most expensive implementations on the planet. If one is looking to reduce consulting time or expenses, SAP would be the absolute wrong solution. It brings up the question “what exactly are best practices in SAP?” Here is another screenshot on the topic of best practices.
Here you can see that now SAP is classifying best practices as a toolset made up of instructions, pre-configuration, sample master data. But let us back up a few steps here. What do best practices have to do with the master data? Best practices are supposed to be business process functionality that is baked into the system. Master data should be kept up to date, and validated with the business, however, this is not something you can bake into the application unless you mean making the software transparent and easy to use, but in that case you are enabling a best practice, you are not, in fact, modeling a best practice yourself.
Overall, this seems more like a jumpstart toolkit. The paragraph goes on to say that there is a NetWeaver component to best practices. However, how can this be? NetWeaver is essentially the infrastructure components of SAP (PI, ABAP, Basis), so what do these have to do with business process functionality best practices? If by best practice SAP means ease of use or sustainable infrastructure tools, then SAP products are a worst practice, because of all the infrastructure I have worked with, it takes SAP the longest to do the most basic things. Also, one questions how serious SAP is about their NetWeaver best practices are because all of their links to supporting content on this page are broken.
The answer to this is that SAP just does not know, and are confusing them. They like to use the term liberally, but they use it in so many ways their usage is not consistent with the term’s meaning. They started off saying one thing with best practices, a statement which was originally false even in that instance, and then their product management could not control themselves, and they just began applying the terminology to a variety of initiatives just for the fun of it.
Interestingly such unsubstantiated statements are quite common either in SAP or outside of SAP. This is demonstrated by the following quotation.
“A few years ago I had a meeting with a marketing director of a well-known consumer goods brand who proudly told me about the world-class stage-gate product process they had introduced. How many successful new products have you launched as a result of this process, I asked? Well, none, he replied, but the process is world-class, he insisted.” – Dr. Ken Hudson
Clearly, if you want to make something sound tantalizing, but you have zero evidence that it is, in fact, beneficial in any way, simply give it some generalized positive label — best practice, world-class, best-in-class, super-duper — the choice is yours. As a large portion of the business community is unthinking zombies, the technique is amazingly effective in almost any domain.
SAP Best Practices on a Project
SAP will want to continue this position on the actual project however, it is untenable. The client resources will eventually figure out that SAP just has normal functionality in its applications, and that it is not based upon best practices. The SAP consultants like me will then be asked to show how SAP functionality is a best practice and I can’t because it isn’t. The presentation that companies should adjust all of their business processes and just do what SAP can do is not a workable solution on a project, it only works during the illusory or the sales portion of the interaction.
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-configuration 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 finishes 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 passed 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 difficult 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 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 firms 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?
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 definition 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 that are described by SAP should be categorized as a sales technique. They have little 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. Best practices are all over SAP sales literature as I described in this article, and are used very frequently by consulting companies, but on actual projects, they mean very little.
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’s software, and second, its 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. The vendors that are more honest about this setup their software to be flexible enough to do things some different ways, but then use their consulting resources to figure out the best way for the particular client. SAP cannot follow this approach because the software design is inherently inflexible, and thus the need for the brilliant sleight of hand known as “SAP best practices.” What “best practices” actually means is that SAP is right. That the way SAP has designed their system is the best way and other ways are wrong. And clients, for the most part, buy this, and consultants have adopted the concept of “best practices,” because it reduces their necessity to present any evidence.
Instead of being hypnotized and distracted by the term best practices, companies should instead get into the details of what software can do and what it cannot do. Secondly, it needs to match that analysis with what the company wants to do. Looking to software vendors to tell you to want to do is a mistake. Your business needs to know what it wants to do, and if they are following poor practices, then need to hire the right people, or bring in the right external business expertise to improve these processes.
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 successfully selling its software and has significant brand recognition.
The Problem: A Lack of Fact-Checking of SAP
There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.
Being Part of the Solution: What to Do About Leonardo
We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. When SAP or their consulting firm are asked to explain these discrepancies, we have found that they further lie to the customer/client and often turn the issue around on the account, as we covered in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised.
If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.
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.
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