- 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.
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:
- Presumption: Failing to prove a conclusion by assuming the conclusion in the proof.
- Weak Inference: Failing to provide suffi cient evidence.
- Distraction: Providing 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 the form of 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: 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.
- 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 discussing.
- 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 on the basis of 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: Where an assertion is deemed true because of the position or authority of the person asserting it.
- Appeal to Accomplishment: Assertion is considered true or false based upon the accomplishment level of the proposer.
- 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.
- 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: 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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:
- The Acquiring Company: They eliminate a competitor.
- 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.
Should SAP Come Clean on How Much SAP ERP Relies on Excel?
In the original presentations from SAP, R/3/ECC was primarily about work in the application. Customers were not told, even after the evidence was quite clear that users would be using ECC in combination with Excel that it is how the system would be used. The number one way to report and do analysis in ECC? Yes, that would be Excel. ECC has been fantastic for creating external spreadsheets. It seems that Microsoft does not get enough credit for ECC being able to function.
What Was Promised?
In research, it is very important to evaluate what was promised, and then what happened. One does not view a discrepancy between promise and outcome and disregard it unless there is no research motive. Moreover, SAP salespeople and consulting companies routinely understate how much ECC relies upon external systems to customers. You don’t even hear the word Excel on SAP presentations. Its as if ECC does everything.
ERP systems were, in essence, a simplistic platitude that was appealing. Remember, the first sales pitch of ERP was that it was the only system you would ever need. So ERP systems were sold with a sophistication similar to razors or coffee. Over decades the logics presented to sell ERP have turned out to be universally untrue. However, because the media entities and consulting firms and other pro-ERP sources never performed a post mortem, these false logics are used to sell ERP systems to this day.
As a principle, it is foolish to be impressed with a system because it is bundled. It is also unwise to try to single-source most of your software from one vendor. However, Gartner was happy to sheepdog customers to SAP vendors….for the right price (payments from vendors).
SAP customers are finding out with indirect access claims and continually increasing support costs, that the more leverage the vendor has over you, the worst you will be treated over time. SAP ERP systems do not have an ROI, and that negative ROI is going to grow as SAP continues to harvest more and more out of their customers. And the customers are now trapped because they have a vendor they over-relied upon, thinking they would have fewer headaches by concentrating their vendor spend.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
Financial 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.