Most Enterprise Resource Planning (ERP) programs are resourced as technology projects and judged as behaviour projects. The build finishes. The cutover holds. Then the business keeps working the way it worked before, in parallel, in spreadsheets, and the benefit case quietly disappears.
Change management is what closes that gap. Not a communications plan bolted on near go-live — a workstream with named owners, dated deliverables, and exit criteria, sitting on the same Integration Roadmap & Timeline as configuration and data.
Why ERP is the hardest change to land
ERP touches the enterprise spines at once: Order-to-Cash, Procure-to-Pay, Record-to-Report, Hire-to-Retire. It moves decision rights, not just screens. The person who used to approve something no longer does. The report a supervisor trusted is replaced by one they have never seen. The workaround that kept a shift moving is now blocked by a control.
That is a change in how people hold authority and get their work done. No amount of training on menu navigation addresses it.
Change management is a workstream, not a message
Treat it the way you treat integration: with artifacts, owners, and dates.
- Change Management Strategy — who is affected, how, and what has to be true for them to work the new way on Day-1.
- Stakeholder and impact map — by role and by site, not by org chart.
- Communication Plan by persona — what is changing, what is not, and where to get help. Managers need talking points. Executives need a briefing rhythm. Everyone needs a visible place to see decisions.
- Role-based training plans and materials — built from Standard Operating Procedures (SOPs), not from vendor courseware.
- User Acceptance Testing (UAT) and Training Program — with explicit UAT exit criteria.
- Adoption Metrics and Monitoring — a baseline before the switch that you will compare against in week one.
Each of those has a name beside it and a date on the roadmap. If one does not, it is not a plan.
Train on tomorrow's job, not on the software
The common failure is scheduling training before the Future-State Blueprint and the SOPs exist. Trainers then teach features, because features are the only thing that is finished. The sandbox does not reflect the future workflow. The sample data does not look like the real thing. People leave the session able to click, and unable to work.
Sequence it properly and training becomes rehearsal:
- Future workflows, decision rights, and exception paths are signed first.
- SOPs are written, then become the training scripts and the UAT test cases.
- The training environment mirrors the to-be design with representative data.
- Scenarios are role-based — the dispatcher's day, the field supervisor's day, the accounts receivable clerk's day.
If a readiness gate is red — configuration, data, access, or trainers — training is rescheduled, not pushed through.
Resistance is usually a signal, not an obstacle
When a team pushes back hard on a new workflow, the most common reason is that the workflow does not survive contact with their reality: a seasonal peak, a compliance window, a customer who will not accept the new document, an asset that cannot be taken offline. That is intelligence, and it is cheaper to hear it in design than in hypercare.
Build the route for it. Exception paths, a visible decision log, and a weekly cadence where a frontline objection can actually change the build. Teams adopt what they helped shape.
Measure adoption like you measure uptime
Adoption is not a feeling at the end of the program. Instrument it by role and watch it daily in week one, then weekly:
- Usage by role, and who is still working outside the system
- Task completion and error rates
- Time-to-competency
- Incident volume and what the incidents are actually about
- System retirements completed, so parallel work disappears on schedule
Put those on the dashboards leaders already trust, with named owners and a report-freshness Service Level Agreement (SLA). A metric nobody owns is not a metric.
Then keep the support on
Change does not end at go-live. Hypercare is the staffed stabilization period immediately after the switch, with incident response targets and a command centre that can route a problem fast. Steady State is the operating cadence that follows — the governance that stops backslide once the project team disperses.
In our own delivery, change management and hypercare run as a pair. Both of our published case studies record the same lesson: the Environmental Services engagement names ongoing change management and blended training as what drives sustainable adoption, and the Infrastructure Construction engagement credits role-specific training plus hypercare, with continuous feedback keeping adoption high.
Where change management sits in the arc
Our operating arc is Map → Gap → Solution → Train → Deploy → Hypercare → Steady State. Change management is not the "Train" box. It runs the whole length of it — it is how Map gets honest answers, how Gap gets prioritised against what people can absorb, and how Deploy lands without a scramble.
If you are about to start an ERP program, the useful question is not which product. It is: who owns adoption, what are they accountable for, and is it on the same roadmap as the build?
See Enterprise Training and Curriculum Development for how we build role-based programs, and Why Tech-First Transformations Fail—and What to Do Instead for why the order of work matters more than the stack.