ERP implementation readiness: what it means, how it is measured, and how it fails

Ask three people on an ERP programme whether it is ready to go live and you will often get three confident answers that do not agree. The programme director cites a plan that is on schedule. The system integrator points to completed test cycles. The finance lead says the numbers still do not reconcile. None of them is lying. They are describing different things and calling all of them "readiness".

That ambiguity is the single most expensive thing on an ERP programme, because it delays the moment anyone has to say a hard number out loud.

Back to the top

What readiness actually means

Readiness is not a feeling, a milestone, or a percentage of tasks closed. It is a statement about evidence: for each thing that must work on day one, can you produce a document that proves it works, dated, owned, and independent of the party that built it?

That last clause is where most programmes come unstuck. A system integrator confirming its own build is ready is not evidence. It is an opinion with a commercial interest attached. This is not an accusation of bad faith — it is simply what happens when the party being measured also holds the measuring tape.

A programme is ready when someone outside it can verify the claim, not when someone inside it repeats the claim.

Back to the top

The six variables that decide a go-live

Across ERP programmes, failure clusters into a small number of areas. Orpington scores readiness against six, weighted by how often each one is the thing that actually causes damage:

• Testing discipline (25%) — whether test coverage maps to real business processes, and whether defects are genuinely closed rather than deferred.
• Governance (20%) — whether decisions get made at the speed the programme moves, and whether bad news travels upward without being softened.
• Change management (15%) — whether the people who must use the system on Monday morning have been trained on the system that will actually exist.
• Data migration (15%) — whether migrated data reconciles to source, and whether anyone has signed that reconciliation.
• Integration (15%) — whether the interfaces to surrounding systems have been tested with real volumes and real failure conditions.
• Go-live strategy (10%) — whether cutover is sequenced, rehearsed, and reversible.

The weightings matter. A programme can be immaculate on data migration and still fail because governance was too slow to escalate a known integration defect. Readiness is not an average; it is a chain, and chains fail at their weakest link.

Back to the top

Why status reporting hides risk

Status reporting is not designed to surface risk. It is designed to summarise progress, and those two things pull in opposite directions.

Consider how a red status actually gets created. Someone close to the work must decide the situation is bad enough to escalate. They must then tell someone whose reputation is attached to the programme going well. On most programmes there is a natural filtering effect at every reporting layer — not through dishonesty, but through reasonable people each rounding slightly toward optimism.

By the time that signal has passed through three layers, a serious problem can arrive at the steering committee as an amber item with a mitigation plan attached.

The tell: if your programme has never reported red, that is not evidence it is healthy. It is evidence your reporting cannot produce a red.

 

Self-assessment versus verification

There is a meaningful difference between asking a programme how ready it is and checking. Both have a place, and confusing them is costly.

A self-assessment is fast, free, and useful as a first read. It tells you what the programme believes about itself — which is genuinely valuable information, particularly when different parts of the programme believe different things.

Verification is slower and asks for documents: test logs, reconciliation reports, UAT sign-off, integration test results, the cutover runbook. It replaces belief with evidence. The gap between the two numbers is usually the most informative output of the whole exercise.

Back to the top

When to assess readiness

The instinct is to assess readiness shortly before go-live. That is the least useful moment, because by then the only remaining options are to launch or to delay, and both are expensive.

The useful windows are earlier:

1. After solution design is frozen, when scope decisions are still reversible.
2. Before the first full end-to-end test cycle, when a coverage gap can still be closed.
3. At the point data migration is first attempted at volume, when reconciliation problems surface but are not yet urgent.
4. Six to eight weeks before the go-live gate — late enough to be real, early enough to act.

What to do with a readiness number

A score is only useful if it changes a decision. A defensible readiness number does three things a status report cannot: it gives the board a figure to interrogate, it identifies which of the six areas is dragging, and it creates a baseline you can re-measure against after remediation.

It also changes the conversation with your system integrator. "We are concerned about testing" is easy to absorb. "Our verified testing discipline is 4 out of 10, and here is the evidence gap" is not.

Orpington works with organisations approaching, midway through, or recovering from ERP implementations across Canada, the United States, the United Kingdom, the United Arab Emirates, Singapore, Hong Kong, Malaysia and Australia, covering SAP S/4HANA and Business One, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, NetSuite and Odoo.

Back to the top

The difference between a risk and an issue

Programmes routinely conflate these, and the conflation is expensive. A risk is something that might happen. An issue is something that has happened. The distinction matters because they require different responses and different people.

A risk register full of items that have already materialised is not a risk register — it is an issue log that nobody has re-labelled, and it will keep generating mitigation plans for events that are already in the past. Review the register periodically and ask, item by item, whether this has happened yet. The ones that have need owners and deadlines, not probability ratings.

Back to the top

Readiness is not evenly distributed

A single programme-level readiness figure is useful for governance but dangerous if it is the only number anyone sees. Averages conceal exactly the information you need.

A programme scoring 78 overall might be at 95 on governance and 40 on data migration. That is not a programme that is three-quarters ready. It is a programme with one severe problem and several healthy areas, and the response required is entirely different from a programme sitting uniformly at 78 across every variable.

Always ask for the breakdown. Then ask which variable is lowest, and what specifically is driving it.

Back to the top

The organisations that get this right

Across engagements, the programmes that reach go-live cleanly tend to share a small number of habits. None of them is sophisticated:

• They ask for evidence routinely, not only when they are worried. Requesting a test log is normal, so producing one is normal.
• They separate the party doing the work from the party confirming the work is done.
• They treat a deferral as a decision requiring a named approver, not as an administrative act.
• They rehearse. Cutover, data loads, rollback — repeatedly, against the clock.
• They make it safe to say a date is at risk, early, without it being read as failure.

The last one does more work than the other four combined. Every other mechanism depends on someone being willing to raise the problem in the first place.

Back to the top

What a readiness engagement actually involves

For those considering independent assessment, it is worth knowing what it does and does not require from the programme team.

It does not require pausing work, running workshops, or producing new documentation. The evidence being reviewed is material that a well-run programme already generates: test execution logs, defect reports, reconciliation output, UAT records, the cutover runbook, the decision log.

If producing that material is itself a significant effort, that finding usually matters more than anything in the documents.

Back to the top