How Accurate are the All Industries Benefits of ERP?

Executive Summary

  • ERP is sold on the ability to be used in any industry.
  • Learn why the proposal that ERP works for any industry is incorrect and what this means for projects.

Introduction

ERP vendors have been adamant that their software can be used for any industry. SAP has many different industry solutions. However, when one examines these advertised capabilities, the actual functionality is often lacking. These SAP industry solutions are really more marketing constructs than usable functionality, and because the marketing is so good, it took me years of working on SAP projects to figure this out. While I have not worked with every industry solution, I have worked with many of them, and none of them have been as advertised. Most of the time the ERP system is implemented without using the functionality of the “industry solution.” SAP industry solutions are designed to get executives in purchasing companies to think that SAP can meet the unique requirements within their industry, but in truth, SAP tends to offer generic functionality as a base, which they sell to most of their customers. Then they add some functionality for the specific industry, which is of dubious implementation value, but serves as the “hook” to make the executive decision-makers think the software has been customized for their needs. I have worked on several SAP implementations for repetitive manufacturing.

The Example of Repetitive Manufacturing

Repetitive manufacturing is a manufacturing environment where the production is continuous and the equipment investments are high, as is the rate of production. Late in one project, it finally came out that the repetitive manufacturing functionality was not worth turning on. As a result the implementing company decided to forgo the functionality and stick with the standard discrete functionality with a few adjustments. SAP got the sale by pitching repetitive functionality down to the eleventh hour. But the company wasted an enormous amount of time discussing whether or not repetitive manufacturing functionality would be used. As a very experienced SAP consultant (from SAP itself) once stated to me, “There is really more sizzle than steak to SAP repetitive manufacturing.” This issue of “there not being much there” is repeated throughout SAP industry solutions. Among prospects there seems to be some confusion on this topic. Just because a software vendor has a number of customers in a particular industry does not mean that their software serves that market or provides the necessary functionality. But with applications from name-brand vendors, so much of the purchasing decision is based upon the brand yet so much of the ERP system is customized by many clients. Across all industries, one of the greatest unheralded “helpers” is probably Excel. It might be more accurate to say in airport advertisements “XYZ ERP vendor + Excel is used by four out of five top chemical companies.” An honest statement—but obviously not as catchy.

Simply put, many executives buy software to advance their careers, because other companies buy it, or because the marketing and the salesmanship dazzled them. As discussed in the next section, another common division between manufacturing companies, who are the most common implementers of ERP systems, is the division between discrete and process industry manufacturers.

The Example of Discrete Versus Process Manufacturing Requirements

In discrete manufacturing (e.g., automobiles, toys and tools), usually there are multiple input items and a single output item. However, in process manufacturing, where the fi nal item cannot be broken down and converted back to the original input products (i.e., cheese cannot be disassembled into its original components, but an automobile can), one input item can convert to multiple output items, or multiple input items can convert to multiple output items. All of these relationships can be easily modeled in a spreadsheet. The finished product of process manufacturing is not simply the assembly of the input products, but is in fact an altogether transformed item. For example:

  1. One cannot unthread fabric to get to the original spools and restock the thread as inventory.
  2. Once crude oil is cracked into jet fuel, kerosene, tar, etc., it cannot be reconstituted back into crude oil.
  3. In some types of process industry manufacturing, the input product is literally “gone.” For instance, when coal is converted into electrical energy, it cannot be converted back into coal.

So what common and important capabilities are typical of process industry manufacturing? The software vendor TGI, which states the following capabilities within its Enterprise 21 software application, can demonstrate the requirements for process manufacturing planning.

“1. Supports infinite-level formulas with yielding at the top level or ingredient level and rank-ordered ingredient substitutes

2. Products can have global formulas or unique facility-specific formulas

3. Supports scalable batches

4. Supports recipes through the integration of formulas and associated processing instructions and notes for use during batch process production

5. System maintained version and revision control with a fully integrated engineering change order process

6. Formulas support nested formulas and intermediates and can have infi nite notes and instructions

7. Supports online review of formulas via single-level and multi-level explosion

8. Multi-level where-used functionality enables rapid access and mass change to all finished goods using specific ingredients, intermediates, and nested formulas

9. Formulas and recipes are easily duplicated and updated for the same product or a new product

10. Formulas are pulled into work orders or batches for tracking and recording of actual ingredients consumed or backflushed at defined standards”

Batch Functionality in SAP ERP

Batch functionality in SAP can be enabled, which is used for batch process manufacturing. Batch functionality is a very popular requirement for all types of batch manufacturing (including manufacturing such items as bakery items, paint, glass, specialty chemical, and pharmaceuticals, as is explained in the book Process Industry Manufacturing Software: ERP, Planning, Recipe, MES & Process Control). Batch functionality allows specific batches (e.g., a batch of pharmaceuticals from a single production run) to be tracked. Batch manufacturing can be enabled in SAP ERP.

However, batch functionality is well known as a major headache to enable. Batch management was added as an afterthought, even though it is foundational to a batch management ERP system and also a process industry ERP system. SAP ERP was designed to work with discrete manufacturing, which simply has quite different requirements. This is not just an issue with SAP ERP, but of ERP generally, and not just with ERP as a software category, but with all manufacturing enterprise software sold to process industry customers. This is a topic in the book, Process Industry Manufacturing Software: ERP, Planning, Recipe, MES & Process Control. The following quotations talk about how enterprise software designed for discrete manufacturing customers is sold to process manufacturing companies.

“For IT chiefs like Pam Haney, IT director at Irvine Scientific, a $28 million life sciences company, issues of competitive advantage are overshadowed by ever-present customization needs with her ERP system. ‘What we’re faced with is having to deal with ERP packages that are not designed for process manufacturers.’” — Why ERP Systems are More Important Than Ever, CIO

“Originally business information systems for manufacturing companies were designed for discrete manufacturers, not process industries. These systems targeted industries such as automotive, consumer electronics, machine tools, etc. The discrete manufacturing sector produces piece parts to form subassemblies, which are then combined to form the fi nal product. Nearly all ERP suppliers have built their information systems to support the business functions of discrete manufacturers.”Process Industry ERP Requirements

Very specific requirements exist in process industry manufacturing companies that must be met one way or another.

