How to Understand The Logic Used to Sell ERP Systems

Executive Summary

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

Introduction

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

Our References

See our references for this article and related articles at this link.

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

They fall into the following categories:

Presumption: Failing to prove a conclusion by assuming the conclusion in the proof.
Weak Inference: Failing to provide sufficient evidence.
Distraction: Providing a conclusion with irrelevant evidence.
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 a quotation from ERP proponents. These logical fallacies are listed below:

Appeal to Probability: Takes something for granted because it might be the case.
Appeal to Fear: A call to emotion where an argument is made by increasing fear. The fear discussed may have a kernel of truth, but the proposer actively increases this fear to win the argument and influence decision-making.
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.
Argument from Ignorance: Assuming a claim is true because it has not been proven false.
Argument from Repetitions: States that, as it has been discussed, it is not worthwhile considering.
Shifting the Burden of Proof: Does not prove a claim but asks for the claim to be disproved.
Argument to Moderation: Assuming that the compromise between two positions is always correct.
Argumentum ad Hominem: Evading the standard requirement to provide counterevidence through the use of a personal attack.
Hasty Generalization: Leaping to a conclusion based on a small sample of data.
Argumentum ad Numerum or Argumentum ad Populum: Appeals to a widespread belief; the fact that many people believe it means it must be true.
Appeal to Authority: An assertion is deemed true because of the person’s position of authority asserting it.
Appeal to Accomplishment: Assertion is considered true or false based upon the accomplishment level of the proposer.
Appeal to Consequences: 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.
Wishful Thinking: An appeal to emotion where a decision is made based upon what is pleasing to think to be true.
Argumentum ad Novitatem/Appeal to Novelty: 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 logic presented by ERP vendors, consulting firms, and IT analysts.

The Logic Used to Sell ERP

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

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

Details on the The Various Logics or Arguments

Y2K (the Year 2000)

Many ERP purchasing decisions were made because companies felt they needed ERP. This interpretation was often based either upon fear (such as the Y2K fear that drove so many ERP implementations) or a herd mentality. ERP presented itself as a silver bullet for the Y2K issue: instead of adjusting the dates on all of a company’s old systems to ensure they would work adequately post the year 2000, they could be replaced—swept away by a shiny new ERP system. Fear of Y2K was central to 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 one 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 ERP did not meet all their business needs, the next idea was to implement the ERP software first and then connect non-ERP software (the so-called best-of-breed software) second. This approach is 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 to 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 was never the case for the vast majority of companies that implemented ERP software.

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

This gets into the customization of ERP systems.

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

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

Many companies have tried to “get more out of their ERP systems” by pushing them in directions where they were never designed to go (of course, with a healthy dose of customization). Still, companies that rely on ERP systems in this way cannot hope to leverage the available manufacturing software properly and will always run their plants at a much lower level of efficiency than companies that adopt the more sophisticated and nuanced IT strategy. ERP systems never replaced all 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. They moved away from this logic so quickly that it makes one wonder if they believed it themselves.

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

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

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

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

Account Control

From the competitive positioning perspective, selling an ERP system to a company was one of the best ways 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 buyer’s interests, 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 third party’s desires. IBM was the first vendor to perfect account control, and many of their strategies (including how they leased their machines, the prices they charged, how they dealt with their customers, etc.) were based on account control strategies. Account control is behind how major consulting companies interact with their clients.

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

Misinformation on ERP

Once the software vendors had implemented the ERP system at a company, their relationship with that company was based on being responsible for its 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, while the integration from other applications they sold would naturally integrate into their ERP system. The software from different vendors was an “unknown,” a guarantee that other software from that vendor would integrate into 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, 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 did work better than competing applications on Windows, although they often made sure of this by postponing information about Windows from becoming public until the new version of Windows was released—they could have very easily released the APIs earlier). This monopoly allowed ERP vendors to compete unfairly: they told clients their applications had a head start integrating into 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 to mislead potential customers into thinking that they could pull a large variety of data from SAP ERP into BI/BW. Instead, what customers received was a starter kit. Companies like SAP and Oracle promptly took full advantage of this market power, which enabled them to charge top dollar for all of their applications and easily compete with applications far superior.

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 in which SAP developed: their pseudo partnership program with other vendors promised entry into SAP’s enormous client database, when in fact, the program was an intelligence-gathering operation by SAP to allow it to steal intellectual property from their “partner” vendors, thus helping them to backward engineer the application.

Once again, the IT/business press and IT analysts failed to explain what this program was, and they lauded it. 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 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 platforms. While they have adapters or interfaces to one another, they are each a separate application; they each have a different database and sit on different hardware. Many of these new applications are acquisitions: after a software vendor acquires another software vendor, they typically develop a marketing program to inform all current and potential customers how well the new applications will work together. ERP clients who purchased Oracle applications were worse off than if the software had been left independent and adapters had been written to Oracle ERP. The long-term history of software acquisition demonstrates that the application stalls as the software price goes up. The application is often subsumed into what is often an inferior application. There are several cases where the acquired application is mainly eliminated. However, the acquiring company also acquires the customers and can increase their prices now that they have removed a competitor from the marketplace. Software acquisitions have only two winners:

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

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

As a result, companies that implemented ERP are essentially back where they started before moving to ERP. 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 never came about.

One Size Fits All

One of the original arguments used to sell ERP systems was that the ERP system’s standard functionality could be used “right out of the box.” But ERP systems are regularly customized, so 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. Still, I can confidently say that most companies that purchased ERP systems had no idea they would eventually customize their ERP systems to the degree they did.

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

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

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

Planning for the Inevitable Customization

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

ERP’s Operational Improvement

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

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

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

“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 possible, and it rarely happens that the systems are operational but not declared “live.” More commonly, the system is announced live before the implementation is complete. Much fine-tuning is required post “go-live” to get the applications working as needed. Frequently, I am part of a team that tunes live projects.

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

Another alternative explanation for the productivity gain during the implementation could be the “Hawthorne Effect.” The Hawthorne Effect is when subjects in a study improve their performance because they know they are being observed. The researchers do not mention this as a possible reason for the post-go-live performance improvement, but it is quite a prominent 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 chooses), the fact that ERP is seen as a “mandatory infrastructure”—as stated in many articles and generally accepted in companies—does not seem to compute.

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

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

What Was Promised?

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

Go to top

Conclusion

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

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

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