How to Understand The Fake Integration Benefits for ERP

Executive Summary

  • ERP systems were sold based on reduced integration costs.
  • Learn how the ERP systems increased most integration costs.

Introduction

Enhanced integration was one of the major selling points of ERP. The hours of PowerPoint presentations that have been created since the first ERP systems were sold describe the great cost savings and integrative benefits that implementing companies would receive from a “solution” where all the main applications used the same database. One of the assumptions about purchasing an ERP system was that the buying company would implement all of the modules and decommission their current software. I discussed this briefly in a previous section. This oversimplified assumption was self-serving for the concept’s promoters, but not considerate of the buyer’s needs. The fact is, some of the company’s pre-existing applications could not be replaced by ERP, and for a variety of excellent reasons.

Here are two of the common scenarios in which companies that implemented ERP found themselves:

Scenario 1: When Companies Replaced All Pre-Existing Systems with ERP

In rare cases, companies eventually replaced every one of their existing systems with ERP, representing a perfect match with what the ERP salespeople proposed.

  1. Some companies that followed this approach paid far more than they had anticipated customizing the ERP application to replicate part of their current solutions.
  2. Some companies that followed this approach lost functionality and wished they had not gone 100 percent ERP, but could not go back once they had completed the switch.
  3. In some cases, they removed all existing systems and replaced them with ERP, and were happy with both the cost and the functionality that resulted from doing this.

Scenario 2: When Companies Replaced Some of the Pre-Existing Systems with ERP

In most cases, companies did not implement all of the modules that they had purchased.

  • General estimates are that an average of 60 percent of the modules was implemented, and 40 percent were unimplemented.
  • Other times, companies implemented all the modules but were unable to decommission pre-existing applications because those applications did something of value for the company, and it would have required too much work to customize their new ERP system.

Advantages of ERP Integration?

Contrary to most assumptions, ERP systems provide no advantages in terms of integration to other systems, and in fact, present several disadvantages:

  1. No Integration Advantage: ERP systems were not designed to integrate well with any other system, except for electronic data interchange (EDI). ERP vendors proposed that their systems integrated better with the other applications that they offered for sale. However, this contention is also dubious. Many applications sold by ERP vendors (Oracle is a good example) resulted from acquisitions. These applications have different heritages than the vendor’s ERP system. Oracle created adapters for these disparate applications, but their value is questionable.
  2. Low Quality and Uncompetitive Middleware: Even when the non-ERP vendor applications were developed internally (such as with SAP), the applications did not integrate very well. I have many years of experience integrating external planning systems to SAP, and contrary to what ERP vendors say, not as many of these applications integrate into the ERP system as what is led to believe. Part of the reason for this is that ERP vendors are not necessarily good at creating middleware (the software that connects other software). Some (such as SAP) are not at all skilled in creating integration applications of any type; they severely lag behind the best vendors in the middleware software category. Therefore, the customer ends up purchasing middleware by default from a company that is uncompetitive in that software category. I discuss this in the following articles that I wrote to inform companies that they were significantly underestimating the short-term and long-term effort involved to maintain the SAP ERP to SAP APO integration application called the “core interface” (CIF). The CIF is an SAP-to-SAP interface, but while it can be brought up quickly, it is so maintenance-intensive that over the long term, I debate whether it is better to develop an adapter from scratch in Why I No Longer Recommend Using the CIF.

ERP companies typically entirely exaggerate how much integration their systems provide. The following is an excellent example of this.

“As companies buy Oracle ERP Cloud, Oracle is seeing more companies attach other Oracle services, such as human capital management. Companies don’t have to buy Oracle HCM Cloud and Oracle Sales Cloud, since Oracle ERP Cloud integrates with cloud and on-premises applications from other providers. But companies see advantages in buying cloud applications from the same provider because those apps are designed to work together, eliminating the integration work that’s often required to weave together cloud services from different providers.” Oracle

This is a complete lie on the part of Oracle, but it is the type of lie frequently told to customers.

The Unfortunate History of ERP “Integration”

Here is a much more effective solution than I have described above: ERP vendors should never have been allowed to procure other vendors. They should not have created external applications, and instead should have published an integration standard and let the middleware vendors (those that were skilled at creating middleware) create the adapters. ERP companies had no interest in this solution. Instead, they intended to use their position at their customers to sell in more software. Often this software was poorly integrated and uncompetitive with best-of-breed applications (outside of just the ERP system). In this way, the ERP companies put their interests ahead of their customers’ interests, as explained in the quotation below.

“Of course, as soon as companies began buying these products, it became clear that enterprise software was another chunk—a much larger and better integrated chunk to be sure, but still a chunk—of software in a complex architecture of IT systems that desperately needed to talk to one another and exchange information. The vendors created clunky, proprietary methods of connecting their systems with others that have improved over the years, but that misses the point. The architecture of these systems, in a broad sense, was just like the ones that they were intended to save you from monolithic, highly integrated and difficult to change.“The high degree of integration envisioned in the R&D lab was tenuous at best inside most customers.”CIO

The Increased Need for Integration

ERP systems integrated some areas of functionality used by the company, but certainly not all things. And again, because most companies have so many applications, there is still a lot of integration work that needs to be done. A 2001 study found that ERP increased the need for integration.

“ERP technology does not offer an integrated solution but amplifies the need for integration.”ERP and Application Integration

ERP as a single architecture.

“Although ERP is touted as a single architecture, ERP applications usually contain different generations and sources of technology. Third-party applications are acquired and amalgamated into the platform, sometimes by name only. In total, this makes the environment complex for the customer and diffi cult to change over time. ERP suppliers have become system integrators. [emphasis added] The sheer size and number of applications makes moving all the applications forward a diffi cult task. Application functionality often lags.”ERP Alternatives

Short Term or Long Term Benefit?

In terms of ERP’s impact on application integration, companies did not see any immediate benefit. But was there a longer-term benefit? Unfortunately, after extensive searching, I was unable to find research data that compared what portion of the IT budget was consumed by application integration before and after ERP implementations. The shortage of research on this topic is particularly disturbing when one considers how confidently those who sold ERP systems predicted that integration costs would decline. However, findings in the study ERP and Application Integration are not promising.

“ERP technology does not offer an integrated solution but it amplifies the need for integration. Enterprises faced integration problems when they attempted to incorporate other applications with an ERP system. Only EDI applications were integrated successfully (81 percent) with ERP infrastructure. This high integration rate derives from the fact that EDI technology follows similar concepts to AI (application integration).”ERP and Application Integration

This shocking quotation states that ERP “amplifies the need for integration.”

But wait, how can that be the case?

It is because ERP applications are self-integrated, the problems that ERP systems have with interfacing with other systems is higher than the benefits derived from ERP’s self-integration. That is yet another amazing statement.

The quotation goes on to say as much.

“All observations discussed above indicate that ERP systems cannot be seen as a reliable solution to integration problems as ERP modules co-exist with other applications. Additionally, there is a need to integrate the ERP solutions with other applications. However, this incorporation causes serious problems, especially with companies.”ERP and Application Integration

ERP may have been a step forward for the integration of the ERP modules, but they were a major step backward for all other forms of integration. However, the only important measurement is total integration—not how much the integration effort was reduced for one application. It is important to consider that no study demonstrates that ERP systems reduce integration costs, and at least one study demonstrates that ERP increases integration costs. This exact statement may be used the next time you hear a person promote the integration benefits of ERP systems: ask him/her to produce the study that demonstrates this “well-known fact.”

Project Experiences with SAP ERP

My personal experience with SAP ERP is that it is a complicated system to write interfaces for, but this level of difficulty varies for each ERP vendor. SAP does not even export data in rows and columns but instead uses something called an intermediate document or IDOC. This is a hierarchical document, which is difficult to read, and time-consuming to write transformation scripts for which will convert the document into rows and columns. Unfortunately, IDOCs also change between versions of SAP, and a single movement of a character by one place can render the integration unusable and require a script rewrite. However, when these IDOCs are changed, it is often not communicated by SAP—so you find out when something breaks. Generally, others who work in SAP ERP integration tend to agree that SAP is difficult to integrate, although they will not go on record as saying so; if one wants to continue to work in an area, it’s better, of course, to keep silent. I did not perform an analysis of all ERP systems to determine integration difficulty. I found it far easier to integrate into some of the lighter open-source ERP systems. Still, it is no coincidence that these applications were developed more recently than Tier 1 ERP applications.

Although there are too few studies upon which to base any definitive conclusion, it is equally possible that ERP systems increased the integration costs that were incurred by companies. But either way (whether it is a wash, or whether ERP increases integration costs), the story does not have a positive outcome. That they most likely did not reduce their integration costs (and quite possibly increased their integration costs) would be quite surprising to companies that gave up so much for the promise of an integrated system.

What is Promised by SAP in Integration

What buyers who follow this strategy often find is that the integration, which is promised during the sales process, is often far less than advertised. This is true of SAP for whom it is a longstanding policy to overstate the degree of integration between its applications. The following article on the CIF is a description of the many integration problems between SAP ERP ECC/R/3 and SAP APO. However, the same problem generalizes to other SAP products.

However, it is certainly not a policy, which is limited to SAP. Instead, it is one of the significant sales misrepresentations/strategies of large software vendors. For software vendors that have grown through acquisition such as Oracle, JDA, and Infor, their “suites” provide minimal integration benefit over purchasing a variety of applications from unrelated software vendors. Each application acquired by these serial acquirers has its heritage, unrelated to the heritage of the acquiring vendor. Therefore the integration “benefits” that are so aggressively promised during the sale process are mostly an illusion. All that happens is that the buyer creates a faster implementation time projection, which must then be changed some duration in the implementation. However, while the integration benefits are illusory, the buyer loses out on the more applicable functionality that could be obtained by making a genuinely competitive process out of the software selection.

ERP and the Internet

There are few people (with the natural exception of ERP vendors themselves) who will debate the notion that ERP systems are walled off from the Internet. Since ERP developed, the Internet has become a significant force, and web front-ends have greatly improved application interfaces and the ability to connect various applications. This point is reinforced by a 2007 article in the MIT Sloan Management Review.

“Just as companies were undertaking multiyear ERP implementations, the Internet was evolving into a major force, changing the way companies transacted business with their customers, suppliers and partners.”

Here’s a concrete example of how far integration has come since ERP first became popular. I recently installed an application called Yesware off of the Internet. Yesware automatically integrates with my Gmail to track emails, and also integrates with a variety of CRM applications; this is integration across Internet servers by different companies that have decided to cooperate. These are two applications that are communicating over the Internet to one another—each performing a different function—and each aware of what the other is doing. All of these adapters are created for me, and all of them work transparently.

My integration effort was limited to clicking a button to install Yesware and rebooting my email client. This is the future of application integration across the Internet. Of course, none of this capability existed when the concept of ERP was developed. In stark contrast, most ERP software—and particularly on-premises ERP software—still sits with dated application interfaces and manually intensive ways of interacting with other systems. Getting most ERP systems to do what I did with Yesware, Gmail, and a CRM application would be a significant initiative at a company and cost quite a lot of money. This point is brought up in the following quotation:

“As the web increasingly becomes the medium for information exchange, your on-premises ERP is increasingly a disconnected silo from the rest of the world.”Craig Sullivan, NetSuite

Rootstock, which covers much of the functionality of an ERP system, does work similarly, as it is part of the Salesforce.com platform. But Rootstock is more of an exception. Most ERP systems do not work this way.

Errors in the Platitudes Regarding ERP Integration

Executive decision-makers, and also researchers, have some general misunderstandings about the state of integration. The following is an example.

“Information integration is a key benefit of ES. This integration can replace functionally oriented and often poorly connected legacy software, resulting in savings in infrastructure support costs. Furthermore, improvements in operational integration enabled by ES can affect the entire organization and therefore can positively impact fi rm performance. As discussed below, ERP systems also provide benefi ts in the area of transaction automation, SCM systems provide more sophisticated planning capabilities, and CRM systems facilitate customer relationship management.”The Impact of Enterprise Systems on Corporate Performance

This and other similar quotes confuse functionality with the system that brings that functionality, in much the same manner as those who confuse an economic system with a particular form of production. For instance, one who says that industrial capitalism is good because “people bake bread for-profit” misses the fact that bread has been baked and sold for thousands of years before the existence of industrial capitalism. Such logic intends to prove that the desired output—the bread in this case—is best accomplished within an industrial capital system versus some alternative system.

Analyzing Quotations

Let’s parse this quotation to analyze it properly because there are several assumptions contained within:

  1. New software can replace poorly connected legacy software: It’s unclear why the legacy systems were so poorly connected in the first place, as was suggested by ERP salesmen during the early stages of ERP’s popularity. All enterprise software faces these integration challenges. Notice the researchers in this quote are using “ES” not “ERP,” as they propose that all enterprise software has advantages in integration over legacy systems. However, no evidence is given as to why this is true. Systems must be made to work with other systems. An ERP system is more integrated to itself, but as I have explained earlier, that is not the end of the story. Furthermore, enterprise software infrastructure costs have not declined due to ERP being implemented. Some vendors do allow their applications to be integrated easily into other systems that are not their own. However, SAP and Oracle do not promote ease of integration to systems from different vendors. Instead, they sell closed systems to companies, getting them to buy into the SAP or Oracle ecology. Even if one vendor provides multiple systems, the systems will not share the same database, and many of the adapters that are offered are of questionable value.
  2. ERP systems also provide benefits in the area of transaction automation: This may have been a differentiator when ERP was first introduced, but now less expensive applications like RootStock or ERPNext can automate transactions as well as any Tier 1 or 2 ERP system. There is no reason to give up so much leverage and pay such a high price for automation that can be found in applications from software vendors that are far easier to deal with.

“ERP systems replace complex and sometimes manual interfaces between different systems with standardized, cross-functional transaction automation.”The Impact of Enterprise Systems on Corporate Performance

This paper was written in 2005, but manual interfaces between systems were replaced a long time ago. There is standardized cross-functional transaction automation, but that is only within the ERP application and not between the ERP application and the many different systems with which it must interact.

“Another benefi t of ERP systems is that all enterprise data is collected once during the initial transaction, stored centrally, and updated in real time. This ensures that all levels of planning are based on the same data and that the resulting plans realistically reflect the prevailing operating conditions of the fi rm. For example, a single, centrally developed forecast ensures that operational processes remain synchronized and allows the firm to provide consistent order information to customers (Bancroft et al. [1998]).” The Impact of Enterprise Systems on Corporate Performance

Unless the company uses an ERP system only (and no other systems), the example above is inaccurate. On projects, I have spent quite a lot of time working on how the supply chain planning system will pull data from the ERP system and how the planning recommendations will be sent back. Data pulls from the ERP system for reporting or business intelligence must also be timed, and this is not a real-time feed. These are just two examples, but all systems that are connected to ERP face the same questions and limitations. The only thing that is true about the above quotation is that the ERP system has updated transactions (stock transfers, purchase orders, financial transactions), but this functionality is generic.

Customization of ERP

Customization rarely works smoothly and becomes something that the company must maintain in the long term. Customization of ERP systems is one of the most expensive customizations a company will ever pay for, as it means hiring programmers at the top of the market and developing from within the ERP software vendor’s environment. This is explained in the following quotation.

