The Five Phases of an ERP Implementation Nobody Budgets For

ERP programmes rarely fail on the software. They fail on the work surrounding the software, most of which is invisible when the business case is written because it does not appear on any vendor's quote.

1. Deciding what the truth is

Before anything can be configured, the business has to agree on definitions it has never had to state precisely. What counts as a customer? When is revenue recognised? Is a transfer between warehouses a movement or a sale? These questions look like data modelling but they are policy, and policy needs an owner with the authority to end an argument.

2. Cleaning the data you are migrating

Every legacy system contains records that were valid under rules nobody remembers. Migration exposes all of it at once — the customer with three tax IDs, the part number with a trailing space, the chart of accounts with two codes for the same expense. Budget for this in weeks, not days, and do it before the first test load rather than after it fails.

Migrating dirty data into a stricter system converts a tolerable mess into a blocking error.

3. Reconciling the process you have with the one you bought

The package encodes a way of working. Your team has another. Every gap is a decision: change the process, configure the system, or build something custom. The temptation is to preserve current practice because that is what people asked for; the discipline is to ask whether the current practice was ever designed or merely accumulated.

• Adopt the standard process unless there is a competitive or regulatory reason not to.

• Write down each deviation and who approved it.

• Re-read that list before go-live — some deviations stop mattering.

4. Rebuilding the reports

Nobody counts the reports until they are gone. The finance team has a decade of spreadsheets keyed to the old table names, and on the Monday after go-live all of them are broken. Inventory the reports that people actually open, port those deliberately, and let the rest die — but make the choice consciously instead of discovering it in a board meeting.

5. The stabilisation period

The first close after go-live takes longer, costs more, and finds problems that no test cycle surfaced because no test cycle had real volume and real people under real deadline pressure. Plan for a period of reduced throughput and staff it with the implementation team still in place. Releasing the integrator the week after go-live is the single most reliable way to turn a rough launch into a crisis.

None of these phases is optional. The only choice is whether they appear in the plan or in the overrun.