The cost of producing programme material has fallen sharply. The cost of getting the decisions wrong has not moved at all.
An ERP and CRM programme produces an extraordinary volume of material. Process descriptions, requirement specifications, fit-gap analyses, configuration documentation, interface designs, migration mappings, test cases, training material, weekly status reporting. For as long as I have worked in this field, that production line has absorbed a large share of the budget and most of the calendar. That is the part which has genuinely changed.
The change is not theoretical. On programmes running today, AI is drafting process documentation from workshop recordings and legacy manuals. It is comparing as-is descriptions across entities and showing where the differences are real rather than merely linguistic. It is generating and maintaining test cases, keeping regression coverage current as the build moves. It is profiling migration data, proposing mappings, and reconciling loads far faster than a team could by hand. It turns a week of reporting into an afternoon. None of this requires a special tool or a separate initiative; most of it is available in platforms the programme already licenses.
The effect is specific and worth naming precisely: the marginal cost of producing an artefact — and of redoing it — has fallen sharply. Two consequences follow. First, work that used to be quietly skipped because it was too expensive is now affordable: a proper data-quality assessment before sign-off, a full regression pass before a release, a second opinion on a design decision that everyone had privately doubted. Second, the shape of the team shifts. Fewer people are needed to write things down. The same number, or more, are needed to judge whether what has been written down is right.
What does not change
The decisions that determine whether an ERP programme succeeds are made early, by people, under conditions of considerable uncertainty. How far the organisation standardises and where local variation is genuinely justified. Whether the business adapts to the platform or the platform is bent to the business. Where the scope boundary sits, and what happens the first time someone credible argues it should move. Who owns master data — not in the governance document, but in practice, with a name and a budget. And underneath all of it: what the programme is actually for, expressed in terms the executive committee would still recognise eighteen months later.
The most consequential decisions in an ERP programme are made at the point when nobody yet knows enough to make them. Better documents do not move that point.
AI can inform those choices. It can assemble the arguments faster, surface precedents, stress-test an assumption, and make it cheap to look at a question from three angles instead of one. What it cannot do is carry the consequence. Accountability is not an analytical function; it is a position someone occupies when a decision turns out to have been wrong. A steering committee cannot delegate that, and no amount of generated analysis makes the choice self-evident at the moment it has to be taken.
The same holds further down the programme. Adoption remains a human process — a controller who does not trust the new close, a warehouse team that keeps the old spreadsheet, a country manager who was never really convinced. Data quality remains a function of what the business does at source, not what the migration tooling can repair. The commercial dynamics between client, implementation partner and software vendor are unchanged, and so are the incentives that come with them. Benefit realisation still depends on someone taking cost or headcount or working capital out of the business after go-live, which no system has ever done on its own.
The failure mode to watch
There is a new risk, and it is the mirror image of the benefit. Programmes can now generate material considerably faster than the organisation can read, challenge and approve it. An unreviewed specification is not an asset; it is a liability that looks like an asset on a progress report. Verification becomes the bottleneck, and verification is precisely the work that requires the most experienced people — the ones the programme was hoping to need fewer of.
Output that is plausible and wrong is also the hardest kind of defect to catch. A migration mapping that is ninety-five per cent correct, produced in an hour, is more dangerous than one that is seventy per cent correct produced over a fortnight, because the first invites trust and the second invites scrutiny. This is manageable, but only if it is treated as a design question for the programme’s operating model rather than a tooling detail.
My honest summary, two years into this: AI has taken a meaningful share of the effort out of ERP implementation, and none of the risk. It has made these programmes faster to run. It has not made them easier to lead — and for the executives who sponsor them, that is the distinction that matters.