Pourquoi les projets ERP durent 18 mois

The contract was signed in January. The vendor's project plan showed a June go-live. It is now October, you are in your third round of user acceptance testing, the go-live has been pushed to Q1, and the consulting firm has just submitted a change request for an additional £180,000 of "scope clarification" work.

You are not behind because your team is incompetent. You are not behind because you chose the wrong software. You are behind because the ERP implementation model is designed, structurally, to take longer than it promises.

This is not an accident. It is how the business model works.

The Common Belief

Most companies believe that ERP projects take longer than planned because of poor project management, inadequate requirements gathering, or choosing a system that doesn't fit the business. Fix those things and the timeline holds.

This belief drives the selection process. Every ERP evaluation includes a detailed assessment of the vendor's implementation methodology. References are checked. Programme managers are assessed. The project plan is scrutinised. Everyone enters the project convinced that theirs will be different.

It rarely is.

Why That Belief Is Wrong

The assumption that ERP delays are caused by execution failures is wrong because it misidentifies the source of the problem. The delays are not caused by poor execution of a good model. They are caused by faithful execution of a model that contains inherent delays.

The ERP implementation model was designed in an era when software had to be customised to fit every business. The assumption baked into every methodology — from SAP to Sage to Oracle — is that the software is a platform and your job is to shape it to your organisation. That shaping requires a translation layer: consultants who understand both the software's logic and your business logic, and can map one onto the other.

That translation layer is where the time goes.

Not because the consultants are slow. Because translation between two complex systems — your business and the ERP's data model — produces ambiguity at every step, and ambiguity in software implementation means rework.

What Actually Happens

ERP implementations follow a consistent failure pattern regardless of vendor, sector, or business size.

The discovery problem. The initial requirements gathering captures what the business thinks it needs based on how it currently works. But requirements for a system you have never seen operating are necessarily incomplete. You do not know what questions to ask about invoice approval workflows until you see what the system does with invoice approval workflows. Requirements emerge through the implementation, not before it. Every ERP methodology calls this scope creep. Operators call it normal.

The configuration gap. The ERP ships as a general-purpose platform. Every field mapping, approval rule, workflow trigger, and finance logic is a configuration decision. Those decisions accumulate — in practice, a mid-market ERP implementation involves thousands of individual configuration decisions. Each one is a specification. Each specification requires a decision. Each decision requires someone from the business who understands the context and someone from the consultancy who understands the system. When those people are not in the same room, decisions queue up.

The dependency chain. Enterprise systems are not modular in the way their architecture diagrams suggest. Finance depends on inventory. Inventory depends on procurement. Procurement depends on your approval hierarchy. Your approval hierarchy depends on your org structure. Your org structure depends on HR. Change one thing and something breaks two domains away. The implementation methodology tries to sequence configuration decisions to avoid contradictions. But the sequence is theirs — not yours. When your business logic doesn't fit their sequence, everything slows.

The incentive problem. ERP consultants are paid by time. A six-month project that becomes an eighteen-month project is, from the consulting firm's P&L, a success. Three times the revenue. The client's frustration is a sales cost, not a delivery cost. This is not a conspiracy — it is the arithmetic of time-billed professional services. When your implementation partner earns more from delay than from speed, velocity reflects that.

Real-World Example

Company: Meridian Facilities Group
Industry: Facilities management and maintenance services
Size: 180 staff, £22M turnover
Problem: ERP implementation ran 14 months over the agreed timeline

What happened:

Meridian engaged a mid-market ERP vendor on a nine-month implementation plan at a fixed price of £420,000. The project covered finance, procurement, field service scheduling, and inventory.

By month four, the field service scheduling module had revealed a requirement the initial discovery had not captured: Meridian's subcontractors needed different approval workflows depending on whether the job was reactive or planned maintenance. The ERP's workflow engine could not distinguish between them without a custom configuration that the fixed-price contract did not include.

The consultant raised a change request. Meridian's project manager contested the scope. Three weeks were lost to negotiation. The resolution required a workaround that partially broke the inventory module's integration with scheduling. A second change request followed.

By month nine, finance was live but field service was not. The original go-live date was missed. The board had already communicated the new system to their largest client as part of a service improvement initiative. Explaining the delay cost the account director a renewal conversation.

Final timeline: twenty-three months. Total cost: £780,000 against an original commitment of £420,000. Field service scheduling was never fully implemented — it runs on a parallel spreadsheet system to this day.

