The platform goes live on a date everyone knows. The operating model changes over a period nobody scheduled, resourced, or put on the plan.
When a board approves an ERP or CRM investment, the document in front of it describes software: modules, licences, an implementation partner, a go-live date, a business case with a payback period. What the board has actually approved is a change to how the organisation works — who decides what, which processes are allowed to differ, who is accountable for data, and what the management numbers mean. That second thing is rarely written down anywhere, and it is almost never resourced.
This is why so many programmes deliver a technically sound system into an organisation that has not changed, and then spend two years wondering where the business case went. The system was the deliverable. The transformation was the work, and nobody was clearly assigned to it.
What actually changes when the system does
Start with decision rights. A standard process removes the ability of a plant, a country, or a sales region to decide something it used to decide on its own. That is not a side effect of the implementation; it is the implementation. Somebody has to say, in advance and out loud, which decisions move up, which stay local, and who arbitrates when the two collide. If that conversation does not happen at executive level, it happens instead in design workshops, where it is settled by whoever argues most persistently — and it produces a solution that reflects internal politics rather than intent.
Then process ownership. In most organisations, nobody owns order-to-cash or the opportunity-to-order process end to end; several functions own pieces of it. A standard process needs a named owner with the authority to approve or refuse a deviation, and a route for anyone who wants an exception. Without that, every deviation request becomes a project decision, the design backlog grows, and the programme becomes the arbiter of business questions it has no mandate to settle.
Data ownership is the third, and it is the one most consistently underestimated. Migration will clean what exists today. It will not create an ongoing accountability for who maintains a customer record, an item master, a price list, or an account hierarchy, at what quality, from which source. That accountability sits in the business, requires capacity, and has to exist before go-live rather than being discovered after the first month-end.
Measurement changes too, and it changes quietly. The new system will compute margin, pipeline, on-time delivery, or forecast differently from the old one. Unless the definitions are agreed and published before go-live, the first reporting cycle produces two sets of numbers, an argument about which is right, and a management team that keeps its old spreadsheet running for a further year. That spreadsheet is the most reliable indicator of a transformation that did not happen.
Last, roles and capacity. The people who can genuinely represent the business in design are the same people the business cannot spare. Every programme resolves this the same way at the start — part-time allocations alongside the day job — and every programme discovers the same thing at design sign-off: the day job won. Either the capacity is released and backfilled properly, or the design gets made by people without the standing to make it.
An ERP programme is an organisational change with a software delivery attached to it. The software delivery is the part with a plan.
Standardisation is a business decision, not a design workshop
The single question that shapes an ERP programme more than any other is how far the organisation intends to standardise, and it is a question about the business model rather than about the system. A group with genuinely different operating models in different markets may be right to accept variation and pay for it. A group whose variation is historical accident dressed up as local requirement is paying for complexity twice: once to build it and once to maintain it through every subsequent upgrade.
What matters is that the answer is decided deliberately, early, and by people who can hold the line — and that the test applied to every deviation request is a business test, not a technical one. Does this difference create value for a customer, or is it simply how we have always done it here? A programme that cannot answer that question in a sentence will standardise wherever resistance is weakest, which is not the same as standardising where it pays.
In CRM the same dynamic appears in a smaller frame but with sharper consequences, because adoption is voluntary in practice. A seller who does not see the point of a stage definition will fill it in badly or not at all, and the pipeline becomes decorative. Standardising a sales process is worth doing only if management is prepared to run the business on the resulting numbers and to have the uncomfortable conversation with the region whose forecast turns out to be fiction.
Adoption is not training
Training teaches people where the buttons are. Adoption is whether they change what they do when nobody is watching, and it is decided mostly by middle management. If a regional director keeps asking for the old report, the old report survives. If a finance manager tolerates a workaround through the first close, the workaround becomes the process. The most useful intervention in the weeks after go-live is not more training; it is senior people visibly using the new system for real decisions, and declining to accept the old artefacts.
The window is short. In my experience the operating pattern that exists at the end of the first quarter after go-live is broadly the pattern the organisation keeps. Hypercare that concentrates entirely on defect resolution misses this: the technical issues get closed while the behavioural ones set. It is worth planning that period as a management exercise with a defect queue attached, rather than the other way round.
How you know it is working
The signals are unglamorous and available early. Deviation requests declining over the design phase rather than accumulating. Decisions being closed at the level where they belong instead of escalating to the steering committee by default. Data quality measured at source and trending in the right direction before migration, not after. Parallel spreadsheets disappearing in the first quarter after go-live. Forecast accuracy improving in CRM, and the close shortening in ERP — both of which are behavioural outcomes with a system underneath, never the reverse.
None of this shows up in an implementation plan, which is exactly why it needs to be somebody’s explicit job. The value in these investments is taken out of the business after go-live, by managers who now have information they did not have before and are prepared to act on it. No system has ever done that on its own, and none of the ones on your shortlist will be the first.