“’We could have written ABAP code, but the cost of ABAP programming and maintenance is enormous,’ says Bill Waters, MMS’s director of information services. With Oberon, MMS saved the initial programming effort and will save even more whenever it upgrades its packaged apps. Oberon provides prebuilt connectors between the two systems and is committed to maintaining and enhancing these links so MMS doesn’t have to.”

The Efficiency of Customizing ERP Applications

ERP applications are not known as efficient applications to customize.

“The problem is the lack of a full set of application development tools in ERP packages. Major ERP vendors may publish APIs, include a low-level programming language, reveal their underlying data schema, and even provide some customization tools. But they don’t usually provide testing and debugging—or much of the other functionality developers expect.”ERP: More than an Application

Customization is a near-universal requirement for ERP systems. According to IDC, 87 percent of respondents to their survey performed moderate to extensive customizations in their ERP system, and estimates from other sources move that figure up to 96 percent.

“During the past two years, Data Exchange has invested several million dollars in its systems overhaul. A good portion of that money went toward custom coding. ‘Each business is unique,’ Malchicoff says. ‘We did a gap analysis of what Oracle could do and what we needed to do for our business.’ The company wrote nineteen modules comprising fifty thousand lines of code for such things as logistics, process control, and data mining. That effort was just as significant as deploying the ERP software—and it cost just as much, an amount Malchicoff had to calculate as part of his ROI analysis.”Making ERP Add Up

How Many Releases Behind the Latest Version

More than a third of small to mid-sized manufacturers that use on-premises ERP operate between two and three releases behind the most up-to-date version of their ERP system. Furthermore, because the modules within the ERP system are so tightly integrated, there is no easy way around the module in order to connect directly into the ERP’s financial system. The reason for this is clear: if we use ERP’s inventory system as an example, the inventory system must have the full information on all inventory movements, even if there is no standard way for the ERP’s inventory module to process the movement.

While many articles describe ERP systems as inflexible, they miss out on the distinction that I just explained: part of this inflexibility is due to the over integration of ERP systems. In one article that followed the “ERP is inflexible theme,” the IT analyst firm IDC did an excellent job of elaborating on one aspect of ERP inflexibility:

“ERP systems in general are not designed to be flexible; in fact, most are designed to provide and automate repeatable business processes. While there is substantial benefit to this automation and predictability, there are also risks and costs.”

The inflexibility of Umbrella Term for ERP Shortcomings

“Inflexibility” is used as an umbrella term for many ERP shortcomings, but “over integration” is the term I use to explain the specific problem that results in inflexibility. ERP systems cannot represent all the different business processes that exist in a system, and its introverted design limits a company’s ability to implement these business processes without considerable and expensive customization. One of the reasons that ERP vendors and consulting companies make so much mention of best practices is because ERP’s coverage of business processes is restricted, making it necessary for ERP vendors to have a readymade argument to use to convince the company not to implement its preferred—and in many cases valuable—business process, and to accept a substitute that requires the company to make all the adjustments. How ERP Sets the Integration Agenda for All Other Applications If you check out the websites of non-ERP vendors, you will find them littered with various certified (by the ERP vendor) integration adapters. (Most of these certified adapters are more marketing sizzle than reality as described in What Are SAP’s Vendor Integration Certifications.)

Integrate Applications of ERP Vendors

Non-ERP vendors must show their ability to integrate with the applications of ERP vendors. During the presale presentation to the customer, they often pay homage to the customer’s existing ERP system (particularly to SAP and Oracle because of their popularity in the market) by talking about the great relationship they have with that ERP vendor, and if possible, by discussing the details of as many joint implementations as possible. I have been critical of software vendors in the inventory optimization space who dilute their message by stating in their marketing literature that they “work with” ERP vendor functionality, rather than replace ERP functionality. These vendors have sophisticated solutions with functionality that is head and shoulders above what can be found in ERP systems.

Yet, because they are concerned about offending the ERP vendor, they are as non-confrontational as possible, even to the point of misrepresenting what their applications actually do. For instance, when they refer to SAP on their websites, they could not be more deferential, as I explain in the following article How to Understand Why Software Vendors are Fear SAP.

Conclusion

ERP vendors continually propose false information on the integration benefits from ERP. The integration benefits never turned out to be true, but they remain mostly unquestioned because of the army of ERP vendors, consultants and industry paid IT analysts that provide the bulk of information about ERP to customers.

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 Integrated Suite Myths Content

References

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

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 naturally inherent within SAP?

Does one have to choose between a best practice implementation and a non-best practise 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 essential to know how SAP presents best practices to its customers.

To enhance this understanding here are some screenshots from SAP’s presentations. I was amazed at what I found from this presentation because what is presented here by SAP has no relationship to what 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. 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 purchasing another application, but nearly always pushes the client in the direction of 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 provided by SAP. Still, this sentence implies that there are other things that SAP offers 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 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 are 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 significantly 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 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 appropriately configured in the first place. These numbers are entirely made up. Before I read this presentation, I was not even aware that all of these best practice accelerators were also 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 implement software. The presentations were 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. Still, the document is not that amusing because companies may read this information and think there is some truth to it. Then when they implement, people like me will have to explain why none of the information contained in the document is correct. This is a constant issue with sales and marketing departments, in that they are continually disseminating false information that then has to eventually be contradicted by people who did not publicise the incorrect 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 cautious 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. These are companies 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 making a proper comparison of different enterprise software, and 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 most excellent 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 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 Large Consulting Firms misuse the Term Best Practices

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 mostly 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 significant 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 disagreement 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 various 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 expect 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 several 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 maybe 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). 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 idea 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 occur 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 vehicle 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 strong statement, but only because I do not have the content expertise to analyze the claim truly. Indeed, some things are desirable in accounting software that could be deemed “best practices.” For instance, it is advisable 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 common 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 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. Still, in that case, you are enabling a best practice; you are not modelling 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 essential 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 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 initially false even in that instance, and then their product management could not control themselves. 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. The following quotation demonstrates this.

“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

If you want to make something sound tantalizing, but you have zero evidence that it is, in fact, beneficial in any way, 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 does not know; they are confused themselves as to how to use the term “best practices.” SAP smears the term, like cream cheese on a bagel, on almost everything they do. With SAP, directly calling standard SAP documentation, a “best practice” will somehow (magically) allow projects to go live much more quickly. In this case, the best practice is an incantation. It’s challenging 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 an awkward 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 work on projects or with software, they do not know this. After realizing that they had been deceived 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 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 utterly 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 continually 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 that and this is because they have no proof; 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 beneficial to ERP vendors as a way of permitting them to criticize a potential customer’s pre-existing systems. Sales and marketing are 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. The term “best practices” to describe ERP systems, is highly effective and an impressive feat of rhetoric because it ignores the critical 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 incredibly 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 sense—any system that you would like to replace. However, many decision-makers missed an essential 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. Other vendors have adopted cost optimization, allocation, the statistical forecasting methods used by DP; in fact, everything in all the modules. 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. 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 achieving 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 rarely 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 repurchase Business Objects?
  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 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 excellent 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 no 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 explicitly 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 was 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 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. This includes 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 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 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. Still, 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, it is 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 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 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 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

How to Understand The Logic Used to Sell ERP Systems

Executive Summary

  • ERP systems were sold based on things that never came true.
  • Find out what were the false logics used to sell ERP systems.

Introduction

Many of the arguments that are habitually made in favor of ERP are, in fact, nothing more than logical fallacies. Because of this, it is essential to review the definition of “logical fallacies.” Proponents of ERP use several logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their official names. It is quite surprising how many of the quotations from ERP proponents fall into one or more categories of logical fallacy and realizing this led me to read a book specifically on logical fallacies to make sure I was able to identify all of them correctly.

When a topic leads one to read a book on the subject of dishonest argumentation, this is a good indicator that something is wrong with the information that is being researched. As always, in the absence of actual evidence, it becomes quite easy to fall into the use of logical fallacies. Logical fallacies are arguments that use poor reasoning.

They fall into the following categories:

  1. Presumption: Failing to prove a conclusion by assuming the conclusion in the proof.
  2. Weak Inference: Failing to provide sufficient evidence.
  3. Distraction: Providing conclusion with irrelevant evidence.
  4. Ambiguity: Failing to provide the conclusion due to vagueness in words, phrases, or grammar.

The Logical Fallacies

At least one of the following logical fallacies is presented in the form of a quotation from ERP proponents. These logical fallacies are listed below:

  1. Appeal to Probability: Takes something for granted because it might be the case.
  2. Appeal to Fear: A call to emotion where an argument is made by increasing fear. The fear discussed may have a kernel of truth, but the proposer actively increases this fear in an attempt to win the argument and gain influence over decision-making.
  3. The False Dichotomy/The False Dilemma: Forces a choice between two alternatives, when there are, in fact, more than two alternatives. One alternative is the proposer’s desired course of action, and one alternative would have an unacceptable outcome.
  4. Argument from Ignorance: Assuming a claim is true because it has not been proven false.
  5. Argument from Repetitions: States that, as it has been discussed, it is not worthwhile considering.
  6. Shifting the Burden of Proof: Does not prove a claim, but asks for the claim to be disproved.
  7. Argument to Moderation: Assuming that the compromise between two positions is always correct.
  8. Argumentum ad Hominem: Evading the standard requirement to provide counterevidence through the use of a personal attack.
  9. Hasty Generalization: Leaping to a conclusion based on a small sample of data.
  10. Argumentum ad Numerum or Argumentum ad Populum: Appeals to a widespread belief; the fact that many people believe it, means it must be true.
  11. Appeal to Authority: Where an assertion is deemed true because of the position of authority of the person asserting it.
  12. Appeal to Accomplishment: Assertion is considered true or false based upon the accomplishment level of the proposer.
  13. Appeal to Consequences: Where the conclusion is supported by a premise that asserts positive or negative consequences from some course of action in an attempt to distract from the initial discussion.
  14. Wishful Thinking: An appeal to emotion where a decision is made based upon what is pleasing to think to be true.
  15. Argumentum ad Novitatem/Appeal to Novelty: Where a proposal is claimed to be true/superior because it is new or modern.

This will now put us in the right frame of mind to review the logics presented by ERP vendors, consulting firms, and IT analysts.

The Logic Used to Sell ERP

The following chapter will cover the logics used to sell ERP systems. Each will be analyzed. However, a brief explanation of each will help set the stage.

  1. Y2K (the Year 2000): This was the concern related to the ability to correctly calculate dates in software that had been developed back when there was a minimal amount of data storage available, and developers saved storage by just using the last two digits of years.
  2. Single System: Companies have preferred to have a fewer number of systems. Developers and consultants know that developing specific purpose applications provides better usability, functionality, and maintainability than applications that try to cover a broad range of areas. However, this reality is unappealing to those that purchase software.
  3. Best Practices: Best practices are mostly a single best way of doing something. Best practices can be applied in software or outside of software. However, in software, the concept of best practices is that software vendors can review how many companies do something and choose the best way to incorporate it into their functionality.
  4. Integration Benefits: Hypothetically, if either a single system or a very few number of systems can be purchased and used by a company, it will reduce the integration costs.
  5. One Size Fits All: Under this logic, if the purchasing company agrees to use the software the way the ERP software vendor recommends, often following the logic of best practices, that all or nearly all companies can use the same ERP software.
  6. All Industries: This logic is that ERP systems, and particularly ERP systems from the more significant vendors because of their experience in so many industries, translates into the software vendor being able to build the functionality in their software to be implemented in any industry and to meet most of their requirements.
  7. Cost Reduction: Related to—or build upon the previous logics—that since all of the earlier logics are true that this will result in a reduction in costs. Also, based upon the idea that if a company concentrates its software purchases from fewer vendors that costs will decline.
  8. The Logic of ERP Driven Improved Financial Performance: This was the logic that ERP would be a pathway to improving the financial performance of a company. At one level, the financial performance was predicted to come from the improved operations of the company—but a second proposal was that the purchasing of an ERP system would signal to other entities, which the purchasing company desired to impress that the purchasing company was making a serious effort to improve. These entities could range from customers, suppliers, potential acquiring companies as well as Wall Street.

Details on the Logics

Y2K (the Year 2000)

Many ERP purchasing decisions were made because companies felt they needed to have ERP. This interpretation was often based either upon fear (such as the Y2K fear that drove so many ERP implementations) or a herd mentality. ERP presented itself as a silver bullet for the Y2K issue: instead of adjusting the dates on all of a company’s old systems to ensure they would work adequately post year 2000, they could be replaced—swept away by a shiny new ERP system. Fear of Y2K was the central component of the ERP vendors’ sales strategy.

“Slater (1999) discusses the breadth of such problems as he notes that ‘companies buy multimillion-dollar software packages only to fi nd out they don’t work—or at least they don’t work well—for one of their key business processes.’ The reason, Slater suggests, is that ERP software is so hot, the fl ames fanned by consultants and the technical press cause companies to simply push forward without dealing with such key restrictions.” – Technology Monoculture

One System to Rule Them All: The Single System Logic for ERP

A primary logic used to promote ERP purchases was that the ERP system would be the only system that an enterprise needed to purchase, as explained in the following quotation.

“The name is now Enterprise Resource Planning (ERP) systems to suggest that all information systems required for the management of a manufacturing enterprise are part of the solution.” – Process Industry ERP Requirements

When companies that purchased ERP found that ERP did not meet all their business needs, the next idea put forward was to implement the ERP software first, and then to connect non-ERP software (the so-called best-of-breed software) second. This approach is considered desirable because ERP is known as the backbone or the “mother ship,” with the other applications connected to it.

The initial idea behind ERP systems was that it would amalgamate many applications into a single system, thus reducing application integration issues. This concept is encapsulated in the quotation below:

“Many technical reasons exist including the replacement of disparate systems into a single integrated system.” – Hitt, et al., 2002

This turned out never to be the case for the vast majority of companies that implemented ERP software.

“The majority of respondents reported that an ERP system fulfi lls only 30 to 50 percent of IT requirements. As a result, many companies did not abandon their legacy systems but they tend to integrate the functionality from disparate applications.”ERP and Application Integration: Exploratory Survey

This gets into the customization of ERP systems.

“Most pharmaceutical companies have invested in enterprise resource planning systems (ERPs), but few get enough bang for the millions of bucks these platforms cost. It’s as if they bought a Lexus loaded with all the extras, but only use it to drive around the neighborhood. ‘Most [drug] companies are using ERP for the bare minimum,’ says Eric Bloom, vice president of information technology at Endo Pharmaceuticals. To realize the promise of ERPs, pharmaceutical manufacturers must fully integrate them with plant systems such as manufacturing execution systems (MES), quality management systems (QMS), and software for targeted applications such as radio frequency identifi cation, or RFID. For most pharmaceutical companies, the biggest issue is, ‘How deep should I take my ERP system into manufacturing?’ says Roddy Martin, vice president for life sciences industry strategies at AMR Research in Boston.”Realizing ERP’s Untapped Potential

