Author: Jonathan Aquarone

ERP implementation challenges have been cataloged in the same vendor listicles for twenty years, and the same seven still sink projects: Hershey left $100 million of Halloween orders unshipped in 1999, and Mission Produce was shipping fruit it could not properly invoice in 2021, for substantially the same reasons. An enterprise resource planning (ERP) system replaces the software that runs your finance, inventory, payroll, and orders with one integrated platform, which is exactly why an implementation touches everything and why the failure modes repeat.

Here is the position this post will defend: the challenges are predictable. What is rare is a buyer who plans against them with numbers instead of adjectives. The pages that rank for this topic will give you ten bullet points and a demo link. None of them will tell you what each challenge costs when it lands, name a company it landed on, or give you a single measurable criterion for beating it.

This post does all three. Seven challenges, one named failure each, and the numbers that separate the projects that survive from the ones that end up in earnings calls and courtrooms.

How Often ERP Implementation Challenges Become Failures

Start with the statistic you have probably already read: “70% of ERP implementations fail, according to Gartner.” It circulates on page after page, and almost nobody links a source, because the primary document behind that exact sentence does not exist.

What Gartner actually published is a prediction, and it is worth quoting precisely: Gartner research predicts that by 2027, more than 70% of recently implemented ERP initiatives will “fail to fully meet their original business goals.” That is analyst Denis Torii, on Gartner’s own site. Failing to fully meet goals is a lower bar than “failure,” and a forecast is a different thing from a measurement. The distinction matters if you are using the number to size your own risk.

The measured numbers are less dramatic and more useful. Panorama Consulting, which has published an annual ERP report for over a decade, put budget overruns at 58% of projects and schedule overruns at 65% in its published report data, with year-to-year swings (55% and 75% appear in other editions). In the same research, 53% of organizations realized less than half of the business benefits they expected, and roughly 40% discovered mid-project that they had underestimated staffing.

So the honest read is this: most ERP projects go over budget or schedule, about half disappoint on benefits, and a minority fail outright. The interesting question is not the rate. It is the pattern. We dissected twenty named disasters in our hub post on why ERP implementations fail, and the same seven patterns explain nearly all of them. This post walks the same seven from the other direction: not as an autopsy, but as the list of what you will face and how to beat each one.

Every figure in that table is public record: earnings disclosures, court filings, or sustained press coverage. Not one of the ten pages ranking for this keyword names even one of these cases. Keep the table in mind as you read; each challenge below picks up its row.

Challenge 1: The Go-Live Date Is Set Before the Plan Exists

Most ERP timelines are political artifacts. A fiscal-year boundary, a contract renewal, a board promise, and suddenly the project has a date before it has a scope. The work is then compressed to fit the date, and the compression comes out of the phases that fail quietly: testing, training, data reconciliation.

Hershey is the canonical case, and we broke it down fully in our Hershey ERP failure post. The integrator’s recommended 48-month scope was squeezed into 30 months so the system would land before Y2K, which pushed go-live into the Halloween ordering season. The software worked. The order-fulfillment process around it did not, $100 million of orders went unshipped, and quarterly profit dropped 19%.

The realistic durations are knowable in advance. An implementation moves through the same phases everywhere (discovery and planning, design, build, data migration, testing, deployment, then support), and the whole sequence runs from a few months at a small company to well over a year at a large one. The testing block alone runs 10 to 15 weeks in practitioner planning guides, with integration testing taking 4 to 6 of those weeks. Cloud deployments compress the phases (one practitioner comparison puts the design phase at 2 months versus 3.5 on-premise, and build at 4 versus 7), but they compress, not eliminate.

How to beat it:

• Derive the date from the plan, never the plan from the date. If the date moves first, say so out loud and re-scope in the open.
• Carry a 20-25% contingency on both budget and schedule. Scope creep and underestimated staffing are the two most common causes of overruns in survey data cited across the industry, and both are certainties, not risks.
• Treat phase-gate dates as forecasts that update. A date that cannot move is a decision to cut testing; you just have not admitted it yet.

Challenge 2: Your Data Is Worse Than You Think

Every company believes its master data is basically fine. Then the migration starts, and the duplicates, dead suppliers, inconsistent addresses, and fields that mean different things in different departments all surface at once. Data migration typically eats 10-15% of total project cost in industry estimates, and it is the line item most often missing from the proposal that won your business.

Target Canada shows the ceiling on this problem. During its 2013 expansion, roughly 70% of the supply-chain data manually loaded into its new systems contained errors: wrong dimensions, wrong costs, wrong vendor terms. Shelves sat empty while warehouses overflowed. The data was the operating model, and the data was wrong.

There are real numbers for the fix as well. A 2025 peer-reviewed engineering study of ERP migrations found data-quality issues behind roughly 32% of migration delays and 27% of budget overruns, and found that organizations investing 12-15% of project budget in data quality saw about 41% fewer implementation issues. Teams running structured validation frameworks achieved measurably higher data accuracy than teams that migrated first and reconciled later. Profile the data before you sign the implementation contract, not after.

• Assign ownership by department: accounting owns financial data, service owns customer records, operations owns the item master. Unowned data does not get cleaned.
• Dedupe, validate, and fill gaps before load. Migrating garbage faster is not progress.
• Reconcile against source systems with end users in the loop, because they know which fields are lies.

SAP-specific migrations have their own failure anatomy, which we covered in why SAP data migrations blow up. The short version applies to every platform: the data workstream is a project, staff it like one.

Challenge 3: The System’s Model Isn’t Your Business Model

Every ERP package embeds assumptions about how a business runs: how inventory is valued, how orders flow, how approvals chain. When those assumptions fit your operation, configuration is straightforward. When they do not, you face the real decision of the whole project: change the process or change the software.

