An ERP is a mirror, not a remedy
An ERP program is sold as transformation. It isn't. An ERP faithfully encodes whatever operating model you configure it against — the same intake, the same handoffs, the same undocumented workarounds — now set in software and far harder to change. If the model is ungoverned going in, the platform industrializes exactly that.
This is why "the implementation went live" and "the business got better" are two different events that often never meet. The software can work exactly as specified while the value in the business case never arrives — because the model underneath it was never read, never standardized, never made governable.
The failure pattern is remarkably consistent
ERP failure is not random or technical. Read across the record and the same root appears: the platform was configured against a model no one had governed.
of discrete-manufacturing ERP implementations fail to meet their objectives, with cost overruns averaging 189% across industries.
shareholder returns go to companies that hold their ERP investment to its original business case — deviating from it is among the most common roadblocks to value.
Deloitte's read is blunt: 69% of leaders hold negative-to-neutral sentiment on ERP investment — not because the software fails, but because value was never held to the case. The recurring synthesis across the record: ERP projects don't fail for technical reasons. The software works. The failures are strategic — decided in "Phase Zero," before a single module is configured.
The gap is not evenly spread: value leaks worst at Adopt & Realize, where a case written against an unread model was never tracked to the P&L — the pattern behind the drift chart above.
Don't digitize a broken model — standardize it first
The instinct is to let the ERP "drive the transformation" — to treat configuration as the moment the operating model gets fixed. It never works that way. Configuration encodes whatever model you hand it. The sequence is the whole game: read and standardize the model, then configure the platform to it — not the reverse.
- Requirements copy how work runs today
- Workarounds become custom objects
- Blueprint drifts as the gaps surface
- Go-live disrupts order-to-cash and finance
- Dysfunction is now faster and costlier to unwind
- Requirements come from the actual state
- The model is standardized before blueprint
- Config encodes a model that works
- Go-live starts value realization, cleanly
- The platform amplifies a governed model
Deloitte's own counsel echoes this: the firms that get ERP value right go slow at the outset to go fast — they spend longer on the model and the data before they configure. Standardization is the prerequisite for a clean ERP — and, past that, for any automation or agentic AI that will act on the platform without a human in every loop.
GSDPI, applied to an ERP program
The same five stages that read the operating model also sequence the program correctly — putting the model-work where it belongs: before configuration, not after go-live.
-
G
Get Requirements
Read the actual state, not the wish-list. Requirements come from how work truly runs — not a copy of today's mess, and not a vendor's reference template. This is Phase Zero, and it decides everything downstream.
-
S
Sort Design & blueprint
Standardize and govern the target operating model before the blueprint is drawn. Decide how work should run, then configure to that — rather than letting the blueprint quietly ratify the current state.
-
D
Do Build & configure
Configure to the governed model and resist customization that re-encodes workarounds — only 7% of firms run ERP as-is, and excess customization is where cost and upgrade-risk spiral. Every custom object should trace to a governed requirement.
-
P
Prove Go-live & realize
Hold delivered value to the original business case. Go-live is the start of value realization, not the end of the project — the moment tracking begins, not the moment the team disbands.
-
I
Improve Optimize
Govern continuous improvement so the ERP stays a living model, not a frozen one. Each release traces to the business case — the platform compounds value instead of ossifying the day-one config.
New Insights, the day they publish.
The operating-model reads behind ERP, AI & services — a short note when one’s worth your time.
New posts & Insights only. Unsubscribe anytime.
Where ERP value leaks — point by point
The failure a board experiences as "the ERP didn't deliver" resolves, on inspection, into specific breaks — almost all of them upstream of go-live. The six that carry the most weight:
Requirements copy the current messGet
Requirements are gathered by asking "what do you do today," which encodes every existing dysfunction into the specification. The ERP is then dutifully built to reproduce the mess — faster, and now in software no one can easily change.
The blueprint skips the actual stateSort
Design runs against an idealized process map or a vendor template — not how work truly moves. The gap between the blueprint and reality stays hidden until go-live, when it surfaces all at once as exceptions, escalations, and manual workarounds.
Customization hardwires the workaroundsDo
Every undocumented workaround becomes a custom object. Only 7% of firms run ERP as-is; excess customization is precisely where cost spirals and upgrades break. The model's dysfunction is now baked into code that must be maintained forever.
Go-live becomes operational disruptionDo
51% of companies hit significant operational disruption at go-live — order-to-cash stalls, finance can't close, the warehouse can't ship. The disruption isn't a software bug; it's the model's hidden gaps meeting reality for the first time.
The business case is quietly abandonedProve
Benefits are defined to win funding, then never tracked once the program starts. Deloitte names this as the roadblock: value accrues only to firms that hold the ERP to its original case. Most don't — and the promised return simply never gets measured.
Go-live is treated as the finish lineImprove
Go-live is meant to be the start of value realization; instead the team disbands and the config freezes. Without a governed optimization loop, the ERP ossifies at its day-one state and the last mile of value is never captured.
How ETEGY reads it
Every failure above traces to one root: the ERP was configured against a model no one had read or governed. We do Phase Zero properly — read the actual state, standardize the model, then let the platform encode a model that works.
A Zero-Based read of the operating model across the GSDPI lifecycle — before a single module is configured — so the ERP hardwires a governed model, not the mess. Then the Traceability Ratio holds delivered value to the original business case. Read first; digitize second. See the ZBT Discovery →
The ERP Readiness Checklist
Ten things that must be true about your operating model before you configure — tickable, grouped by GSDPI stage, with a Phase Zero verdict. Built to circulate: take it into your steering committee.