Change is the word
An ERP programme is a change programme that happens to involve software. Organisations that fund it as a technology project get a technically successful system that nobody uses the way it was designed.
Why it matters
The system goes live on one day. The organisation changes over a year, and only if someone planned for it. Adoption is where the benefit is, and adoption is not a phase at the end.
- Benefits come from behaviour: A correctly configured process performed the old way delivers nothing.
- Workarounds are permanent: Whatever people do in the first month becomes the process.
- It cannot be compressed: Change is the thing that gets cut when the schedule slips, and it is the thing whose absence causes the failure.
Putting it into practice
- 01
Impact assessment
Role by role, what changes about how each person spends their day.
- 02
Sponsorship
Visible, business-side ownership, held by someone whose result depends on it.
- 03
Engagement
The people doing the work involved in the design, early enough to shape it.
- 04
Communication
Honest about what changes and what is harder, not only what improves.
- 05
Capability
Training on the process people will actually run, in the environment they will run it in.
- 06
Reinforcement
Support, measurement and correction through the first full cycle, not the first week.
Train on the process, not on the screens. People who know where the buttons are but not what the process expects will invent their own process, and it will be the old one.
What you need in place
- A change impact assessment by role: Specific enough to be useful to a manager.
- Business sponsorship with accountability for adoption: Named, and measured on it.
- Super users from the business: Selected for credibility, given time, and kept after go-live.
- Training in a realistic environment: With the organisation's own data and scenarios.
- Adoption measurement: What people actually do in the system, monitored after go-live.
- A workaround amnesty and hunt: Find them in the first quarter and fix the cause.
Questions to ask
01Impact
Whose job changes, and by how much?
If we cannot answer role by role, change is not planned.
02Sponsorship
Who in the business is accountable for adoption?
Not the programme — the business.
03Capacity
Do super users have time released for the role?
A super user with a full day job is a title.
04Training
Will people train on real scenarios with real data?
Generic training produces generic competence.
05After
Who supports the first month-end?
The first close is where confidence is won or lost.
06Measurement
How will we know people actually adopted it?
Usage data, not survey sentiment.
Metrics and KPIs to track
Change readiness by role
Assessed before go-live, not assumed.
Training completion and competence
Completed against assessed capable.
Adoption
Transactions performed in the system as designed.
Workaround incidence
Identified in the first quarter, and closed.
Support volume by process
Where people are struggling, by area.
Benefit realisation
Against baseline, by owner.
Alongside this