Lidl chose to change the software. The retailer ran its inventory management on purchase prices; SAP’s retail standard assumed sale prices. Rather than adapt, Lidl customized against the grain of the system for seven years, and wrote off around €500 million when it scrapped the project in 2018. The bitter footnote: SAP had named Lidl a top customer one year before the collapse. Avon hit the same wall from the user side in 2013, abandoning a four-year, $125 million rollout after sales reps found the new ordering system so hard to use that they started quitting.

The consultant’s rulebook is blunt on this. As Günter Dusch puts it in SAP Basics, Tips and Tricks for Prospective SAP Consultants (translated from the German): “SAP standard objects are never changed in Customizing! Copying and adapting is the correct procedure.” The rule generalizes past SAP: heavy customization is not a workaround for a model mismatch, it is a decision to maintain your own software fork forever.

Map your processes before configuration starts, and be honest about which ones are genuinely differentiating. Most are not, and standard process plus retraining is cheaper than custom code plus upgrades. A few are, and compliance obligations (tax rules, GDPR, SOX controls, industry certifications) belong in scope from day one rather than discovered as change orders. The failure mode on one side is Lidl. On the other side it is a company that paved its old cow paths into the new system and bought nothing but a migration.

Challenge 4: Everyone Selling to You Is Overpromising

The demo was flawless. Demos are. The demo environment has clean master data, no volume load, and no interfaces to your 15-year-old warehouse system. The estimate attached to it is the number that won a competitive bid, which means it is the optimistic scenario by construction.

Here is the sentence a systems integrator (SI, the consulting firm that implements the software) cannot print: the estimate that wins your deal is the one that flatters your assumptions, and the vendor billing by the hour is not incentivized to correct your schedule fantasy before signature. That is not villainy, it is structure. Waste Management’s lawsuit against SAP pleaded that the sales cycle promised $220 million in annual benefits from a system the suit alleged was demoed in a rigged environment; the claim started at $100 million in damages, grew toward $500 million, and settled. MillerCoors and HCL spent 2017 suing each other over whose fault an understaffed blueprint phase was, and settled too. The pattern survives every software generation because the incentive does.

Rates are part of the same fog. A widely cited industry figure puts ERP consultants at $150-175 per hour plus travel, but that number dates from 2020 and moves sharply with seniority, region, and how much of the team sits offshore. Treat any single blended rate as a question, not an answer: whose hours, at what tier, on which workstream, and what happens to the rate when the people you met in the sales cycle roll off.

What to demand before signing: the named delivery team, not the bench. References from projects that actually shipped, at your scale, in your industry. Every assumption behind the estimate in writing, so a broken assumption becomes a conversation instead of a change-order ambush. Vendor-published criteria lists (industry experience, support model, training capability, scalability) are fine as far as they go; they are also written by the people being evaluated. Finding a partner whose track record you can check independently is the actual problem, and it is the one our engine works on: describe your project and watch it rank vendors against your requirements, free, no signup, no sales call attached.

Challenge 5: Nobody Owns the Project (and Everyone Is Part-Time)

Ask who owns your ERP project and you will usually get a committee. Ask whose bonus depends on it and the room goes quiet. That vacuum is where projects die, because every hard call (pause or push, cut scope or slip the date) lands with the party that has the least incentive to make it honestly: the integrator.

National Grid is the buyer-side anatomy lesson. The utility went live in 2012 with a hurricane bearing down and a delay priced at roughly $50 million on the table. It pushed. What followed, per the litigation record: payroll errors, 15,000 unpaid supplier invoices, a period-end close that went from 4 days to 43, and a recovery effort that ran 850 contractors at a burn near $30 million a month for two years, about $585 million in all. Wipro paid $75 million to settle; the total program has been reported near $1 billion. The 4-to-43-day close is the detail worth memorizing, because it is the red flag any executive can read without a single technical briefing.

The staffing version of the same vacuum hides in plain sight, and the advice pages contradict each other about it. One ranking page cites SAP guidance that key project-team members need at least 25% of their week; another says 50% for months or years. Practitioners who have run these projects say neither works: core roles need to be full-time, with backfills hired so the business keeps running. Half attention produces full problems. Panorama’s finding that around 40% of organizations underestimated staffing is what that spread looks like after the fact.

• Name one accountable executive sponsor with real rank, and put them in every quality-gate review.
• Backfill your key users’ day jobs. Never schedule finance during month-end close or the warehouse during peak season.
• Buy independent quality assurance that reports to you, not to the integrator. Expert witnesses who work ERP lawsuits list the same recurring warning sign: an implementation partner prioritizing its own speed over the buyer’s continuity, with nobody contractually positioned to say so.
• Remember that ownership has consequences upward, too. When Invacare’s transformation stalled in 2021, the board did not fire the integrator. In 2022 it removed the CEO.

Challenge 6: Going Live With Defects You Already Know About

No project goes live defect-free, and no honest advisor will promise you one that does. The failure pattern is narrower: going live with critical defects you have already logged, because the date won the argument. MillerCoors went live in 2014 carrying 8 critical and 47 high-priority defects, by the account in its own subsequent lawsuit. Everyone knew. The go-live happened anyway.

“Test adequately” is the advice every ranking page offers, and it is advice you cannot operationalize. These are the gates practitioners actually use, and they are numbers, not adjectives:

Whether you cut over big-bang or in phases changes the blast radius, not the physics: a phased rollout by module or region caps how much can break at once, at the price of running two systems side by side longer.

Challenge 7: Treating Go-Live as the Finish Line

Projects are staffed, budgeted, and bonused to reach go-live. Then the consultants roll off, the war room empties, and the actual test begins: will a thousand people do their jobs in this system tomorrow morning? Success is adoption, not cutover, and ERP systems stay in service for a decade or more, so the adoption curve is the asset you were buying all along.