And this is the constant problem: ERP does very little for manufacturing. This is true; in fact, most ERP systems were never really designed with much manufacturing functionality. Often ERP is discussed in terms of its MRP/DRP functionality, but even this is quite basic, not only from a sophistication level but also from a usability perspective. They can perform essential functions on the inventory level—such as goods issue and goods receipt—but ERP systems cannot be considered as much more than a starter kit for any manufacturing company.

Many companies have tried to “get more out of their ERP systems” by pushing them in directions where they were never designed to go (of course, with a healthy dose of customization). Still, companies that rely on ERP systems in this way cannot hope to leverage the available manufacturing software properly, and will always run their plants at a much lower level of efficiency than companies that adopt the more sophisticated and nuanced IT strategy. ERP systems never replaced all of the legacy systems in companies that purchased ERP. Therefore, this prediction was spectacularly incorrect.

Secondly, ERP vendors did not stick with this principle (of ERP being the only system a company needed to purchase) for very long, as the next section will describe. The fact that they moved away from this logic so quickly makes one wonder if they ever actually believed it themselves.

The Changing Story on ERP’s Ability to Meet All Requirements

Soon after the significant ERP vendors had saturated the market for ERP software, they began to develop specialized applications for things like supply chain planning, business intelligence, customer relationship management, etc. That is, when the opportunity presented itself, they immediately contradicted their logic that they had used to convince so many companies to buy ERP systems.

Curiously, a review of the IT/business literature at the time shows that the business/technology press did not seem to pick up on the fact that this new strategy was utterly inconsistent with the earlier arguments used to convince companies to buy ERP. I could find no articles that explained how inconsistent the new diversified application strategy was with ERP vendors’ statements made previously. ERP vendors moved away from providing only ERP systems for several good reasons.

  1. The Single System Approach Was Unworkable: The single system concept was never anything more than marketing hyperbole—and only a credible hypothesis for the naive, and it is unlikely the vendors believed what they were selling. There was simply no way that an ERP system, with its elementary approach to all functionality, could meet all the needs within companies.
  2. Sales Growth: Once ERP vendors had sold their ERP applications into most of the large and medium to large customers globally, they needed to develop more applications to increase their sales. In some cases, they could have added functionality to ERP; however, this strategy would not have maximized the ERP vendors’ revenues, as they would only get upgrade revenues from their existing clients. The trick was to sell new applications to their current clients. And to do so without having the clients remember that the primary justification for purchasing ERP in the first place was that it would cover all of a company’s requirements with a single application that contained all of the best practices (more on that later in this chapter). The ERP vendors relied upon both their consulting partners as well as the compliant IT analysts (the ERP vendors being the most significant sell-side revenue stream of the major IT analysts) to never point out this minor detail to customers.

Account Control

From the competitive positioning perspective, selling an ERP system to a company was one of the best ways ever developed to sell more software (after IBM unbundled software from hardware in 1969) into the same company in the future and to control the account. Rather than looking out for the interests of the buyer, account control is how third parties—such as software vendors and consulting companies—manipulate (or direct, depending upon your preference) their customers into following the desires of the third party. IBM was the first vendor to perfect account control, and many of their strategies (including how they leased their machines, the prices they charged, the way they dealt with their customers, etc.) were based upon account control strategies. Account control is behind how major consulting companies interact with their clients.

For instance, large consulting companies want more of their consultants on a project rather than the consultants from the software vendors, because they receive more billing hours and because it helps them control the account and control the information that their customers receive. At large software purchasing companies, in particular, the enterprise software market cannot be understood without understanding account control.

Misinformation on ERP

Once the software vendors had implemented the ERP system at a company, their relationship with that company was based on the fact that they were responsible for that company’s largest IT purchase. They had the network effect on their side. The misinformation they passed to their clients reinforced the dubious concept that ERP was somehow the keystone application. They pushed the “boogie man” of integration: that is, while the integration from other applications they sold would naturally integrate to their ERP system. The software from different vendors was an “unknown,” a guarantee that other software from that vendor would integrate to the ERP system at a reasonable cost or in a reasonable timeframe. That was the story anyway; a future section in this chapter will explain why this was never true.

Monopoly Power

This integration argument is particularly compelling because the ERP system is considered the central application for a company—the application to which other applications must integrate. This granted ERP software vendors the same type of monopoly power over their customers that Microsoft gained through controlling the operating system on PCs (but in the case of Microsoft, their applications actually did work better than competing applications on Windows, although they often made sure of this by postponing information about Windows from becoming public until the new version of Windows was released—they could have very easily released the APIs earlier). This monopoly allowed ERP vendors to compete unfairly: they told clients that their applications had a head start on integrating to the company’s ERP system. In the example of SAP and Oracle, the integration benefits were far more illusory. I can recall my shock when I analyzed the prebuilt adapter that extracted information from SAP ERP SAP BI/BW. It was clear that Development had done the absolute minimum required in order to mislead potential customers into thinking that they could pull a large variety of data from SAP ERP into BI/BW. Instead, what customers really received was a starter kit. Companies like SAP and Oracle promptly took full advantage of this market power, and this enabled them to charge top dollar for all of their applications, and furthermore to easily compete with applications that were far superior to their own applications.

Overall, this power was abused in so many ways that it would be tedious for my readers if I listed them all. But I will mention one of the more creative ways, which was developed by SAP: their pseudo partnership program with other vendors promised entry into SAP’s enormous client database, when in fact the program was an intelligence-gathering operation by SAP to allow it to steal intellectual property from their “partner” vendors, thus helping them to backward engineer the application.

Once again, the IT/business press and IT analysts failed to explain what this program was, and in fact, they lauded it. And once again, they were proven incorrect when the program died and did not lead to a new golden age of integrated applications (no surprise, it was never intended to). The upshot of all of this was that the ERP vendors were in an excellent position to sell more software into these accounts.

Selling More Software into Accounts

These new non-ERP applications all have their own platforms, and while they have adapters or interfaces to one another, they are each a separate application; they each have a different database and sit on different hardware. Many of these new applications are acquisitions: after a software vendor acquires another software vendor, they typically develop a marketing program to inform all current and potential customers as to how well the new applications will work together. ERP clients who purchased applications that Oracle had acquired were worse off than if the software had been left independent and adapters had been written to Oracle ERP. The long-term history of software acquisition clearly demonstrates that as the price of software goes up, development of the application stalls, and in many cases, the application is subsumed into what is often an inferior application. There are several cases where the acquired application is mostly eliminated. But the acquiring company also acquires the customers and is able to increase their prices now that they have removed a competitor from the marketplace. Software acquisitions have only two winners:

  1. The Acquiring Company: They eliminate a competitor.
  2. The Senior Members of the Acquired Firm: They receive a handsome buyout as compensation.

Despite promises on the part of the acquiring vendor, often the reality for integration does not change much after an acquisition. For example, many of these software vendors already had adapters that connected to Oracle ERP. However, the acquisitions allowed Oracle to increase the price of the acquired application because they became part of the “Oracle Suite.”

As a result, companies that implemented ERP are essentially back where they started before the move to ERP, except now they rely more on external application development through commercial software rather than internal application development. While buying companies were sold on the idea that ERP would take a “blank sheet of paper” approach, to the present day companies still have complex landscapes with many applications that have separate databases and separate hardware and are interfaced, but not integrated—just like before the whole ERP trend began. Promises of a single integrated system simply never came about.

One Size Fits All

One of the original arguments used to sell ERP systems was that the standard functionality of the ERP system could be used “right out of the box.” But as ERP systems are customized so regularly, this sales pitch has long since been forgotten. Not only was this assumption wrong, but it was also fabulously wrong. According to research by Mint Jutras, around 96 percent of respondents to a survey stated that they did moderate to extensive customization to their ERP systems. This has been my experience on projects as well, but I can say with confidence that most companies that purchased ERP systems had no idea they would eventually customize their ERP systems to the degree that they did.

I once had a defense contractor as a client. They discussed their interest in replacing a system that connected to the Department of Defense. At first, it seemed as if we could take the logic for the system and port it to SAP ERP. However, the more we analyzed the application, the more it became apparent that this application was so specialized and had taken so much time and effort to build that the best course of action was simply to keep the system but integrate it into SAP ERP.

It looks much easier to decommission software when you do not personally use it and are not aware of everything that it does. Over the decades, many companies have gone through this identical process. Very little is written on the subject of system replacement errors, which led IT decision-makers to underestimate significantly the degree to which companies faced this issue of being unable to decommission systems that were performing essential tasks. And to overestimate how well the ERP implementations at other companies were faring. Companies bought ERP, often without knowing how specialized their applications were, and they ended up having to integrate many more systems to the ERP system than they had expected, as well as to customize their ERP systems more than they ever anticipated. As a result, their ERP systems consumed a much higher percentage of their IT budgets than forecasted.

All of the above happened, but to a much larger degree, on the Air Force’s Expeditionary Combat Support System (ECSS) initiative, a now-notorious program to take all of the Air Force’s support systems (two hundred and forty legacy systems) and move them to Oracle ERP, which we covered in the following article.

Planning for the Inevitable Customization

Unanticipated customization significantly increases implementation costs and durations. It also means long-term and largely unplanned maintenance as the customized ERP systems face issues caused by each new version (or at least major version) of the ERP software released by the vendor. The customization required for ERP systems has demonstrated that these systems are simply starter kits rather than entirely usable systems. Companies went to the tremendous expense to do nothing more than replicate functionality that was, in many cases, working perfectly well and meeting requirements in the legacy applications that ERP salespeople criticized as archaic. The reality is that the ERP salespeople had no idea what they were talking about. Most had never worked in the field of software implementation and, like trained parrots, were repeating catchphrases. It is the height of arrogance to state that you “know” that the functionality in your software is better than the functionality residing in a customer’s system when you have never seen nor analyzed their system and probably would not understand it if you did.

ERP’s Operational Improvement

One of the logical arguments used to sell ERP was that it would improve the company’s operations. I was able to find several studies that showed a correlation between operational improvements in a company and ERP implementations. A quotation from one of these studies, Which Came First, IT or Productivity, says the following about operational versus financial performance.

“Our results demonstrate that ERP adoption strongly infl uences operational performance (inventory turnover, asset utilization, collection efficiency) and labor productivity but has a negligible impact on measures of financial return or profitability.”

This is a bit of a paradox. Shouldn’t improvements in financial performance evidence improvements in operational efficiency? The study ERP Investment, Business Impact, and Productivity Measures says the following about productivity and brings up some interesting issues in terms of when the productivity is measured.

Given that most of our data is before and during implementation, this suggests that higher performing firms tend to adopt ERP and that their performance is at least maintained and possibly improved by ERP adoption. Our data does not have many (data) points post implementation. “Our results on performance analyses using the same specifications previously, consistently show that firms have higher performance during the implementation than before or after.

“It also suggests that the paybacks begin to appear before the projects are completed—probably the most reasonable interpretation is that many of the components of an ERP adoption are completed and operational before the firm declares the project to be complete.”

In all likelihood, this statement is not true. Companies declare their systems “live” as soon as they can, and rarely does it happen that the systems are operational but not declared “live.” More commonly, the system is announced live before the implementation is complete. Much fine-tuning is required post “go-live” to get the applications working as needed. Frequently I am part of a team that tunes live projects.

“Alternatively, it could be that many of the ‘belt-tightening’ organizational changes such as changes in inventory policy or reduction in the number of suppliers begin to generate gains fairly quickly, even if the more technical aspects of the project have not yet been completed.”

Other alternative explanations for the productivity gain during the implementation could be the “Hawthorne Effect.” The Hawthorne Effect is when subjects in a study improve their performance because they know they are being observed. The researchers do not mention this as a possible reason for the post-go-live performance improvement, but it is quite obvious and likely explanation.

“There is a productivity gain during the implementation period, followed by a partial loss thereafter. When value added is used as the dependent variable, the gains are 3.6 percent during implementation with a loss of 4.7 percent for a net gain of –1.1 percent (t= .8, not significant).”

I list the Hawthorne Effect as a likely reason for the gain during the implementation because the software is not yet operational; therefore, the benefit cannot be from the software itself. Regardless of the reason, the short-term gain in productivity— followed by an overall loss of productivity—is not a happy ending or a compelling reason to purchase an ERP system. When the actual benefits of ERP are evaluated (evaluated from any dimension one cares to choose), the fact that ERP is seen as a “mandatory infrastructure”—as stated in many articles and as is generally accepted in companies—does not seem to compute.

Should SAP Come Clean on How Much SAP ERP Relies on Excel?

In the original presentations from SAP, R/3/ECC was primarily about work in the application. Customers were not told, even after the evidence was quite clear that users would be using ECC in combination with Excel, that it is how the system would be used. The number one way to report and do analysis in ECC? Yes, that would be Excel. ECC has been fantastic for creating external spreadsheets. It seems that Microsoft does not get enough credit for ECC being able to function.

What Was Promised?

In research, it is essential to evaluate what was promised, and then what happened. One does not view a discrepancy between promise and outcome and disregard it unless there is no research motive. Moreover, SAP salespeople and consulting companies routinely understate how much ECC relies upon external systems to customers. You don’t even hear the word Excel on SAP presentations. Its as if ECC does everything.

Conclusion

ERP systems were, in essence, a simplistic platitude that was appealing. Remember, the first sales pitch of ERP was that it was the only system you would ever need. So ERP systems were sold with a sophistication similar to razors or coffee. Over decades the logics presented to sell ERP have turned out to be universally untrue. However, because the media entities and consulting firms and other pro-ERP sources never performed a post mortem, these false logics are used to sell ERP systems to this day.

As a principle, it is foolish to be impressed with a system because it is bundled. It is also unwise to try to single-source most of your software from one vendor. However, Gartner was happy to sheepdog customers to SAP vendors….for the right price (payments from vendors).

SAP customers are finding out with indirect access claims and continually increasing support costs, that the more leverage the vendor has over you, the worst you will be treated over time. SAP ERP systems do not have an ROI, and that negative ROI is going to grow as SAP continues to harvest more and more out of their customers. And the customers are now trapped because they have a vendor they over-relied upon, thinking they would have fewer headaches by concentrating their vendor spend.

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 Integrated Suite Myths Content

References

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

The History of ERP Systems

Executive Summary

  • The history of ERP systems is normally misrepresented by those with software to services to sell.
  • Find out the real story around ERP history.

Introduction

I find it amazing that there is so little information about the history of ERP, other than a few short articles on the Internet and the paper ERP: A Short History, by F. Robert Jacobs and F.C. Weston Jr. in 2007 in the Journal of Operations Management. It is curious, but I can come to no other conclusion than this: very rarely have ERP systems been put under the microscope.

The articles on ERP tend to accept all of the initially proposed benefits of ERP as if they were true, and almost all of the materials written about ERP systems since ERP systems were first introduced (outside of academic materials) have been promotional in nature. The articles have not demonstrated historical knowledge and certainly are not scientific in their orientation (that is, based on evidence and/or testing). Book after book, and article after article, promote ERP and provide advice about improving ERP implementations—yet never do the authors question the benefits of ERP. The influence of ERP has been so great and has so strongly impacted the structure of the enterprise software market (in addition to impacting the decisions that are made by companies outside decisions about ERP itself), that ERP as a topic really deserves a comprehensive written history. What follows is not that comprehensive history by any means, but enough of a background to support the analysis presented in the following chapters.

