The Enormous Waste of ERP Systems

Executive Summary

• Dave McComb’s book Software Wasteland is one of the best books on IT and IT waste.
• Companies have spent huge sums on ERP systems, but have received little return from these investments.

Introduction

The quotes from Dave McCombs’ books are quite shocking. These quotes are so amazing, we created a number of articles to make them available to ourselves in an easily findable way so that we could use them in the future.

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

Quotes

“Enterprise applications are expensive. Even the internal cost to procure them is expensive. We have had front row seats and watched several organizations spend years and at one organization spend over a decade trying to buy an ERP system. (Imagine what they could have accomplished in a decade if they hadn’t been pursuing this goal.) However, it’s not just the expense. As expensive as they are, few companies would believe they could recreate the functionality for less by building it or reusing existing well-tested components.

The second hidden cost to packaged applications is the implementation cost. You might think that the cost to implement a packaged solution and a custom solution might be comparable, but they are not. I have had the privilege of working on a custom system being implemented in one division of a client while another division was implementing a packaged solution. While the packaged solution saved some money on development, they more than made up for it in implementation.

The cost of implementation a packaged application in an enterprise is mostly driven by these activities.

1. Configuration: As packages have become more and more complex, the act of turning on and off various features has become a dark art. In the world of health administration software, battle between vendors is often pitched in “”how many flags do you have?”” front. The “”flags”” are options you can turn on or off in the system functionality. These flags essentially turn on and off chunks of code within the system. In some ways, configuration is the equivalent of coding. If there were just a few flags and they were isolated and independent, it would just be a matter of choosing between alternate bits of tested functionality. But when there are thousands, and they interfere with each other, configuration can get complex and should only be performed by experts.”

Modification or extension: Most packages do not do exactly what you want them to. The alternatives are either to modify the software you’ve purchased or to extend with additional programs. Extension is greatly preferred becuase modifying third party code makes it very hard to stay current with package updates. However, often modification is the only way to go. Here we get an interesting bit of reuse of the concept introduced in the previous section. Recall that the cost of a change introduced late in a system’s lifecycle can be 40 times as expensive as the same feature being introduced early in the lifecycle. Imagine you had 20 such changes you want to introduce to a system. The cost of adding them to an already existing system would be 800 (40 * 20) times as much as adding them to a customer system early in its design stage. Keep in mind you still have to build the base system to apply the 20 changes, but as we’ll see later, this is nowhere near as hard as it used to be.

Data conversion. When you buy package software, you get a data model that is arbitrarily different from the one you are replacing. Also let’s hope you are replacing only one, as many package implementations are additive: they are adding just a few extra features or datatypes that can’t be handled by the existing systems, but aren’t worth dismantling the existing systems. By itself, that isn’t a problem. The problem arises when you do a trial conversion and you realize that in addition to being structured differently, the new system requires new data and has different ideas about data integrity and validation. This often gives rise a “Data Quality” project to “Clean up” the data. Yes, your existing system often has arbitrarily different ideas about quality (baked int from the vendors experience with other clients) that you must now conform. Again, the data clean-up project is often several times larger than the cost of the software. To be sure, some of the clean up is useful, but most of the work is conforming to a different model.

Change management: Most of your employees have grown up using the existing system. This is how they know your business and your industry. Whatever the labels are on the screens and reports, whatever workflow the system has imposed on them, over time becomes their internal mental model of how a system should work. Many have made careers out of working around the idiosyncrasies in the existing system to get it to work. The new system has all new screens, new reports, new terms, new labels, new impliit and explicit work flow, and a need for a whole slew of new workarounds. The new system proclaims this state of affairs as “best practice.” It is just some averaging of the vendors’ original conception with whatever part of their implementation experience they could fit back into the base product. However, the jarring nature of the change leads to “change management,” which is a euphemism for retraining people who had learned on the job and aren’t excited about a system that typically isn’t easier, just different. Again, the change management portion of a package implementation project can easily exceed the cost of the system.

Conclusion

ERP systems are extraordinarily wasteful systems that are supported by an army of financially biased vendors and consulting firms.

ERP systems have been a massive failure in terms of attaining their previous promises made by ERP vendors. ERP systems are now major consumers of IT budgets. Our book The Real Story on ERP: Separating Fiction from Reality, demonstrated that ERP systems do not have a positive ROI.