Revlon shows what the morning after looks like when this challenge wins. Its system went live in 2018; the business around it was not ready. The company disclosed a material weakness in its financial controls, attributed roughly $64 million in lost sales to service-level disruption at one distribution center, watched the stock fall 6.9% within a day of the disclosure, and collected investor lawsuits. The system was live. The business was not.

Training fails on timing more than on content. One implementation lead describes a retail client that trained every user two months before go-live; by launch day they had forgotten most of it, and the project ended up printing refresher job aids at every workstation and doubling floor support. Train within 2 to 3 weeks of first use, by role, with floor support and a named escalation path for the first weeks. One-and-done classroom sessions before cutover are how resistance to change gets manufactured: people do not resist the software so much as they resist being made bad at their jobs overnight.

• Budget hypercare (the intensive support window after go-live) for 3 to 6 months before the project starts, not out of whatever money is left.
• Define success as adoption metrics (transaction error rates, support-ticket trends, cycle times), and report them to the sponsor monthly.
• Expect the first enhancement requests within 3 to 6 months, and keep enough team to act on them. The system that cannot absorb its first change requests is already aging.

Frequently Asked Questions

What is a common challenge in ERP implementation?

Data quality is the most consistently underestimated one: duplicates, dead records, and inconsistent fields surface during migration, which typically consumes 10-15% of project cost. The most damaging, though, is a go-live date fixed before scope is understood, because it silently cuts testing and training.

What are the common ERP implementation failures?

The public record shows seven repeating patterns: compressed timelines (Hershey), bad data (Target Canada), forcing the system against the business model (Lidl), vendor overpromise (Waste Management), governance vacuum (National Grid), going live with known defects (MillerCoors), and abandoning the project at go-live (Revlon).

Why is ERP implementation so hard?

Because it is an organizational change wearing a software costume. One system replaces every department’s habits at once, so it inherits every process ambiguity, data sin, and political fault line you already have. The technology usually works; the schedule, staffing, and ownership decisions around it are what fail.

What are the 4 key ERP implementation strategies?

Big-bang (everything at once, fastest and riskiest), phased (by module or region, slower but contained), parallel (old and new run together, safest and most expensive), and hybrid combinations. Panorama’s overrun data argues for phasing anything large: 65% of projects already miss their schedules without betting the whole company on one weekend.

Sources

• Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives” (Denis Torii): the verified 2027 prediction quoted in the statistics section.
• Panorama Consulting ERP Report archives: budget, schedule, benefits, and staffing figures.
• World Journal of Advanced Engineering Technology and Sciences (2025), ERP migration study: data-quality delay, overrun, and investment figures.
• Günter Dusch, SAP Basics, Tips and Tricks for Prospective SAP Consultants (English 2nd edition, translated from the German): quoted on customization discipline.
• Case figures (Hershey, Target Canada, Lidl, Avon, Waste Management, MillerCoors, National Grid, PG&E, Revlon, Invacare, Mission Produce): public earnings disclosures, court filings, and sustained press coverage, as compiled in our hub analysis of why ERP implementations fail.

All seven challenges are beatable, and here is the uncomfortable symmetry: every company in the table above beat none of the ones that mattered on its project. The playbook is not secret. Realistic dates, profiled data, honest fit decisions, verified vendors, full-time ownership, numeric gates, and a budget that extends past go-live. The discipline is available to any buyer willing to own the project instead of renting ownership from the people selling it. If you are assembling your shortlist, browse the vendor directory by module and industry and start with delivery records instead of logos.

The Hershey ERP implementation failure of 1999 left more than $100 million of Kisses and Jolly Ranchers sitting in warehouses that were full while the orders went unshipped, dropped quarterly profits 19 percent, and knocked 8 percent off the stock in a single day. Everyone in enterprise software knows the moral: don’t rush an ERP project. Almost nobody knows the mechanism that actually broke, the governance hole that let a fictional schedule survive three years of planning, or the ending. Two years later the same company upgraded the same software in 11 months, ahead of schedule and about 20 percent under budget.

That second half changes the lesson. The software was never the problem. The calendar was, and nobody in the room was paid to say so.

This is the full autopsy: what Hershey built, what broke, what it cost by the quarter, and what the redo proves.

What Hershey Was Actually Building in 1996

In late 1996, Hershey’s management approved a project called Enterprise 21: replace the mainframe legacy systems before their two-digit date fields hit the year 2000, move to client/server architecture and TCP/IP, and give retailers the delivery data they had started demanding. The plan was budgeted around $110 million. Hershey’s own annual report, filed with the SEC in March 2000, shows where it landed: $98.8 million of capitalized software and hardware plus $13.2 million of expenses by the end of 1999, with total commitments expected at $115 to $120 million, a range that now included the cost of fixing what went wrong.

Enterprise resource planning (ERP) software runs a company’s core operations, finance, inventory, and orders, on one integrated system. Hershey bought three suites at once:

• SAP R/3, the flagship ERP product of the era, covering finance, purchasing, materials management, warehousing, order processing, and billing.
• Manugistics for supply chain planning: transport management, production, forecasting, and scheduling.
• Siebel for customer relationship management (CRM) plus a pricing promotions module.

IBM Global Services was hired to make the three talk to each other. Barcoding went in across plants and products. On paper, one integrated platform. In practice, three vendors, one integrator, and every interface between them a place for something to break. It was the kind of program that fails often enough that we built a whole pattern library of ERP failures around it, and Hershey is the case every later disaster gets compared to.

One number drives everything that follows: Halloween and Christmas accounted for roughly 40 percent of a confectioner’s annual sales. Hershey’s year is not evenly shaped. Its ERP risk wasn’t either.