What is ERP?

Conceptually, ERP is a combined set of modules that share a database and user interface, and that supports multiple functions used by different business units.10 Because the ERP modules use a single database, employees in different divisions (e.g., accounting and sales) can rely on the same information for their specific needs and without any time lag. ERP covers what is sometimes considered a company’s “core” business processes. These processes are mirrored in the four basic modules of SAP’s ERP system:

  • Sales and Distribution
  • Materials Management
  • Production Planning
  • Financial and Controlling

ERP Gets its Start A bill of materials (BOM) is the listing of components and subcomponents that make up a finished good. The first enterprise system in which the BOM was encapsulated was the material requirements planning system or MRP system for short. Major MRP functionality is shown in the following graphic.

MRP Versus ERP

I will use the term “MRP” a number of times in this book, and you may notice that MRP sounds very similar to the term “ERP.” This is not a coincidence; ERP is actually based upon the term MRP, although, as we will see, it is not a particularly descriptive term for what ERP actually does. MRP software predated ERP software by more than a decade, with MRP systems beginning to be implemented in the mid-1970s and ERP systems beginning to be implemented in the mid-1980s. At one time, MRP systems were sold as standalone systems, and there were around thirty competitors in the market. Many ERP vendors acquired MRP vendors and began to include this software as part of a broader integrated offering.

In its earliest incarnation, ERP software was known as “business systems” software. Prior to the change in terminology, vendors of business systems were simply growing the footprint of their applications; it was actually the IT analyst firm Gartner that began referring to these systems like Enterprise Resource Planning, or ERP. However, as previously stated, in time, the MRP software vendors became subsumed within ERP suites primarily through mergers and acquisitions.

“In the early 1980s, MRP expanded from a material planning and control system to a company-wide system capable of planning and controlling virtually all of the fi rm’s resources. This expanded approach was so fundamentally different from the original concept of MRP that Wight (1984) coined the term MRP II, which refers to manufacturing resource planning. A major purpose of MRP II is to integrate primary functions (i.e., production, marketing and fi nance) and other functions such as personnel, engineering, and purchasing into the planning process. “A key difference between MRP II and ERP is that while MRP II has traditionally focused on the planning and scheduling of internal resources, ERP strives to plan and schedule supplier resources as well, based on the dynamic customer demands and schedules.” — Planning for ERP Systems: Analysis and Future Trend

The dates in the above chart are estimates of when these technologies became broadly used, not when they were first developed. MRP is a method of performing supply and production planning.

The Simplicity of MRP

MRP is quite simple and requires nothing more than elementary arithmetic to perform its functions.12 The software processing requirements are quite low. For instance, while a supply and production planning problem will take hours to run using more advanced methods, MRP can be run for the entire supply network in just a few minutes. Even two decades after the rise of advanced supply chain planning software, MRP is still the dominant procedure/method used in companies around the world for supply and demand planning. MRP is also run in external supply chain planning applications; however, the vast majority of MRP planning runs that are performed today are performed in ERP systems. Let us look at two graphics that succinctly explain how MRP works.

For procured items, MRP converts forecasts and sales orders into purchase orders and production orders with the right dates so material can be brought in on time to support demand. Additionally, the purchase orders and production orders are batched (that is, they are not necessarily in the same quantities as the sales orders) in order to meet order minimums and to create economic order quantities.

Both MRP for procured items and MRP for manufactured items are inbound methods. There is also a method for outbound planning, which is called DRP (distribution requirements planning. I won’t get into DRP here, but I do explain the history of it in the article The History of MRP and DRP.

The Focus of ERP Systems

The relationship between MRP and ERP systems that I have described up to this point could easily lead one to believe that ERP systems were first designed to meet the needs of supply chain management. However, the opposite is true. In fact, ERP systems were actually designed first to meet the needs of finance and sales, and to a lesser degree, manufacturing and supply chain management. When one compares the functionality depth in the SAP ERP modules of Sales and Distribution (SD), Material Management (MM), Production Planning (PP), and Finance and Controlling (FI/CO), FI/CO has by far the greatest depth in functionality.

The major selling point of ERP systems was not that these systems provided particularly good functionality in any operational area. In actuality, they provided very basic functionality in all areas (I will address the notion of best practices in Chapter 4: “The Best Practice Logic for ERP”), but anything that occurred in operations was immediately reflected on the accounting side because all of the applications shared the same database. It was an argument tailor-made for executives: they would never have to deal with the functional limitations of ERP systems personally. That is the common issue when the individuals who buy items are different from the individuals who use the item. Anyone who has had to use a centrally purchased corporate laptop should have no problem understanding this.

However, as we will see further on, companies eventually paid for accepting the assumption that functionality did not really matter all that much, as long as all the applications were integrated.

Why Are ERP Systems Called ERP?

The first system that is recognized to be ERP was an enlargement of an MRP system. This was the IBM MMAS system. However, in an interesting historical turn of events, IBM never became a major player in the ERP space even though they had the first ERP system.

“In 1975 IBM offered its Manufacturing Management and Account System (MMAS) which Bill Robinson from IBM considers a true precursor to ERP. It created general ledger postings and job costing plus forecasting updates emanating from both inventory and production transactions and could generate manufacturing orders from customer orders using either a standard bill of material or a bill of material attached to the customer order.” — ERP: A Short History Gartner is credited with naming ERP systems.

The term “ERP”—Enterprise Resource Planning—was adopted from the term “material requirements planning” (MRP) or “manufacturing requirements planning” by simply replacing the “M” with an “E.” 14 This was done because, in addition to containing the MRP supply and production planning method, ERP systems also contained sales, financial accounting, and materials management functionality. Gartner found itself analyzing what appeared to be a new software category, and they needed a way to broaden out the terminology in a way that was more descriptive than “business systems.” Additions to the MRP functionality made the application include more than just material or manufacturing, and expanded it to the entire “enterprise.”

ERP Begins Its Life with an Illogical Name

I was unable to find whom at Gartner actually named ERP. The term, although wildly successful, unfortunately, is also inaccurate. Naming ERP systems after MRP made little sense because MRP is just one small component of what ERP does. Furthermore, ERP systems have little in the way of actual planning functionality, and instead, are transaction processing systems. They are designed to do things like accept sales orders, create purchase requisitions and convert them to purchase orders, and then connect every transaction to the financial module. If anything, ERP systems were and continue to be the exact opposite of planning. ERP systems are generally known as “execution” systems. This is one reason why companies, after completing their ERP implementations, connected external supply chain planning applications to ERP to replace ERP’s limited planning functionality. On the finance side, “planning” is not performed in the ERP system. Instead, the data is exported to a flat file and opened in a spreadsheet or exported to a reporting application. Regardless of the area in which the analysis is performed, the best way to actually perform planning is to export the data from the ERP system. In reality, ERP systems just tell companies what already happened, for use in planning for the future.

ERP Limitations

Companies found that planning was only the beginning of ERP’s limitations. ERP is now well known for many limitations in its ability to present analytical data to customers. The shortcomings of ERP in this regard are a strong precursor to the growth of the separate business intelligence market, a market that was not supposed to have developed if the original projections by proponents of ERP had come true—that all reporting would be done within the ERP system. What was once known as “reporting” was renamed “business intelligence” to make it sound more appealing and leading edge. After all, “reporting” is boring…but “business intelligence” is leading edge. Business intelligence requires data to be extracted from ERP systems and placed into business intelligence repositories and performs the reporting from these off-line repositories.16 This point is reinforced by the following quotation from Craig Sullivan of NetSuite, a vendor of SaaS ERP and other things.

“Stone-Age ERP was designed when businesses were top-heavy in general administration—when it was standard practice to have someone assigned to rekeying purchase orders or time and expense entries. Today, any unnecessary bureaucracy just wastes time that could be better spent elsewhere.”

Most ERP systems have not evolved past their humble roots, and to the disappointment of many companies that own ERP systems, many ERP systems have essentially stabilized. Stabilization is a development term that means only minimal improvements are being made to the system, as explained in the following quotation.

“Our point is that current ERP technology provides an informationrich environment that is ripe for very intelligent planning and execution logic, yet little has changed since the late 1970s in the logic associated with such applications as forecasting, reorder point logic, MRP, production scheduling, etc. The current systems are now just executing the old logic much faster and in real-time. The area is ripe for innovative new approaches to these old problems. This may include partnering with our business counterparts who live in this dynamic environment on a day-to-day basis.” — ERP: A Short History

The Reality of ERP

“The preponderance of corporate pain lurking throughout the lifespan of a traditional on-premise ERP suite is unequivocal. To wit: ERP projects have only a 7 percent chance of coming in on time, most certainly will cost more than estimated, and very likely will deliver very unsatisfying results. In addition, today’s enterprise has little better than a 50 percent chance that users will want to and actually use the application. Poor application design just adds to the turmoil. In sum, ‘ERP success’ has become a very subjective metric.”Why ERP Is Still So Hard

What is ERP Implementation History?

Only rarely is the actual success rate of ERP implementations quoted. According to the publication, The Critical Success Factors for ERP Implementation: An Organizational Fit Perspective, the success rate is roughly 25 percent. So, according to this source, 75 percent of ERP implementations are considered failures. But quoting just one study is misleading because the estimates are truly all over the map, as the quotation below attests.

“A study by the Standish Group estimates that 31 percent of projects are not successful (Kamhawi, 2007). Barker and Frolick (2003) suggest that 50 percent of ERP implementations are failures. Hong and Kim (2002) estimate a 75 percent failure rate, while Scott and Vessey (2002) estimates failure rates as high as 90 percent. Different statistics for the success or failure of ERP projects have been offered by researchers. In addition Bradford and Sandy (2002) reported that 57 percent of the companies they interviewed had not attempted to assess the performance of their ERP systems owing to a lack of empirically effective evaluation models.” — Measures of Success in Project Implementing Enterprise Resource Planning

Stupidity Disguised as Consulting Advice

One of the ridiculous arguments I’ve heard is that ERP implementations are so difficult that companies that manage to pull them off gain a competitive advantage over other companies. In this incarnation, the ERP system is presented as something akin to the Ironman Triathlon, where the implementing company proves its toughness by running the gauntlet.

It is a ludicrous analogy, which, as far as I am aware, is unique in the field of enterprise software where ease of implementation—rather than the difficulty of implementation—is considered a virtue. And in fact, the argument is edging extremely close to circular reasoning: ERP is virtuous because it is difficult to do, and it is difficult to do because it is virtuous. It is also one of the few times that a high failure rate is presented as a positive attribute of a software category.

One can imagine airport advertisements like this, which focus on ERP’s character-building qualities rather than on its negligible benefits. What is interesting about the problematic implementation record of ERP is that it never seemed to quell the insatiable desire of companies to continue to implement ERP systems. Nothing should ever be accepted as a course of action because “it is hard.” If difficulty irrespective of a beneficial outcome is being promoted, then some type of scam is at play. 

This is the main takeaway: ERP was so quickly established as a mandatory application suite that not even gruesome stories of ERP failures and cost overruns could mitigate the desire for ERP implementations.

What is the Satisfaction Level with ERP Systems?

Discussed much less frequently is how effective ERP systems are in helping companies achieve their objectives after the systems are live. It turns out that the satisfaction level with ERP systems is low.

“Pretty much no one is really satisfied with the state of their ERP. Only 23 percent of users would recommend their ERP system to another enterprise. The truth is that ERP has been placed on the backburner because of the recession and manufacturers have suffered because of it.” — Old and Bad All Over Manufacturing

My research into ERP continually reinforced a central concept: very rarely does ERP impress the companies where it is installed. Who really promotes ERP systems as good? This is exclusively the province of ERP vendors and consulting firms. With customers, ERP tends to be discussed in terms of being a rite of passage.

  • ERP is also commonly referred to as a “standard.”
  • But the adjective “good” does not seem to surface much in discussions about ERP systems.

Of the ERP systems that I have worked with—and these systems are the more popular systems—I would say that none of them have impressed me. Furthermore, multiple aspects of the ERP system displease companies; common complaints include the following:

  1. Stagnant Applications: There is a perceived lack of innovation on the part of ERP vendors. It is increasingly apparent that many ERP vendors are funneling their support revenues into other applications, leaving their existing ERP customers with dated applications.
  2. Costs: ERP buyers frequently mention the high costs of upgrades and support.
  3. ERP Inflexibility: The inability of ERP systems to be adjusted is a constant constraint that companies must work within.
  4. Missing Required Functionality: The inability of ERP to meet a company’s business requirements, which leads to the following point.
  5. Customization: There is a constant need to customize the ERP system, leading to another complaint: the expense to upgrade ERP systems. In a properly functioning media system, these types of issues would be the topic of more articles and better explained.

The Obvious Question

Software buyers should ask the following obvious question:

If ERP software vendors and consulting companies made all of these projections for how ERP would help companies, at some point shouldn’t an investigation into the actual benefits of the software category be performed, particularly when it is the largest enterprise software category? Whose interests do the IT media support: the software vendors or the buyers? The IT media was instrumental in building up demand for ERP software and in serving as an echo chamber for software vendors and IT consultancies.

ERP and Account Control

The history papers that I reviewed for this book left out the fact that ERP was yet another attempt (and one of the most successful attempts by software vendors in the enterprise software space) to take control of clients. Each vendor replaced many of their client’s applications with ERP and then used their leverage as the ERP provider to sell more applications to these semi-captive companies. Mediocre systems were justified on the basis that they were at least integrated and that having poor functionality in an integrated system was better than a nonintegrated system that provided the business with the functionality they needed to get their job done. ERP had a second impact in that several vendors became extremely well-positioned to sell other types of software.

The Outcome of the ERP Boom

Two of the most powerful vendors were created through the ERP boom. One was SAP, which is the most successful ERP company and which parlayed this success into other enterprise software areas. Currently, SAP stands as the largest enterprise software vendor in the world, and the second is Oracle, which extended its reach from the database into the application software realm with ERP software. From their dominant position in ERP, these vendors acquired a number of software companies that were effective at growing the company (although usually bad for the acquired software itself, as well as for the customers).

SAP and Oracle have ridden the “ERP wave” and owe much of their current central position with customers to their role as the provider of the customers’ ERP system. Both companies are “Peter Principled” control enormous faceless conglomerates that neither company has the competence to manage intelligently, and serve as liabilities for all of their customers. SAP and Oracle are followed by companies like Infor and Epicor, and other ERP vendors whose primary organizational goals are to match the account control enjoyed by the ERP market leaders.

How to Understand ERP as The F-22 of Enterprise Software

The F-22/F-35 fighter program is a massive waste of taxpayer dollars that can’t be stopped because of Lockheed Martin’s lobbying.

ERP systems have a great deal in common with the F-22/F-35 program.

In the book The Real Story Behind ERP: Separating Fiction from Reality, I explained something that no major IT consulting company or ERP vendor would want to get out. That is that the consensus of all the academic studies into ERP shows that ERP systems do not show a positive ROI.

However, particularly for ERP systems from the largest vendors, ERP systems have shown an even more nefarious outcome than simply having no ROI themselves. This is that the ERP system is used by the software vendors and the consulting companies to direct IT purchases into other inefficient areas as well.

Understanding the F-22

The F-22 fighter is a long-running exorbitantly expensive initiative to develop the next-generation fighter for three branches of the US military, which began all the way back in 1991.

  • Twenty-seven years later, the F22 costs roughly $68,000 per flight hour.
  • The F-22, while having been featured in movies, has barely taken part in any military action. The F-22 is a stealth aircraft, but for a publicity stunt, it has been used occasionally to bomb Afghanistan — a country without radar.
  • The F-22 has a massive logistics tail and unending reliability problems.

However, the proposal was that all of this would work out because it would go into the F-35. As explained in the video below, this was always a deception developed by those trying to keep the program alive.

As the video above explains, the fact that the F-35 is of little use, but its continued purchase cannot be stopped.

Lockheed Martin, as with ERP vendors, issues simplistic platitudes to support the F-22 and now F-35. One is that the planes provide jobs, but of course, any plane produced would also provide jobs. Therefore it need not be a bad plane. Second, Lockheed Martin has conflated support for the F-22 and F-35 with patriotism. Good patriots who love America want to get ripped off by Lockheed Martin and field the most wasteful fighter jet ever produced in the history of humankind. Americans who want a better value are unpatriotic and may not love America sufficiently.

ERP vendors, and their partners in crime, large consulting companies follow similar approaches in establishing ERP systems as the only option. “Everyone agrees” that ERP systems are necessary and are the “digital core” (as proposed by SAP). And something that all the people who agree with this have in common is that a) they sell or otherwise financially benefit from ERP systems, or b) they have never analyzed the issue in a sufficient level of detail to develop an informed viewpoint on the topic.