Outcome: The system is used. It is not trusted. Manual reconciliations between the ERP and the spreadsheet system take the finance team two days per month. The original business case showed an eighteen-month ROI. Year three has just begun.

The Cost of Ignoring It

Every month an ERP project runs over its planned timeline carries a direct and compounding cost.

Revenue impact: Go-live delays typically mean the old system runs in parallel with the new one, or the business operates on manual processes during transition. Both create operational drag. Sales opportunities require manual reporting. Invoicing slows. Collection cycles lengthen.

Direct cost overrun: The average ERP implementation runs 40–60% over budget. On a £500,000 project, that is £200,000–£300,000 in additional consulting fees, internal resource time, and management overhead.

Organisational fatigue: Long implementations exhaust the people running them. The project team is typically drawn from the best operational minds in the business — the finance director, the head of operations, the IT lead. They are unavailable for growth work for the duration of the project. On an eighteen-month implementation, that is a significant opportunity cost.

The opportunity cost of delay: Every month the new system is not live, the efficiency gains in the business case are not being realised. An ROI that was promised at twelve months stretches to three or four years. By the time the system is stable, the business has often evolved past some of the original requirements.

The sunk cost trap: Once significant money has been spent on an implementation, the business becomes reluctant to challenge decisions that are visibly failing. "We've come this far" drives investment in implementations that would be better stopped than continued. The cost of completion feels lower than the cost of walking away, even when walking away is the better outcome.

What Good Looks Like

The businesses that avoid the eighteen-month problem share a structural characteristic: their systems derive from their business logic, rather than their business logic being reshaped to fit their systems.

This sounds obvious. It is rarely how ERP procurement actually works.

In practice, it means:

Front-loading the business model, not the requirements document. Before selecting a system, document how your business actually works — not as a requirements list, but as a model. How does work flow? Who approves what? How does revenue recognise? Where are the exception cases? A business that knows its own operating model can evaluate software against it, rather than discovering misalignment mid-implementation.

Separating configuration from customisation. Configuration — adjusting standard system behaviour through settings — is manageable. Customisation — writing code to make the system do something it was not designed to do — is where implementations spiral. Good implementations have a clear rule: if it requires custom code, the requirement is challenged before the code is written. The operational complexity that drives customisation requests is almost always a consequence of the business having undocumented processes that the system cannot accommodate in standard form.

Staging risk. Not everything needs to go live at once. A phased implementation that delivers finance on month three, procurement on month five, and operations on month eight carries less organisational risk than a big-bang go-live on month nine that slips to month eighteen.

Fixing incentives. Time-billed consulting creates misaligned incentives. Outcome-based commercial models — fixed price with penalty clauses for delay, or vendor-funded implementation with revenue share — align the implementation partner's success to yours. This is part of the broader pattern of why most ERP projects deliver less than promised — the incentive structure of the implementation model and the incentive structure of the business case are pulling in opposite directions from day one.

ENTMAZ Perspective

The eighteen-month problem is a consequence of a specific architectural assumption: that enterprise systems are platforms to be configured onto businesses, rather than systems generated from business descriptions.

When a business describes how it operates — its people, its processes, its approval logic, its financial rules — and a system is compiled from that description, there is no configuration gap. The translation layer that consumes the time in traditional implementations does not exist. The system is not being shaped to fit the business. It was generated from it.

The go-live is not the end of an eighteen-month project. It is the output of a structured description session.

This changes the economics of implementation entirely. Not because it removes complexity, but because it moves complexity to where it belongs — into the business model compilation, not into an ongoing project managed by external consultants.

Conclusion

ERP projects take eighteen months because the implementation model requires it. The delays are not failures of execution — they are the predictable output of an architecture that requires human translation between a general-purpose platform and a specific business.

The vendor's six-month timeline is not a lie. It is a description of how long the project would take if every requirement were known upfront, every configuration decision were straightforward, and every dependency resolved cleanly. None of those conditions exist in practice.

The question to ask before starting an ERP project is not "how do we execute this faster?" It is: "why does this require an implementation project at all?"

Key Takeaways

• ERP implementation delays are structural, not accidental — they are produced by a model that requires human translation between platform and business
• Requirements emerge through implementation, not before it; every ERP methodology calls this scope creep, operators call it normal
• Time-billed consulting creates incentives that are mathematically misaligned with fast delivery
• The average ERP implementation runs 40–60% over budget; the sunk cost trap then prevents businesses from challenging failing implementations
• The alternative is not faster project management — it is a different architecture where the system derives from the business, not the other way around