The 30-Month Gamble Behind the Hershey ERP Implementation Failure

The recommended schedule for a program of this scope was about 48 months. Hershey compressed it to roughly 30, targeting an April 1999 cutover in the lean season, with the Y2K deadline as the immovable backstop. The compression itself is the most quoted fact of the Hershey ERP implementation failure. What gets quoted less is that the first phase worked.

In January 1999, on schedule, Hershey switched on purchasing, accounts payable, fixed assets, the general ledger, production reporting, and plant inventory tracking. The filing lists them plainly. Then the hard part slipped. SAP’s order processing and billing, Siebel’s pricing and promotions, and Manugistics’ planning and scheduling missed the April window and landed in July 1999, three months late, exactly when retailers start placing Halloween orders.

Hershey had a choice: phase the remaining modules in one at a time and test each, or switch everything on at once. Slipping past Y2K felt impossible. So it chose the big bang, the all-at-once go-live. Industry practice at the time held that a new ERP system needs three to six weeks after go-live just to find and fix what testing missed. An April cutover had that buffer built in. A July cutover spent it on Halloween.

Every row of that table was a decision someone approved. Keep that in mind for the governance section.

The Mechanism: Inventory SAP Could Not See

Here is the part most retellings skip, and it’s the most instructive detail in the whole case.

During peak season, Hershey stored finished product wherever it fit: rented spaces, temporary facilities, sometimes unused rooms inside its own factories. The old logistics system and the people who ran it knew where everything was. SAP R/3 did not, because those informal locations were never defined as storage points in the system’s master data. R/3 checked the official locations, found nothing to promise against, and the order failed. The warehouses were full. The system was blind.

Kenneth D. Miesemer, Hershey’s director of Eastern distribution, put it flatly at the time: “We’d had a real problem with inventory accuracy, and a lot of the time we didn’t have the right inventory to the right place according to our records.” The root cause wasn’t code. It was the gap between the technical team building the system and the operations people who knew how peak season actually worked, and a testing window too short for that gap to surface. Data problems like this are still the most common way go-lives die, which is why we wrote separately about why SAP data migrations blow up.

The consultant’s rulebook has said the same thing for decades. As Günter Dusch writes in SAP Basics, Tips and Tricks for Prospective SAP Consultants (translated from the German): “Most companies have a 3-system landscape: a development system, a quality management or test system and a production system.” Changes reach production only after a successful test phase. Hershey compressed exactly that discipline out of the plan.

The operational slide was fast. Hershey went live with about eight days of supplies as a buffer, more than usual. Within three weeks it was clear deadlines would be missed. Deliveries that normally took five days stretched into a twelve-day promise to distributors, which was also missed. By August 1999, Hershey was 15 days behind on orders. And with three vendors on one program, accountability dissolved on contact. Forrester Research’s Stephen Cole summarized the vendor dynamics in one line:

There were three cooks in that kitchen. That’s why there is so much finger-pointing going on.

AMR Research’s Jim Shepard added the epitaph for compressed test plans: things that work fine in testing “can turn out to be a disaster” once real orders hit. They did.

The Damage, by the Numbers

Hershey said nothing publicly until mid-September 1999, when it announced that its new systems were failing to process orders. The stock fell 8 percent that day. The damage kept compounding for two quarters.

The primary record matches the press coverage. Hershey’s FY1999 10-K states it in the dry language of a filing: “The reduction in shipments resulted primarily from difficulties in order fulfillment (customer service, warehousing, and shipping) encountered since the start-up of a new integrated information system and new business processes during the third quarter of 1999.” The same filing discloses a second-order mess almost nobody mentions: accounts receivable swelled with customer deductions and past-due balances because billing itself was producing errors. The system that couldn’t ship also couldn’t invoice cleanly.

Two footnotes to the damage. First, FY1999 net income looks almost normal in the annual numbers, but only because Hershey booked a $165 million after-tax gain selling its pasta business that January. Read the quarter, not the year. Second, the story made the front page of the Wall Street Journal, which is its own category of cost.

The market damage had a sharper edge than the financials. Candy is substitutable. A 7-Eleven category manager said that when Kit Kat ran out, they would simply expand the facings of Snickers. Ron Coppel of Eby-Brown, a distributor, was blunter: “If you don’t have my toothpaste, I’m walking out. But for a chocolate bar, I’ll pick another one.” Analyst William Leach captured where things stood by November: “They’ve missed Halloween, they’re probably going to miss Christmas, and they might even start missing Easter.” He was close. The problems ran to the end of the year.

The Governance Hole: Nobody Was Paid to Say No

Now the question the case files under “what went wrong” but should file under “who.” When Enterprise 21 started, Hershey had no chief information officer. IT reported through a vice president. The board had no member with information technology competence. A $110 million program that touched every order the company shipped was governed by an org chart with nobody senior enough to challenge the 30-month schedule, and no regular process kept top management informed of how implementation was actually going. The network was never load-profiled before go-live. After the disaster, the board recruited Allen Loren, then CIO of American Express, to fill the gap it had just discovered.

Dave Boulanger of AMR Research, who later worked on the fix, made the diagnosis: “A lack of technological savviness at the top, whether it was the CEO, or CIO, or somebody else, was to blame. If you don’t understand the complexity of it all, this is precisely the kind of thing you would do.” That experience gap at the top of ERP programs has not gone away; it has gotten more expensive, as we argue in our piece on the SAP talent crunch nobody is pricing in.

Here is what the vendors said, and why it matters. SAP’s US chief executive: “If it was a system issue, I’d point directly to a system issue.” SAP America’s consumer products general manager said there were no software issues per se. Siebel said its software wasn’t the problem either. The uncomfortable part is that they were right. And that is precisely the take a systems integrator will never put in a proposal: when a project fails on process, schedule, and governance rather than code, every vendor walks away clean, the integrator invoices through the recovery, and the buyer absorbs the whole loss. The only party with no exit is you. Your protection is not the logo on the software. It is the governance and the contract you set before anyone types a date into a project plan.