Quotes from Scientific America on the F35

Like ERP, the F22/F35 has been relentlessly pitched by those that either make ERP or make money off ERP using exaggerated claims. With respect to the F22/F35, this is explained in the following quotes.

“The company building the F-35 has made grand claims. Lockheed Martin said the plane would be far better than current aircraft – “four times more effective” in air-to-air combat, “eight times more effective” in air-to-ground combat and “three times more effective” in recognizing and suppressing an enemy’s air defenses. It would, in fact, be “second only to the F-22 in air superiority.” In addition, the F-35 was to have better range and require less logistics support than current military aircraft. The Pentagon is still calling the F-35 “the most affordable, lethal, supportable, and survivable aircraft ever to be used.”

But that’s not how the plane has turned out. In January 2015, mock combat testing pitted the F-35 against an F-16, one of the fighters it is slated to replace. The F-35A was flown “clean” with empty weapon bays and without any drag-inducing and heavy externally mounted weapons or fuel tanks. The F-16D, a heavier and somewhat less capable training version of the mainstay F-16C, was further encumbered with two 370-gallon external wing-mounted fuel tanks.

In spite of its significant advantages, the F-35A’s test pilot noted that the F-35A was less maneuverable and markedly inferior to the F-16D in a visual-range dogfight.

Lockheed Martin and the Pentagon say the F-35’s superiority over its rivals lies in its ability to remain undetected, giving it “first look, first shot, first kill.” Hugh Harkins, a highly respected author on military combat aircraft, called that claim “a marketing and publicity gimmick” in his book on Russia’s Sukhoi Su-35S, a potential opponent of the F-35. He also wrote, “In real terms an aircraft in the class of the F-35 cannot compete with the Su-35S for out and out performance such as speed, climb, altitude, and maneuverability.”

Other critics have been even harsher. Pierre Sprey, a cofounding member of the so-called “fighter mafia” at the Pentagon and a co-designer of the F-16, calls the F-35 an “inherently a terrible airplane” that is the product of “an exceptionally dumb piece of Air Force PR spin.” He has said the F-35 would likely lose a close-in combat encounter to a well-flown MiG-21, a 1950s Soviet fighter design. Robert Dorr, an Air Force veteran, career diplomat and military air combat historian, wrote in his book “Air Power Abandoned,” “The F-35 demonstrates repeatedly that it can’t live up to promises made for it. … It’s that bad.” – Scientific America

Continuing the Undending Fiasco that is the F-22 and F-35

ERP is eerily similar to the F-22 and F-35 not only in the inability to meet exaggerated claims but in how it has created a great number of financially biased entities that support it. For the F-35, the proponents of the fighter are the politicians in the various states. The customer is the normal US citizen (ostensibly who is purchasing defense), i.e., the taxpayer. However, the decision-maker is different than the taxpayer. The politician is far more focused on their political career than defense overall. Many years after the JSF was conceived, and with the development of drones (which often run around $5,000 per flight hour), there are many who question whether the F-35 has any reason for existing. But this does not matter to the US politicians that seek to direct revenues to their states.

Lockheed Martin need only make payments to the right politicians and then set up the F-35 so that most US states receive income from the F-35 (right now 46 out of 50 states do).

This is enough to have the F-35 continue to be purchased, regardless of whether it is a good fighter or a good value for US taxpayers.

The video uses the term “political engineering” to describe how Lockheed Martin continues to receive funding for the F-35.

The Political Engineering of ERP

ERP has its own proponents. While ERP is a poor value for most companies that have implemented ERP (as explained in the book The Real Story Behind ERP: Separating Fiction from Reality), ERP is very good for the largest consulting companies. These consulting companies are very high in recommending ERP systems. Normally ERP systems from the largest vendors like Oracle and SAP, but especially SAP.

The lesson from the history of enterprise software history is that consulting companies don’t much care what the right software for their clients to purchase and implement is. They are in it to maximize their own billing hours. Therefore, they will recommend the software categories and the vendors within each category that maximizes their revenues. The longer your software takes to implement, and the worse value the software is for the end customer, the more the large consulting companies will sing your praises!

The clients of consulting companies don’t seem to recognize that nearly all of the consulting company’s “recommendations” are determined by working backward from self-interest. 

In the Vox video, it states.

“Despite deep design flaws and constant problems, there have been no serious efforts to cancel or scale back the project.”

This quotation was referring to the F-35, but it applies equally to ERP systems. Once in place, ERP systems take on a life of their own.

Lack of Oversight

ERP systems are typically implemented by large corrupt consulting firms. They do not allow any independent entity into the company to evaluate the process. If a client asks for this, the consulting firm will state that

“They already do that.”

ERP implementations are normally so filled with waste that they have similarities with a US defense contract, which also has very little oversight and enormous cost overruns as a normal course of business. This reduction in oversight in the US defense contracting is described in the following quotation from a comment on an article in the blog BIG by Matt Stoller.

Lockheed did let me have as much time in the F35 plant as I wanted.  And, I had free reign to talk to anyone.  I was totally appalled by what I saw.  It was clear that the rate of production promised would not be accomplished with the plant as designed.

Even more disturbing was that there was complete lack of DoD oversight – none.  There were no DoD engineers in the plant.  Back in the Pentagon I asked to meet with the procurement people who were in charge of DoD industrial policy.

There had been such a thing during the time when DoD did not take 35 years to produce an AC that still does not meet it design objectives and did not cause pilots to pass out – the F35.  I was told that the lack of an industrial policy is an industrial policy.  Around that time the administration changed from Bush to Obama and the situation only got worse.  I let it go and continued my job while continuing to see the inside. – BIG

Pushing Customers to Reinvest in Low or Negative ROI ERP Systems

ERP vendors continually reinforce investing more back into the ERP system. This can take the form of unnecessary upgrades. Increasing support costs, customization, remediation, etc..

The Example of S/4HANA

For the past three years, SAP has been telling a wide variety of lies about S/4HANA in order to…you guessed it, get companies to redirect even more money into ERP, even though companies that do this will have little hope of getting this investment back. S/4HANA is an amazingly brazen example of how many ERP vendors harvest their accounts in that SAP’s demand that customers pay for what is merely an upgrade to ECC and should be covered by SAP’s 22%+ yearly software support fee. (we covered this topic in the article Why S/4HANA Should be Free). SAP does not worry about their claims about R/2, R/3 and ECC not coming true, they have simply pushed the claims forward to S/4HANA.

For example, SAP has stated that running MRP and end of period close is really horribly problematic in ECC, and therefore companies should move to S/4HANA. However, curiously, when SAP was selling companies on moving to ECC, they did not, at the time, point out how horribly ECC was in these two processes.

Statements made by both SAP and other ERP vendors win our Golden Pinocchio award. The intent is to make it seem as if everything the ERP vendors offers is “naturally integrated,” and that other vendor that connects to their ERP do not also use adapters. 

How ERP Vendors Overstate the Integration Argument

ERP vendors use their relationships with customers to push their customers to purchase other non-ERP software that they offer, arguing that while it may not be competitive in its own right, at least it is “integrated” back to the ERP system. This argument dilutes the most important aspects of the software that should drive any software purchase, which is the quality of the software, combined with how well that software matches the business requirements of the customer. It is also misleading because ERP vendors use an adapter to connect their non-ERP to ERP systems, in the same way that non-ERP vendors do.

This results in large amounts of mediocre or worse software that has been acquired by ERP vendors, only being selected because it happens to be owned by the ERP vendors. Not because it is good software, and not because it meets the business requirements. Therefore the ERP system cannot be looked at in isolation from its impact on the rest of the company’s IT landscape. While, as was pointed out already, the studies point very clearly to ERP systems not having an ROI, ERP systems also reduce the ROI of the other systems that a company purchases. This is accomplished through the way that ERP redirects purchases away from competitive applications to the applications that the ERP vendor happens to have in their stable.

When taken as a whole, this means that it is the case the ERP has a substantially negative ROI when this larger effect is taken into account. These types of analyses are not done in the industry. The assumption is that ERP has a positive ROI. A positive ROI that has never been proven. Therefore the analysis of the impact of ERP on the ROI of related applications is beyond the industry’s ability to process or even analyze properly. 

The IT organizations within companies that are often more interested in keeping the number of software vendors to a minimum push for what is most cases the worst software for the business inside of their companies to use, so they can both deal with fewer vendors. Another prime motivator is so the IT decision-maker can show their allegiance to specific vendors to which they frequently have more loyalty than to the company they receive their paychecks.

Maintaining a Portfolio of Applications that are Not the Expertise of the ERP Vendor

This has caused ERP vendors to maintain broad portfolios of applications that normally are not adept at maintaining. That means acquiring applications that they have no business acquiring. SAP is an excellent example of this. SAP has really only ever demonstrated competency in ERP, yet they maintain a broad portfolio of bad applications that have nothing to do with ERP. Applications that get acquired by ERP vendors to “broaden the portfolio” become less prominent over time.

Driving Industry Consolidation

ERP vendors have, in many cases, acquired other non-ERP applications, specifically, so they could force these non-ERP applications into their accounts. And thus, ERP has been a force of consolidation in the enterprise software market, making the overall market less competitive.

Along with the consulting companies, many directors and VPs of IT have an incentive to keep up the high investments into ERP for career reasons, which means that ERP continues to soak up resources, further decreasing its ROI from neutral to negative, to steeply negative.

Conclusion

Conceptually, ERP is a combined set of modules that share a database and user interface, and which supports multiple functions used by different business units. Because the ERP modules share a single database, employees in different divisions—for example, accounting and sales—can rely on the same information for their specific needs without any time lag. A major selling point of ERP systems was not that they provided particularly good functionality in any operational area. In actuality, they provided very basic functionality in all areas, but, because the applications shared the same database, anything that occurred in operations was immediately reflected on the accounting side. It was an argument tailor-made for executives who would never have to deal with the functionality limitations of ERP systems personally.

Gartner is credited with naming ERP systems. The term ERP (Enterprise Resource Planning) was adopted from the term “material requirements planning” (MRP) or “manufacturing requirements planning” by simply removing the “M” and replacing it with an “E.” This was done because, while ERP systems contained the MRP supply and production planning method, they also contained sales, financial accounting, and materials management functionality. Companies found that planning was only the beginning of ERP’s limitations. ERP is now well known for many limitations in its ability to present analytical data to customers. The shortcomings of ERP in this regard are a strong precursor to the growth of the separate business intelligence market, a market that was not supposed to have developed if all reporting was done within the ERP system as had been originally projected by proponents of ERP. My research into ERP continually reinforced a central concept that ERP rarely impresses the companies where it is installed. Instead, ERP tends to be discussed as a rite of passage.

Although there is an enormous influence of ERP systems on information technology, remarkably little has been written on the history of ERP. This is for good reason. If history were known, many ERP systems would be reduced in investment, and the reputation of ERP vendors would be irreparably damaged. ERP vendors, the compliant ERP consulting firms, and the paid off IT media and IT analysts make sure that the history stays hidden.

Options for ERP

ERP proponents like to present the idea that there are not options for ERP. In fact, they go a step further. They state that there aren’t real alternatives to whatever ERP they happen to have resources they can bill for. Then after they buy ERP, they tell their customers they don’t have options outside of buying applications from the same vendor that made the ERP system. Consulting companies are very good at leading companies down a restricted number of options, all of which end up benefiting the consulting company itself.

Here is the truth, there are a large number of options to ERP systems, and furthermore, to how any ERP system is used. Here are just a few alternatives — without getting into any specific vendor offerings.

  1. A commercial ERP system can be purchased, but large areas of it unused, and combined with better external functionality.
  2. A commercial ERP system can be purchased, but large areas of it unused and connected to custom functionality/custom applications rather than porting the code to the ERP system (that is not recoding everything in say SAP’s ABAP and porting to the SAP system)
  3. An open-source ERP can be used, and with the large extra pool of money, any number web-based (hosted on AWS or Google Cloud for example) applications can be developed and connected to the ERP system.
  4. ERP can be dispensed with entirely, and a financial solution can be connected to both specialized applications and custom coded applications.
  5. ERP can be dispensed with entirely, and a custom-coded solution can be created which covers financials and other and combined with specialized applications.

These are just five options. Any number of permutations are possible from these options. The evidence of decades of ERP projects heading back to the 1980s is clear; no company of any size or complexity will use an ERP system by itself without support from other applications.

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 Better Managing ERP Content

References

https://mattstoller.substack.com/p/how-bill-clinton-and-american-financiers

Thanks to Ahmed Azmi for his contribution to this article.

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

How to Understand Why SAP ERP is Unquestioned

Executive Summary

  • ERP systems were proposed to reduce complexity.
  • The result was that landscapes became even more complicated.

Introduction

This book was hatched during a conversation with a longtime friend who works in SAP Basis—the infrastructure area of SAP that is concerned with installing and maintaining the SAP applications. During our conversation, he made the following comment:

“Look at the typical SAP landscape at a company. It now has so many applications that it eliminates what was supposed to be the advantage of ERP in the first place.”

My friend’s statement got me thinking: what is known about the benefits of ERP?

ERP significantly predates my introduction to working on IT projects. Because ERP has been on every project in which I have been involved, I discovered through my research was that my colleague’s single observation was only the tip of the iceberg. Only one example of what turned out to be multiple false assumptions about ERP put forward by multiple entities over many years. I held several false assumptions regarding the benefits of ERP myself; I had never analyzed the issue carefully and had been fed a steady stream of misinformation about ERP by biased parties and those who repeated the message they had heard from others. However, after I read the academic research on ERP, I was appalled to find unsubstantiated statements about ERP made repeatedly and routinely by individuals who presented themselves in their articles as knowing something about the ERP market. Of all the technologies I have researched, the coverage of ERP that I found was probably the worst journalism I have ever encountered.

