You’ve selected your ERP, signed the contract with your implementation partner, and signed off on the project plan. Now you’re asking yourself: where do you start to ensure your teams actually adopt the new system?
ERP change management is not a list of good intentions. It is a sequential plan with deliverables at every stage, named owners, and measurable indicators. Without this structure, even the most technically successful ERP projects can end in marginal usage and total loss of value.
This article gives you an 8-step plan, from initial scoping through to the long-term embedding of new practices. For the methodological layer — ADKAR model, resistance profiles, communication matrix — see our practical ERP change management guide, which complements this operational plan.
Why Change Management Is the Real Risk in Any ERP Project
ERP Failures Have Human Causes, Not Technical Ones
Post-project audits consistently point to the same finding: the majority of ERP deployments that fall short of their objectives failed on the human side, not the technical side. The system works — but users don’t engage with it. They work around it, maintain parallel spreadsheets, and ask to go back to the old tool.
This is not stubbornness. It is the predictable consequence of a poorly prepared change: teams informed too late, training scheduled too early, an executive sponsor invisible on the ground, and inadequate post-go-live support.
The “We Were Better Off Before” Syndrome
“We were better off before” is unavoidable in the first weeks after go-live. The productivity curve dips before it recovers — this is normal, documented, and can be communicated in advance. What is unacceptable is when the curve never recovers.
To prevent this scenario, change management must start during the scoping phase, not during deployment. The 8 steps below align with the full project lifecycle.
Step 1: Map Your Stakeholders and Anticipate Resistance
The Influence-Impact Matrix
Before any change action begins, identify key stakeholders by positioning them on two axes: their influence on the project (ability to block or accelerate) and the project’s impact on their role (high or low).
This yields four quadrants:
- High influence / high impact: strategic allies if convinced, powerful blockers if resistant. Invest time here from day one.
- High influence / low impact: keep informed regularly to prevent disengagement that turns into passive-aggressive opposition.
- Low influence / high impact: end users. Their adoption determines ROI. Do not underestimate them.
- Low influence / low impact: standard communication, without over-investment.
Identifying Blockers and Natural Champions
In every department, there are informal opinion leaders. Identify them before the design phase begins — they are the ones who will shift their colleagues’ opinions. If convinced, they become your natural champions. If resistant, they become the focal point of resistance.
Expected deliverable: a stakeholder register listing, for each key actor, their level of influence, their anticipated level of resistance, who is responsible for engaging them, and the recommended contact frequency. This document evolves throughout the project.
Step 2: Define and Embody a Clear Vision of “After”
The Promise You Can Make to Your Users
Teams accept change when they understand what they gain from it — not abstractly, but concretely, at the level of their own role.
The promise must be role-specific. To the procurement team: “You will no longer re-enter orders received by email. They will be integrated automatically.” To the finance team: “The month-end reconciliation that took you two days will be reduced to a few hours.” These concrete examples are worth more than ten PowerPoint presentations on “digital transformation.”
There is, however, one promise you should never make: that everything will be easy, that the transition will be smooth, that there will be no difficulties. Users will not believe this façade optimism, and you will lose credibility at the first incident.
The Non-Delegable Role of the Executive Sponsor
The executive sponsor must be visible — not just at the kick-off. They must sign project newsletters, appear at progress meetings, and personally intervene in cases of high-level hierarchical resistance.
Change management cannot come only from the project manager or the implementation partner. It must be perceived as a leadership priority. This visibility cannot be delegated.
Step 3: Build a Key User Network
Selection Criteria
Key users (superusers or subject matter experts) are the pivot of the entire approach. They are not simply the people who happen to be available or who already know IT systems. The selection criteria that actually work are:
- Business credibility: recognised by their peers for their process expertise
- Informal influence: their opinion carries weight in their department, regardless of grade
- Openness to change: curious, receptive, not attached only to “how we’ve always done it”
- Availability: at minimum 50% of their time must be freed up during the configuration phase. A key user at 10% capacity is an ineffective key user.
Plan for at least one key user per impacted functional department. For critical processes (finance, logistics, production), consider two key users to ensure continuity.
Deep Training and the Relay Role
Key users receive training two to three times longer than end users. They understand not only the screens but also the logic of the system: why this configuration, what are the implications of a misconfiguration, how to diagnose a first-level issue.
In return, they become the first level of post-go-live support for their department and produce training materials adapted to their business context. It is they — not the implementation partner — who understand the operational reality on the ground.
Step 4: Build the Communication Plan
Segmented Messages by Audience
Communication must be segmented. The message addressed to the executive committee is not the message addressed to data-entry operators. Three levels at minimum:
- Senior leaders and executives: strategic stakes, expected ROI, milestone schedule, upcoming decisions
- Middle managers: impact on their teams, their relay role, available resources to support their staff
- End users: what changes in their day-to-day, concrete benefits, training schedule, support contacts
Timing and Frequency
The first official communication should go out at least six months before go-live. Not a technical email — a communication signed by senior management explaining the why of the project.
After that, the recommended cadence: monthly communication during the build phase (progress, early previews, testimonials), fortnightly in the pre-go-live preparation phase, and weekly in go-live week.
The principle of repetition is key: a message needs to be heard multiple times across different channels before it is absorbed. Vary your formats (email, internal newsletter, posters, team meetings, live demos) without changing the core message.
Step 5: Build the Training Plan
Duration by User Profile
Training duration must be proportional to role complexity:
| Profile | Recommended Duration | Format |
|---|---|---|
| Key users | 5 to 10 days | Intensive classroom + involvement in testing |
| Daily users | 2 to 3 days | Short sessions, 30% theory / 70% practice |
| Operational managers | 1 day | Reporting, dashboards, approval workflows |
| Senior executives | Half day | Summary reporting, key indicators |
The Classic Mistake: Training Too Early
Training users too early is just as counterproductive as training them too late. Sessions scheduled three months before go-live will be forgotten by the time the system goes live. The optimal window is two to four weeks before go-live for end users.
On format: in-person remains the norm for initial sessions (interaction, questions, immediate practice). Short videos (under five minutes) covering key tasks usefully complement training for quick post-go-live reference. Laminated job aids posted at workstations significantly reduce support calls in the first weeks.
Step 6: Run the Post-Go-Live Hypercare Phase
Day −1 to Day +30: A Dedicated Support Cell
The hypercare phase is the most critical period for adoption. This is where first impressions form, where frustrations surface, and where each user makes their often unconscious decision to “trust” — or not — the new system.
An effective hypercare setup includes:
- A dedicated phone or physical support line (not just a ticketing system that implies 24-hour wait times)
- Key users available as the priority resource in each department
- Implementation partner consultants reachable for technical anomalies
- A short escalation channel for critical blockers
The physical presence of key users “on the floor” in the first weeks (floor-walking) is consistently underestimated. The ability to answer a question in thirty seconds by walking across the office beats the best video tutorial.
Adoption KPIs to Monitor
Three indicators are sufficient to manage hypercare:
- Daily login rate: if users are not logging in, they have found a workaround. Target: above 90% by Day +15.
- Ticket volume: this must decrease week over week. A plateau or uptick signals a structural problem.
- Data entry error rate: measured on critical processes (orders, invoices, stock). A high and stable rate signals a training or configuration issue.
Criteria for Closing Hypercare
Hypercare can be progressively wound down when three conditions are met: login rate above 90%, ticket volume in sustained decline, and key users self-declare they can handle first-level support without external reinforcement. Closing hypercare early for budget reasons is a short-term saving that costs dearly later.
Step 7: Measure Adoption at 30, 90, and 180 Days
Quantitative Indicators
Adoption is not declared — it is measured:
| Timeframe | Indicator | Signal of Good Adoption |
|---|---|---|
| Day +30 | Daily login rate | > 90% of active users |
| Day +30 | Support ticket volume | In clear decline |
| Day +90 | Dual entry ERP + spreadsheet | < 5% of processes |
| Day +90 | Real-time transactions | > 80% of expected volume |
| Day +180 | User autonomy | Key user support sufficient, no partner recourse needed |
Qualitative Indicators: 5 Questions to Ask Users
A short survey (five questions maximum) at Day +30 and Day +90 provides a reading that complements log data:
- How would you rate your confidence with the new ERP? (score 1 to 5)
- Was the training you received suited to your role?
- Have you encountered unresolved difficulties in the past two weeks?
- Would you recommend the support programme to a colleague?
- Is there a process you continue to manage outside the ERP?
The last question is the most revealing. A “yes” triggers an immediate investigation: either a training gap, an inadequate configuration, or active resistance.
Corrective Actions Based on Results
A low login rate at Day +30 triggers a department-by-department investigation, with the line manager in the lead. Persistent dual entry at Day +90 triggers a process-redesign session with the relevant key users. Measuring is not enough: every indicator must have a pre-defined action trigger.
Step 8: Embed New Practices for the Long Term
Integrate the ERP into HR Processes
Long-term embedding requires institutionalisation. If correct ERP usage is not part of operational managers’ annual objectives, it will remain optional. If new-hire onboarding does not include ERP training in the first two weeks, newcomers will learn poor practices from their colleagues.
These two levers should be activated quickly after stabilisation: include a data quality objective in managers’ annual reviews, and standardise ERP training in the onboarding programme.
Proactively Communicate on Future Developments
One frequently overlooked risk: users who have stabilised into their new practices can regress if a version upgrade or new feature is deployed without prior communication. Build a communication calendar covering upcoming changes, however minor.
Create an Internal User Community
Organisations that sustain adoption over the long term share a common approach: a community structure — an internal forum or dedicated Teams/Slack channel for ERP questions, quarterly sharing sessions run by key users, and recognition of “ERP champions” who contribute to the collective.
This lightweight structure creates a virtuous cycle: users who have questions get answers quickly, key users deepen their expertise through practice, and the culture of ERP mastery spreads organically.
Checklist: 20 Control Points Before Go-Live
This checklist covers the human dimension of the project. It complements (without replacing) the technical cutover checklist on operational aspects.
Governance and Sponsorship
- The executive sponsor is identified, committed, and visible to teams
- A change management lead is appointed (internal or specialist consultancy)
- The steering committee includes a change management update at every meeting
Stakeholder Mapping and Engagement
- Stakeholder mapping is complete and current
- All identified blockers have a personalised engagement plan
- Natural champions have been identified and mobilised
Key Users
- A key user is designated for each impacted functional department
- Key users have had at least 50% of their normal workload freed up
- Deep key user training is complete and validated
- Key users have participated in user acceptance testing
Communication
- The first official communication was sent at least six months before go-live
- A communication plan by audience (leadership, managers, users) is documented
- Feedback channels (Q&A inbox, pulse survey) are in place
Training
- The training plan by user profile is finalised
- All end-user sessions are scheduled within the four weeks before go-live
- Training materials (by department) are written and validated by key users
- A sandbox environment is available for users to practise
Hypercare
- The post-go-live support setup (helpline, floor presence) is sized and documented
- Adoption indicators (logins, tickets, errors) are configured in the reporting dashboard
- An action trigger is defined for each indicator (threshold + owner)
To go further, see our full methodological guide on ERP change management, which covers the ADKAR model, resistance profiles, and communication matrix in depth. And to manage post-go-live stabilisation, consult our 90-day post-go-live checklist.
