Why ERP Implementations Keep Failing

In the fall of 1999, Hershey's was preparing for Halloween, its most important sales season of the year. The company had just finished a $150 million SAP implementation. According to accounts from the time, the system went live in July, months behind schedule, and when the Halloween orders came in, the software could not handle the load. Shipments failed. Stores ran short on candy. Hershey's reported a 19% drop in quarterly profit. The software worked. The timing did not. And the timing was chosen not by engineers but by executives who had a deadline to hit.

That story is almost 27 years old. Most IS researchers know it by heart. And yet, large ERP go-lives still produce headlines about cost overruns, failed cutoffs, and user resistance every year. The tools have improved. The vendor certifications have multiplied. The consulting methodologies have grown thicker. The failures keep coming.

The reason is not the software. It never was.

ERP systems are built on a premise: that a business can map its processes onto a standard set of workflows defined by the vendor. SAP, Oracle, and Microsoft Dynamics each carry embedded assumptions about how procurement, finance, manufacturing, and HR should work. When a company buys one of these systems, it is not just buying software. It is buying an opinion about how organizations should operate. The question is whether that opinion matches the reality inside the organization doing the buying.

Most of the time, it does not match well. And the gap between the software's assumptions and the organization's actual way of working is where ERP implementations die.

Around 2000, Nike rolled out a demand-planning system from i2 Technologies. According to widely reported accounts from the time, the system generated incorrect demand signals that led to roughly $100 million in inventory problems. Nike over-ordered some products and under-ordered others. Again, the software ran. The configuration was wrong. The forecasting model did not fit how Nike's supply chain actually operated.

A few years later, Waste Management sued SAP for $500 million in 2008, claiming SAP had promised the software would work for their business when it would not. The case settled, but the underlying complaint was familiar: the vendor sold a vision; the client bought it; the fit between the software and the business was never really there.

What ties these cases together is not bad code. It is misaligned expectations and what researchers in IS would call an organizational readiness problem. Companies sign contracts based on demos. Demos show best-case configurations. The actual work of fitting a complex ERP to a messy real-world organization takes years and requires the organization to change deeply, sometimes painfully. That change is always harder than expected.

There is a theoretical frame that explains this well, and it goes back further than most people think. Eric Trist and Ken Bamforth, writing in 1951 about British coal mines, argued that you cannot optimize a work system by treating the technology and the people separately. You have to optimize both together. A change to the technical side creates ripple effects on the social side, and vice versa. Their sociotechnical systems framework, later extended by IS scholars in the context of information systems, makes a simple but powerful point: a system is not just the code. It is the code plus the people plus the processes plus the shared understandings that make work happen.

ERP implementations routinely violate this. Companies optimize the technical side: they buy good software, configure it carefully, test it in staging environments, train superusers. Then they assume the social side will adapt. Employees will follow the new workflows. Managers will stop maintaining the old spreadsheets. Department heads will give up the workarounds they spent years developing because those workarounds fit their actual needs better than the standard process ever will.

That assumption is almost always wrong.

When an organization forces its processes to fit the software rather than the other way around, it does not just create friction. It loses institutional knowledge. The old process, messy as it was, encoded years of learning about edge cases, exceptions, customer quirks, and supplier behaviors. Nobody wrote that knowledge down. It lived in the people who ran the process. When the ERP arrives and replaces the process with a standard workflow, that knowledge disappears. The new system handles the common case fine. The edge cases start breaking, quietly, until they break loudly.

There is also a political dimension that IS research talks about less than it should. ERP go-lives are driven by deadlines that have nothing to do with readiness. A fiscal year ends. A contract with a legacy system vendor expires. A board presentation promised a go-live date eighteen months ago. By the time that date arrives, the project team knows the system is not ready. The data migration has gaps. The training was rushed. The parallel run showed problems. But the project is over budget, and canceling or delaying feels worse politically than going live and fixing problems afterward.

So they go live. And then they fix problems afterward. Expensively.

Hershey's went live at harvest season because the project had already slipped twice. Nike's supply chain team was under pressure to show results from its technology investment. Waste Management's leadership had approved the budget and wanted to see the system running. In each case, the people closest to the work knew things were not right. The decision to proceed anyway was made further up the chain, by people whose incentives were tied to the deadline, not to the operational outcome.

This is not a technology problem. It is a governance problem dressed in technology clothes.

The uncomfortable conclusion, for anyone who has watched these projects from the inside, is that "go-live" is the wrong measure of success. I have seen organizations celebrate a go-live while their finance team was manually reconciling records in Excel because the ERP's closing process did not work right. The system was live. Nothing important was actually working. Real success in an ERP implementation is not the moment the system goes live. It is six months later, when users have stopped using workarounds, when the data in the system matches reality, when the processes the organization actually runs are the processes the system was built to support. That moment is much harder to reach, much less visible to executives, and much less likely to appear in a press release.

Until organizations start measuring success that way, and until project timelines are driven by readiness rather than by calendar pressure, the pattern will keep repeating. The software will keep getting blamed. The CIOs will keep getting fired. And somewhere, next year, another company will go live too early, during the worst possible time, and wonder what went wrong.