You selected the right ERP, negotiated the contract with the integrator, and validated the functional scope. And yet, six months after Go Live, the teams are still entering their data into parallel Excel files. This scenario is one I have observed dozens of times. The reason is always the same: change management was treated as a secondary concern.
70% of ERP project failures are linked to the human factor, not to technology. This figure, from Prosci studies and confirmed by McKinsey, should be displayed in bold in every project charter. An ERP does not transform an organization simply by going live. It is the users who make it work — or who undermine it.
This practical guide provides you with a structured methodology for managing change throughout your ERP implementation project. No abstract theory: just concrete tools, templates, and measurable indicators.
Why Change Management Is the Number One Success Factor
An ERP project is an organizational transformation project that relies on a technological tool — not the other way around. This distinction is fundamental.
When a company deploys an ERP, it simultaneously affects:
- Business processes: the way people work changes, sometimes drastically
- Roles and responsibilities: data is shared, silos fall, controls evolve
- Corporate culture: transparency increases, traceability becomes the norm
- Individual skills: every employee must learn new daily routines
The statistics are telling. According to Panorama Consulting, ERP projects that invest more than 10% of the total budget in change management have a success rate 33% higher than those that allocate less than 5%. Gartner estimates that unaddressed resistance to change extends the return on investment timeline by 12 to 18 months on average.
The financial stakes are considerable. For a EUR 500,000 ERP project, an adoption failure represents not only the loss of the initial investment, but also hidden costs: degraded productivity for months, double data entry, data errors, and team demotivation. To explore the causes of failure in more depth, consult our article on ERP implementation failures and how to avoid them.
The ADKAR Model Applied to ERP
The ADKAR model, developed by Prosci, is the most operational reference framework for structuring change management. Its advantage: it focuses on the individual, not the organization. And it is indeed each individual who decides, consciously or not, to adopt or reject the new ERP.
Awareness
Objective: every employee understands why the company is changing systems.
In an ERP context, awareness comes from clear messaging about the limitations of the current system and the expected benefits. Do not talk about “digital transformation” in vague terms. Talk about the time wasted re-entering orders, recurring inventory errors, and the inability to produce reliable consolidated reporting.
Concrete actions:
- Diagnostic presentation by senior management (not by IT)
- Testimonials from similar companies that successfully made the transition
- Written FAQ addressing the most common concerns
Desire
Objective: every employee wants to participate in the change.
This is the most delicate step. Awareness is not enough: one can understand the necessity of change and still not want to participate. Buy-in is built through early involvement and answering the question “What’s in it for me personally?”
Concrete actions:
- Identification of champions in each department (the future key users)
- Co-design workshops for target processes
- Transparent communication about the concrete impact by job function
Knowledge
Objective: every employee knows how to work with the new ERP.
Training is the pillar of this step. But beware: training too early is just as ineffective as training too late. The optimal timing is between 2 and 4 weeks before Go Live, with refreshers during the first week of production.
Concrete actions:
- Differentiated training paths by user profile (see dedicated section below)
- Documentation of business processes in the ERP, not just features
- Training environment (sandbox) accessible for self-paced learning
Ability
Objective: every employee can actually perform their tasks in the new tool.
The difference between Knowledge and Ability is crucial. One can have completed training and still be unable to apply the procedures in the real context of daily work. This is the post-Go Live ramp-up phase.
Concrete actions:
- Enhanced on-site support for the first 4 weeks (floor-walking)
- Dedicated hotline with guaranteed response times
- Catch-up sessions for struggling users
Reinforcement
Objective: new practices become standard practices.
Without reinforcement, the risk of regression is high. Users naturally revert to their old habits as soon as project pressure subsides.
Concrete actions:
- Removal of access to legacy systems (deadline announced in advance)
- Recognition and reward for early adopters
- Monthly review of adoption indicators for 6 months
Communication Plan: When, To Whom, What Message
Communication is the nervous system of change management. It must be planned with the same rigor as a testing plan.
Communication Matrix by Phase
| Project phase | Audience | Key message | Channel |
|---|---|---|---|
| Scoping | Executive committee | Strategic vision, expected ROI | Dedicated meeting |
| Scoping | All employees | Why this project, overall timeline | Town hall + CEO email |
| Design | Operational managers | Impact on their teams, expected role | Workshops by department |
| Design | Key users | Their mission, mobilization schedule | Key user kick-off |
| Build | All employees | Progress, first screenshots, testimonials | Monthly newsletter |
| Go Live preparation | End users | Training schedule, available support | Email + signage |
| Go Live | Everyone | Emergency procedures, support contacts | Intranet + SMS/Teams |
| Post Go Live | Everyone | Quick wins, fixes in progress, next steps | Biweekly newsletter |
The Three Golden Rules
-
The messenger matters as much as the message. Strategic announcements must come from senior management. Operational information flows through middle management. IT communicates only on technical matters.
-
Repeating is not nagging. A message must be heard 5 to 7 times before it is internalized. Vary the channels, not the substance.
-
Listen as much as you speak. Set up feedback channels: anonymous suggestion boxes, monthly morale surveys, project manager office hours.
Training Strategy by User Profile
A classic mistake is to offer the same training to everyone. The needs, starting levels, and motivations differ dramatically depending on the profile.
Power Users (Key Users)
Profile: 1 to 3 people per department, future business process owners.
Training: in-depth (5 to 10 days), including configuration, parameterization of their domain, and first-level troubleshooting. They must understand the system’s logic, not just the screens.
Timing: training during the build phase, involvement in testing.
Deliverables: they write the training materials for end users in their department.
End Users
Profile: all employees who will use the ERP on a daily basis.
Training: targeted to their business processes (1 to 3 days). No generic training — an accountant does not need to see the procurement module, and vice versa.
Timing: 2 to 4 weeks before Go Live. Short sessions (half-days), alternating theory and hands-on practice in the sandbox.
Recommended format: 30% presentation, 70% practical exercises based on real company scenarios.
Executive Leadership and Managers
Profile: decision-makers and supervisors who do not enter data into the ERP but use the outputs.
Training: short (half a day), focused on reporting, dashboards, and approval workflows.
Timing: just before Go Live. Include a dedicated session on their role as change agents.
Managing Resistance: 5 Profiles and How to Address Them
Resistance to change is not a flaw. It is a normal human reaction to uncertainty. Ignoring it is the worst strategy. Identifying and addressing it individually is the best.
1. The Rational Skeptic
Behavior: asks pointed questions, compares with the old system, demands evidence.
Approach: this is a potential ally. Answer their objections factually. Involve them in testing. Once convinced, they become your best ambassador.
2. The Anxious
Behavior: worries about not succeeding, fears for their job, avoids training sessions.
Approach: individual reassurance. Offer personalized support. Show that training is progressive. Highlight their business expertise, which remains indispensable.
3. The Nostalgic
Behavior: idealizes the old system, constantly reminds everyone that “it was better before.”
Approach: acknowledge the qualities of the old system. Concretely demonstrate what the new one brings in addition. Document the pain points of the old system to remind everyone why the change was decided.
4. The Political Operator
Behavior: resists because the project threatens their sphere of influence or control.
Approach: escalation to senior management is necessary. Political resistance cannot be resolved at the operational level. The executive sponsor must intervene to clarify new responsibilities.
5. The Passive Resister
Behavior: does not openly oppose but does not participate in anything, does not use the system.
Approach: the most dangerous profile because it is invisible. Detect it through adoption indicators (logins, transactions). Activate line management for individualized follow-up.
Change Management Success Indicators
What is not measured cannot be managed. Here are the KPIs to track before, during, and after Go Live.
Adoption Indicators
| Indicator | Target | Measurement |
|---|---|---|
| Daily login rate | > 90% at D+30 | ERP logs |
| Transactions per user | Aligned with target processes | ERP reporting |
| Dual entry rate (ERP + Excel) | 0% at D+90 | Field audit |
| Level 1 support tickets | Decreasing week over week | ITSM tool |
Satisfaction Indicators
| Indicator | Target | Measurement |
|---|---|---|
| Training satisfaction | > 4/5 | Post-training questionnaire |
| Confidence in the new tool | > 3.5/5 at D+30 | Monthly survey |
| Internal project NPS | > 20 at D+90 | Quarterly survey |
Skills Ramp-Up Indicator
The average time to autonomy is the most revealing indicator. Measure the time between the first login and the moment the user no longer needs support. A reasonable target: 4 to 6 weeks for end users, 2 to 3 weeks for power users.
Timeline: Change Management Aligned with Project Phases
Change management is not a standalone phase. It overlays the five phases of the ERP project and begins at scoping.
Phase 1 — Scoping (Months 1-2)
- Appointment of the change management lead
- Organizational impact analysis (which departments, which processes, what scale)
- Stakeholder mapping and their stance toward the change
- First official communication from senior management
Phase 2 — Design (Months 3-5)
- Launch of the key user network
- Co-design workshops for target processes (involvement = buy-in)
- Start of regular communication (project newsletter)
- Training needs assessment by profile
Phase 3 — Build (Months 6-9)
- Development of training materials
- In-depth training for key users
- Intensified communication (demos, testimonials, FAQ)
- First change barometer
Phase 4 — Go Live Preparation (Months 10-11)
- End user training
- Executive and manager training
- Setup of the post-Go Live support framework
- Cutover communication: date, operating procedures, contacts
Phase 5 — Go Live and Stabilization (Month 12+)
- Enhanced on-site support (floor-walking, hotline)
- Daily tracking of adoption indicators
- Catch-up and advanced training sessions
- Celebration of quick wins
- Monthly review and adjustments for 6 months
Mistakes to Avoid
To conclude, here are the five most common mistakes I observe on assignments:
-
Starting change management at the training stage. That is too late. The work begins at scoping.
-
Delegating everything to the integrator. The integrator knows the tool, not your corporate culture. Change management is an internal responsibility.
-
Underestimating middle management. Line managers are the real change agents. If they are not on board, the message does not cascade down.
-
Confusing training with change management. Training is a component of change management, not a synonym for it. Training people who do not understand why things are changing is like teaching students who do not want to learn.
-
Stopping the effort at Go Live. The post-Go Live phase is the most critical for embedding new practices. Maintain the support framework for at least 6 months.
In Summary
Change management is not a luxury or a “nice to have.” It is the factor that distinguishes ERP projects that truly transform an organization from those that become just another poorly used tool. Invest at least 10 to 15% of your project budget in it, appoint a dedicated lead, and follow a structured methodology like ADKAR.
For an overview of all ERP project stages, see our complete ERP implementation guide. And to understand how change management fits with the other phases, consult our article on the 5 phases of a successful ERP project.