Based on my research, I concluded that the vast majority of articles on ERP are misleading and not useful to people who are attempting to understand ERP truly. Of course, the articles are beneficial to companies that wish to sell ERP software or services. Interestingly, ERP is a topic that has not been analyzed critically outside of academic literature. For those who believe that—at any time, at any place—the best determining factor of what is true is what most people think, this will not be a good book for you. Examples of when the prevailing opinion is incorrect are too easy to point out for anyone to be able to propose that generally agreed-upon opinions are correct. For instance, at one time, various gods explained all physical phenomena.

The Commonality of Believing False Things

In ancient Egypt, there was a wind god, a sun god, a god of the harvest, a god that ate the sun in the evening and gave birth to the moon and did the opposite in the morning. In ancient times people believed that physical phenomena could be controlled by praying to or making offerings to these gods. If that example is from a time too long ago for you, consider this: within the past one hundred years, the most prestigious universities in the US declared that women could never work in medicine because they would become hysterical at the sight of blood. More recently, US intervention in other countries was based upon a “domino theory,” a proposal that was never proven, never meant to be proven, and was simply a justification for the violation of most of the treaties that the US had signed. These are the tip of the iceberg concerning beliefs that were widely never actually seen as a project without an ERP system.

Henry Ford received the Grand Cross of the German Eagle, the highest medal Nazi Germany could give to a non-German. However, you won’t find this story in any Ford commercial; if something does not fit with the desired history narrative, it is conveniently altered until the desirable storyline is created. For this reason, the great frequency with which the biggest and most prestigious institutions have been wrong is underestimated enormously. It is, therefore, quite likely that many commonly held beliefs today are wrong; in fact, it is easy to demonstrate that they are.

ERP as Just Another False Belief

There are many areas where the commonly held—and institutionally held— opinions are at odds with research in the area, and ERP is such an area. During my research, I found some statements that amounted to: “ERP must be beneficial because so many highly paid executives cannot be wrong.” However, couldn’t the same statement be made about mortgage-backed securities and credit default swaps? AIG, Goldman Sachs and Bear Stearns love them; these companies are chock full of smart people, so how could they be wrong? People who are well disposed toward ERP will most likely read this book (actually they will most likely not read it) and reject it out of hand; how can people agree with something that is counter to their financial benefit? If a person consults in ERP, that person is going to be sold on ERP. Who would ever be so thick as to believe something that could negatively affect their pocketbook?

If you are a partner at a large consulting company that implements ERP systems and your large house and large Lexus have been paid for by ERP implementations, you will not want to read this book—guaranteed—and you will not want other people to read it. Your life would be more difficult if this information got out. However, if you are one of these partners, the problem is that you will have nothing but anecdotal evidence (you have seen ERP work and provide value to clients). Or you have argumentum ad numerum (lots of companies use ERP and how can they be wrong?), or ad hominem (the author must not know what he or she is talking about). This is because the research on ERP will not support what you are telling your clients nor your luxurious lifestyle.

Very few people have suggested what I propose in this book, so it’s rare that people have even had to confront the question of the evaluation of evidence regarding the benefits of ERP. I can anticipate the negative responses because one person, Cynthia Rettig, wrote one of the few articles that were not critical of ERP in an ancillary way, but were vital of ERP’s foundation. Many of the criticisms of her article fell into categories listed in the previous paragraph (argumentum ad numerum, ad hominem, etc.).

Even the most educated part of society—people with PhDs in the sciences—finish their academic careers, still clinging to the idea that discoveries disproving the theories upon which they built their careers must somehow be wrong. A famous example of this is Albert Einstein. Einstein was eerily prescient about most of his scientific hypothesis; in fact, he is widely credited with seeing fifty years beyond any of his contemporaries. However, when he made predictions about the new science of quantum mechanics, he was incorrect. Niels Bohr—a thought leader in what was an entirely new field and who did not follow rules of “large” physics—was proven correct. It turns out that God does play with dice, after all. The desire to find evidence to support one’s already existing hypothesis and to filter out contradictory information is called “confirmation bias.” It is one of the most powerful of cognitive biases. It exists in all of us—except not necessarily to the same degree in each individual, and not to the same degree in each individual at each age in their lifetime. Confirmation bias explains why things that are learned early in life, no matter how false, are adhered to so firmly into adulthood. It explains why advertisers will pay more to reach younger viewers than older viewers.

The Young Impressionable Brain

The young brain is the most malleable; it exhibits what neurologists call neuroplasticity, and as such, it can learn new things quickly. As the brain ages, it develops specific neural connections (actually, the development of knowledge means creating some neural connections at the expense of other neural connections), meaning that it becomes increasingly “hard-wired” for particular thoughts and particular ways of thinking as we age. Although sometimes suggested, it is not true that the best-educated people are immune to confirmation bias. The more an individual has invested in any philosophy or course of action, the more they have to lose by adapting to a new way of thinking. The merely following of the advice can reduce the ability to question that advice, particularly if that advice comes from an entity with some authority. The investment can be both psychological as well as real (in that one receives negative real-world consequences for changing one’s views). Both of these factors—the psychological need to protect previous mental investments as well as real-world consequences of changing one’s views—frequently combine to prevent people from changing to a new and better way of doing things and often make the mind impervious to contradictory information. There is research indicating that math is performed with less accuracy when the conclusion conflicts with one’s beliefs.

One question to ask is:

“Can the person who disagrees with the contentions in this article actually afford to agree with them?”

The Test of Financial Bias

Most importantly, do they have a financial bias? As for myself, I can reasonably propose that I am financially unbiased concerning ERP, unlike the few other authors who have written on the topic of ERP. I do not make my income from ERP, but I do derive work based on the sale or implementation of ERP. I connect the systems I work with to ERP, and if ERP were to go away tomorrow, I would connect a different system to the planning systems in which I specialize.

For the longest time, it has been proposed that ERP serves as a backbone and helps the implementation of other systems. However, from my experience, I have found that ERP tends to interfere with implementing other systems. Although, I should say that all of my implementation experience is with “Big ERP,” and in performing research for this book and other research initiatives at Brightwork Research & Analysis, I’ve found some ERP systems that do not impose as much interfere. I have been impressed with several smaller “ERP” applications; while they have similarities in terms of their footprint, they have nothing in common with Tier 1 or Tier 1 ERP software vendors in terms of costs, account control, business model, and a variety of other factors.

The Lack of Questioning with ERP

Quite merely, ERP has been ubiquitous and an unquestioned necessity. Indeed, I don’t recall people saying they liked any of the ERP systems that had been on these projects, but that did not matter; ERP was just the reality. After this conversation with my colleague, I began researching the topic of ERP’s usefulness and value-add to companies. I expected to find a large number of books—and quantities of research and articles—that demonstrated the benefits of ERP. Instead, I found quite the opposite. Here is a synopsis of what I found:

  1. There are few research studies on the benefits of ERP. The research that does exist shows that ERP has low financial payback.
  2. Research into multiple aspects of ERP by serious researchers (not some survey by a consulting company or IT analyst firm) clearly shows that ERP significantly changes companies, but that the benefits from these changes are dubious. That is, there can be a mixture of positive and negative outcomes from ERP implementations.
  3. The actual research is at complete odds with most articles on ERP, which almost universally promote ERP as a virtue.
  4. Most of the information on ERP is unsubstantiated hyperbole written by people who benefit financially from ERP implementations directly, or by those who have “sampled the Kool-Aid” and don’t question any of the assumptions about ERP.
  5. There are no books that question the benefits of ERP.
  6. There is no book on the history of ERP.

What the Research into ERP Revealed

What I discovered through my research was that my colleague’s single observation was only the tip of the iceberg, only one example of what turned out to be multiple false assumptions about ERP put forward by multiple entities over many years. I held several false assumptions regarding the benefits of ERP myself; I had never analyzed the issue closely and had been fed a steady stream of misinformation about ERP by biased parties and those who repeated the message they had heard from others. However, after I read the academic research on ERP, I was appalled to find unsubstantiated statements about ERP made repeatedly and routinely by individuals who presented themselves in their articles as knowing something about the ERP market. Of all the technologies I have researched, the coverage of ERP that I found was probably the worst journalism I have ever encountered. Based on my research, I concluded that the vast majority of articles on ERP are misleading and not useful to people who are attempting to understand ERP truly.

Of course, the articles are handy to companies that wish to sell ERP software or services. Interestingly, ERP is a topic that has not been analyzed critically outside of academic literature. For those who believe that—at any time, at any place—the best determining factor of what is true is what most people think, this will not be a good book for you. Examples of when the prevailing opinion is incorrect are too easy to point out for anyone to be able to propose that generally agreed-upon opinions are correct. For instance, at one time, various gods explained all physical phenomena.

Conclusion

Since I began working with ERP in 1997, I have found that ERP systems have interfered with the value that can be obtained from business intelligence systems, bill of material systems, web storefronts, etc. This is in addition to the planning systems I have implemented (in fact, pretty much any system that must be connected to the ERP system). In the past, I accepted this as the way it was: I thought IT implementation had to be difficult and frustrating. My exposure to many systems that are far easier to implement and have better functionality than Big ERP has led me to question my assumptions. More companies should be asking themselves this question; unfortunately, these types of questions are not asked because groupthink has settled over the topic of ERP.

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 ERP Myths Content

References

Thanks to Ahmed Azmi for his contribution to this article.

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

How to Use the Latest New Digital Transformation Terms!

Executive Summary

  • Digital transformation is ramping up the bridge and has caused its digital transformations requiring a whole new set of super open-minded terminology.
  • This is not some “Deepak Chopra-ish” fanciful wordplay, but serious terminology enhancements that all implementers and OTs should be aware of.

Introduction to the New Digital Transformation Terms

The term digital transformation has been with us for a few years, with digital transformations appearing left and right. However, there are special conditions that have now arisen on projects that require further elaboration through terminological discussions. You will learn about these new and groundbreaking digital transformation terminologies in this article.

What is the Right Terminology for Digital Transformations that Fail?

The problem with the term digital transformation is that while we switched out the word “implementation” for digital transformation, it was quickly determined that nothing changed on projects. This lead cynicism to run rampant. Depression occasionally set in, with some of those in software implementation going so far as to wonder (out loud sometimes) if it was merely wordplay.

What did change is that many marketing departments had to use the “find-replace” command in their word processing systems to bring their documents up to snuff?

Within a short period, a revolution occurred in the IT industry, and there were no longer any software implementations.

Why might you ask?

Well, to understand why we need to go back to why the terms were switched in the first place.

The Digital Transformation Master Plan

What follows is top secret. It is not for presentation to non-SAP friendly personnel.

This graphic displays the bad old days of software implementation.

SAP and SAP consulting firms figured out the fundamental flaw in software implementations. And it had nothing to do with the lies told during the sales process, immature SAP applications like S/4HANA being implemented or faked resumes by SAP consulting firms. No, the problem was that the declaration of success had to wait until the end of the project. And since SAP projects failed with such frequency, it meant that most projects would never get to the promised land of being declared a success.

SAP and its consulting partners needed to make a radical change to address this issue.

Introducing……”DT!”

The answer was simple. Make the project associated with a successful terminology so that the process itself rather than the outcome was the focus — i.e., a “digital transformation.”

This way, the project is already successful because it is associated with something considered virtuous. Who in their right mind could be against transforming something?

It does not matter that the term is meaningless in the modern context as it is from the 1900s describing the transition from nondigital technologies to digital technologies. Almost no SAP consultants or customers will bother to look it up!

Assert meaningless terms to your heart’s content!

Furthermore, it turns out that IT departments also have no interest in validating the success of their projects, and are very happy to use this terminology also. Everybody wins!

The 100% Conversion Ratio of Software Implementations to Digital Transformation

We are delighted to report that the conversion of SAP software implementations to digital transformation was 100% successful. There are now no more software implementations occurring…..anywhere.

However, the industry was left with a problem.

The Need for New Digitial Transformation Terminology

Even if digital transformations fail, they are still referred to as digital transformations. For example, the fact that Lidl recently halted one of its SAP projects to go back to it is far more desirable “legacy” system did nothing to diminish the fact that it was still labeled as a “digital transformation.” It is still labeled as a successful implementation on the KPS website. However, was it? Both SAP and KPS still consider the Lidl SAP failure to be a digital transformation…..because they got paid.

Digital Transformation or Bank Account Transformation?

This brings up the question, should a digital transformation that fails instead be more accurately called a..

“Digital bank account transformation”?

And this leads to the next topic.

What is the Right Terminology for Digital Transformations that Fail and are Greater than $300 million?

Now, if the digital transformation fails but also costs more than $300 million? After much discussion, it was agreed that it would be called a..

“digital boondoglefication.”

What is the Right Terminology for Digital Transformations that Lead to High Degrees of Account Control?

A significant benefit of ERP digital transformations is that they put the vendor and consulting company in a good position regarding account control. This allows the vendor and consulting partner the face time to talk down any competing applications. Our research into ERP implementations….digital transformations is that this is a primary ROI to ERP digital transformations. As a high degree of account control is the desired outcome of such projects, the question has been posed “what should they be called.” It was concluded that this is a.

“digital accountformation.”

Conclusion

This is an exciting time to be developing new terminology for the digital transformation industry, and we are happy to report on all of the tremendous new terminologies that are coming from the field. As with the original base term of digital transformation, all of the new derivative terms are equally evidence-free. Digital transformations are transforming digital transformations, and that can only be a good thing, as this video from the digital transformation center can attest.

 

Digital transformation is not simply a term being parroted by people who have “no idea what they are talking about.” Far from it. Endorsements for digital transformation can be found in this video. It is easy to see the excitement in the responses from these endorsements. It turns out that digital transformation is creating more breakthroughs leading to more OT booms than at any time in history (according to the video). 

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 Digital Transformation Content

References

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

Is SAP ERP Good Because it Won Against Other Options?

Executive Summary

  • The concept is sometimes promoted that because SAP ERP is popular, that it must lead to good outcomes for customers.
  • What were the true reasons for SAP ERP’s popularity?

Introduction to SAP ERP Being Popular as an Argument

We recently found this quote on ECC regarding its popularity.

“R/3 in its days – before SAP had the dominant market position it has today – did win against most of the options on the market so it had some merit. “

How SAP Sold Out Customers to Corrupt Consulting Firms

There are many things to say here. First, SAP was the most aggressive vendor in giving away it is consulting to consulting firms. These firms, in turn, recommended SAP. Not because SAP was right or the correct fit, but because it allowed them to make the most money. Therefore, the playing field was not level. Consequently, it is not at all evident that this was a good decision merely because many companies selected ECC.

How is SAP Degrading Customer’s Investments into SAP?

