---
title: Why ERP Implementations Fail in Industrial Operations
author: Alon Gozlan
published: 2026-07-12
modified: 2026-08-07
url: https://opsima.com/blog/industry-insights/erp-implementation-failure-industrial-operations/
description: "Gartner: 70%+ of ERP projects miss their goals by 2027. Five failure patterns, three receipts, and a tailor-made ERP alternative."
---

# Why ERP Implementations Fail in Industrial Operations

> Gartner: 70%+ of ERP projects miss their goals by 2027. Five failure patterns, three receipts, and a tailor-made ERP alternative.

[Gartner projects that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals](https://www.gartner.com/en/information-technology/insights/what-it-leaders-must-do-to-avoid-disappointing-erp-initiatives). Panorama Consulting’s [2026 ERP Report](https://www.panorama-consulting.com/panorama-consulting-group-releases-latest-study-of-erp-implementation-outcomes-across-the-globe/) found more than 25% of organizations exceeded budget. A [2026 analysis by Godlan](https://godlan.com/erp-implementation-failure-statistics/) (an Infor partner, treat as directional) put manufacturing ERP failure at 73% with average overruns of 215%.

If you run a port, a yard, a mine, or any field-driven operation, those numbers feel low. The failure rate is not a project-management problem. It is structural. The same five things go wrong, in the same order, on every engagement I walk into after the fact.

**TL;DR**

- Gartner: 70%+ of recent ERP projects miss their original business goals by 2027.

- Panorama: 25%+ of ERP implementations blow past budget on additional technology needs.

- Godlan: 73% of discrete manufacturing ERP projects fail objectives with 215% cost overruns.

- Five failure patterns repeat across industrial engagements: template mismatch, OT integration debt, adoption cliff, pilot-to-production drop-off, sunk-cost lock-in.

- Hershey ($100M in unfulfilled orders), Lidl (€500M written off), and Revlon ($64M Q1 shortfall) show the pattern at scale.

- Roughly 60% of operational reality lives [off-system](/blog/operational-insights/operational-excellence/), in radio, WhatsApp, and shift notes the ERP never sees.

## Stats Snapshot for ERP Implementation Failure

Every number in the sections below is sourced. This table gathers the primary evidence in one place for quick reference.

| Source
| Key Finding
|

| Gartner
| 70%+ of recently implemented ERP initiatives miss original business goals by 2027
|

| Panorama Consulting 2026
| 25%+ of ERP projects exceed budget, driven by additional technology needs
|

| Godlan 2026
| 73% of manufacturing ERP projects fail objectives, 215% average cost overrun
|

| [CIO on Hershey](https://www.cio.com/article/270245/supply-chain-management-supply-chain-hershey-s-bittersweet-lesson.html)
| ~$100M in Halloween 1999 orders went unfulfilled after rushed SAP go-live
|

| [Handelsblatt on Lidl](https://www.handelsblatt.com/unternehmen/handel-konsumgueter/digitale-transformation-wie-sap-und-lidl-hunderte-millionen-euro-versenkt-haben/22850166.html)
| Reported ~€500M written off after a seven-year SAP effort collapsed
|

| [Dolfing on Revlon](https://www.henricodolfing.ch/en/case-study-6-how-revlon-got-sued-by-its-own-shareholders-because-of-a-failed-sap-implementation/)
| $64M in Q1 2018 orders could not be fulfilled after SAP migration
|

| [Revlon 10-K 2018](https://www.sec.gov/Archives/edgar/data/887921/000088792119000004/rev201810-k.htm)
| $294.2M net loss for full-year 2018 disclosed in annual filing
|

*Primary sources referenced above:*

[![Gartner insights page: what IT leaders must do to avoid disappointing ERP initiatives](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-1-gartner.png)](https://www.gartner.com/en/information-technology/insights/what-it-leaders-must-do-to-avoid-disappointing-erp-initiatives)
[![Panorama Consulting 2026 ERP Report release page](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-2-panorama-consulting-2026.png)](https://www.panorama-consulting.com/panorama-consulting-group-releases-latest-study-of-erp-implementation-outcomes-across-the-globe/)
[![Godlan 2026 ERP implementation failure statistics article](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-3-godlan-2026.png)](https://godlan.com/erp-implementation-failure-statistics/)
[![CIO article: Hershey supply chain bittersweet lesson from 1999 SAP failure](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-4-cio-on-hershey.png)](https://www.cio.com/article/270245/supply-chain-management-supply-chain-hershey-s-bittersweet-lesson.html)
[![Handelsblatt article on Lidl SAP implementation losses](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-5-handelsblatt-on-lidl.png)](https://www.handelsblatt.com/unternehmen/handel-konsumgueter/digitale-transformation-wie-sap-und-lidl-hunderte-millionen-euro-versenkt-haben/22850166.html)
[![Henrico Dolfing case study on Revlon 2018 SAP implementation failure](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-6-dolfing-on-revlon.png)](https://www.henricodolfing.ch/en/case-study-6-how-revlon-got-sued-by-its-own-shareholders-because-of-a-failed-sap-implementation/)
[![Revlon 2018 10-K annual filing on SEC EDGAR](https://opsima.com/blog/wp-content/uploads/2026/07/erp-failure-source-7-revlon-10-k-2018.png)](https://www.sec.gov/Archives/edgar/data/887921/000088792119000004/rev201810-k.htm)

## The Five Ways ERP Projects Fail Industrial Ops

Five patterns keep repeating. They show up in different combinations across operations and vendors. Every failed implementation I have reviewed maps to at least three of them. Each pattern gets its own section below.

### 1. Scope creep from generic templates

Every major ERP is built on process templates. There is a standard way to model a purchase order, and a standard work order. A standard inventory record. Those templates were designed for the broadest possible customer set.

They fit that customer set about as well as one-size apparel fits a real human body.

The implementation team maps the customer process to the template. Wherever it does not fit, they choose: customize the system, or change the process. Customization is expensive and creates permanent technical debt. Changing the process asks operators to work differently than they know how to work.

In practice both happen at once. Scope expands to cover the customization. Operators are told to adapt anyway. The build cost grows meaningfully before go-live. The result is neither a clean template nor a faithful reproduction of the workflow.

Tailor-made ERP software starts from your workflow, not from a vendor template. There is no translation layer between how the operation runs and how the system expects it to.

### 2. OT integration debt

Operational technology means [SCADA](/integrations/ignition-scada), PLCs, [MES](/integrations/deltav-mes), telematics, and sensor networks. It runs the physical operation. It does not speak ERP.

ERP systems were built for business data: transactions, records, approvals. OT generates real-time signals at a volume most ERP data models were never built to handle.

The typical fix is a connector. Middleware translates OT signals into ERP-friendly records, and connectors work in demos. In production they become their own multi-year maintenance project.

A connector built for one PLC firmware breaks when the PLC is updated. One tuned to 100 events per second does not survive 10,000. The six-month integration [backlog](/blog/industry-insights/legacy-system-modernization/) is still open two years later. The ops team runs a parallel process in spreadsheets because the connected system is only connected about 60% of the time.

I have seen this pattern on operations floors across ports and yards. The connectors are not bad software. They are the wrong architecture for the problem.

[Tailor-made industrial software](/software/) treats OT as a first-class requirement from day one, not middleware bolted on later. When your [integration layer](/integrations/) handles SCADA, PLC, and telematics as native data streams, there is no connector debt to accumulate.

### 3. Adoption cliff

The adoption cliff hits when the people who use the system daily decide they are more productive ignoring it than learning it. Terminal operators, shift supervisors, dispatchers, maintenance crews.

This is not irrational. It is a rational response to a system designed in a conference room by a project team that never ran a shift.

The cliff shows up within 90 days of go-live. The project team is gone. The ops team reverts to WhatsApp, radio, and spreadsheets for the decisions that matter. The ERP is used for the reports finance requires.

The system of record becomes a system of compliance.

Adoption is not a training problem. More training on a bad workflow is still more training on a bad workflow. Adoption is a design problem. The people who were going to use the system were not in the room when the workflow was designed.

Tailor-made ERP software is built by learning the field. Sitting with the people who run the shift. Mapping the actual exceptions and edge cases. Building workflows around what they already know how to do.

The result is a system that fits the job, so operators actually use it. The [live operations view](/liveoperations/) looks like the operation because it was built from the operation.

### 4. Pilot-to-production drop-off

ERP pilots succeed. Proof-of-concept runs on clean, curated data, and a small, coached user group. A narrow process set the implementation team knows how to handle.

The executive sponsor sees the demo. The project gets greenlit, and full deployment begins.

Production is a different animal. It has messy legacy data never fully cleaned before migration. It has edge cases the pilot never touched. A carrier with a non-standard BOL format. Equipment with a maintenance history in an unincluded system. A shift handover that runs over radio and WhatsApp because it always has.

The clean pilot environment and the live production environment are not the same place.

The drop-off is not a data problem in isolation. It is what happens when you pilot on a simplified version of reality, then deploy into the full version without adjusting the system.

Software built for your specific operation is validated against how the operation actually behaves, that includes the off-system data. The [status capture layer](/statuscapture/) handles what comes in over radio, [WhatsApp](/integrations/whatsapp), and email, not just what arrives through structured integrations. The production environment is the design environment.

### 5. Sunk-cost lock-in

Once an industrial organization has spent two to five million dollars on ERP licensing, consulting, and customization, walking away becomes politically impossible.

The CFO approved the number. The board saw the presentation. The operators who raised concerns early were overruled. By the time it is clear the system will not deliver, the organization is 18 months in.

Nobody wants to be the person who signs the memo calling the investment a write-off.

So the organization doubles down, and more customization. More consulting, and more change management. Total cost grows, and go-live slips. The system that eventually ships is a compromise nobody has the authority to replace.

I have watched operations teams run parallel systems for years, and ERP for compliance. WhatsApp and spreadsheets for anything that mattered.

Tailor-made ERP software inverts the risk model. You do not spend two million dollars before you know the system works. You see a real, working solution on your data, for a problem you choose, and you pay only if it earns its place. The first risk is on us.

## How ERP Failures Play Out at Scale

The next three cases are documented failures, and real numbers. Named organizations. Each maps to one or more of the patterns above.

**Hershey, 1999.** Hershey ran a simultaneous [SAP](/integrations/sap), Manugistics, and Siebel go-live in summer 1999. The plan was compressed by about six months to hit Halloween. The system went live as Halloween orders poured in. It could not fulfill roughly $100 million worth of Kisses and Jolly Ranchers on time. Hershey stock fell roughly 8% in one day. The cause was pilot-to-production drop-off at a $100 million scale.

**Lidl, 2018.** After roughly seven years and an estimated €500 million in spend, Lidl abandoned its SAP implementation. Per Handelsblatt reporting, the root problem was a data-model mismatch. SAP’s standard retail inventory model runs on retail prices. Lidl’s operation runs on purchase prices. Lidl refused to change its process, so SAP was customized instead. The customization ran for years without delivering value. Neither Lidl nor SAP has officially confirmed the reported figures. Scope creep from generic templates, at a €500 million scale.

**Revlon, 2018.** Revlon’s SAP migration at its Oxford, NC facility disrupted Q1 shipments. The company could not fulfill an estimated $64 million worth of orders in Q1 alone. The figure surfaced in investor class action filings drawn from earnings disclosures. Revlon reported a $294.2 million net loss for full-year 2018 in its annual 10-K. The $64 million figure is sometimes conflated on LinkedIn with the $3 billion debt load that preceded Revlon’s later bankruptcy. These are different events. The 2018 ERP failure was an OT integration and production readiness failure.

The through-line: none of these were technology problems. They were architecture and validation problems. Every organization deployed a system that worked in a controlled environment and broke under real operations.

## The Third Path

There are two obvious responses to the failure list above.

The first is to build in-house, and hire an engineering team. Specify requirements from scratch. Build software that fits the operation exactly, and it works occasionally. It also requires a multi-year engineering commitment, technical leadership most operators do not have, and ongoing investment to maintain what was built.

If your core job is running a port, a yard, or a mine, building software in-house is a distraction.

The second is to buy a better ERP or a more specialized vertical SaaS and manage the implementation more carefully. This is the same bet placed again with better project governance. The structural problems do not go away because the project manager is more experienced.

The third path is different in kind, not degree. An AI-native software factory: built for your specific goals, wired into your specific systems and data, validated against how your operation actually behaves. Kept running and improving across its lifecycle.

This is [the third path we have written about before](/blog/comparison/build-vs-buy-enterprise-software/). It addresses the failure patterns at their root, not their symptoms.

The Opsima model makes this concrete. We learn how the operation actually runs, edge cases included. We build software designed around that workflow. It integrates with the ERP, [EAM](/integrations/ibm-maximo), [TMS](/integrations/blue-yonder-tms), [TOS](/integrations/navis-n4), or [WMS](/integrations/manhattan-wm) you already run, rather than replacing it. We handle the data that never reaches your systems of record: the radio calls, the WhatsApp threads, the handwritten shift notes. That is roughly 60% of operational reality on most floors I have walked.

Two service modes: (1) overlay on top of your existing SAP, Maximo, Priority, JDE, or AS400 with zero rip-and-replace, or (2) build the replacement from scratch when the legacy system has been outgrown.

Then we go live, validate against real production behavior, and keep the system running and improving as the operation changes.

The commercial model reflects the risk inversion. You do not commit to a multi-million-dollar licensing deal before you have seen the system work. We build a real, working solution for a problem you choose, on your data, on your infrastructure. You see it run. You evaluate it against your operation, and then you decide.

The details are on the [pricing page](/pricing/). The short version: we take the first risk.

The [case studies](/case-studies/) show what this looks like in practice. One of them is PNCT.

## What It Looks Like When It Works

Port Newark Container Terminal handles roughly 1.65 million TEUs a year across a fleet of more than 100 [straddle carriers](/integrations/kalmar). The fleet runs 24 hours a day, seven days a week. Straddle carrier availability is the constraint. When a carrier is down, throughput drops. Every hour of unplanned downtime has a real cost.

The problem PNCT brought to Opsima was not exotic. Equipment data, maintenance history, and operational logs sat in systems that did not talk to each other. Technicians made maintenance calls on incomplete information. Breakdowns were reactive, not anticipated.

Opsima built a solution connected to the systems PNCT already ran. Telemetry, maintenance records, and operational data pulled into a live operations layer the maintenance team could actually use.

The result: [+5% straddle carrier fleet availability and roughly a 15% reduction in unplanned breakdowns](/case-studies/pnct/).

On a fleet of 100 carriers, 5% availability is roughly five additional units online every shift. Those five units do not require new equipment purchases. They do not require new capital expenditure. They do not require new staff. They are throughput capacity recovered from the existing fleet through better information.

The team at PNCT put it plainly: “You weren’t just another big software vendor. You came in with a concept already and a can-do attitude.”

That is the difference between a system built for a thousand customers and one built for you.

One scoped problem, and one shipped system. Weeks, not years.

## A 10-Question ERP Fit Diagnostic

Before committing to an ERP implementation, or before accepting that the current one is the best available option, answer these ten questions honestly. Each maps to one of the five failure patterns above.

**On template fit:**

1. Can your operations team describe a workflow the ERP handles exactly as designed, without customization or workaround?

1. When a process changes in the field, how long does it take to reflect that change in the system? Hours, weeks, or months?

**On OT integration:**

1. Are your SCADA and PLC feeds treated as first-class data, or ingested through a connector outside the main architecture?

1. Has your integration project been “nearly complete” for more than six months?

**On adoption:**

1. Did the people who run your shifts have meaningful input into the workflow design? Or were they pulled in for UAT after the design was locked?

1. What percentage of operational decisions are actually made inside the system versus alongside it, in radio calls, WhatsApp, and spreadsheets?

**On pilot-to-production:**

1. Was your pilot run on a cleaned, curated dataset, or on a live, messy snapshot of production data?

1. Does the system handle exception cases as well as the standard case? The non-standard carrier, the patchy maintenance history, the radio handover?

**On commercial risk:**

1. Did you see a working solution on your data before committing to the spend? Or did you commit on a vendor demo running vendor data?

1. Does the pricing depend on whether the system works for your operation, or does the vendor get paid regardless?

If you answered no to three or more, you are not describing an ERP fit. You are describing a software-fit problem that a tailor-made ERP approach can address.

## The Bottom Line

ERP implementations fail in industrial operations for structural reasons, and those reasons repeat.

Generic templates force operations to bend, and OT integration debt accumulates. Adoption collapses when the people running the operation were not in the room when the workflow was designed. Pilots succeed on clean data and fail on production reality. Sunk costs make it politically impossible to change course.

The alternative is software built around your operation. Your workflow, your systems, your data. Kept running and improved over its lifecycle, not handed off and forgotten.

Tailor-made ERP software, built for your workflow, paid only after you see the value. That is what ERP was supposed to be.

Tell us the process you have given up on fixing. We build a real, working solution on your data, for a problem you choose. You pay only if it earns its place. To de-risk the next implementation with tailor-made ERP software built around your operation, [book a working session with Opsima](/bookdemo/).

## Frequently Asked Questions

### What percentage of ERP implementations fail?

[Gartner projects that by 2027, more than 70% of recently implemented ERP initiatives](https://www.gartner.com/en/information-technology/insights/what-it-leaders-must-do-to-avoid-disappointing-erp-initiatives) will fail to fully meet their original business goals. In discrete manufacturing, [Godlan reports the failure rate closer to 73%, with average cost overruns of 215%](https://godlan.com/erp-implementation-failure-statistics/). Industrial operations tend to sit at the worse end of that range.

### Why do ERP implementations fail in industrial operations?

Five structural patterns repeat: generic templates force operations to bend, OT integration debt accumulates through fragile connectors, adoption collapses when operators are not in the workflow design, pilots succeed on clean data and fail on production reality, and sunk-cost lock-in prevents course correction. Each pattern shows up before technology issues do.

### What is OT integration debt?

OT integration debt is the growing maintenance burden of middleware connectors that translate SCADA, PLC, MES, telematics, and sensor data into ERP records. Each firmware change or throughput increase breaks the connector. Six-month integration projects stay open for years, and the ops team runs parallel spreadsheets because the connected system is only connected part of the time.

### How much does an ERP implementation actually cost?

[Panorama Consulting found more than 25% of ERP projects exceed budget in 2026](https://www.panorama-consulting.com/panorama-consulting-group-releases-latest-study-of-erp-implementation-outcomes-across-the-globe/), with additional technology needs cited as the leading cause. [Godlan’s discrete manufacturing analysis put average cost overruns at 215%](https://godlan.com/erp-implementation-failure-statistics/). A single industrial ERP program typically consumes two to five million dollars in licensing, consulting, and customization before go-live.

### What are the biggest ERP failures ever documented?

Three cases stand out. Hershey’s 1999 SAP go-live left roughly $100 million in Halloween orders unfulfilled. Lidl abandoned its SAP implementation in 2018 after an estimated €500 million in spend. Revlon’s 2018 SAP migration disrupted Q1 shipments to the tune of an estimated $64 million in unfulfilled orders. All three were validation and architecture failures, not software failures.

### What is personalized software and how is it different from ERP?

Personalized software is built for one operation’s specific goals, wired into that operation’s existing systems and data. It is validated against real production behavior rather than a curated pilot dataset. ERP asks the operation to bend to a generic template. Personalized software starts from the workflow and builds around it, then keeps improving across its lifecycle.

### How does Opsima reduce ERP implementation risk?

Opsima learns how the operation actually runs, builds software around that workflow, integrates with the ERP, EAM, TMS, TOS, or WMS already in place, and validates against production data before go-live. The commercial model inverts the risk: no multi-million-dollar license commitment before the system is proven on your data. You pay only when the software earns its place.

### How long does a personalized software implementation take?

A scoped operational problem typically ships in weeks, not the multi-year timeline a comparable ERP customization would run. The reason is architectural: the system is built around the workflow from day one rather than mapped onto a generic template. PNCT’s fleet availability solution is one example of that timeline in production.