“Today, process manufacturers have a proliferation of products. These products are produced using the same equipment or using existing processes downstream but at the same site. Because of the number of products now fl owing through the same cost center, using financially based cost systems to develop accurate, individual product costs is difficult, sometimes impossible. Furthermore, as multiple methods evolve for producing the same end item (whether in a sister plant or with newer technologies in an existing plant), the setting of standard costs must reflect a weighted average cost. This type of costing can only be done using an ERP system designed for the process environment.”Process Industry ERP Requirements

Unplanned Customizations

Businesses require solutions that have been designed from the ground up to meet their requirements, not software that attempts to meet their requirements. ERP vendors claim they can address the specific requirements of manufacturers by appealing (successfully) to all industries with slick marketing literature, yet with the barest level of functionality. Right now, thousands of companies have made unplanned customizations to their ERP systems because ERP vendors told them that the software would cover their industry-specific requirements when, in fact, they could not. So much money has flowed into Tier 1 ERP vendors who have provided generic solutions and left promises regarding industry-specific functionality unfulfilled, that money has been prevented from flowing to solutions that could have been developed to offer companies software that meets their requirements. This is another example of a prediction made by many ERP vendors that helped them get sales but has been bad for their “customers” and bad for the enterprise software market overall.

Conclusion

The concept of using ERP for any industry with little customization is a sales construct that after decades has proven not to be true. The more customers have bought into this sales pitch, the more unplanned expenses and corrections and customizations were required of the ERP systems that they purchased and implemented.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP 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 to Understand The Fake Integration Benefits for ERP

Executive Summary

  • ERP systems were sold on the basis of 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 very good 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 were 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, with the exception of 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 of a dubious nature. Many applications sold by ERP vendors (Oracle being 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 to 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). In fact some (such as SAP) are not at all skilled in creating integration applications of any type; they seriously 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 greatly 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, 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 normally entirely exaggerate how much integration their systems provide. The following is a good 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 allowed the middleware vendors (those that were actually skilled at creating middleware) to 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 own 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 galling 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 actually 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 an extremely difficult 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 will be changes is 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 to, 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 to some of the lighter open-source ERP systems, but 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.

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 an important 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 clearly 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 major 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 in fact work in a similar way, 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 in order to analyze it properly because there are a number of 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 to other systems that are not their own. However, SAP and Oracle do not promote ease of integration to systems from other 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 fi rst 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 on 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.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP 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 simply inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? What constitutes a best practice implementation? This is all extremely confusing, as well as logically inconsistent.

Understanding the Presentation of SAP Best Practices

It’s important to understand how SAP presents best practices to client. To enhance this understanding here are some screenshots from SAP’s own presentations. I was actually was very surprised in what I found from this presentation because what is presented here by SAP has no relationship to what actually occurs on SAP implementations.