Moreover, as I observed, that initial decision is looking worse and worse as SAP is changing the terms of the deal by giving customers a bad upgrade option in S/4HANA and by using indirect access to illegally push the account to buy SAP. Customers now deal with an SAP that is making up false constructs (like Type 2 indirect access) to control them. SAP thinks and behaves as if they are owed a certain percentage of the IT budget, even if the customer does not want to use their software. A vendor that acts this way is a liability to have in the building. SAP will be pummelling its customers for the next two decades. Every year that passes will likely increase the regret that they ever purchased SAP.

Who Likes ECC, Customers or SAP Consultants?

There is no evidence that ERP systems are beneficial to customers that implement them. I can say I have never seen an SAP account particularly happy with ECC. Users also do not enjoy working with ECC. They find it a burden and SAP is frequently lampooned at my client sites. It is also often commented that the system does not live up to expectations or is otherwise “takes forever” to “get things done.” ECC frequently appears to be a system that was forced on the users by the executives rather than a system that users want to use. The people who are happy with ECC, are consultants who make money from ECC.

The most prominent defenders or ECC or SAP on LinkedIn are never customers. They are SAP consultants who say a lot of unscientific things to defend their source of income. 10 out of 10 SAP consultants enjoy billing hours for SAP. I keep pointing to academic research that no other ERP consultant has read and that no ERP consultant is interested in reading. That is the academic consensus of decades of papers on the subject demonstrates no ROI from ERP systems.

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.

Is it Right to Lead Clients into SAP Software Failure?

Executive Summary

  • S/4HANA is an implementation that makes money for SAP and consulting partners but has a very low likelihood of success.
  • S/4HANA implementation has turned into quicksand, and the consulting partners know this.

Introduction to S/4HANA Risks

Our observation from many implementation data points of S/4HANA as outlined in our S/4HANA implementation study is that S/4HANA is the highest risk application with the least likelihood of going live of any application we track. One major reason? S/4HANA is not a completed application.

The risks of S/4HANA implementations that are specific to S/4HANA (that is exclusive of all of the factors outside of S/4HANA such as the implementation partner, customer, etc..) break into the following:

  1. Incomplete nature of the overall application. (see SAP’s Misleading Storyline For S/4HANA Being Incomplete)
  2. Problems with HANA has in supporting a S/4HANA ERP system.
  3. Customization remediation effort due to changes in the database schema.
  4. Data migration effort due to the changed in the schema and the shortage of tools for making the migration (along with migrating custom tables)
  5. The loss of functionality through “simplification.”
  6. Customization remediation effort due to changes in functionality.

Obtaining Financially Biased Information About S/4HANA from SAP’s Coterie

Interestingly, the entities that provide information about S/4HANA to the market are either SAP itself or SAP consulting firms. SAP has been massively overstating S/4HANA as covered in How Accurate was Hasso Plattner on S/4HANA? Media entities that cover SAP are paid directly by SAP. We are a research entity that focused mostly on SAP. When we receive research requests from companies interested in the validation of information about S/4HANA that has been provided by SAP and their coterie, we find that in 100% of cases, the company is working from an inaccurate set of assumptions. And in 100% of cases, the assumptions are positively biased. It is clear that the objectives of SAP and their coterie is to get S/4HANA into companies by any means necessary, and by telling any lie, they need to tell.

S/4HANA’s deplorable implementation history has been almost entirely censored. SAP consulting firms won’t discuss these failures and halted projects with prospects; they want to discuss SAP marketing talking points. And when an individual from a consulting firm writes an article about S/4HANA, they are cautious to never discuss their financial bias in favor of S/4HANA, or that they, for instance, have a quota to sell S/4HANA services. Instead, they prefer to present their views as if they are impartial.

This explains articles like this that vastly overestimate the readiness of S/4HANA for implementation and underestimate the implementation challenges with S/4HANA. They have no other purpose than to drum up business for S/4HANA implementation services.

The S/4HANA On-Premises vs. Cloud Distinction

These are all called out for S/4HANA on-premises. S/4HANA Cloud has too small of a functionality footprint for any one company but small professional services firms to implement. (S/4HANA on-premises and S/4HANA Cloud are two separate applications, something which SAP deliberately obscures to customers and Wall Street.)

Implementation Costs

Secondly, the implementation cost of S/4HANA on-premises is guaranteed to be extremely high for the factors listed above. Merely the costs of items 3 and 4 will be extremely high. S/4HANA is like no other SAP ERP upgrade, which was already quite problematic and expensive.

ERP Failure Rates

ERP and, more broadly, enterprise software failure rates are a frequent topic of conversation among those that work in the industry. However, what is curious is how undiscussed the implementation of applications that have a very low likelihood of implementation success. If the implementation advisory function is more focused on billing hours than in selecting applications that have higher probabilities of implementation success, then naturally, failure rates will be higher than necessary.

Increasing Consulting Revenues with S/4HANA

Even with S/4HANA’s extremely low implementability, SAP consulting firms still want the S/4HANA consulting business. This means they work with SAP to mislead customers, and prospects about the existing S/4HANA case studies, their personal implementation experience with S/4HANA, and S/4HANA’s revenues.

But what happens if the project that is being recommended by the consulting company has close to no chance of being successful?

Consulting

What we are seeing is a consulting ecosystem that is recommending S/4HANA implementations that, in most cases, will not go live and will worsen the condition of the client, but which benefit the consulting company. So should consulting companies be recommending implementations that they know will fail? The SAP consulting market has become so profitable for so many companies, combined with SAP bringing out such immature applications, that implementations are recommended that have close to zero chance of improving the condition of the customers.

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 Improving Implementation Content

References

Repair MRP Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.

Getting Serious About MRP Improvement

Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re

The Most Common Procedure for Supply and Production Planning?

While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Opportunities to Improve MRP
  • Chapter 3: Where Supply Planning Fits Within the Supply Chain
  • Chapter 4: MRP Versus MRP II
  • Chapter 5: MRP Explained
  • Chapter 6: Net Requirements and Pegging in MRP
  • Chapter 7: Where MRP is Applicable
  • Chapter 8: Specific Steps for Improving MRP
  • Chapter 9: Conclusion
  • Appendix A: Calculating MRP
Categories SAP

Is SAP’s ERP System Innovative?

Executive Summary

  • SAP’s ERP systems are often presented as a useful application, even innovative, but we question this assertion.
  • To understand SAP ERP, it becomes necessary to know how ERP was originally sold when SAP first became a well-known vendor.

Introduction to Whether SAP’s ERP Was Innovative

SAP claims to be an innovative application. The following quotation presents this.

“To be fair to SAP, they have great products and they have not so good products 🙂
SAP Business Suite is a great ERP when implemented properly and deployed on a scalable/reliable platform (ahem, e.g. Oracle).
You have correctly pointed out all those inaccurate claims on their other not so good products. However, this shouldn’t diminish those positive impacts of their very trusty and reliable Business Suite applications since 1992. Rational product development decisions should prevail over old feud though. Moreover, the rational thing to do is to continue the ECC product line way past 2030 with updates in technology and Business processes so that true innovations without disruption is what all customers can depend on.”

Is ECC a Good Product? Is it an Innovative Product?

There is a consensus that ECC is a good product. SAP’s entire existence is due to ECC.

However, is ECC innovative? To consider this question, let us consider the actual definition of innovation.

“Innovation can be defined simply as a “new idea, device or method”. However, innovation is often also viewed[by whom?] as the application of better solutions that meet new requirements, unarticulated needs, or existing market needs. Such innovation takes place through the provision of more-effective products, processes, services, technologies, or business models that are made available to markets, governments and society. The term “innovation” can be defined[by whom?] as something original and more effective and, as a consequence, new, that “breaks into” the market or society.” – Wikipedia

Therefore, innovative means the company came up with something that no one else came up with. It must be new. Now let us consider ECC.

ECC was just a better and broader implementation of something all the ERP vendors were doing back in the 1980s. At that time, software vendors were acquiring MRP vendors and incorporating MRP systems into financial systems to make “ERP.” The benefit was integration, but less discussed was that much was lost in this process. For example, it worsened the MRP systems, which is something I covered in this article Why are Companies Still Running MRP from ERP?

The idea was that with one system, costs would decrease. However, can anyone look at the costs of ERP implementations and say these reduced costs?

Another problem is that ECC is so weak in so many areas that without Excel, it would die.

The number one way to report and do analysis in ECC? Yes, that would be Excel. ECC has been fantastic for creating external spreadsheets. It seems that Microsoft does not get enough credit for ECC being able to function. 

ECC is Good Outside of Finance?

ECC is challenging to use in supply chain management (the area of functionality I have been consulting in for decades in SAP), and it received far less development effort than SAP’s FI/CO module. I consult with ECC customers that generally have great difficulty in managing the supply chain process with ECC. The supply chain functionality was hastily created by what looks to be force feeding supply chain books to developers. The forecasting functionality is virtually impossible to work with. I could go on and on. But this is why I recommend to companies that they do not perform MRP or forecasting or any supply or production planning in ECC.

Deloitte and Accenture, on the other hand, desiring to bill the most SAP hours as possible, never recommend reducing the reliance on SAP, no matter how bad the functionality. The entire SAP consulting ecosystem exists not to help customers, but to bill as many hours in SAP as possible. Any approach that reduces this primary objective will never be recommended. SAP gives awards to consulting companies, no matter how much they mistreat clients. Even WiPro won an award!

However, SAP proposes ECC is excellent for all of the things mentioned above. The result is that now companies perform these functions in ECC with great difficulty. This issue extends to analytics (all ECC systems have separate analytics systems) to sales order management (CRM has taken much of ECC’s sales order origination function) (why SAP loves indirect access claims against Salesforce).

ECC, a System Propped Up By Customization, Other Systems and Excel

As time has progressed from the initial “sales job” for ECC as the Swiss Army knife of applications, ECC has given up increasing amounts of functionality to other better applications. No one seems to remember that this is not what SAP or their coalition of the billing said would happen. Originally CIOs wanted to get rid of their multiple systems, but decades later, ECC also has….you guessed it, many systems connected to it. And SAP is more challenging to integrate with other systems than any other vendor.

Without these systems, and without extensive customizations (something else that SAP lied to customers about), and without exporting to Excel, the frustration with ECC would have no release valve, ECC would be removed from companies at a far high rate. People that consider the popularity of ECC neglect to mention that ECC is propped up from so many dimensions. ECC can be regarded as like an older man. If four other people drive him around and give him his medication, he can have an active lifestyle. But without that external help, he is not going anywhere.

ECC is stable, comprehensive (a relative term I know), standardized, and probably a few more accolades…..but innovative? Companies that implemented ECC are better off than before they purchased ECC? Not the companies I see, and that is not what the academic research indicates.

And as we will discuss, life is about to get even more difficult for ECC customers.

When and How ERP Became the Largest Software Category

ERP became the largest enterprise software category purchased during the 1980s, and it held onto this title until just recently until giving it up to CRM. But it did so without any evidence that ERP improved the condition of companies that purchased it and used it.

It is important to recall that SAP and consulting companies told customers that ECC was the only system companies would never need and would lower their spending. Over decades a tremendous number of companies have lied about the impact of ERP on customers. Because all of the money is on the side of the ERP “industrial complex,” they are never called out on their inaccuracy. These are the usual suspects. And they have something fundamental in common. None of them care about what is true.

The Sordid History of ERP

Looking back at the history of ERP, it is easy to see that ERP was purchased because it became a trendy item. Deloitte, Gartner, Accenture, and a whole industry — all with a pro-ERP financial bias — all told companies they had to have an ERP system. My analysis of the academic literature is that ERP systems have a negative ROI (as covered in The Real Story Behind ERP).  And because of the high cost of SAP ECC implementations and ongoing maintenance and the fact that ERP systems don’t particularly enable companies to do things better than they did them before.

SAP ECC has a strongly negative ROI. SAP ECC implementations are the most expensive implementations that we track. We offer two online TCO calculators for ECC, one for large customers, and a second for extra-large customers. Lidl just canceled a 7-year project that cost 500 million Euros. Many billion-dollar and up R/3/ECC failures are all through SAP’s history. Imagine what happens to the ROI of ERP when the failures are taken into account?

Both software vendors and consulting companies have been cautious never to let their customers know the TCO of ERP. It would be ruinous to ERP sales, and therefore would not allow the most critical driver in all of the ERP industry, namely quota attainment.

Trapped by SAP ECC and Lead to the Slaughter with S/4HANA?

Executives brought no standard of evidence to the decision making process concerning ERP, never asking what proof vendors or consulting companies could point to. Executives within customers that purchased ECC were not so much “thinking” as following the adverse risk strategy of just “looking at what your neighbor is doing.”

Now, these companies are stuck with ECC systems that offer little flexibility, are extravagant to maintain, and with the introduction of S/4HANA have a highly unappealing upgrade path. S/4HANA cannot be upgraded from ECC, but is a full reimplementation, pounding customers budgets once again. This is truly outrageous, but the consulting companies are silent on this, presenting S/4HANA as a positive development. (the customer’s expensive TCO is money in consulting firm’s pockets)

Deloitte and Accenture’s perspective on software TCO can be understood by Matthew McConaughey’s speech in the Wolf of Wall Street. “You take your customer’s money and put it in your pocket.” This is how the SAP consulting companies think about their customers. 

With the introduction of S/4HANA, a system that over three years after the introduction is still not ready to be implemented, SAP has made the entire value proposition of their ERP system from bad to horrendous. And this is before we get into the other questions of the even lower ROI products that customers often buy from SAP to connect to ECC, and the indirect access liabilities of HANA, which SAP stipulates as the database for S/4HANA.

Conclusion

We conclude that while SAP R/3/ECC has been great for Deloitte, Infosys (and, of course Oracle who loves those database revenues driven by ECC with 70% of all ECC instances using the Oracle DB), ECC has not been beneficial for customers that implemented it. That is, these SAP customers would have been better off custom coding their solutions (or keeping their existing solutions). Moreover, now companies have SAP, they have SAP account reps trolling their hallways. These sales reps are insistent that their customers double down on their negative ROI SAP ERP investments with even more negative ROI investments into more SAP products that are a step down from ECC. And that with indirect access, customers may have to pay for connecting any non-SAP applications to the negative ROI SAP ERP application. The entire SAP scenario has completely lost the plot. And money rather than product drives every decision.

If only customers buying SAP ERP back in the 1980s and 1990s had any idea that this would be the eventual outcome of their trendy SAP ERP purchase.

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 ERP Content

References

https://en.wikipedia.org/wiki/Innovation

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
Categories SAP

Personally Attacking Those Who Critique ERP Failures

Executive Summary

  • Pro-ERP consultants personally attack ERP critics and point the finger away from the software products when discussing ERP failures.
  • Pro-ERP consultants and ERP software vendors motivated to sell products, silence ERP critics, and create a narrative that project management teams are to blame for ERP failures.
  • Lawsuits, which are often revealed due to public disclosure laws, show that many companies are unable to implement ERP products successfully.

Introduction

ERP implementations have a long money trail behind them. It has come to my attention that there is a strong network of pro-ERP consultants that spend at least some of their time attempting to promote a very strongly pro-ERP overlay or interpretation onto ERP failures. Those who disagree with the “ERP friendly” post-mortem analyses of ERP failures are singled out for personal attacks.

In this article, we will review a textbook case of this type of personal attack.

A Standard Pro ERP Comment

