How SAP Uses Best Practices to Control the Implementation

Executive Summary

  • SAP uses the false assumptions of best practices to control accounts.
  • Best practices assumptions damage the project from beginning to end.

Introduction

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 its customers.

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).

This is the text which accompanies the slide above:

SAP Best Practices are packages that provide preconfigured business processes and project accelerators to streamline customer implementations. – SAP

A best practice is not anything that is described above, instead, it is functionality in the software that is supposed to be the best way to perform a business process. This sentence is very concerning because firstly best practice functionality is not really provided by SAP, but this sentence implies that there are other things that SAP provides to their clients that are not part of the software that are also best practices. It makes me wonder how much time people in sales in SAP actually spend in the software they are selling.

All vendors offer documentation and guides for how to implement their software. However, they are generally not called “best practices.” Again, best practices are supposed to be contained in the software themselves, they are not the manuals for the company. SAP is defining best practices so broadly here, that it appears that everything they offer is a best practice, and nothing is not a best practice. They list automated tools on this slide, which again, I have never seen on a project. Finally, they finish off with a graphic of a box. So now SAP best practices is something you can pick up and take with you on your projects I suppose.

This looks interesting, but again I have never seen any of these things on an actual project. I would be concerned if this is presented to a client, and then as an implementor, I am expected to gain all these benefits from “Solution Builder” when in fact it will not even be used on a project. SAP is actually very time-consuming to configure and is the most challenging system to configure that I have worked with. However, this messaging is misrepresenting how difficult it is to configure SAP, and proposing these solutions will greatly ease my task. This is consistent with much of SAP’s messaging, that SAP is amazingly easy to put in, and already has most of your business process or something even better (best practices) already in the application. This is simply delusional. People that write these things need to actually spend some time on an SAP project.

This slide shows three things I am supposed to be able to leverage to improve the implementation. One is the Solution Builder, the next is the Implementation Assistant, the final one is the Building Block Builder.

I have never seen any of these tools on a single project I have worked on.

The average implementation time for an SAP project is now 4.2 month?

That is interesting.

I should note that this study goes back to 2006, 2007 and 2004. Therefore it cannot be that my information is out of date. I don’t see SAP projects going live faster than a year, and I arrive on many projects where the module has been live for several years and is still not delivering very much value because it was either a poor choice for the business or because it was never configured properly in the first place. These numbers are completely made up. Before I read this presentation, I was not even aware that all of these best practice accelerators were even used on projects, that is how little consequence “best practices” that are described in this presentation have on actual SAP implementations.

The individuals who made this presentation are not living in reality, and are not talking to or listening to the people inside of SAP that actually implement software. The presentations were clearly developed from a marketing angle, but it is so divorced from reality that it crosses the line into fiction. In some ways, the presentation serves as a comedic document, but in reality, the document is not that amusing because companies may read this information and think there is some truth to it. Then when they actually implement, people like me will have to explain why none of the information contained in the document is true. This is a constant issue with sales and marketing departments, in that they are constantly disseminating false information that then has to eventually be contradicted by people who did not disseminate the false information to begin with. When that happens, marketing and sales is nowhere to be found and is often retelling the same false story to new customers.

We cover this problem in more detail in the article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.  

Not Performing 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. When you ask SAP consultants about SAP functionality, they are very careful to always position SAP as the default choice. Any critique about the ineffectiveness of the functionality of SAP applications is met with the benefits of integration to SAP.

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 Why Companies Select the Wrong Demand Planning Systems. 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 the article Why Big Consulting Firms Cannot Do Software Selection.

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. 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 business 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.

After working with IBM on several occasions I can say with confidence that their best practices are fake.

Best Practices as a Legitimate Concept?

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:

  1. To initially sell the software.
  2. To control the implementation process to guide the client into using the SAP way of doing things.
  3. To shut down dissension on the part of users.
  4. To prevent executives from actually analyzing the underlying reasons why users are unhappy with the implementation.

What is unknown by most of the population is that the concept of best practices has been thoroughly analyzed in academic research, and found to be invalid.

Fake Best Practices

Best practices sound suspiciously like something that one is asked to take on faith— and they are. Eugene Bardach, a professor of public policy, analyzed claims of best practices in his field and found that best practices are not based upon research.

“Appearances can be very deceiving. On closer inspection, it often turns out that the supposedly ‘good’ practice is not solving the problem at all. Inadequate measurement plus someone’s rose-colored glasses were simply producing the illusion of mitigating the problem. It may also turn out that, even if good effects have truly occurred, the allegedly ‘good’ practice had little or nothing to do with producing them.”

The further one gets from actual implementation, and the less experienced one has with working with software, the more likely one is to believe that software can encapsulate best practices. Because the term “best practices” is so general, it does read a book on the topic of dishonest argumentation, this is a good indicator that something is wrong with the information that is being researched.