Here you can see SAP proposing that SAP best practices can reduce the adjustments necessary to the software. In an implementation, a company brings its requirements, and then those that the software cannot meet are either removed from scope, or they are accommodated with an enhancement or by buying another application (SAP never recommends the second option, which is buying another application, but nearly always pushes the client in the direction of an enhancement, and enhancement that is written in ABAP, even though in many cases a non-SAP coding platform may be better. 

Not Doing A Proper Software Selection

The presentation of SAP best practices is a method for SAP sales to lull their potential clients into not performing a thorough comparison of their business requirements versus what SAP software can do, versus what competing applications can do. I have written on many occasions that the enterprise software market is very inefficient with most companies selecting the wrong software for their needs and I described for demand planning software in this article. One reason for this is that companies do not perform a thorough software selection, and another reason is that they rely upon biased and corrupt consulting companies like Accenture or IBM that have long-standing relationships with vendors that they recommend to clients no matter what the fit is with the client’s requirements. This is why large consulting companies are incapable of performing an honest software selection as I described in this article.

In essence, what SAP is doing is asking its potential clients to forget doing a proper comparison of different enterprise software, and simply trust their statement that all the best practices exist in SAP in any case, “so what the point of actually performing a software selection?”

SAP Best Practices and SAP’s Marketing Machine

On some projects, through the years I have noticed the term “SAP best practices” used by SAP quite frequently. In the beginning, It always struck me as a bit curious, but on the other hand, I never gave it much thought. But only after speaking with a person who analyzes SAP software as well as other vendors did I realized that this is nothing supporting the SAP best practices concept. It is a canard. As I describe in this post, SAP has what I think is the world’s greatest enterprise marketing machine. SAP best practices are part of its strategy for business development. SAP has some marketing concepts that they use for business development to gain, keep and maintain market clients in the marketplace. Best practice is one of these. It’s important to understand that SAP marketing messages work not only to get SAP clients, but also to control the interpretation of their software during implementation and after a go live. However, later on in this article, I will show that SAP is both not based upon best practices, and secondly, in SAP’s documentation, they are confused as to what a best practice is.

How The Term Best Practices is Misused by Large Consulting Firms

SAP is not the only company that uses the term as a marketing construct and for business development. Large consulting firm consultants also like to use the term and use it in a way that is almost always misleading. I once worked as a consultant at IBM who created a custom fix for a safety stock problem in a way that was a worst practice, and then proposed that weekly delivery frequency was “best practice.” This is somewhat amusing as this consultant was so technical he was almost a development resource, and would not know a best practice if it hit him in the head. This is, in fact, my view of most of the IBM consultants that I have met that work in IBM’s SAP practice. IBM consultants in their SAP practice do have good technical skills, but they are essentially lying to clients when it comes to their business knowledge.

IBM also promised a large number of best practices from their “vault in Armonk,” however, one of the major complaints of the client is that IBM did not seem to offer any, even though this was a major focus of the overall sales presentation to the client. The only best practices that the client received were made up ones to obtain buy-in on decisions the consultant wanted to go his way. They had nothing to do with a large data sample of companies that showed that one way of doing something was superior to another.

Best Practices

The concept behind best practices is that there is one best way of doing something. That is if a user creates and interacts with a purchase order in a system, there is one best way to view, manage and process that purchase order. SAP claims that their software is built around best practices because they are so large that they can say they have “standardized” their software on the best practice.

The concept is used in multiple ways on accounts:

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

How SAP Uses the Concept of Best Practices

I suppose I don’t spend enough time listening or reading to SAP’s marketing message because it took a conversation with an industry analyst to have it explained to me that SAP hides behind the concept of best practices to defend weaknesses in their software. The basic strategy is that SAP prepares their executives up for complaints about their software by priming their executives to think that any complaints are because the users are resisting the best practices that are in the software. The sentence may be “You may receive push back on the system, but that is a change management issue because your employees are resisting the best practices that are in the software.”

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

The truth is that while there might be some standard processing in parts of SAP software that are in fact best practices, by in large the concept is significantly over-applied, and ends up being somewhat of an excuse by SAP to fend off criticism. The question should be, what evidence is ever presented that SAP software only contains best practices? The answer is that no evidence ever is usually provided, at least when the claim is made orally, which is where it ends in most circumstances. However, you can find several SAP resources on best practices. I have entered a screenshot below of best practices.

As you can see, SAP claims that because they are so big, they have all best practices included. Secondly, they propose that customers who use best practices have been able to reduce consulting by 50% and reduce mistakes. However, wait one second, aren’t best practices naturally inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? Secondly, SAP implementations are the most expensive implementations on the planet. If one is looking to reduce consulting time or expenses, SAP would be the absolute wrong solution. It brings up the question “what exactly are best practices in SAP?” Here is another screenshot on the topic of best practices.

Here you can see that now SAP is classifying best practices as a toolset made up of instructions, pre-configuration, sample master data. But let us back up a few steps here. What do best practices have to do with the master data? Best practices are supposed to be business process functionality that is baked into the system. Master data should be kept up to date, and validated with the business, however, this is not something you can bake into the application unless you mean making the software transparent and easy to use, but in that case you are enabling a best practice, you are not, in fact, modeling a best practice yourself.

Overall, this seems more like a jumpstart toolkit. The paragraph goes on to say that there is a NetWeaver component to best practices. However, how can this be? NetWeaver is essentially the infrastructure components of SAP (PI, ABAP, Basis), so what do these have to do with business process functionality best practices? If by best practice SAP means ease of use or sustainable infrastructure tools, then SAP products are a worst practice, because of all the infrastructure I have worked with, it takes SAP the longest to do the most basic things. Also, one questions how serious SAP is about their NetWeaver best practices are because all of their links to supporting content on this page are broken.

The answer to this is that SAP just does not know, and are confusing them. They like to use the term liberally, but they use it in so many ways their usage is not consistent with the term’s meaning. They started off saying one thing with best practices, a statement which was originally false even in that instance, and then their product management could not control themselves, and they just began applying the terminology to a variety of initiatives just for the fun of it.

World Class

Interestingly such unsubstantiated statements are quite common either in SAP or outside of SAP. This is demonstrated by the following quotation.

“A few years ago I had a meeting with a marketing director of a well-known consumer goods brand who proudly told me about the world-class stage-gate product process they had introduced. How many successful new products have you launched as a result of this process, I asked? Well, none, he replied, but the process is world-class, he insisted.” – Dr. Ken Hudson

Clearly, if you want to make something sound tantalizing, but you have zero evidence that it is, in fact, beneficial in any way, simply give it some generalized positive label — best practice, world-class, best-in-class, super-duper — the choice is yours. As a large portion of the business community is unthinking zombies, the technique is amazingly effective in almost any domain.

SAP Best Practices on a Project

SAP will want to continue this position on the actual project however, it is untenable. The client resources will eventually figure out that SAP just has normal functionality in its applications, and that it is not based upon best practices. The SAP consultants like me will then be asked to show how SAP functionality is a best practice and I can’t because it isn’t. The presentation that companies should adjust all of their business processes and just do what SAP can do is not a workable solution on a project, it only works during the illusory or the sales portion of the interaction.

SAP’s Confusion on the Topic of Best Practices

It brings up the question “what exactly are best practices in SAP?” Here is another quotation on the topic of best practices.

“SAP Best Practices Based Upon Netweaver—SAP Best Practices provide a toolset that helps IT and functional project team members to quickly deploy functionality in SAP solutions—from SAPNetWeaver, to core SAP applications. The toolset comprises a mix of step-by-step instructions, preconfi guration, sample master data, code samples (where applicable) and end-user training—organized by technical or business scenarios that you might want to implement in your landscape. Below you will find the SAP Best Practice versions that support the implementation of SAP NetWeaver components.” — SAP

In this quotation, SAP classifies best practices as a toolset or accelerator made up of instructions, pre-configuration and sample master data. But let’s back up a few steps here and take just one example. What do best practices have to do with the master data samples? Best practices are supposed to be business process functionality that is in the system naturally. Master data should be kept up to date and validated with the business, which I suppose could be said to be a best practice; this is not something you can bake into the application unless you mean to make the software transparent and easy to use. In that case, you are enabling a best practice; you are not modeling a best practice yourself. Overall, SAP’s best practice seems more like a jumpstart toolkit that contains a combination of things that are best practices. The paragraph goes on to say that there is a NetWeaver component to best practices.

How can this be?

NetWeaver is comprised of the infrastructure components of SAP, so what do these have to do with business process functionality best practices? I suppose one could say that their infrastructure follows best practices, with the business, software, toolkits and infrastructure software all based upon best practices. SAP hammers away at this theme throughout their documentation, but because they apply it to everything they do, it begins to sound like unsupported conjecture— and that is the best-case scenario.

Confusion on Best Practices by SAP

The worst-case scenario is that SAP employs marketers who can’t keep their story straight and have limited English and logic foundations. Also one questions how serious SAP is about their NetWeaver best practices because, when I reviewed this material, all of their links to supporting content on the web page were broken.

The answer to these questions?

SAP just does not know; they are confused themselves as to how to use the term “best practices.” SAP simply smears the term, like cream cheese on a bagel, on almost everything they do. With SAP, simply calling standard SAP documentation a “best practice” will somehow (magically) allow projects to go live much more quickly. In this case, a best practice is an incantation. It’s difficult to take a vendor seriously when they are so undisciplined as to the use of their terminology. SAP finishes off the proposal by declaring that best practices enable SAP implementations to go live in 4.2 months. This is not true; in all my years working with SAP I have never seen any SAP module go live in 4.2 months. This is another problem with credibility: SAP implementations are measured in years—not months—and anyone who works in SAP knows this. So where is this number coming from, and what module is SAP talking about? Where is the evidence for this? No evidence is ever presented.

The Negative Effect of Best Practice Claims on Projects

If only best practice claims ended when the software was sold, that would be one thing; however, the conversations regarding best practices passed from sales to the consultants who are supposed to make good on these claims during the implementation. When you repeatedly tell a customer that they will get best practices in every dimension if they buy your software, unfortunately, they don’t forget this. As with any promise that can’t be fulfilled, SAP consultants are put in a difficult position. I would know—I have been one of these consultants. On many of my projects, the term “best practice” becomes a punch line. The individuals in the implementing company come to realize that there is no such thing as best practices. Jokes such as, “But wait…it’s okay because it has best practices,” or, “All we need on this project is just more best practices!” are quite common. Because marketing and salespeople don’t actually work on projects or with software, they do not know this. After realizing that they had been bamboozled by SAP Sales (accompanied by a healthy dose of cynicism about best practices), I heard senior members of my client declare, “We don’t want to hear anything more about best practices.” In the implementation phase, best practices lose all credibility.

Non-ERP Uses of the Term “Best Practices”

SAP is certainly not the only company that uses the term “best practices” as a marketing construct for the purposes of business development. Consultants from large consulting firms also like to use the term and use it in a way that is almost always misleading. I once worked with a consultant who created a custom adjustment for a safety stock problem in a way that was completely inadvisable: I would consider it to be a worst practice. He then proposed that weekly delivery frequency was best practice. He essentially suggested that any technique that he wanted to employ was a best practice. On this project, I learned that twice-a-week delivery was a best practice; who knew that how frequently a product is delivered could be a best practice?

It isn’t.

Consulting companies are constantly using the term “best practices” to sell work. However, as with best practice claims made by ERP vendors, no evidence exists that what the consultants promote as a best practice is, in fact, that and this is because they have no evidence; it’s an opinion. It’s one thing to say that this or that is one’s opinion from experience. But it’s something else to gusset up this opinion as a best practice—with zero evidence—simply because one would like to have their opinion carry more weight. It is also common to hear from the client that the consulting company did not seem to offer best practices once they were on the project. The reason is simple enough: once one gets into the details of the actual recommendation, they look a whole lot less like “best practices” than they did from a distance.

Criticizing Pre-existing Systems

Best practices have been very useful to ERP vendors as a way of giving them permission to criticize a potential customer’s pre-existing systems. Sales and marketing is about changing perceptions to encourage a purchasing decision. One way of doing this is to increase the purported virtues of the item to be purchased (in this case, the ERP system). Another way is to lower the perceived value of the customer’s current item. Using the term “legacy” to describe all previous systems, and the term “best practices” to describe ERP systems, is highly effective and an impressive feat of rhetoric because it ignores the important fact that the legacy system had been customized for the business requirements, while the ERP system had not. Essentially ERP vendors appealed to a central concept: how things are done in other organizations must be better than how things are done in the potential customer’s company. This is a reversal of the “not invented here,” philosophy which proposes, “anything not invented here.” This is explained in the following quotation:

“ ‘Don’t assume newer is necessarily better,’ advised Project Manager Ellen Harmon of the Washington State Community and Technical Colleges Center for Information Services. Harmon considers her existing legacy system to be just another, older ERP. ‘We actually have an ERP that has been developed over the last 18 to 20 years for specifi c clients, and because of that, this ERP is very focused on these particular client needs.’ The case is the same at other universities.‘Their legacy systems have been developed to meet their specific needs and are tailored to their environment,’ said Harmon. ‘An ERP vendor might say your system is old, and therefore is bad, and we will sell you this new system. But it is a legacy system, too.’ ” — Promise of ERP System

This quotation brings up an interesting question: what is the definition of “legacy”? An ERP vendor may be selling a system that has an older code base than the “legacy” system it is replacing. Interestingly, the designs of many of the ERP applications sold today are extremely dated, and yet they are never referred to as “legacy.” To a software salesman, other people’s systems are legacy, but your systems are never legacy. One might ask why this is the case. The reason is not hard to determine. “Legacy” is a term of propaganda that is applied to systems that the designator would prefer to denigrate as a pretext for proposing another system. If you work in ERP Sales, then all pre-existing systems in the companies to which you would like to sell your ERP software are legacy. The ERP system you are selling—no matter how dated—is never referred to as legacy. Therefore the term “legacy” has two meanings: the actual definition (“an old method, technology, computer system or application program”) and the real meaning—any system that you would like to replace. However, many decision makers missed an important detail of infrastructure technology management, as explained in the following quotation:

“IT analysts estimate that the cost to replace business logic is about fi ve times that of reuse, and that’s not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits—they always have, and they always will. New software may increase the risk of system failures and security breaches.” — Wikipedia

Many companies relearned this fact about computer systems. Many of the cost overruns of ERP systems were related to replacing business logic.

Conclusion

Best practices that are described by SAP should be categorized as a sales technique. They have little validity on an actual project. The way to evaluate enterprise software is whether it has specific functionality that addresses the needs or business requirements. Using the term best practices simply interferes with this analysis and places a false schema on top of the analysis that needs to be done. Best practices are all over SAP sales literature as I described in this article, and are used very frequently by consulting companies, but on actual projects, they mean very little.

SAP uses unsupported marketing concepts for business development in several major categories of their message to companies, but best practices might be the most effective. First of all the statement does not hold up against any analysis of SAP’s software, and second, its dangerous to assume that any software vendor is telling the truth regarding the idea that they have all the best ways of doing things already programmed into their business logic, so you don’t have to worry or question. Secondly, SAP is not clear as to what best practices are themselves and does not even take the time to keep the links on the topics updated. The vendors that are more honest about this setup their software to be flexible enough to do things some different ways, but then use their consulting resources to figure out the best way for the particular client. SAP cannot follow this approach because the software design is inherently inflexible, and thus the need for the brilliant sleight of hand known as “SAP best practices.” What “best practices” actually means is that SAP is right. That the way SAP has designed their system is the best way and other ways are wrong. And clients, for the most part, buy this, and consultants have adopted the concept of “best practices,” because it reduces their necessity to present any evidence.

Instead of being hypnotized and distracted by the term best practices, companies should instead get into the details of what software can do and what it cannot do. Secondly, it needs to match that analysis with what the company wants to do. Looking to software vendors to tell you to want to do is a mistake. Your business needs to know what it wants to do, and if they are following poor practices, then need to hire the right people, or bring in the right external business expertise to improve these processes.

Best practices have been a deep well that ERP vendors have repeatedly drawn from in order to support multiple objectives. ERP vendors do not attempt to hire professional researchers to validate their claims regarding best practices because a) most of what they are proposing is simply how their software works—and is not a best practice, and b) customers generally don’t question the best practice claims made by ERP vendors. Generally, all that is needed to convince companies that a software vendor has best practices is if the software vendor has marketing documentation that declares the existence of best practices, and if that software vendor is generally successfully selling its software and has significant brand recognition.

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

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

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 to Understand The Best Practice Logic for ERP

