- The broad purchase of ERP systems without looking for evidence says many things about IT decision making within companies.
- Learn what areas lead to so many companies to fail on ERP.
Decision-making in companies is often presented as highly rational. The assumption is that attentive and thorough research is performed before purchasing decisions are made. A perfect example of this line of thinking is presented in the following quotation:
“If IT were not delivering value, rational decision makers would not keep investing in it.” — Andrew McAfee
The above quotation provides an example of the logical fallacy of an appeal to authority combined with the logical fallacy of an appeal to accomplishment. The same argument could be made for exotic financial instruments. How could mortgage-backed securities and credit default swaps—which fell in value so precipitously that without government intervention every US investment bank involved in these instruments would have had to shut their doors—possibly be lacking in value?
Many entities, ranging from consulting firms to the business press that cover these companies, as well as the software buying companies themselves, have an interest in having this line of reasoning accepted. However, the results of my research and experience in software selection, some of which is encapsulated in the book, Enterprise Software Selection: How to Pinpoint the Perfect Software Solution using Multiple Information Sources, actually show considerable evidence to the contrary. A few of the issues that are problematic for IT decision-making are listed below:
- Selecting Biased Information Sources: Companies often lack the knowledge to make appropriate software selection decisions for themselves. Often this issue is not mitigated by hiring external parties because the buying companies are frequently misled by advisory firms. These firms are more interested in selling IT consulting services than in providing objective advice. These advisory firms are not “fiduciaries,” in that they have no legal responsibility to put their client’s fi nancial interests above their own. This issue is similar to the problem of a lack of fiduciary responsibility that the majority of financial advisors have, which is why financial advisors have a very strong tendency to place their clients into investment vehicles that benefit them more than they benefi t their client’s. This is discussed in detail in the following article. Enterprise software buyers rely upon research from entities that are themselves paid by software vendors, along with a host of other limiting factors.
- Accepting Simplistic Explanations: As will be shown repeatedly in this chapter, companies deciding which course of action to follow tend to be influenced by oversimplified rationales or logics. If the executive decision-makers knew technology better, and if they had studied the history of enterprise software sales methods, there is no way that the oversimplifi ed logics that were so effective in selling ERP to them would have worked. Another way of looking at this is that it was simply all too easy.
- Companies Do Not Delve into Detail on Functionality: There is a strong tendency for buying companies to accept that functionality between the software of multiple vendors is the same, as long as the description of the functionality is the same and the functionality is proven to be similar when demonstrated by a skilled pre-sales consultant. In fact, rarely is the competing functionality “the same.” Often there are very signifi cant differences in the usability, implement-ability and maintainability of functionality that is at first blush seen as identical across multiple applications. A purpose of the software selection process is to determine the best fit between the various desired functionalities versus its documented business requirements and the functionalities that are available from competing applications.
- Overestimation of Implement-ability: Companies have a strong tendency to overestimate what they can implement. Software vendors that market a broad or deep set of software functionality are of no help to these companies. However, some functionality is tricky to implement properly. In addition, companies will often have a certain level of funding in mind for software implementations, but will then implement more advanced functionality that requires a greater commitment of funds than they are interested in making. This lack of funding, which increases the general failure rate on projects, is addressed with the concept of Maximum Tolerable Functionality, as explained in the following article:
- Susceptibility to Salesmanship: Good salespeople are paid very well by software vendors for a reason. Salesmanship works. However, sales, regardless of how well done, does not have anything to do with how well the application can be implemented. Software salespeople will become “best friends” with their prospects, but after the sale is made, the relationship will not count for much. In fact, salespeople frequently make implementations worse by insisting that overpromised capabilities can be met with “creativity.” Some of the sales presentations that I have seen seem highly conceptual and have little to do with how an application is used in reality; one of the old jokes in this area is that the difference between a car salesperson and a software salesperson is that the software salesperson does not know he is lying. Unfortunately this joke has quite a bit of truth to it.
The Reality of Getting Around Rationality
There is no way of getting around the fact that companies appear far less rational when one works within them and sees “how the sausage is made,” than when one reads about them from afar. Business journalists, afraid of losing their access to information, have a strong incentive to place a positive spin on their coverage of a company, and most of the journalists are suitably compliant. Secondly, journalists don’t actually work in the companies they cover; thus it is quite easy for them to get bamboozled. Typically the executives who are interviewed and provide information to the journalists are good at selling or at least good at making good impressions, and are motivated to improve their prominence in the field as well as to positively impact the company’s stock price. A nice write-up on them and their company gives them even more negotiating leverage for salary increases, bonuses, stock options, etc. The most extreme example of this is the Wall Street Journal, which produces puff pieces on executives, building them into either geniuses or exemplars of highly capable and responsible corporate officers. The Wall Street Journal completely misrepresented how the industry worked when I was young and had not yet worked in these large companies. Now I understand the Wall Street Journal’s focus on making companies look good for stock market ends.
ERP Success and Failure
ERP success and failure rates are difficult to estimate, as was explained several pages ago. Much of this is definitional: what does one consider a success?
The failure rate of ERP systems is far higher than generally understood. While some high-profile failures get released to the business press, in most cases the news simply never gets out. I know of several implementations that have featured very prominently in the marketing literature of several software vendors, and have been featured both by this vendor, and even at the implementing company for over ten years. This customer is the main reference account for the software, has numerous press releases and marketing documents created for the project, and the truth is that the client is barely using the application. This is a case where the client has so much of their reputation wrapped up in the success of this application, that they cannot admit the failure—it is simply too embarrassing. However, another reason that so many implementation failures go unrecognized is that companies often do not even know the applications well enough to know that their implementations have failed. I have written a number of articles that explain how some of the most advanced software available is poorly configured to such a degree that there was no point implementing the sophisticated software that had been selected such as What is Your Supply Planning Optimizer Optimizing?
When I have brought up this matter to several of my clients, I have been told that there is no time allocated to fix the system; we must hit the deadlines to roll out the flawed configuration to new regions. At one company I was told that part of my role was to be enthusiastic about the system and to use my credibility with the business to get them to believe that the system was working well. The information I provide regarding a detailed analysis of system output and its fit with what the business needs is often suppressed and never reaches the ultimate decision-makers. The top decision-makers are in effect insulated from accurate information about how systems perform and instead are told only the good news. It’s a complicated political stew of competing agendas that results in decisions being made without any logical foundation for the positives or negatives of the actual impact of the decisions. However, I suspect that to those readers with significant work experience, this is not exactly news.
The first assumption to dispense with is that because companies are big they must have rational decision-making processes or have effective channels for transmitting information to decision makers. This should help to explain why companies have universally accepted the following examples of logic for implementing ERP systems.
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.
The Real Story on ERP
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.
- 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