More than a quarter of ERP projects significantly overshoot their initial budget, according to Panorama Consulting’s 2024 ERP Report. These statistics are well-known, widely cited, and routinely ignored at contract-signing time. What gets less attention is the precise anatomy of what happens when an ERP project transforms into an industrial catastrophe: who made which decision, at what moment, and why no one stopped it.
This article provides a forensic analysis of five publicly documented cases — Nike, Revlon, FoxMeyer, Lidl, Hershey — to extract the failure mechanisms and one actionable countermeasure for each. The intended audience: CIOs, CFOs, and CEOs of mid-market and enterprise organisations who are about to sign an ERP contract or are already in the implementation phase.
Why Large ERP Projects Fail — The 4 Recurring Pathologies
Before diving into the cases, it is worth establishing an analytical framework. The study of documented ERP failures consistently surfaces four recurring pathologies, often in combination.
Underestimating change management. Project teams allocate less than 5% of the total budget to change management on average. Yet Prosci’s research shows that projects investing more than 10% in this area have a success rate 33% higher than those that do not. The gap is structural: change management produces no visible deliverable — so it is the first thing cut when budgets come under pressure.
Poorly scoped functional perimeter (scope creep). Every workshop surfaces new requirements. Every department head wants “just a few specific features.” What begins as a standard ERP deployment ends as a bespoke development exercise, with timelines slipping and an integrator invoicing each new request as a change order.
Wrong choice of implementation partner. The integrator may be changed mid-project — which is fatal — or may lack the genuine sector expertise they pitched during the sales process. The reference client cited in the proposal is not always the same team that shows up on your project.
Passive executive sponsorship. An ERP reshapes business processes, master data, roles, and accountabilities. Without an active executive sponsor — not nominally assigned but genuinely active — trade-offs don’t get made, resistance doesn’t get managed, and the project drifts into “maintenance of the status quo” mode.
These four pathologies form the analytical framework for the five cases below.
Case 1 — Nike and i2 Technologies (2000–2001): $100 Million and Empty Shelves
What happened
In 2000, Nike deployed a new demand planning and supply chain module from i2 Technologies, integrated into its existing ERP environment. By June 2000, the system began generating erroneous orders: popular models like the Air Jordan went out of stock in stores while slow-moving models accumulated in warehouses. Nike acknowledged $100 million in lost sales, with the total market impact estimated at $400 million when factoring in the stock price hit.
Forensic root causes
The core issue was a fundamental incompatibility: i2’s demand forecasting module and its production planning module operated on different business rules and stored data in different formats. The two applications did not speak the same language. Additionally, i2 had been so heavily customised to integrate with Nike’s existing systems that some operations took over a minute to execute — making the system unusable at scale.
Pathologies triggered: wrong implementation partner, poorly scoped perimeter (simultaneous deployment of multiple modules without compatibility validation), uncleaned data at go-live.
Actionable lesson
Never deploy a supply chain module without first validating the consistency of master data (items, suppliers, lead times) and the compatibility of business rules across modules. Require a realistic load test using your own production data — not a demo dataset — before any go-live.
Case 2 — Revlon and SAP S/4HANA (2018): $64 Million in Lost Sales and a Class Action
What happened
In February 2018, Revlon cut over to SAP S/4HANA for a significant portion of its North American operations. The go-live triggered major disruptions at its Oxford facility: the company could no longer manufacture certain finished goods quantities or fulfil deliveries to major US retailers. The result: $64 million in unrealised sales, $54 million in remediation charges, and a net loss of $70 million in Q4 2018. In 2019, shareholder class actions followed, alleging that investors had been inadequately informed of implementation risks.
Forensic root causes
Two structural factors stand out from the post-mortem analysis. First, the lead integrator had changed mid-project, after the design phase — one of the most dangerous transitions in an ERP deployment: the incoming integrator inherits an architecture they did not design. Second, user acceptance testing was insufficiently thorough relative to the complexity of cosmetic manufacturing processes, particularly batch management and traceability.
Pathologies triggered: wrong implementation partner (integrator change mid-project), insufficient governance (leadership did not halt the project despite warning signals), incomplete testing.
Actionable lesson
The integrator who designed the solution must be the one who delivers the go-live. Any change to the core team after the design phase must trigger a formal review of the test plan. Contractualise this rule upfront: a “key personnel continuity” clause with a substitution penalty protects your interests before you sign.
Case 3 — FoxMeyer Drug and SAP R/3 (1996): The Bankruptcy of a $5 Billion Distributor
What happened
FoxMeyer Drug was the fourth-largest US pharmaceutical distributor, with $5 billion in annual revenue. In 1993, it launched two concurrent projects: an SAP R/3 implementation and the construction of a highly automated warehouse with robotic picking. The initial SAP budget was $65 million. When SAP went live, the system could only process 10,000 orders per night — against 420,000 with the previous system. FoxMeyer was forced into bankruptcy in 1996. The bankruptcy trustee subsequently sued both SAP and Andersen Consulting for $500 million each, though the cases settled out of court.
Forensic root causes
FoxMeyer made the mistake of coupling two simultaneous major transformations: the ERP and the physical automation of the warehouse. The two projects created interdependencies that nobody managed. The SAP system had not been dimensioned for FoxMeyer’s actual transaction volumes — a pharmaceutical distributor processes millions of order lines daily. Employees, seeing their jobs threatened by automation, partially sabotaged the data migration. Management created no mechanism to address this resistance.
Pathologies triggered: absent change management, overly broad scope (two simultaneous transformations), absent governance (no arbitration between the two projects).
Actionable lesson
Never couple an ERP migration with a simultaneous transformation of physical operations (relocation, automation, restructuring). Sequence your transformations with a minimum six-month gap between the ERP go-live and any other major infrastructure change. Size the system against your real peak loads from the pre-project phase — not your average volume.
Case 4 — Lidl and SAP IS-Retail (2011–2018): €500 Million Written Off After 7 Years
What happened
In 2011, Lidl launched the eLWIS project (electronic Lidl Warenmanagement und Informations System), an SAP IS-Retail implementation intended to modernise its inventory management globally. What was meant to cost €201 million over a few years ultimately consumed €500 million over seven years before being abandoned in July 2018. Lidl reverted to its legacy in-house system “Wawi,” which it then modernised instead.
Forensic root causes
The central reason is well-documented: Lidl managed its inventory at purchase price, while SAP IS-Retail natively operates on retail (selling) price. Rather than adapting its processes to the SAP standard, Lidl chose to adapt SAP to its processes. This decision triggered a cascade of customisations, each making the system more fragile, slower to maintain, and costlier to evolve. Governance was also fragmented across national entities, making arbitration impossible at the group level.
Pathologies triggered: over-customisation (refusal to adapt processes to the standard), dispersed governance (no single sponsor), poorly scoped perimeter (strategic objectives unachievable at an acceptable cost).
Actionable lesson
The founding principle of a successful ERP deployment is this: adapt your processes to the standard ERP, not the other way around. Every customisation carries a hidden cost at every upgrade. Before approving any “business-specific feature,” ask: is this a genuine competitive differentiator, or a codified work habit? Most of the time, it is the latter — and it does not justify a bespoke development.
Case 5 — Hershey and SAP/Siebel/Manugistics (1999): Halloween Without Chocolate
What happened
In 1999, Hershey deployed three platforms simultaneously: SAP R/3 (ERP), Siebel (CRM), and Manugistics (supply chain planning). The entire programme ran on a 30-month timeline — instead of the recommended 48 months — with a go-live in July 1999, just six weeks before the peak Halloween season. The result: Hershey was unable to fulfil $100 million in orders during the most critical period of the year. Quarterly earnings fell 19% and the stock lost 8%.
Forensic root causes
Two factors precipitated the disaster. The timeline was driven by the Y2K deadline: the company needed to be on its new systems before 1 January 2000, which created artificial pressure on the go-live date. This urgency led to compressed testing phases — “shortened to the point of ineffectiveness,” according to post-mortem analyses. And nobody applied the elementary rule of scheduling a go-live well away from peak business periods.
Pathologies triggered: overly broad scope (three simultaneous systems), absent governance (no arbitration on the timeline), insufficient testing.
Actionable lesson
The go-live date is a strategic decision, not a project delivery milestone. It must be chosen during a low-activity window, with a stabilisation buffer of at least eight weeks before the next business peak. Identify your three highest-activity periods of the year at the scoping stage, and contractually prohibit a go-live within 12 weeks of each one.
The Anti-Failure Toolkit: 10 Questions to Ask Before Signing
These five cases converge on a set of warning signals that every decision-maker should work through before committing to an ERP project.
- Have you listed the three peak-activity periods of your business year? Is the go-live date more than 12 weeks away from each of them?
- Is the integrator that won the tender the one who will actually deliver the project? Request CVs of the consultants who will be on site — not the reference profiles from the sales proposal.
- Have you quantified the cost of every customisation requested? Any non-standard requirement must carry a five-year maintenance cost estimate.
- Is your master data clean before configuration begins? Items, suppliers, customers, chart of accounts: run a data quality audit before anything else.
- What is your resistance-management plan? Who owns it, with what budget, and what KPIs?
- Do you have an executive sponsor who will personally attend steering committee meetings — not one who systematically delegates?
- Does the test plan include load scenarios using your real production data? Testing on synthetic data or reduced volumes validates very little.
- Do you have a key personnel continuity clause in the integrator contract? Without it, senior consultants can be rotated off after the sale.
- Are you running another major transformation simultaneously (relocation, automation, restructuring)? If so, sequence them.
- Do you have a documented, tested rollback plan? FoxMeyer did not.
Conclusion
These five disasters — empty shelves in Portland, lipstick stranded in a warehouse, a pharmaceutical distributor in bankruptcy, €500 million buried in code that never shipped, and Halloween without chocolate — have very little to do with technology. They have everything to do with governance decisions made poorly, data prepared inadequately, timelines set unrealistically, and processes that no one was willing to challenge.
A successful ERP implementation is not a matter of budget or vendor reputation. It is a matter of discipline in scoping, testing, and change management. These five cases illustrate that more vividly than any theoretical framework could.
To go further, read our guide on the red flags that signal an ERP project heading for failure and our practical guide to ERP change management. If you are in contract negotiation, our article on the 15 clauses to secure before signing gives you the concrete levers to protect your organisation.