The following is a share on a LinkedIn post by Eric Kimberling, who published the statistics of ERP implementations. The following is the slide that Eric shared.

Now notice the response from a pro-ERP commenter regarding this analysis.

Hi Eric Kimberling your assessment is cruel but dare to say you are right especially with 80% of mediocrity.

That is “awesome” that with 30 years of ERP on the market and so many beautiful methods, tools, and certifications we still can see poor picture with many hysteric voices around ERP. Of course, even these mediocrities are not really so bad (as it somehow works) but bad things are much louder than good.

After all, here is definitely a lot of things to do. My take is we tend to much focus on material things and toys are drawing our attention away from the main area of ERP – these solutions are still for people not for robots or AI!

Studying loud failures, I found all these started very shiny with sound reasonable vision. They drifted astray. The cause of poor picture is that ERP project management lack at persistence with this vision.”

Let us review the assumptions within this comment.

Non-Pro ERP Voices are Hysterical?

The commenter states the following:

“many hysterical voices around ERP.”

This implies that if a person critiques ERP implementation failures, then that voice is hysterical. However, I review ERP sales material, and on the frenzied scale, the arguments made to promote ERP systems appear far less rational than those that critique ERP implementation failures. In the article What Was the Real Story with the Revlon S/4HANA Failure?, we found that the ERP system implementation undermined Revlon’s ability to function. Revlon was not told anything about how this ERP system was not ready to be implemented.

Conversely, one would naturally assume those that cover up ERP failures or defend them or point to the customer being responsible are level-headed and rational (not hysterical).

This sets up the debate under the artificial construct between sane people (defenders of ERP failures) and those that are insane (those that critique ERP failures). What a convenient way to move away from addressing the points of your opposition.

Many Beautiful Methods, Tools, and Certifications?

The commenter states that:

“so many beautiful methods, tools, and certifications we still can see poor picture.”

But how true is this contention?

I have reviewed many of these methods in the article, The Real Story on SAP Implementation Methodologies, from SAP and many consultancies.  My conclusion is that these methodologies are primarily written by marketing and sales entities, and they don’t have much of an impact on projects. Having reviewed so many of them, I have no idea what this commenter finds so impressive. Some methodologies, which have been backward engineered to sell more services, do not address the primary risk factor.

How do I know this?

Well, first, it is clear from reading them. Many readers of these methodologies are not even aware that a methodology is not what they think it is, as I cover in Why Methodology Does Not Mean What You Think it Does.

Secondly, when I worked on Deloitte’s methodology for SAP, I was told to adjust it so that it could incorporate as many of Deloitte’s services as possible. Therefore it was less of an implementation method than it was a sales document. Deloitte presented hirees all of their various services as part of a “proven approach” to improving the project. The statements had no foundation in research, and the only thing they were proven to do is meet a quota for a partner. I have spent many hours with partners at these consulting companies, and none of them care about their customers. They care about money. They are all under heavy quota pressure and cannot afford to put their customer’s interests first. These are the institutional incentives within these companies.

Reviewing the History of Implementation Methodologies (for SAP)

If we look at SAP for a moment, for over 20 years the company has introduced an array of methods that were ostensibly designed to speed implementations, such as ASAP (which we cover in Did ASAP Ever Reduce SAP Implementation Timelines?) and the Rapid Deployment Solution or RDS (which we cover in How to Best Understand the Faux SAP RDS).

I have never seen one of these methodologies make one bit of difference in any SAP project. They aren’t even designed or primarily designed by implementors, but instead by partners and marketing resources — people without an authentic understanding of the reality around implementations.

SAP’s ASAP was introduced with great fanfare, but did anyone go back and check if it did what it said it would do?

Of course not.

Let us say that a consulting partner did, and the method did nothing. How would they publish these results and expect to keep on good terms with SAP? Experienced implementers (like myself, I say, implementers that do the work, not PMs that are associated with management and do not touch SAP) say that these methodologies are to romance the executives.

The ERP consulting space does not question the intent of these “methodologies.” Perhaps they are never intended to improve implementations, but instead intended to do what they look like, which is to improve the consulting company’s ability to close sales.

The Result of All of These “Beautiful Methodologies?”

Now, after all of this, how long do SAP implementations take? Well, our research shows that SAP implementations are lengthening, not shortening.

Why?

With products like HANA and S/4HANA being so immature, (for details, see Analysis of Steve Chaflen’s Article on S/4HANA Maturity), these implementations are restricted from completion. With SAP’s new C/4HANA, its maturity is so far out, yet still, the company already started promoting it at SAPPHIRE 2018. Bluefin Solutions published an article trying to hype customers on C/4HANA as covered in the article, How Accurate Was Bluefin Solutions on C/4HANA?  Bluefin Solutions could have told its prospects the truth about C/4HANA’s maturity in the critiqued article, but did they? Of course not. That would be bad for sales. This gets to the issue of why the consulting companies that implement solutions don’t have any interest in honestly informing their “clients” of the reality of these applications.

There is also no evidence that success rates for ERP projects have increased.

Studying ERP Failures Honestly or Through the Lens of Financial Bias?

To study failures in a way that leads to a beneficial outcome for future ERP projects means to study them honestly and not from the perspective of “what is in it for me.”

As I have observed in the past, the majority of those writing about ERP failures are riddled with financial bias, as they want ERP implementation to continue unabated. In my meta-research into all (literally all) of the academic literature on the returns from ERP systems going back to the 1980s, the research showed no ROI from ERP implementations. This is covered in the book The Real Story on ERP. This should be no great surprise as these systems are so expensive to implement. ROI is possible from ERP, but not if you choose a Deloitte or IBM to implement.

ERP Failures Are Loud?

The commenter argues that ERP failures are “loud.”

The implication is that these failures attract people’s attention and distract them from the great story of ERP.

But where is this great story?

The idea of ERP systems as some great enabler has been a fiction constructed to sell ERP systems. Furthermore, how much money goes into publishing ERP failures?

Not much.

Now, let us see how much money goes into promoting ERP as valuable items to purchase. As covered in the article, How to Best Understand the Control of SAP on IT Media. SAP funnels money to major IT media outlets for positive media coverage. Oracle and other ERP vendors with ample resources do the same. IT media sources serve as a PR/marketing function for the IT companies, and this means that anything that increases revenues and margins will be covered. When vendors interact with IT media entities, they say the following.

“Impress us, show us that our spend with you is driving our revenues and lead generation.”

And of course, the media entities do what they can to bend over backward to show them why they should spend more with them.

IDG owns 8 of the top 20 IT media brands. 

This is the page that readers of IDG IT websites don’t see; it is directed towards advertizers and those that want to publish paid placements. Notice the quotation. 

“IDG organizes our content, demand generation, and ad serving so that we can segment audiences deeper an anyone else. Our customers know they can rely on IDG to deliver the right buyer at scale exactly when they are most receptive to a marketer’s message…”

That is journalism?

They are producing rigged content designed to get the “audience” to buy. IDG is willing to republish anything vendors or consulting companies say, and the other IT media entities work the same way. You can even choose the media “brand” you would like your false information published. It is customer focused!

It should be noted that there is no overlap between what the IT media entities do and journalism. Journalism only arose under a condition where the reader, in some way, compensates the publisher for the content they consume. In every situation, when the publisher receives their income from companies exclusively, the content devolves into propaganda. This is a problem in media that cuts across the different media categories as publishing have been demonetized by the Internet and by companies like Google that take the advertising dollars for themselves choking off revenues from content creators.

Not only do vendors and consulting firms not care about what is true, but there is also an industry willing to repeat any message in return for money.

To flourish as an IT media entity, one must get advertising dollars and paid placements or e-mail addresses (in the case of TechTarget, which only exits to collect and share e-mail addresses). IT media entities compete with each other for these industry sourced dollars, and people are promoted or demoted based on how well they cater to industry income sources.

In IT media, there is no dedication to the readers, as readers (after demonetization of media brought by the Internet) do not pay for content. And in this milieu, ERP vendors are some of the largest spenders.

For companies that want to get their story out, each media entity has a dollar figure attached. Gartner is the leader because they can charge the most for access to their readers. Gartner can punish companies that don’t pay them by excluding them from various ratings. 

ERP consulting companies have great reach, and there is no mention of the actual ROI or success rate of ERP systems on any of their web pages. ERP and consulting marketing spend massive, and it’s all designed to get companies to purchase ERP systems. The argument that more corporate money supports the case against ERP (by promoting ERP failures) overhyping ERP purchases is complicated to make. Let us think for a moment:

How much money do IDG, Gartner, and others receive to criticize ERP? How much money do they get to promote ERP?

Once again, nearly all the money is on the side of promoting ERP!

*I want to apologize for using that exclamation point. That came extremely close to being “hysterical.” It’s essential to observe corruption but to be non-plussed. It is the true sign of maturity to accept corruption as entirely normal and nothing to get worked up about. People who casually accept corruption are well-balanced and perfectly adjusted members of society. People that are revulsed by corruption need counseling.

A History of False Constructs to Promote ERP

Over the decades since ERP was introduced, ERP has been promoted with a series of false constructs ranging from how they replace legacy systems (covered in How SAP Used and Abused the Term Legacy) to the idea that a significant competitive advantage could be attained through re-engineering (included in Re-engineering and its Impact on ERP Sales). We have analyzed all of the constructs behind ERP and found nearly all of them to be false.

Yet, how often has the accuracy of these constructs been challenged by vendors, consulting companies, or IT media entities? How does the money flow into these entities? ERP proponents have not been held accountable for the many things (benefits) they said that would happen with ERP, which did not occur. If the field were titled “against ERP proponents,” they would not have gotten off “Scott Free.”

The Reality of ERP Systems Versus the Fantasy

Companies that have implemented ERP systems do not have the competitive advantage vendors and consulting companies promised them. They have spent mightily and made vendors and consulting companies, but what company is today using ERP is “enthused” about the system they now have? What company that has ERP sees it as some empowering system, versus a bookkeeping system that gobbles up the IT budget?

Who was the ERP system designed for? To benefit the customer, or for the vendors and consulting firms?

A Single Reason for ERP Failures: Project Management

This commenter states the following.

“I found all these started very shiny with sound reasonable vision. They drifted astray. The cause of poor picture is that ERP project management lack at persistence with this vision.”

Did all of the failures start with a reasonable vision? Let us parse that comment.

Did the management begin with a realistic understanding of what they purchased, or was inaccurate information given both in the sales process and during the implementation? I would say it’s the latter. Finally, this commenter concludes that the single reason for ERP failures is a “lack of persistence” with a “reasonable vision.”

Really?

Does every ERP implementation fail because of a lack of persistence?

This is the status quo explanation that obviates any need on the part of the vendor or the consulting company to provide accurate information to the customer. How convenient. But also, observed through its proper lens, what an intensely self-serving comment. It appears that all of the customers that fail with ERP are losers, and lack the fortitude and persistence to follow through on the vision of ERP. That is to persevere so that they can finally attain the golden chalice of a system with a negative ROI.

They are weak and soft-bellied! This falls into the category of victim shaming. We cover this in the article How to Know if You are Tough Enough for ERP?

Unfortunately, I have also been categorized as a weak soft-bellied loser who would not jump on board (aka get with the program) with the “vision” of the company being created by the head of sales for a vendor.

The man who famously said…

“I never want to hear something not existing as an excuse to not sell!”

The Illumination of ERP Industry Practices Brought by Court Cases

These public ERP failures and the lawsuits are of great concern to ERP proponents because they expose the truth of these implementations. This is the only time that the dirty underside and tricks played by vendors and consulting companies are given a public forum. And let us remember, the only reason this occurs is that the legal systems in the countries where these cases are filed require public disclosure of the complaint. Corporations do not share the truth in a public forum. If it were left to corporations, the PR and marketing departments would massage all information. However, the courts require the publication of the complaint. Court complaints are why we know of ERP failures, and they are what ERP entities seeking to defend their money train find so disagreeable.

Since ERP projects began failing, there has been a strong attempt by vendors and consultants to control the narrative in a way that is favorable to the industry. SAP has a specific way they release paid placements through major IT media entities to control the narrative to point entirely away from themselves, as covered in the article The Art of Blaming the Client When a Project Fails.

  • This article points out that Michael Krigsman (the IT failure “expert”) makes comments about project failure that have nothing to do with the facts of each of the project failures on which he comments. No matter which projects, Michael Krigsman is there with aphorisms that discuss how “training is important.”
  • Neither the IT media entity nor the sources that are compensated by SAP disclose their financial bias. One wonders why a media entity would not disclose its payments from a vendor to help point blame away from the vendor. Could there be any possible reason for leaving out such information from the reader? If anyone can figure out this intensely complex question, please comment because it is simply too complex for this author’s limited brainpan.

Lying About ERP’s Mapping to Requirements Cannot be Discussed

Deloitte/IBM/Infosys, etc.. lie to accounts before they close the account. They habitually exaggerate how much SAP will cover the requirements, as covered in the article The Overmapping of ERP Systems to Requirements. This is so well known at this point. It is outrageous to see status quo ERP defenders imply it does not exist. Deloitte/IBM/Infosys, etc.. lie to accounts during the implementation to put off the day of reckoning.

When these behaviors are brought up, the personal attacks begin from the SAP consulting defenders! Why is it virtually every time the SAP consultants, whether they work for the implementation company ceaselessly defend the consulting company and never address (i.e., quickly pivot away) from the issues with the vendor and the consulting firm? Interesting isn’t it. The response is thus…

“Its really much more complicated than that……”

Now the pivot…

“….the real issue is the lack of training, focus __________ (fill in the blank)”

Notice…” it’s much more complicated” always results in “it is the client’s fault.”

No matter how much money is wasted on ERP projects, ERP status quo defenders are always there to tell pro-reform individuals not to be negative. When provided the example of the Air Force’s $1 billion ERP failure, which was again highly based upon lying on the part of the Oracle and the consulting partner, the answer I received from the pro-status quo SAP consultant was that the project was “complex.” For these individuals, no amount of money is too large to waste on ERP!

Conclusion

Something that has not escaped my attention is that the SAP proponents, with their financial bias, never seem to call out many of the very obvious failings of the industry side of the equation. ERP proponents have a story to tell, which is to pay no attention to ERP failures or accept their biased explanations as to the “whys.” However, ERP proponents telling their story means silencing those who critique the overall industry. That is why those critics must themselves be criticized.

The Problem: A Lack of Fact-Checking of ERP Vendors

ERP vendors leave out the fact that the ERP systems they sold did not revolutionize the companies where they were sold. Most companies that have ERP systems do not see them as strategic. That is, they are not systems that should continue to absorb the percentage of the budget that they absorb.

Being Part of the Solution: What to Do About ERP Support Costs

ERP vendors want high support payments without really doing that much for the support income. ERP systems absorb the IT budgets far more than they were every forecasted to absorb and deliver less than they were promised to deliver. The constant yearly cost of ERP systems robs the IT departments of the resources they could deploy on applications that meet many open business requirements that ERP systems said they would match but only met partially.

If you need independent advice and fact-checking that is outside of the ERP vendor and ERP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

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 Support Content

References

The negative ROI of ERP systems from academic studies is covered in the following book.

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