Executive Summary

  • ERP systems are frequently sold on the claim of best practices.
  • ERP customers usually do not realize that best practices don’t exist.

Introduction

Many of the arguments that are habitually made in favor of ERP are, in fact, nothing more than logical fallacies, and because of this it is important to review briefly the definition of “logical fallacies.” Proponents of ERP use a number of logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their official names. In fact, 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 in order to make sure I was able to identify all of them properly. When a topic leads one to actually There are some interesting questions that should be asked whenever any software vendor makes a statement about best practices:

  1. Who decided something is a best practice?
  2. Was the best practice put to a vote?
  3. Was it deemed to be so by an expert?

If item three is affirmative, where is the research to support the notion that a way of doing something is a best practice? What a person who asks these types of inflammatory questions (yes, simply asking for evidence is considered inflammatory with regard to best practices) will find is that in the vast majority of cases, the practice is a “best practice” simply because the proposer declares it to be so. There is no research and no explanation as to how it was determined to be a best practice. Furthermore, if two different ERP systems—both of which are based upon best practices—diverge in some way on how to do things, which one is actually performing the best practice?

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

The Car Versus Truck Best Practice Example

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

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

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

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

Best Practices in Which Software?

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

Conclusion

The fact that the concept of best practices was such an effective marketing ploy is yet another indicator that many of the executives that analyzed ERP software sales pitches did not have sufficient experience with the software they were purchasing to know that software couldn’t be purchased using best practices as a measure. Now that I have covered best practices generally, I will provide specific examples of how best practices have been used to sell ERP, and what the results were. To some degree, all the ERP companies used best practices to sell their software. I happen to focus on how SAP uses the term because I have spent so much time over the years reading their literature.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP 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 to Understand The Logic Used to Sell ERP Systems