The Redo: Same Company, Same Software, Opposite Result

Page one of Google ends this story in 1999. The record doesn’t.

Hershey hired a CIO, George Davis from Computer Sciences Corporation, and put a real testing program in place. By Easter 2000 it was fulfilling orders. Halloween and Christmas 2000 passed without incident. Third-quarter 2000 revenue came in at $1.197 billion, up 12 percent over the disaster quarter, with profits up 23 percent, from $87.6 million to $107.4 million. Full-year 2000 sales reached $4.2 billion. The $65 million distribution center Hershey had leased mid-crisis became a 1.2 million square foot hub that helped cut order cycle times in half.

Then the real test: in July 2001, Hershey went back into the fire and upgraded to SAP R/3 4.6. Eleven months later it was done, ahead of schedule and about 20 percent under budget. The team ran dry runs down to loading dock detail, putting bar codes on empty pallets to rehearse distribution. Major improvements to invoice verification and credit processing showed up within 60 days of cutover. Joe Zakutney, who ran the upgrade, credited “strong program management and executive leadership, diligent planning and an extensive testing and training plan.”

Steve Sawyer of Penn State drew the sardonic conclusion: “most corporations don’t fail so dramatically the first time, so their repair is never so good.” And the relationship outlasted the disaster by decades. Hershey runs SAP to this day; its own business process manager has presented the company’s SAP financial supply chain deployment at industry sessions as a success story. The company that owns the most famous SAP failure in history is a reference customer. Sit with that before blaming software for a schedule.

What a 2026 Buyer Should Take From 1999

It would be comforting to treat Hershey as ancient history. The data says otherwise. Gartner’s current research predicts that by 2027, more than 70 percent of recently implemented ERP initiatives will fail to fully meet their original business goals. The technology has changed completely since 1999. The failure physics haven’t.

The modern go/no-go discipline reads like a point-by-point rebuke of Hershey’s July decision. Hold your own project against it:

• Never go live during peak season or month-end close. Pick the slow period and protect it.
• Treat the go-live date as an output of testing, not an input to it. If test cycles compress, the date moves.
• Cutover plans at step level, with owners and times. “Migrate data” is not a plan.
• Integrations tested end to end, and performance tested under real business load, not demo load.
• Train users two to three weeks before they touch the system, not months early.
• Choose big bang, phased, or hybrid as a priced risk decision, on the record, with the board seeing the price.

The pause-or-push arithmetic deserves its own line, because Hershey’s July choice is still made every quarter somewhere. National Grid faced it in 2012, went live to avoid an estimated $50 million delay, and spent $585 million on the recovery. The cost of a delay is visible and bounded. The cost of a broken go-live is neither. When someone on your steering committee says the company can’t afford to slip the date, the Hershey question is whether it can afford not to.

The gates tell you what to demand. They don’t tell you which implementation partner will accept them in writing, staff for them, and hold the date honest when testing says slip. That matching problem is what our engine does: describe your project and watch it rank vendors against it, free, no signup.

Frequently Asked Questions

Which company suffered a failed ERP implementation?

Hershey Foods is the canonical case: its 1999 SAP R/3 go-live left over $100 million in orders unshipped and cut quarterly profits 19 percent. It has plenty of company, including Nike, Lidl, Revlon, MillerCoors, and National Grid, each failing for recognizably similar process and governance reasons.

What is the Hershey controversy?

In enterprise software, “the Hershey controversy” means the 1999 ERP disaster: a 48-month program compressed into about 30, a big-bang July go-live into Halloween ordering season, and $100 million of candy the system couldn’t ship. The dispute was over blame: SAP said the software worked, and the record backs that up.

What ERP system does Hershey use?

SAP, continuously since the 1999 project. Hershey stabilized R/3 by 2000, upgraded to R/3 4.6 in 2002 ahead of schedule and about 20 percent under budget, and has since extended its SAP footprint, including financial supply chain management, which its own staff has presented publicly as a success.

Why do so many ERP implementations fail?

Gartner predicts more than 70 percent of recent ERP initiatives will fail to fully meet original business goals by 2027. The recurring causes are process, not code: compressed schedules, cut testing, bad go-live timing, weak executive governance, and unmanaged data. Our full breakdown of why ERP implementations fail maps each cause to a named disaster.

Sources

• Hershey Foods Corporation FY1999 Form 10-K (SEC EDGAR, filed March 13, 2000): order-fulfillment language, phase module lists, project cost accounting, receivables disclosure, distribution center lease.
• “ERP Implementation Failure at Hershey Foods Corporation,” ICFAI Center for Management Research case 908-001-1 (2008): the compiled press record, including quotes from Computerworld, ZDNet, CFO Magazine, Baseline, and BusinessWeek coverage from 1999 to 2002.
• Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives”: the by-2027 failure prediction.
• Günter Dusch, SAP Basics, Tips and Tricks for Prospective SAP Consultants (translated from the German): quoted in the section on the three-system testing discipline.
• “SAP FSCM Case Study: The Hershey Company,” HighRadius conference session: Hershey’s current SAP footprint.

The software Hershey bought in 1996 still runs the company. The go-live that nearly broke it took 30 months; the one that worked took 11. If you’re choosing the people who will hold your date honest, start by browsing the vendor directory by module and industry and make the schedule conversation the first one, not the last.

