The business decisions hidden inside an ERP project

Enterprise resource planning programmes are budgeted as software projects and delivered as organisational ones. That mismatch is the single best predictor of how one will go, and it shows up long before anybody configures anything.

The decisions arrive whether you plan for them or not.

At some point somebody has to say when an order becomes a commitment, what happens to a cost that arrives after a period closes, who may approve a purchase and at what value, which legal entity owns which balance, and what the chart of accounts is for. These are not technical questions and no configuration screen can answer them.

The organisations that treat these as project work settle them in workshops, early, with the people who own the consequences. The organisations that treat the programme as an installation meet the same questions during testing, asked by a consultant who needs an answer today, and answered by whoever is in the room. The second route is not cheaper; the decisions are simply made worse and later.

The chart of accounts is a governance document.

It is treated as a finance housekeeping task and it is actually a statement about how the business will be understood. Decide it around how you want to be able to ask questions in three years, not around how the last system was set up, because migrating a chart of accounts afterwards is one of the most expensive corrections available.

The same is true of cost centre structure and of the dimensions you attach to a transaction. Adding a dimension later is easy. Getting three years of history to carry it is not.

Master data is on the critical path, and it always starts late.

Customers, suppliers, items, cost centres and employees exist in several systems with different keys, different spellings and different opinions about what is current. Nobody owns them, because ownership was never assigned to anybody. Reconciling that is slow, visible and unglamorous, and it is the most common reason a go-live date moves.

Two things help more than anything else. Name an owner per data domain, a person rather than a department, with the authority to decide that a record is wrong. And start loading into a test environment early and repeatedly, because the first load finds problems and the fifth one should be boring. A migration rehearsed five times is a different risk from one rehearsed once.

Standard process is a real choice, not a default.

Every programme says it will adopt standard process and then accumulates exceptions. Some of those exceptions are genuine competitive difference and should be kept. Most are habits from a previous system, and configuring them faithfully makes them permanent and expensive.

The useful discipline is to make each exception argue for itself in writing: what it costs to build, what it costs to maintain through upgrades, and what would actually happen if it did not exist. Most do not survive the third question. The ones that do are the ones worth paying for.

Testing is where the process design gets validated, not the software.

The software works. What is being tested is whether the process design matches how the work actually happens, and that can only be found by the people who do it, running their own scenarios, with their own awkward cases. A test script written by the implementer and executed by the implementer proves that the configuration matches the specification, which was never the risk.

Budget for the business time this needs, and protect it. Testing that is done in the gaps between day jobs is the most common way a defect reaches production, and the cost of finding it there is an order of magnitude higher.

Cutover is a rehearsal problem.

The cutover is a sequence with a time limit and a rollback point. It should be run end to end, at full data volume, before the weekend that matters, and the rehearsal should be timed. A cutover plan that has never been executed is a document, not a plan.

Decide the rollback position explicitly and write down who may call it. Under pressure at three in the morning, nobody wants to be the person interpreting an unwritten intention.

What good looks like at the end.

A configured system that matches a documented process design. Reconciled data with a named owner per domain. A rehearsed cutover. People trained on their own process rather than on a menu. And a written list of what was deliberately deferred, with dates, so the things that were dropped to protect the date are visible rather than quietly forgotten.