Why do ERP Projects Fail?

Part 4 of “What is ERP Really”
At its simplest level, ERP is a set of best practices for performing different duties in your company, including finance, HR, manufacturing and the warehouse. To get the most from the software, you have to get people inside your company to adopt the work methods outlined in the software. If the people in the different departments that will use ERP don’t agree that the work methods embedded in the software are better than the ones they currently use, they will resist using the software or will want IT to change the software to match the ways they currently do things. This is where ERP projects break down. Political fights break out over how—or even whether—the software will be installed. IT gets bogged down in long, expensive customization efforts to modify the ERP software to fit with powerful business barons’ wishes. Customizations make the software more unstable and harder to maintain when it finally does come to life. The horror stories you hear in the press about ERP can usually be traced to the changes the company made in the core ERP software to fit its own work methods. Because ERP covers so much of what a business does, a failure in the software can bring a company to a halt, literally.

But IT can fix the bugs pretty quickly in most cases, and besides, few big companies can avoid customizing ERP in some fashion—every business is different and is bound to have unique work methods that a vendor cannot account for when developing its software. The mistake companies make is assuming that changing people’s habits will be easier than customizing the software. It’s not. Getting people inside your company to use the software to improve the ways they do their jobs is by far the harder challenge. If your company is resistant to change, then your ERP project is more likely to fail.

One cautionary tale that came to light in 2008 illustrates that sometimes there is a big difference between what an ERP vendor promises to deliver in its software and what actually is ready for prime-time enterprise use. Trash-disposal company Waste Management announced in March 2008 that it was suing SAP, seeking the recovery of $100 million in project expenses that related to a failed ERP implementation that had started in 2005. In the complaint, Waste Management alleges that SAP executives participated in a fraudulent sales scheme and that SAP’s Waste and Recycling ERP product was actually “fake software” that was still not ready for Waste Management’s use by spring 2008.

How do I configure ERP software?

Even if a company installs on-premise ERP software for the so-called right reasons and everyone can agree on the optimal definition of a customer, the inherent difficulties of implementing something as complex as ERP is like, well, teaching an elephant to do the hootchy-kootchy. The packages are built from database tables, thousands of them, that IS programmers and end users must set to match their business processes; each table has a decision “switch” that leads the software down one decision path or another. By presenting only one way for the company to do each task—say, run the payroll or close the books—a company’s individual operating units and far-flung divisions are integrated under one system. But figuring out precisely how to set all the switches in the tables requires a deep understanding of the existing processes being used to operate the business. As the table settings are decided, these business processes are reengineered, ERP’s way. Most ERP systems are not shipped as a shell system in which customers must determine at the minutia level how all the functional procedures should be set, making thousands of decisions that affect how their system behaves in line with their own business activities. Most ERP systems are preconfigured, allowing just hundreds—rather than thousands—of procedural settings to be made by the customer.

Even the new on-demand or software-as-a-service (SaaS) ERP offerings necessitate some system configuration and customization to each company’s individual requirements. This process, however, generally takes less time and resources than with an ERP application that’s installed on-premise.

How do companies organize their ERP projects?

Based on our observations, there are three commonly used ways of installing ERP.

The Big Bang—In this, the most ambitious and difficult of approaches to ERP implementation, companies cast off all their legacy systems at once and install a single ERP system across the entire company. Though this method dominated early ERP implementations, few companies dare to attempt it anymore because it calls for the entire company to mobilize and change at once. Most of the ERP implementation horror stories from the late ’90s warn us about companies that used this strategy. Getting everyone to cooperate and accept a new software system at the same time is a tremendous effort, largely because the new system will not have any advocates. No one within the company has any experience using it, so no one is sure whether it will work. Also, ERP inevitably involves compromises. Many departments have computer systems that have been honed to match the ways they work. In most cases, ERP offers neither the range of functionality nor the comfort of familiarity that a custom legacy system can offer. In many cases, the speed of the new system may suffer because it is serving the entire company rather than a single department. ERP implementation requires a direct mandate from the CEO.

Franchising strategy—This approach suits large or diverse companies that do not share many common processes across business units. Independent ERP systems are installed in each unit, while linking common processes, such as financial bookkeeping, across the enterprise. This has emerged as the most common way of implementing ERP. In most cases, the business units each have their own “instances” of ERP—that is, a separate system and database. The systems link together only to share the information necessary for the corporation to get a performance big picture across all the business units (business unit revenues, for example), or for processes that don’t vary much from business unit to business unit (perhaps HR benefits). Usually, these implementations begin with a demonstration or pilot installation in a particularly open-minded and patient business unit where the core business of the corporation will not be disrupted if something goes wrong. Once the project team gets the system up and running and works out all the bugs, the team begins selling other units on ERP, using the first implementation as a kind of in-house customer reference. Plan for this strategy to take a long time.

Slam dunk—ERP dictates the process design in this method, where the focus is on just a few key processes, such as those contained in an ERP system’s financial module. The slam dunk is generally for smaller companies expecting to grow into ERP. The goal here is to get ERP up and running quickly and to ditch the fancy reengineering in favor of the ERP system’s “canned” processes. Few companies that have approached ERP this way can claim much payback from the new system. Most use it as an infrastructure to support more diligent installation efforts down the road. Yet many discover that a slammed-in ERP system is little better than a legacy system because it doesn’t force employees to change any of their old habits. In fact, doing the hard work of process reengineering after the system is in can be more challenging than if there had been no system at all because at that point few people in the company will have felt much benefit.

The On-Demand Nibble—You’re most likely to see this approach in a small or midsize business that’s lost its patience for Excel spreadsheets and the fax machine, and in large companies that either have massive operations and will never be able to standardize on one system or have been burned by costly and not-so-satisfying ERP rollouts in the past. In this instance, companies turn to a small but growing number of on-demand or software-as-a-service (SaaS) ERP vendors that can offer:

• faster implementation times (there’s no software to install on-premise, and that literally shaves months off installation periods);
• easier and more frequent upgrades (they can happen automatically because the vendor manages the applications and can roll out patches and bug fixes more regularly); and
• cheaper up-front costs (the software price tag can be much cheaper than traditional on-premise applications because of subscription pricing that is on a “per user, per month” basis as well as big reductions in integration and consulting fees).

Why companies are just “dipping their toes” in the on-demand and SaaS waters right now is because those companies (and their vigilant IT departments) still have concerns about housing their mission-critical and highly sensitive ERP data (such as HR and financial) on a third party’s servers and not their own.