Ask why ERP implementations fail and the internet hands you a listicle: ten reasons, zero receipts, and a demo-request form at the bottom. The public record is more useful. Enterprise resource planning (ERP) software, the systems that run a company’s finance, supply chain, and payroll, has produced a documented trail of disasters going back to 1999: Hershey missing Halloween, Lidl scrapping seven years of work, Birmingham City Council still paying for its go-live a decade into the 2020s. Twenty-two of those failures are public enough to put in a table.

Read them together and something uncomfortable shows up. The software is almost never the killer. The same seven patterns repeat across a quarter century of wreckage, every one of them was visible from the boardroom, and every one of them was survivable.

What follows is the pattern file: the disaster ledger, the real numbers behind the failure-rate folklore, the seven patterns themselves, what a failure actually costs, and the warning signs a board can catch before the write-off. The pressing question was never whether ERP projects can fail. It’s whether yours will fail in one of the seven ways everyone else already paid to discover.

The Disaster Ledger: 22 Famous ERP Failures in One Table

Every page ranking for this topic keeps its case library in prose, scattered across paragraphs. Nobody tabulates it. So here is the ledger: 22 named ERP failures with the year, the system, the headline cost, and the primary pattern each one exhibits. The figures are as reported in press coverage, court filings, and earnings disclosures.

The rest of this post is what those rows have in common.

The ERP Failure Rate: What the Numbers Actually Say

The failure statistic on every vendor page is folklore. Three of the ten pages ranking for this exact search attribute a “55 to 75 percent” or “70 percent” failure rate to Gartner. None of them links a primary document. Nobody links one because no traceable primary document exists, and that is a checkable observation: the range circulates from blog to blog, each citing the last.

The honest answer to “what percent of ERP implementations fail” is that no single defensible number exists; the recycled 55 to 75 percent range has no traceable primary source, and the closest verified figure is Gartner’s prediction that by 2027, more than 70 percent of recently implemented ERP initiatives will fail to fully meet their original business goals.

Here is the provenance, claim by claim.

Two things make the true rate slippery. First, the definition swings the number: a project that ships late and over budget but eventually works is a failure by one definition and a rounding error by another. Panorama’s own surveys have separately found 23% of projects exceeding budgets in one year and 58% in another, roughly half of organizations needing unplanned additional technology, 40% underestimating staffing, and 40% discovering organizational issues mid-project. Second, the success side is real: the same reports find 97% of organizations reporting process improvements after a working implementation, 95% better customer experience, 91% cost reductions, and 90% productivity gains. A working ERP pays. That is exactly why treating failure as a coin flip you can’t influence is the laziest possible read of the data.

The disasters in the ledger were not unlucky draws from a 70 percent hat. They were specific, repeated, preventable mistakes. Which brings us to the patterns.

Why ERP Implementations Fail: The Seven Repeating Patterns

Page one splits into two camps on this question. One camp publishes reason lists with no evidence: NetSuite counts ten causes, Clearsulting nine, ClickLearn three, Velosio six. The other camp publishes case roundups with no synthesis: here are the disasters, draw your own conclusions. Neither connects the two.

Connect them and seven patterns fall out. The consensus framing, repeated by Lumenia and most practitioners, is that ERP failure is a business problem rather than a technology problem, and the ledger largely backs that up. But it needs a candor footnote: Lidl and Spar Group both prove that system-model fit is a real, project-killing question. The software wasn’t broken in either case. It just modeled the business wrong, and nobody tested the difference until after go-live. “The technology rarely fails” and “the technology choice can’t sink you” are different claims. Only the first is true.

The matrix below marks where each pattern shows up across ten of the marquee cases. The typical disaster exhibits two to four of the seven.

1. The Immovable Go-Live Date

Hershey’s integrator recommended 48 months. Hershey took 30, and the compressed schedule pushed go-live into Halloween ordering season, the worst possible week on its calendar. The result: $100M in orders it held in inventory but could not ship, a 19% profit decline, and the case study every ERP writer has cited since. National Grid went live under a different calendar gun, with Superstorm Sandy bearing down and a delay priced at roughly $50M. J&J Snack Foods went live mid-quarter during a busy period in 2022 and gave back roughly $20M in sales. Mission Produce cut over in November 2021 and, in CEO Steve Barnard’s own words on the earnings call, shipped fruit unfit for sale and had to buy from third parties to cover orders. That one cost $22.2M in gross profit.

The date always has a defensible reason. Fiscal year boundaries, license renewals, a board promise. The pattern is going live because the calendar says so, when the system’s readiness says otherwise. This is the everyday version of the “unrealistic timelines” entry on every consensus list, and it is the single most repeated line in the ledger.

2. Garbage Data at the Gate

Target Canada launched its 2013 expansion on an ERP filled by hand, at speed, by new hires. Roughly 70 percent of the manually entered supply-chain data contained errors. Orders went out wrong, shelves sat empty while warehouses overflowed, and the supply chain never recovered. Southeast Power Group spent four-plus years on a project scoped for less than one, unable to issue accurate invoices off corrupted data.

Nike belongs partly in this pattern too: its i2 engine generated demand forecasts bad enough to order the wrong shoes at scale, and a forecast is only as good as the history feeding it. Garbage in was not a metaphor. It was $100M of the wrong inventory.

Every listicle mentions data quality. What the cases add is the mechanism: bad data doesn’t degrade an ERP, it disables one, because every downstream module trusts the record upstream. Migration is where NetSuite’s “data hygiene” bullet and ECI’s “trap phase” warning stop being abstractions and start being unshippable orders.

3. The System Model vs. the Business Model

Lidl valued inventory at purchase price. SAP for Retail assumed retail price. That single modeling mismatch, plus the customization spiral that followed from refusing to change either side, consumed seven years and roughly €500M before Lidl scrapped the program in 2018. The irony is on the record: SAP had publicly named Lidl a top customer in 2017, one year before the collapse.

