What makes ERP different from every other system decision
Most software failures are contained failures: a CRM that flops leaves the sales team on spreadsheets, annoyed but operational. An ERP failure stops invoices, deliveries, payroll and the month-end close simultaneously, because the ERP is where the business's transactions actually live. That asymmetry should drive the whole decision: the question is not which platform has the best capabilities, but which combination of platform, integrator, phasing and internal capability minimises the probability of the business being unable to ship product in the week after go-live. Organisations that frame the decision as a software selection consistently under-invest in the parts that determine survival.
The four failure modes to design against
- Data migration: years of inconsistent material masters, duplicate customer records and undocumented pricing conditions have to be cleansed and mapped, and every legacy field that will not map is a business rule someone must own. Migration is a business programme wearing a technical costume.
- Customisation creep: each department defends its exceptions, each exception becomes a modification, and eighteen months in you have rebuilt the legacy system inside the new one, at implementation rates, with an upgrade path destroyed and every future vendor release a mini-project.
- Parallel running: the old and new systems must both be fed during cutover phases, which doubles workload on exactly the finance and operations people who are also the programme's subject-matter experts. Attrition in that group during the programme is a leading indicator of go-live failure.
- Integrator dependency: the systems integrator writes the design it will then bill to build, its A-team rotates off after the blueprint phase, and by year two the organisation cannot change a workflow without a change order. Knowledge transfer to internal staff is in every proposal and delivered by almost none, unless it is contractually gated.
Questions to settle before selecting anything
Decide the standardisation question first, at executive level, before the integrator arrives to arbitrate it at a day rate: where will the business adopt the system's standard process, and which local exceptions are genuinely worth the permanent cost of a modification? Decide the phasing philosophy: a big-bang cutover risks everything at once but ends the pain sooner, while phased go-lives by site or module reduce the blast radius but stretch parallel running and integration complexity across years. Decide what happens to the business change agenda during the programme, because an organisation that tries to restructure, acquire and re-platform simultaneously is choosing its failure mode. And decide who owns the programme internally: an ERP change run by IT delivers a system; only one run by the business delivers an operation.
Where the business case breaks
Three lines deserve forensic attention before approval. The legacy retirement line: the case assumes the old systems switch off, but interfaces, regulatory archives and one stubborn subsidiary keep fragments alive for years, and each fragment carries licence, support and integration cost the case booked as savings. The internal backfill line: the finance and supply-chain experts seconded to the programme leave holes that get filled with contractors, a cost that typically appears nowhere. And the steady-state line: the new platform needs a permanent internal team (configuration, integration, release management) that is larger than the legacy support team the case retired. If those three lines survive scrutiny, the case is unusually honest. If they are absent, the real number has not been presented yet.
The perspective that changes ERP decisions
Executives who have taken a business through an ERP replacement carry scar tissue that reads programme plans differently. They check whether the data cleansing started before the contract was signed, because starting after means the timeline was fiction from day one. They check the integrator contract for who bears the cost of rework when the design proves wrong. They ask which executive is personally accountable for go-live readiness: not programme delivery, but the operational judgement that the business can actually run on the new system. Independent challenge before commitment most often changes the scope and the sequencing rather than the platform: smaller first phase, data programme brought forward, standardisation decisions escalated. Internal teams rarely make those changes unprompted, because every one of them makes the programme look slower at approval.
