Trupeer Blog
Summarise
Almost half of ERP projects still treat the people side as a rounding error. A European study of 208 organizations found that almost half allocated less than 5% of the total project budget to change-management activities, even though about one third of those projects ran two to three years, according to the IFIP Conf-IRM paper on ERP change management. I've sat through cutovers that hit the date and still failed in the business. The system was live. The habits were not.
An ERP change management plan is the proof that the new way of working stuck, including later AI recommendations, not a training calendar that ends at cutover.
Table of Contents
What Should an ERP Change Management Plan Include
An ERP change plan should show who must work differently, what support they need, and how the business will check that new processes continue after go-live. Training attendance is only one signal. Owners need evidence that staff follow the process, address workarounds, and act on AI recommendations where those become part of the work.
A technical cutover can have a detailed schedule while the people side is reduced to a slide. A long ERP program needs ongoing ownership, not a training week. Organizations do apply formal change management to ERP projects, and larger employers are more likely to use structured approaches. The operating model may differ by scale, but every project needs accountable business owners.
What goes in the ERP change plan
Plan part | Typical owner | Starts | Good looks like |
|---|---|---|---|
Executive sponsorship | Business sponsor with the CIO | Before blueprint | Sponsors make visible decisions when process design conflicts with local habits |
Stakeholder and impact map | Change lead | During discovery | Roles are assessed for impact, influence, skill, and willingness |
Two-way communications | Sponsor plus communications lead | After the case for change is agreed | Managers can explain why the change is happening, what changes, and what stays |
Role-based training | Process owner with L&D | After process design, before UAT | People practice realistic transactions instead of only attending a class |
Super-user network | Functional leads | Before conference-room pilots | Each site and shift has named floor support |
Hypercare reinforcement | Business process owner | Go-live through 90 days | Workarounds are logged, assigned, and closed |
Adoption metrics | Sponsor with process owners | Defined before build | Measures track behavior over time, not attendance alone |
Fund the work as a dedicated project line during design, then retain measurement after deployment. The budget should cover owners' time, local communication, practice, floor support, and follow-up. For a wider view of sponsorship and resistance, a practical playbook for organisational change offers a useful companion when sizing the ERP effort.
For a 400-user distributor, a light champion model, one process owner, and a short hypercare rota may fit. A multi-country finance rollout needs country process owners, local-language support, and funding set aside from blueprint. In either case, assign someone to review whether the new behavior lasts after cutover, including whether staff use or bypass AI recommendations.
Practical rule: size the plan to headcount, and fund it beyond go-live.
How Do You Build the Plan Before Cutover
Run three phases, Prepare Approach, Manage Change, and Sustain Outcomes, and use ADKAR inside the middle phase so training is not one blob.
I think this rhythm stops organizational change management from collapsing into a newsletter. Prosci's change management process is the operating cadence I use, and the ADKAR model is how I check whether a person can transact.
Six moves before cutover
Define success in business terms. Module go-live dates are not benefits. If the close still needs a side spreadsheet, you missed the point.
List who must work differently by role, site, and language. A global template that ignores a plant shift will bounce.
Assess impact on real transactions, close, procure-to-pay, order-to-cash, or HR, and pick how heavy sponsorship, communications, and practice need to be. Light impact gets a job aid. Heavy impact gets a pilot.
Move people through Awareness, Desire, Knowledge, Ability, and Reinforcement. Each stage gets a different tactic. A user who never hears why the ERP is replacing the old stack will sit through class and still resist.
Track who is behind and change the intervention before UAT sign-off. Waiting for go-live turns a coaching gap into a ticket storm.
Hand ownership to process owners. Review error rates and schedule refresher practice. The implementation team does not own adoption forever.
Take a global finance deployment. Preparation maps country tax and close. Manage Change runs role-based pilots and watches whether critical workflows complete. Sustain Outcomes puts the controller on exception rates after go-live.
An accounts-payable clerk can explain the new match rules and still fail invoice matching until she posts realistic invoices in a sandbox. Knowledge is not ability. Tie that practice back to how you captured the process in ERP requirements gathering, or the sandbox teaches a design nobody signed.
The cutover date is a milestone. It is not the plan.
Who Needs Which Message and Which Practice
Segment people by what changes in their day, then give sponsors a script, managers a local story, and doers hands-on practice.
If you ask me, a single town hall creates awareness and almost no ability. I've noticed the pattern in older ERP survey work too. A 2010 ZDNet analysis of Panorama Consulting findings reported that more than 53% of organizations rated their ability to deal with change as fairly poor or very poor, and 47% described communication between management and employees as poor. The same analysis found 57% of implementations took longer than expected. A blast email will not fix that.
Who gets which message and practice
Audience | What changes in their day | Channel | Question they ask | Practice |
|---|---|---|---|---|
Executives | Scope and local-habit tradeoffs | Steering session with the sponsor | Which exceptions do we allow | A visible decision when design conflicts with local habits |
Managers | Team impact and objections | Local huddles | What changes, and what stays, for my team | Objection handling in their own words and language |
Super users | Floor support by site and shift | Office hours and conference-room pilots | How do I unblock this transaction | Coaching on the live process before UAT |
End users | Daily transactions | Sandbox and job aids | How do I finish my own job | Realistic transactions, not a shared town-hall link |
I keep four audiences and I stop there. Executives trade scope. Managers translate impact. Super users coach the floor. End users transact. Conference-room pilots belong to process owners. Sandbox transactions belong to clerks. Huddles belong to managers who have to handle objections out loud.
Procurement hears why three-way match replaces email approvals. A buyer in Spain needs that same story in local labor context and language, not a copy of the US slide. Desire fails when the reason feels foreign. Ability fails when she has never posted a real PO. Those are different fixes, so don't send everyone the same training link. I map the channels in a communication plan for change management before the first town hall goes on the calendar.
How Do You Prove Adoption After Go-Live
Measure whether the intended transaction happens in the ERP, not whether people sat in class.
I've seen teams declare victory on deployment completion while plants slide back to spreadsheets. A 2025 Panorama Consulting ERP report found that fewer than one-third of organizations reported an intense focus on organizational change management. People work stays underweighted, and post-go-live governance is the gap.
30-60-90 adoption checks
Signal | Day 30 | Day 60 | Day 90 | Owner |
|---|---|---|---|---|
Critical transactions in the new workflow | First full cycle completed by each in-scope role | Volume stable versus the old path | No material volume left on side systems | Process owner |
Exception and rework rate | Baseline captured in hypercare | Down from the day-30 spike | Inside the benefit case | Functional lead |
Support-ticket themes | Top five themes named | Repeat themes have a fix or a job aid | New themes are defects, not confusion | Support lead |
Master-data quality | Owners named for customer, vendor, item | Defect backlog falling | New records pass the rules | Data owner |
Legacy workarounds | Spreadsheet and email paths listed | Each path has a retire date | Retired or formally accepted | Sponsor |
The weekly heat map
Through hypercare I score each group on impact, influence, capability, willingness, and local complexity. Every red cell gets an owner and a deadline. We review it weekly through design, testing, and the first 90 days. If the number slips, someone intervenes that week, not at the next steering deck.
Say invoice match looks fine at headquarters and awful in two plants. The process owner schedules floor coaching there. Another global webinar will not move a bad plant. I track the same signals in end-user adoption metrics so attendance never gets mistaken for use.
A technically successful rollout can still be an adoption failure.
What Tips Stop the Slide Back to Old Habits
Reinforce the new way weekly, and write rules for when an ERP copilot is authoritative versus when a human must check.
In my work the quiet failure is fatigue. People attended training, then a release changed a screen and nobody updated the job aid. Old spreadsheets come back because they still match the job.
Cut needless customization. Training has to match the live system, or every local tweak becomes a private process.
Put end users in conference-room pilots. Designers miss the click that blocks a shift.
Name master-data owners before build. Bad vendor and item records teach people not to trust the ERP.
Keep a super-user office hour on each shift. Floor questions die if support only exists in headquarters hours.
Refresh materials when configuration changes. A stale job aid is how workarounds get official.
Re-certify roles that touch cash, inventory, or employee data. One class at go-live is not a control.
When the copilot joins the process
Forecasts tied to Gartner, as covered in Rimini Street's Predicts 2026 ERP briefing, say only 30% of organizations are expected to have sufficient data quality to fully utilize advanced AI by 2027. Purchased copilots then sit unused because ownership is unclear and people are tired.
A buyer may accept an automated supplier classification until a bad code hits the ledger. The plan has to say who verifies, who escalates, how the exception is documented, and how performance is judged. AI literacy, human-in-the-loop checks, audit trails, and a note when a model or business rule changes belong in the same reinforcement loop as the job aid. I keep those procedures current the way I describe in maintaining training documentation after go-live.
One-time training cannot govern a process that keeps changing.
What Should You Lock In This Week
This week, book the sponsor, score only the two roles whose work changes most, and name the three day-30 behaviors those owners will watch.
In my experience the design window closes while teams hunt for a perfect template. Five actions are enough.
Put 45 minutes on the business sponsor's calendar with the CIO before blueprint. Leave with one rule for when a local habit loses to the standard process.
Draft the heat map for those two roles only. Score impact, influence, capability, willingness, and local complexity. Put an owner and a date on every red cell.
Add a change line to the project budget for the full horizon, even if the first amount is small, so practice is not borrowed from training week.
Schedule the first sandbox before UAT and use realistic transactions, not a slide read-through.
Record one real click-path and turn it into a searchable role procedure super users can refresh when a screen changes. I've seen that single recording travel further than an emailed deck.
If you ask me, Trupeer is how you keep that recording current. One capture becomes the SOP and the later refresher. A starting structure sits in this ERP end-user training plan. For Genpact, Trupeer accelerated a global Workday rollout by 6 months. Trupeer reports 60% faster program delivery and 1.5× productivity at go-live.
Leave the week with owners, a budget line, and day-30 evidence, not another training date.
What Else Do People Ask About ERP Change Plans
When should the plan start? Before blueprint. Impact assessment after design freeze is damage control, and I've seen that slip cost a release. Start while scope can still move.
How much budget is enough? There is no universal percent, but under 5 percent is the failure pattern I watch. Give change its own line for the full project horizon.
Do we need ADKAR and a project phase model? Yes. I use phases to run the program and ADKAR to see whether a person can transact. One without the other leaves a gap.
How is this different from training? Training is the Knowledge and Ability slice. The plan also covers sponsorship, desire, and reinforcement after go-live.
How do global teams keep procedures current? I point them to Trupeer so one recording becomes a searchable, updateable walkthrough rather than a stale deck, with more context on the Trupeer blog.
Trupeer Inc. turns a screen recording of the live ERP click-path into a polished walkthrough, a step-by-step procedure, and a searchable guide your super users can refresh when a screen or rule changes. That is the reinforcement piece most cutovers skip, especially once copilots and releases keep moving the process. If you want the day-30 evidence to stay current, visit Trupeer Inc..