Haribo never mapped its legacy workflows onto the new system and watched Gold Bear sales drop about 25 percent when it couldn’t keep product on shelves. Spar Group, a case none of the ranking pages carries, lost the ability to analyze product margins after its SAP go-live. In low-margin retail, that is blindness at the exact altitude where the business lives or dies. LeasePlan wrote off €92M on a monolithic build that could not fit the digital business it was becoming. Avon spent four years and $125M on a pilot so hard to use that sales reps quit rather than adopt it, then aborted the rollout.

The consensus lists file this under “over-customization” and “business process re-engineering not in the plan.” The buyer-side translation: the fit question is testable before you sign, and none of these five tested it.

4. The Vendor Overpromise

Waste Management’s suit against SAP contains a number worth memorizing: a promised $220M in annual benefits from software pitched as an out-of-the-box fit. The suit started at $100M in 2008 and was amended to $500M before settling. Nike bet its supply chain on i2’s demand-planning engine and got $100M in lost sales, a 20 percent stock dip, and class-action suits for the trouble.

The pattern survives today in gentler forms. One vendor on page one of this very search advertises a “100 percent success rate” while noting most of its clients arrive after a failed implementation. Read that twice. A perfect record marketed to you across two decades of documented industry disasters is not evidence of safety. It is the overpromise pattern, live, in the wild. Expert witnesses who work ERP litigation describe the recurring theme in these cases as the implementation partner prioritizing its own speed over the client’s value and continuity. Flimsy requirements make the promise easy to make and impossible to check.

5. The Governance Vacuum

Birmingham City Council’s Oracle project ran from a £39M budget past £90M while problems went unreported upward, and the council, Europe’s largest local authority, was still untangling it years after go-live. The US Navy spent roughly $1B across four separate ERP pilots that could not talk to each other, then started an ~$800M replacement program. Worth & Co. churned through integrators for five years, paid $4.5M, and ended up suing Oracle.

The everyday form of this pattern, named in practitioner forums over and over, is delegation: handing the project to IT or to the vendor and checking back at go-live. Clearsulting calls it governance; NetSuite calls it leadership buy-in and too many decision-makers; Lumenia insists the sponsor hold real rank. All of those are the same observation. When nobody with organizational power owns the project, the project is unowned, and unowned projects report good news until they can’t.

6. Going Live With Known Defects

MillerCoors went live with 8 critical and 47 high-severity defects, open and documented. The result was a $100M lawsuit against HCL. PG&E left production data sitting in a demo database, exposed 47,000-plus asset records, and traced the root cause to a non-expert working a specialized testing role with no dedicated test environment. Revlon’s controls broke visibly enough that the company disclosed a material weakness in its financial reporting: an audit-grade admission that the system went live before it was ready.

Every consensus list includes “insufficient testing.” The cases sharpen it. The defect counts were known. Someone with the authority to say “not yet” looked at 8 critical defects and said “go.” The testing didn’t fail. The go/no-go decision did.

7. Treating Go-Live as the Finish Line

Clark County School District, the fifth-largest in the United States, launched a new HCM and payroll platform and started issuing wrong paychecks to educators. National Grid’s aftermath included payroll errors and 15,000 unpaid supplier invoices. Ranpak booked its $6.5M implementation, went live in January 2022, and watched $5M of profit disappear the following quarter as operations absorbed the new system.

The consensus definition is right and bears repeating plainly: success is defined by adoption, not go-live. Training, change management, and post-go-live support are where ClickLearn’s three reasons, Clearsulting’s “upskilling,” and ECI’s human-psychology framing all point. Cutover is the middle of the project. The organizations in the ledger that treated it as the end paid for the difference in the quarters that followed.

What an ERP Failure Actually Costs: Anatomy of the Bill

Page one asserts that failure costs “tens or hundreds of millions” and leaves it there. The ledger lets us do better: break the bill into categories, each with a named receipt.

National Grid is the only case public enough to decompose fully, and the decomposition is the lesson. Total program cost: close to $1B. Fees paid to Wipro: over $100M, with Ernst and Young also engaged on the implementation. Post-go-live burn: roughly $30M a month at the program’s end. The $585M recovery figure that press coverage repeats is not the whole bill. It is the largest line item on it.

Notice the shape: the recovery cost multiples of the project. That ratio holds across the ledger, which is why the sticker price of the implementation is the least interesting number in the business case. If you want the baseline for what a healthy project should run before any of this goes wrong, we published the real numbers in our breakdown of what an SAP implementation actually costs.

The Red Flags Visible From the Boardroom

Here is the part no ranking page writes, because most of them are written by people who sell implementations. Every disaster in the ledger emitted executive-visible signals before the write-off. Not technical signals. Board-meeting signals.

• The period-end close is stretching. National Grid’s monthly close went from 4 days to 43 after go-live. No dashboard access required; the CFO knows this number cold.
• Integrator fees keep accruing during a “pause.” Invacare paused its program in 2021 while fees continued. By August 2022 the board had ousted CEO Matt Monaghan, citing the stalled transformation. A pause that still bills is not a pause.
• Known defect counts at go-live. MillerCoors carried 8 critical and 47 high-severity defects across the line. If nobody will show the board the open-defect list before cutover, that is the answer.
• Auditor findings. Revlon’s material weakness disclosure was the failure surfacing through the controls process. By then the market reaction was already booked.
• Spend is outrunning delivered progress. The recurring theme expert witnesses report from ERP litigation: cost burn tracked against milestones actually delivered, and a partner moving at its own preferred speed rather than yours.

Then there is the pause-or-push decision itself, and the ledger’s clearest arithmetic. National Grid went live partly because a delay had been costed at roughly $50M. The broken go-live cost $585M to fix. The delay was priced. The failure wasn’t.