Executive Summary

  • ERP systems were sold on the basis of 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, and because of this it is important to review briefl  the defi nition of “logical fallacies.” Proponents of ERP use a number of logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their offi cial names. In fact, 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 specifi cally on logical fallacies in order to make sure I was able to identify all of them properly. When a topic leads one to actually 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. 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 conclusion by assuming the conclusion in the proof.
  2. Weak Inference: Failing to provide suffi cient 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: An appeal 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 infl uence 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 discussing.
  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 on the basis of 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 or 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 (Year 2000): This was the concern related to the ability to properly calculate dates in software that had been developed back when there was a very small 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 essentially 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 simply 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 larger 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 previous 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 fi nancial 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 (Year 2000)

Many ERP purchasing decisions were made because companies simply 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 properly post year 2000, they could be replaced—swept away by a shiny new ERP system. Fear of Y2K was a main 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 fi rst, 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 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 basic 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), but companies that rely on ERP systems in this way cannot hope to properly leverage the available manufacturing software, 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 major 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 own 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 completely inconsistent with the earlier arguments used to convince companies to buy ERP. I could fi nd no articles that explained how inconsistent the new diversifi ed application strategy was with ERP vendors’ own 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 actually 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 in order to increase their sales. In some cases they could have simply 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 existing clients, without having the clients remember that the main 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 largest 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 own 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 really 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 other 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 unfairly compete: 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 actually 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. In fact, 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 actually 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 simply subsumed into what is often an inferior application. There are a number of 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 to 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 greatly underestimate the degree to which companies faced this issue of being unable to decommission systems that were performing important tasks, and to overestimate how well the ERP implementations at other companies were faring. Companies bought ERP, often without knowing how specialized their own 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 greatly increases implementation costs and durations. It also means long-term and largely unanticipated 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 completely 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 simply 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 operational efficiency be evidenced by improvements in financial performance? 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 declared live before the implementation is complete. Much fine-tuning is required post “go-live” to get the applications working as required. 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 a 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.

Conclusion

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.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP 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 to Understand the Non Stop Promotion of ERP

Executive Summary

  • Most of the sources of information in IT are filled with ERP based financial bias.
  • Find out how this makes the coverage of ERP inaccurate.

Introduction

ERP is based upon the oversimplified concept that companies should buy an integrated financial/manufacturing/supply chain/sales management system. This concept could be implemented well or poorly, but it is important to differentiate the implementation of the concept (that is the resulting software application) from the concept itself. Proponents of ERP state that the ERP concept is not only beneficial but that ERP systems are a requirement for all companies. Companies that don’t buy and implement ERP systems are “not with the times” and “don’t have good executives making decisions for them.” In fact, the logical fallacy used in promoting this concept is “appeal to fear,” and it is effective against executive decision-makers who must keep marketable acronyms such as ERP on their resumes.

For some time, being involved in or overseeing ERP implementations was an important addition to an executive’s resume. In the course of doing research for this book, I found a number of articles that implied that companies, where ERP has not yet been implemented, should absolutely be thinking of using an ERP system. These articles present no evidence that companies benefit from ERP, but instead rely upon the logical fallacy of “argumentum ad numerum”—that many companies have implemented ERP. They then combined this fallacy with hypothetical statements about how ERP software may benefit a company. Furthermore, this viewpoint is not contradicted by the opposing viewpoint that ERP may not always be the best approach. There is little variability and very little independent thinking on the topic.

How Accurate is the Unanimous View?

