How ERP Implementations Fail Before Go-Live

An ERP programme changes how an organisation records orders, inventory, production, payments and financial truth. Software configuration is only one part of that change. Failure develops when nobody owns a cross-functional decision, legacy exceptions are reproduced without challenge, migration is treated as a final import and testing proves screens rather than complete operations. Reports can remain green because configuration tasks are closing while the difficult questions accumulate elsewhere. By go-live, those questions appear as blocked shipments, unreconciled balances and manual workarounds. The useful management task is to identify leading indicators while there is still time to change scope, decisions or sequencing.

No owner for the end-to-end process

Departmental representatives naturally optimise their own stage. Sales wants flexible order entry, operations wants stable planning, finance wants posting control and procurement wants supplier continuity. An end-to-end process owner must decide how those needs fit from trigger to ledger, including exception paths. If workshops repeatedly end with “the business will confirm”, the project has a decision system problem, not a scheduling problem. Maintain a decision log with owner, deadline, affected controls and downstream dependencies. Escalate ageing decisions according to consequence. A configured field should never be mistaken for an agreed policy; configuration should trace to a named process decision and an acceptance scenario.

Scope expands through exception preservation

Teams often describe every legacy variation as mandatory because somebody uses it today. Some encode genuine regulatory or commercial needs; others compensate for old system limits or inconsistent master data. Copying all of them produces customisation, branching workflows and a testing surface that the programme cannot sustain. Ask what outcome each exception protects, how often it occurs, who authorises it and what happens if the standard process is used. Record deviations from the target design with lifetime ownership and upgrade implications. Scope also expands invisibly through reports, interfaces, roles and data conversions, so these need the same estimation and change control as visible modules.

• Workshops close without decisions, owners or dated follow-up.
• Prototype approval is based on screens rather than end-to-end scenarios.
• Custom reports and interfaces grow while core process scope appears unchanged.
• Migration totals are unavailable or cannot reconcile to controlled sources.
• Testing dates stay fixed even as design and data arrive late.

Data exposes unresolved design

Duplicate suppliers, ambiguous units of measure and inactive products are not simply dirty records. They reveal missing ownership and rules that the new system will need every day. Mapping legacy values forces decisions about chart of accounts, warehouses, tax treatment, customer hierarchy and open transaction state. If migration work is postponed until configuration is “finished”, those decisions arrive after the design that depends on them. Profile data early, define target rules, assign business data owners and run repeated conversions. Every rehearsal should produce control totals, exception reports and reconciliation sign-off. A successful load is one whose meaning and balances are correct, not one whose rows entered the database.

Integration progress can be misleading

An interface marked complete may only demonstrate a happy-path message. Production readiness includes identity mapping, idempotency, ordering, retry behaviour, dead-letter handling, reconciliation and operational ownership. Batch cut-offs and time zones can create financial differences even when payloads are correct. Contracts should define which system owns each field and how corrections propagate. Test duplicates, late arrivals, partial failures and upstream changes, then show how support staff detect and recover them. If the project cannot state where an order or journal is during failure, the integration is not complete. Interface counts are weak progress measures; proven business scenarios and reconciled outcomes are stronger.

Testing must follow transactions to the ledger

Scripted tests that click through one module can miss the consequence of a transaction elsewhere. Scenario testing should begin with realistic business events and finish with inventory, cash, tax and general-ledger effects. Include credit holds, returns, short receipts, price differences, rejected payments, backdated changes and period close. Use migrated master and opening data rather than pristine fixtures whenever practical. Defects should be classified by process, configuration, data, integration or training so patterns become visible. User acceptance is not a ceremonial signature; business owners need evidence that critical scenarios work, controls operate and known limitations have explicit treatment.

Go-live readiness is evidence, not confidence

Readiness criteria should be agreed before schedule pressure peaks. They include reconciled migration rehearsals, completed critical scenarios, role and segregation review, cutover timings, support rosters, monitoring, rollback or containment options and accepted residual defects. Training must use the configured process and realistic roles, not generic product tours. Cutover needs a minute-by-minute dependency plan, clear authority to stop and criteria for resuming business. A go-live decision should show what has been proven and what risk is being accepted. Optimism, effort already spent and an immovable date are not evidence, although they frequently influence the room unless the governance design resists them.

Operational readiness extends past launch

The first days of use concentrate unfamiliar work, opening data and interface timing in one place. A support model should distinguish user guidance, master-data correction, configuration defects, integration failures and genuine software faults, because each needs a different owner and response. Give support staff trace identifiers, reconciliation views and safe runbooks rather than direct database access. Triage rules should prioritise blocked financial or fulfilment processes over cosmetic issues, and changes during stabilisation need normal approval and regression checks. Otherwise rapid fixes create a second, undocumented configuration before the first period close. Plan the first operational cycles explicitly: daily settlements, inventory planning, payroll where relevant, tax reporting and month end. Some defects appear only when volumes accumulate or a period boundary is crossed. Define enhanced monitoring and reconciliation for these cycles, with an exit criterion for returning to normal support. Retain legacy access according to an approved read-only and retention plan, rather than leaving an uncontrolled fallback that users continue to update. Successful launch is not the absence of tickets. It is the ability to process, reconcile and close the business while issues are identified through controlled channels and resolved without damaging the integrity of the new system.

Stabilisation after launch also needs design. Classify support demand as guidance, master data, configuration, integration or software failure, and route each class to an accountable owner. Provide trace identifiers, reconciliation views and safe runbooks rather than direct database access. Plan the first daily, weekly and period-end cycles because accumulated volume and cut-offs reveal defects that a launch-day check cannot. Emergency changes still require approval and regression evidence. Define when enhanced support ends using reconciled operations and resolved critical issues, not a falling ticket count. Without these controls, rapid fixes can create an undocumented second configuration before finance completes its first close.

Act on the signals while choices remain

Review the programme through a small set of artefacts: process ownership, open decisions, scope deviations, data profiling and reconciliation, end-to-end scenario results, interface recovery tests and readiness evidence. Look for ageing and repeated deferral, not just totals. When a signal deteriorates, change something real by narrowing scope, adding decision authority, resequencing work or moving the date; do not merely add reporting. ERP programmes become controllable when progress means an operating process has been decided, configured, supplied with trusted data and proven from event to ledger. That definition makes uncomfortable facts visible early, which is exactly when they are useful.