The last lever is the one buyers forget they hold: the contract. Wipro paid National Grid $75M. Waste Management amended its suit against SAP from $100M to $500M and settled. MillerCoors filed against HCL in the Northern District of Illinois in March 2017 over what the complaint framed as an incomplete blueprinting phase; HCL countersued that June, and the parties settled, a sequence documented in TechTarget’s reporting on the case. Litigation is nobody’s plan A. But the recourse exists, and the quality of your statement of work decides whether it exists for you.

Boards sit at different distances from these signals. A few get all of them monthly, because they asked for exactly these numbers at kickoff. More get a status deck with a traffic light somebody negotiated. And some find out from the auditors, which is the most expensive subscription of the three.

You are in charge of your project, not your system integrator.

That line belongs to Eric Kimberling, who works ERP failures as an expert witness, writing about National Grid. His companion advice: independent, third-party quality assurance on the program is the board’s insurance policy, and it would likely have prevented the National Grid disaster outright.

The Buyer’s Prevention Playbook

Prevention advice on page one is written for project managers. This list is written for the people who approve the budget, because every pattern in Section 3 was stoppable from the buyer’s chair.

1. Staff it honestly. Core team members give the project at least half their time, on paper, backfilled. Carry a 20 to 25 percent contingency on top of planned cost. Name the phases plainly: install the software, migrate the data, train the people. Weeks for a small firm. Months to years for a large one. Every compressed version of this sentence in the ledger ended in Section 4.
2. Test to numeric gates, not vibes. 90 percent-plus test-case completion before go-live. Critical-defect resolution tracked and trending to zero. Every external integration validated before testing closes. The full sequence: point testing, volume and load testing, and a complete mock go-live. MillerCoors’ 8 critical defects would not have survived this paragraph.
3. Respect the calendar. Never go live at peak season or over a month-end close. Train people within two to three weeks of first use, not months early. Budget a cutover window that assumes the data migration will not fit a weekend, because it rarely does. Hershey’s Halloween is 25 years old and still the controlling precedent.
4. Buy independent QA. A third party with no revenue stake in the go-date, reporting to you, not the integrator. This is the National Grid lesson priced against a $585M recovery: the insurance policy costs a rounding error.
5. Define success as adoption, not go-live. Fund change management before, during, and after cutover, and hold a post-go-live support budget you expect to spend. The ledger’s pattern-7 rows are what deleting this line item looks like.
6. Pick the partner on delivery evidence, not badges, and put protections in the contract. The pitch team is not the delivery team, references beat logos, and the statement of work is the only card you hold when a pattern starts. We wrote the full evaluation method, scorecard included, in our guide to choosing an SAP implementation partner honestly.

One more thing a systems integrator’s blog cannot print, so we will. Every disaster in the ledger had a professional integrator on the payroll, and the integrator got paid either way; National Grid’s recovery alone moved roughly $30M a month into consulting firms for two years. Failure is a revenue stream for the industry that implements. We don’t do implementations, which is why we can put that sentence in writing, and why step 6 deserves more diligence than your last one got. If you’re staring down that selection now, describe your project and watch the engine rank partners by delivery evidence, free, no signup.

Frequently Asked Questions

What are the common reasons for ERP implementation failure?

Seven patterns cover the documented disasters: immovable go-live dates, bad data at migration, system-model misfit with the business, vendor overpromising, absent governance, going live with known defects, and treating go-live as the finish line. People and governance failures, not broken software, drive nearly all of them.

What percent of ERP implementations fail?

No verified single rate exists. The widely cited 55 to 75 percent range has no traceable primary source. Gartner’s actual prediction: by 2027, more than 70 percent of recent ERP initiatives will fail to fully meet original business goals. Panorama’s published reports show 55 to 58 percent budget overruns.

What are the failures of ERP implementation?

An ERP failure is a project that derails, falls short of expectations, or gets abandoned: significant deviation on scope, budget, or timeline. Lidl scrapped seven years of work for roughly €500M, Avon aborted after $125M, and Revlon disclosed a material weakness after its go-live disrupted shipping.

What are the problems with ERP implementation?

The recurring problems are data quality at migration, compressed timelines that force peak-season go-lives, defect-laden cutovers approved anyway, under-resourced core teams, and adoption ignored after launch. Each one is visible early: defect counts, close times, and burn rate against progress all signal trouble before the write-off does.

Sources

• Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives” (analyst Denis Torii): the verified by-2027 prediction quoted in the failure-rate section.
• Panorama Consulting Group, ERP Report series (public report downloads, 2015 and later editions): budget, schedule, and benefits-realization statistics. Cited by name; report-year figures as published.
• TechTarget, “MillerCoors ERP lawsuit begins harshly, ends softly”: the litigation record for the MillerCoors v. HCL dispute.
• Company disclosures and contemporaneous press coverage for the named cases: Hershey, Nike, Lidl, Revlon, National Grid, Waste Management, Haribo, LeasePlan, the US Navy, Birmingham City Council, Avon, Target Canada, Mission Produce, Invacare, Ranpak, J&J Snack Foods, Southeast Power Group, PG&E, Worth & Co., Spar Group, and Clark County School District. Figures appear as publicly reported; several are approximations noted with a tilde.

The disasters keep repeating because the patterns live on the buyer’s side of the table, and the buyer’s side is exactly where nobody selling an implementation can afford to point. The software will keep getting better. The seven patterns don’t care. They are organizational, they are visible from the boardroom, and they are yours to catch, which is the most optimistic sentence in this post: everything in the ledger was preventable with information that existed at the time. We’ll take the famous cases apart one at a time in upcoming autopsies. Until then, if a project is in your future, start where the evidence lives: browse the vendor directory by module and industry and pick the team that has already shipped a project shaped like yours.