After a review of the research on ERP benefits has been presented, the reader should question whether this unanimity of opinion is justified. Companies have invested an enormous number of resources into ERP systems, and contrary to the opinion presented in most of the literature in the area, the failings of ERP to meet the expectations of implementing companies is not something that can be rectified simply with a change in management practice or by hiring a new implementation consultant. This is because the aspects of ERP that have been most disappointing are related to the fact that the concept of ERP—regardless of the specific implementation of the concept (the software)—was never as advantageous as was presented. Once companies can interpret these limitations as permanent in nature, they can begin to deal with ERP in a realistic manner rather than by relying upon a new release, wishful thinking, or some new marketing construct provided by their ERP vendor to improve the condition of their ERP systems.

Everpresent Financial Bias

Clearly, information generally available on ERP systems is subject to financial bias, for the obvious reason that the ERP industry is so large and so lucrative. Just a few ERP implementations can make a partner at a large consulting company well off, as they make a lot of money off of their consultants and it takes many consultants to implement an ERP system. For salespeople who sell ERP systems, the same rules apply. Because of the financial bias that exists, information published about ERP is quite positive, bordering on the Pollyannaish. Meanwhile, negative information about ERP tends to be suppressed. When negative information about ERP (mostly in the form of information about failed implementations) does get out, normally the information is spun so that the software and the concept of ERP is not blamed. Instead, the repetitive narrative is that the implementing company must have made some mistakes, and these mistakes are simply managerial in nature and therefore correctable. Clearly, with all this money to be made in ERP systems, the question of who can be trusted to provide accurate information on ERP is clearly not a question that I have come up with exclusively, as the following quotation demonstrates.

“ERP is a multi-billion dollar industry dominated by consultants and software vendors. This is not going to change anytime soon since software and software expertise are the necessities of an automated system. But for a practitioner within an industry responsible for a project and a company that must live with the outcomes, the question is: Who solely has your best interest in mind? I can say only one thing: The deck is clearly stacked against you.” — Control Your ERP Destiny: Reduce Project Costs, Mitigate Risks, and Design Better Business Solutions

Financial bias has caused some highly inaccurate information to be released by most of those who have written about ERP. The fact that so many entities were spectacularly wrong with respect to their predictions for ERP has been one of the great missed stories of enterprise software. And who will cover this story? The IT press themselves are the main culprits; after all, will those who take in advertising revenue from ERP vendors break the story that the emperor has no clothes? It fits into the overall storyline of ERP systems; in fact, the ERP phenomenon cannot really be understood without understanding how wrong the projections about ERP have been, and therefore, this is the main theme of this book. It is only through understanding why these projections were so wrong and by taking a full account of ERP as it is today (not blindly accepting the fabricated sales pitch of entities that make their money from implementing ERP), that companies that already have ERP can determine the best way to manage ERP in the future. Secondly, for companies that have not yet implemented ERP, this book will address how to avoid the mistakes of companies that jumped on the ERP bandwagon to their great detriment, and are now stuck in a situation where the system is negatively impacting their ability to meet business requirements and ERP’s resource consumption crowds out best-of-breed solutions.

Unintended Consequences and the Definition of Success

The promises to ERP buyers have not come true, but many things that ERP buyers were never promised and never expected—such as the power that enterprise software buyers handed over to ERP vendors after implementing ERP (and particularly Big ERP vendors and big consulting companies) or the large percentage of the IT budget that the ERP system would consume into perpetuity—did become realities. Therefore, it’s quite important to differentiate between the commercial success of ERP and the benefits analysis of what ERP does for companies. No one could dispute that ERP has been tremendously successful for ERP software vendors and for the major consulting companies. On the basis of software sales, ERP systems comprise the highest grossing category of application software ever developed. The sales, implementation, and maintenance of ERP systems have created an enormous number of well-paying jobs and quite well off ERP salesmen and consulting firm partners.

Currently, all of the major consulting companies are dependent upon their ERP consulting practice to make their numbers. However, what this book will focus on is the value that ERP provides to the companies that implement it. This book will address two major assumptions. The fi rst is the unquestioned assumption that ERP is necessary.

Big ERP Benefits Companies?

The second assumption is that Big ERP actually benefits companies. As this book will demonstrate, there is no evidence to support these views, and there is quite a bit of evidence that ERP has been an unfortunate misallocation of resources within enterprise software. (In fact, the evidence is that ERP is the largest misallocation of resources to have ever occurred in the history of enterprise software—possibly not as momentous a statement as it appears to be as the history of enterprise software only goes back to the early 1970s, but the total resources expended on ERP since its inception have been gigantic.) This book explains the background of ERP, the expectations that were set for it, and why it is a myth that ERP systems improve the state of companies better than other software that could be implemented. ERP proponents say it is “ERP versus nothing”—a logical fallacy called a “false dichotomy/false dilemma” that is used to stack the deck in favor or ERP—however, the question is really “ERP versus true alternative applications” and therefore alternative expenditures of resources.

The Consensus on ERP

In the previous section, I discussed the commonly held belief that ERP is essential infrastructure for a company, something that is particularly true if the company in question is in manufacturing. It is interesting that Aberdeen Research wrote a paper that stated the following about this type of assumption right in the title of the paper: “To ERP or Not to ERP: In Manufacturing, It Isn’t Even a Question.” The words in this title can be described reasonably as the general consensus on ERP, but it is a curious consensus considering ERP’s history. Interestingly, one cannot find consulting advice that questions whether ERP is even a good idea.

The only real topic of conversation is when to implement ERP software or how to improve ERP implementations. If one does not have ERP installed, the question is not whether ERP is a good fit, a good value, and can meet the company’s business requirements, but why ERP hasn’t been implemented already and when the company plans to implement it. Therefore, for the most part, Aberdeen’s research conclusion is correct: this is what the majority of manufacturers believe. But what Aberdeen does not know is that this assumption is not true. With this consensus about ERP among those who provide advice, it is little wonder that most enterprise software buyers believe they need ERP as explained in the quotations below:

“More than 85 percent of respondents agreed or strongly agreed that their ERP systems were essential to the core of their businesses, and that they ‘could not live without them.’ Interestingly, just 4 percent of IT leaders said their ERP system offered their companies competitive differentiation or advantage.” — Thomas Wailgun, CIO

“The business sees the slick demos and possibilities, and then keeps forking over the money for this, and they don’t understand why they are still paying all this money,’ Wang says. ‘Why is it so hard to get a simple report? Why is it so hard to add a new product or build a new product line? Why is it so hard to get consolidated financial information? [underline added] Isn’t that the whole point of ERP?’ ” — Thomas Wailgun, CIO