Another topic is related to the overall idea of best practices.

At first sight, the logic of best practices as propagated by consultancies seems irresistible: by copying practices of the worldwide mose successful companies, drawing on consultants’ experiences, one can improve one’s performance. However, some authors warn that the practice of implementing best practices is not as easy as consultants insinuate. Thus, Sandal argues that “one of the most pervasive and damaging follower afflictions that has increasingly infested corporate psychology is a disease known as best practicism. He attributes the causes of this disease to a number of erroneous beliefs, among them the belief that best practices are easier and less risky and the belief that the best practices can easily be transferred from one company to another. In a similar vein, Wareham and Gerrits question whether best practices remain best practices when transferred to another context.

Considering the problems in identifying best practices and in transferring them it is somewhat astonishing that best practices are given such a prominent role in consultancies’ communication. – Trading “Best Practices” – A Good Practice?, Industrial and Corporate Change

The Car Versus Truck Best Practice Example

Let’s take the example of two automobiles: one sedan and one truck. I currently own a Honda Accord but have been thinking of buying a four-wheel drive Toyota Tundra. These are two very different automobiles built for different purposes. Both score very well in reliability, which I consider a best practice; that is, I prefer high-quality cars that require infrequent repairs. However, could the fact that they both use an internal combustion engine and pneumatic tires be considered best practices? These are two of the most important inventions in human history, so I suppose I would not object to calling them best practices. But on the other hand, every car I look at offers the same thing, so while they are best practices, they are not differentiators. Am I interested in comparing best practices that are not differentiators? I would say probably not. The Toyota has four-wheel drive, which can be a best practice if you intend to take the car off-road, but is an unnecessary and extravagant option if one does not intend to use the vehicle in this manner. Four-wheel drive decreases gas mileage after all, and the knobby tires required to go off-road, ride roughly on a paved road. So should I sell my Honda and buy the Toyota? Well, there are a number of factors, such as how much I will be using the vehicle for commuting versus taking my jet ski to the lake and going camping.

The vehicle’s benefits to me change depending upon the situation. There are some best practices, such as reliability, that are important to me but may be less important to other people. For instance, neither of these are particularly stylish. However, the Land Rover is very stylish and has the best practice of four-wheel drive. If anyone has ever sat inside of a Land Rover with a leather interior, I think we can agree that their interiors are a best practice (that is, they feel very nice). In order to get the stylish ride, one has to pay a great deal more and give up the Japanese reliability for English reliability.

So how do I decide on my vehicle with all these competing best practices?

I hope I have shown that there is a reason that people don’t take the concept of best practices to buying an automobile, or really to any other purchasing decision, and this is because the concept is ridiculous. People look for a series of trade-offs in characteristics until they find a desirable compromise, and then make their purchase decision. It does not happen now, and will not happen in the future, that your friend will announce that he based his new car purchasing decision on best practices.

Best Practices in Which Software?

I used the example of cars because most everyone has at some point made a decision to purchase a car and because cars are relatively easy to understand. However, the concept of best practices is equally unhelpful and even problematic in making distinctions between things that we do not know as well. As my expertise is supply chain software, I know that making supply chain software decisions based upon best practices does not make any sense. This is elementary for me because I have spent more than a decade and a half analyzing and configuring supply chain software and work with it almost every day. However, because I don’t know much about accounting software, if someone were to propose that accounting software can be purchased based upon best practices, it would seem to me to be a tenable statement, but only because I do not have the content expertise to truly analyze the claim. Certainly, there are things that are desirable in accounting software that could be deemed “best practices.” For instance, it is desirable that the program post the actual quantities entered into the database, rather than using a random number generator. It is desirable that the program not crash and delete the last five hundred accounting entries. However, once we get past the rather banal areas of functionality, there will be considerable debate as to what are best practices.

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 something akin to the following:

“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.”

In this way, SAP’s software deficiencies are deflected back on the user.

Is SAP in Fact 100% Built on Best Practices? 50%?

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.

“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, pre configuration, 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

Best Practices in……Master Data?

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 based upon worst practices, 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.

World Class = Best Practices = Digital Transformation?

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.

Ahh, the new term for his is digital transformation, a term as meaningless as best practices as we cover in the article The Problem with the Term Digital Transformation.

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?

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 — which is another technique SAP uses that we cover in the article How SAP Used and Abused the Term Legacy, 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.

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 have 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. 

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 put 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.

Conclusion

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. Best practices are all over SAP sales literature as I described in this An Analysis of SAP’s Messaging on Best Practices, 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.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

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 Other SAP Consulting Firm Management Content

References

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

Wellstein, Benjamin., Kieser, Alfred., Trading “Best Practices” – A Good Practice?, Industrial and Corporate Change. Jun 1, 20122.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

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.

Chapters

  • 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