Gartner projects that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals. Panorama Consulting’s 2026 ERP Report found more than 25% of organizations exceeded budget. A 2026 analysis by Godlan (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, 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 | ~$100M in Halloween 1999 orders went unfulfilled after rushed SAP go-live |
| Handelsblatt on Lidl | Reported ~€500M written off after a seven-year SAP effort collapsed |
| Dolfing on Revlon | $64M in Q1 2018 orders could not be fulfilled after SAP migration |
| Revlon 10-K 2018 | $294.2M net loss for full-year 2018 disclosed in annual filing |
Primary sources referenced above:
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, PLCs, 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 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 treats OT as a first-class requirement from day one, not middleware bolted on later. When your integration layer 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 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 handles what comes in over radio, 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, 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. 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, TMS, TOS, or WMS 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. The short version: we take the first risk.
The 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. 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.
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:
- Can your operations team describe a workflow the ERP handles exactly as designed, without customization or workaround?
- 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:
- Are your SCADA and PLC feeds treated as first-class data, or ingested through a connector outside the main architecture?
- Has your integration project been “nearly complete” for more than six months?
On adoption:
- 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?
- What percentage of operational decisions are actually made inside the system versus alongside it, in radio calls, WhatsApp, and spreadsheets?
On pilot-to-production:
- Was your pilot run on a cleaned, curated dataset, or on a live, messy snapshot of production data?
- 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:
- 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?
- 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.
Stop letting operational events vanish into spreadsheets.
Roughly 60% of your ops data lives off-system. Opsima captures it in personalized software, in weeks.
See how it works →