Companies see the low functionality and the poor reporting functionality of their ERP systems, along with the problems integrating with non-ERP systems, but they don’t seem to be able to put the separate data points together into a complete story. As “everybody” has implemented and used ERP, how could ERP itself be bad?

Books and Other Publications on Software Selection

I perform a comprehensive literature review before I begin writing any book. One of my favorite quotations about research is from the highly respected RAND Corporation, a think tank based in Santa Monica, California—a location not far from where I grew up and where I used to walk with my friend when I was in high school—at that time having no idea of the historically significant institution that I would stroll by on my lost surfing weekends. RAND’s Standards for High-Quality Research and Analysis publication makes the following statement regarding how its research references other work.

“A high-quality study cannot be done in intellectual isolation: it necessarily builds on and contributes to a body of research and analysis. The relationships between a given study and its predecessors should be rich and explicit. The study team’s understanding of past research should be evident in many aspects of its work, from the way in which the problem is formulated and approached to the discussion of the findings and their implications. The team should take particular care to explain the ways in which its study agrees, disagrees, or otherwise differs importantly from previous studies. Failure to demonstrate an understanding of previous research lowers the perceived quality of a study, despite any other good characteristics it may possess.”

There are so many books that promote ERP, rather than analyze ERP, that there was little to reference when doing research for this book—this is a “why” book rather than a “how” book. Books on ERP have a strong tendency to deal in platitudes and unexamined assumptions and offer very little new or different information on the topic. The closest I could find to a book that applied some critical thinking to ERP was, Control Your ERP Destiny: Reduce Project Costs, Mitigate Risks, and Design Better Business Solutions, which is sort of a “tell all” book about the errors of ERP implementations. However, as with almost all ERP books, it concentrates on providing information to companies to help improve their ERP implementations rather than questioning the logical and evidentiary foundation for ERP. Most of the references in this book you are reading are not from other books but from a combination of my personal experience and some articles (including academic articles) that study the impacts and benefits of ERP.

Unreliable Information from ERP Vendors

The only quality ERP statistics came from either academic research or, to far a lesser degree, IT analysts. And very little of the material from ERP vendors were found to be reliable; even when they point out flaws in the arguments of other ERP vendors, they proceed to promote their own arguments, which are not based on evidence and often contain logical fallacies. Smaller ERP vendors have gone on the aggressive against Big ERP abuses, but often their arguments are also self-serving. And after reviewing a number of ERP applications, some of the best smaller ERP systems are certainly not the loudest nor do they have the biggest marketing budgets. Some might say that this should be obvious, as these are software vendors and thus entirely biased. However, this has not been true of all vendors in all software categories that I have analyzed. For example, some vendors in the other software categories we cover have added significant content to their space. One vendor that has provided very good and very accurate content in the area of ERP is e2b enterprise, and they are referenced throughout this book. Many of the authors who work for both IT analyst firms as well as IT periodicals frequently quote statistics from other sources, with the same statistics referenced repeatedly. Some of the conclusions that were drawn from the research of others display clear logical errors.

A Lack of Analysis on ERP

Many authors in this area are simply not qualified or have not spent the time to try to make sense of the numbers and to triangulate them with other sources. They may be effective beat reporters, but they lack a background in research. Because of this, one finds that many of the same numbers are repeated in various articles; however, when you study the underlying research, you will find that the conclusions do not follow from the statistic that is quoted in the secondarily sourced article. Executive decision-makers certainly do not have time to perform this type of analysis themselves, and as a result, there is little doubt that many of them have been misled by authors who lacked the background to perform the analysis for the articles that they wrote on ERP.

Aberdeen’s Fake ERP Cost Estimation

The most prolific IT analyst firm with respect to ERP cost estimation is Aberdeen. However, Aberdeen’s cost estimates are not realistic. They greatly underestimate the implementation costs for ERP projects, as well as underestimate the variance in license costs between the Tier 1 and Tier 2 vendors (projecting them with an average cost per user no greater than 15 percent in a study that included SAP, Oracle, Lawson, and QAD). Aberdeen did, however, have an interesting estimate of the average number of users per ERP vendor, and that helped reinforce how various ERP vendors tend to sell into different sized companies. This is well known in the industry, but the exact figures helped drive the point home. One of the more comprehensive studies of the benefits of ERP also evaluated the research on ERP and explained their findings in the following quotation.

“Previous evidence on ERP systems has come from qualitative case studies (e.g., Markus et al. 2000) or surveys of self-reported perceptual performance (e.g., Swanson and Wang 2003), but relatively few studies collect data from a large number of fi rms or use objective measures of productivity and performance.” — Which Came First, IT or Productivity?

Conclusion

This lack of information also demonstrates that the demand for such information was never very high. ERP was one of the most powerful trends in enterprise software; however, it was one that was driven largely without the support of academic or other forms of research. This may have been attributed to the compelling logic of ERP. Some philosophies have their own appeal and lower the need for proof in order to make people believe them to be true. ERP was clearly one of these philosophies. I cannot explain why so much writing on the topic of ERP is so generic and duplicated, I only know that this is what I found, but it has a basis in financial bias. In performing research for this book, I would frequently jump between different books and articles; often the similarities were so striking that it seemed as if I were reading from the same book or article.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP 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

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other S/4HANA Content

SAP Labs Publishes Dishonest Paper About ERP

Executive Summary

  • SAP Labs published a paper specifically designed to mislead readers about ERP.
  • We analyzed this paper.

Introduction

“Some mature information technologies, such as ERP systems and relational databases, are now undergoing commoditization, much like what happened in the automotive and chemical industries over the past 15 years. This trend is accelerating by reducing IT spending because of slowing economic growth.

I see big technology and business model changes coming from ERP. New technology trends such as high-performance computing, pervasive connectivity, Web services, and SOA will affect the front end as well as the back end of ERP.

….an ERP’s average life cycle is about 15 years.”

This is a study from SAP Labs. Interestingly none of these things happened in the roughly nine years since this was published. SOA and web services went nowhere. High-performance computing has had no effect on ERP.

SOA lets developers partition and decouple applications. It provides a bridge between incompatible technologies.

No one did more to undermine SOA than SAP. SAP is based upon coupling applications and restricting competition. Why would they want to decouple applications?

Web services are ideal for letting developers adapt ERP to fast-changing business processes. Web services can be orchestrated to create multi-service business processes that connect via SOA to the robust and reliable back end….

Once again, no one did more to undermine this than SAP. SAP does not want flexibility or open systems. But people who work for SAP Labs are not going to put this in a paper.

Conclusions

This is a completely dishonest paper written by SAP Labs and should not have been accepted as a research paper. There is much more in it that what we have quoted, but it is all primarily self-serving information for SAP, and as we described, none of it came true. It obscures the fact that SAP as a matter of policy undermines the supposed openness trends that are a big part of the paper.

This paper was written by Paul Hofmann who is Vice President of Research at SAP Labs. He has a Ph.D. in physics from Technical University in Darmstadt Germany.

However, this demonstrates that private industry research offerings can’t seem to do much more than serving as marketing puff pieces for the company they work for. This is why private research has such a poor reputation. This paper should not have been accepted for publication.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP 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

ERP is Deal, Long Live ERP. SAP Labs, Published by the IEEE Computer Society, Paul Hoffman. 2008.

Do Non Manufacturing Distribution Companies Require ERP?

Executive Summary

  • ERP is a commonly implemented application, but the need for it declines if the company does not intend to maintain a production BOM.
  • We cover the trade-offs of ERP for non-BOM maintaining companies.

Introduction

In this article, we investigated what happens when an OEM performs no manufacturing and an alternative model to the convention design — where the OEM runs MRP and explodes the BOM. In one alternative, MRP is run by the OEM, but only for the well-finished level. In this article we take this thought exercise to one following level — and this third scenario is where the OEM also performs no distribution. In fact, many high-tech OEMs outsource not only manufacturing but distribution as well. However, most consulting companies follow a standard policy of recommending ERP implementations to their clients.

Why?

This is done not because there is any evidence that ERP systems provide a financial return (they don’t as is explained in the SCM Focus Press book The Real Story Behind ERP: Separating Fact from Fiction.)

Consulting doesn’t know or care much what works for their clients but is intensively driven to maximize their revenues — which means software categories which maximize the revenues of consulting companies will be recommended. ERP provides a negative return on investment, even for enterprises that have most of the business processes covered by ERP systems, but can be especially poor values for companies that cannot use ERP systems for much more of a minority of what they do because they do not fit the ERP cookie cutter design. To see why this is the case, let us look at the application components of ERP systems:

  1. Sales
  2. Materials Management/Distribution
  3. Production Planning
  4. Finance and Controlling

For many high-tech OEMs they, as we have just discussed do no production or distribution, so they have no use for two of the standard application components of any ERP system. As for the Sales component, this is an entertaining area.

How About Sales and Finance?

What is happening is that CRM is encroaching on the standard sales module of applications like SAP and Oracle. Increasingly solutions like Salesforce can provide most all of the functions of the sales module of ERP systems — and they are far easier to use, and allow a true connection to the sales force. Specific best of breed applications for sophisticated functionality such as pricing can be added at a higher functionality level than anything offered by the major ERP vendors. This leaves the finance module – which any company requires. The finance module can be acquired with a system such as Financial Force, which is pre-integrated with Salesforce and is native to the Force platform, or Intacct, which also provides easy to integrate stand-alone finance application, and which is capable of scaling to the accounting needs of even large companies. However, the original argument, or should I say one of the major original reasons for ERP system acquisition was that one could use all of the modules of an ERP system and they have been fully integrated (sit on the same database, no interfaces, etc..) However, while this may apply to many traditional companies – it in no way applies to many other businesses that do not perform all the traditional functions of a manufacturing company. Here is why:

  1. The ERP system may be integrated, but these high-tech OEMs have little use for the set of functionality that ERP systems offer.
  2. ERP systems are a significant expense, much larger than anyone originally projected. It is laughable now, but ERP was originally planned to decrease IT costs. This is probably the point where anyone who has worked in ERP sales will want to stop reading. This is because promoters of ERP systems have been proven wrong on every one of the major logics that were used to justify ERP (as is covered in great detail the SCM Focus Press book The Real Story Behind ERP: Separating Fact from Fiction). And this applies in particular to Tier 1 ERP vendors and becomes less and less true, and one moves through the Tier 2 and least true as one moves to cloud-based ERP.

Alternate Designs to Exploding the BOM with MRP

  1. The Alternative Design 1: MRP at Finished Good Level at OEM

The Benefits of the Alternative Design

The OEM gets a much easier and lower cost to maintain the system, and the complexity manufacturing is moved to where it should reside, at the CM as they are planning the production. Some companies attempt to prepare their CM/subcontract suppliers actively. This can work when the OEM is a sizable part of the demand of the CM/subcontractor (and there are still complications in this – a detailed explanation of the type of software that can relatively easily handle this requirement is covered in the SCM Focus Press book  SuperPlant: Creating a Nimble Manufacturing Enterprise with Adaptive Planning Software) if one represents only a small fraction of the demand for a CM/subcontractor capacity, it makes little sense to model this plant – in fact, it is highly unlikely the CM/contractor would be willing to share capacity information – it is simply not worth their time.

If MRP is Required, Must it Come From an ERP System?

In Alternative Design 1 above, MRP is still performed for the well-finished level. Wouldn’t an ERP system be required to run MRP? Actually no. MRP functionality can be purchased at low cost compared to a full ERP system. Demand Works Smoothie runs MRP and does so with overall functionality and usability, which is superior to any ERP system that SCM Focus has tested – which includes all Tier 1, and several Tier 2 as well as multiple clouds based ERP systems. More on this topic is covered in detail in the article Why Not All MRP Systems Are Created Equal.

Conclusion

The answer is that for many companies that do no manufacturing or distribution even, do not require an ERP system. Instead, they can combine much high value best of breed applications at a fraction of the cost and long-term total cost of ownership, while increasing their flexibility. More on this topic will follow at this site, as we will release portions of insights from upcoming books on these subjects.

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.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP Content

References

https://www.sciencedirect.com/science/article/pii/0272696381900310 MRP. Accessed October 18, 2013. https://en.wikipedia.org/wiki/Material_requirements_planning

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