Change management plan: fix resistance before it starts

A change management plan for an ERP programme sets out how people will move from the way they work today to the way the new system needs them to work, and who is responsible for getting them there. It starts at mobilisation, not at training. It has seven parts, each with a named owner, and it is wired into the charter, the design workshops and the quality gates rather than run as a side stream.

Most resistance does not come out of nowhere. It builds slowly, well before kickoff. You hear it in sideways comments in early meetings. You notice key business leads going quiet. By the time a formal change plan is drafted, much of the damage is done.

It usually starts in a few predictable places:

1. Key users left out of early design.
2. Department heads surprised by impacts nobody discussed with them.
3. Vague communication that invites second-guessing.
4. Past failed projects that left quiet distrust behind.

These are structural problems, not just communication problems. If the steering committee is passive, expect friction. If the project charter says nothing about adoption, you have already lost a lever.

1. 01MobilisationMap influence and collect the informal history
2. 02DesignAgree adoption KPIs, power users co-author
3. 03TestingBusiness users test their own processes
4. 04TrainingRole-based, on real data, at times people can attend
5. 05Go-live gateAdoption thresholds, not only functional sign-off
6. 06First 90 daysTrack logins, errors, tickets and workarounds

Workarounds caught before they become habits

A change plan is not a communications calendar. These are the seven components and who should own each.

Component	Purpose	Owner
Role and influence mapping	Everyone affected, with their influence, not just their title	Change lead
Change impact assessment	How each group's roles, processes and tools change	Process owners with the change team
Communication plan	Audiences, messages, channels and timing, with feedback loops	Communications lead
Training and enablement	Role-based curriculum, practice, readiness checks	Training manager
Leadership engagement	Leaders aligned, briefed and visibly backing the change	Executive sponsor with the change lead
Adoption KPIs	Behaviour measures agreed in design and tracked past go-live	Change lead
Resistance monitoring	Early warning signs mapped to teams	All workstream leads

Communication in most change plans means newsletters, emails and town halls. That is not what moves people.

I remember a rollout where we communicated everything on time, but no one could explain why the process was changing. We had volume, but no clarity.

Tailor by audience. Senior managers want business impact first. End users need to hear it from their own manager, not a programme lead they have never met. Functional leads respond better when they own part of the message.

Build in feedback. Outbound-only communication is half a plan. I worked with a team where weekly Q&A calls made more impact than any email. Link what you hear to the risk register, so weak spots show up before they surface in public.

Get the timing right. Too early creates confusion. Too late feels forced. In one rollout, users thought their jobs were being replaced. Nobody said that. But the silence filled in the gaps. Address the fear directly and early, before someone else does it for you.

Do not reuse the people map from the last project. Influence changes from programme to programme. Build the map from scratch and update it every month.

For each person, track three things: how much the change affects them, where they stand today (supportive, neutral or resistant), and how much influence they have over others. A resistant middle manager with a team that follows them matters more than a resistant individual user.

Collect the informal history too. Past failed projects shape behaviour in ways the lessons-learned documents never record. A few hours of listening to what people remember tells you what you are really dealing with. My stakeholder management guide covers the mapping in more detail.

Training is one part of change management, not the whole of it. The common failure is training that comes too late, in the wrong format, and stops before people are confident. A one-day course two weeks before go-live is not readiness.

What works:

1. Role-based content. Teach each group what it needs for its own job, not a system tour.
2. Practice on real data. Use the business's own data and transactions, not demo scenarios.
3. Power users as trainers. People learn better from colleagues they trust. Treat power users as co-authors of the design, not just testers.
4. Training at the right time. A finance team I worked with skipped sessions because they were scheduled at the wrong time. Moving them fixed it.
5. Support after go-live. Confidence drops after go-live, not before. Staff hypercare with people who can answer real questions quickly.

User acceptance testing is part of adoption as well. I remember a UAT session where a small mistake in pricing logic would have caused incorrect invoicing. A team lead spotted it. No one else had. That one catch saved weeks of cleanup, and it happened because a business user felt the system was partly theirs.

Put adoption thresholds into your quality gates. "The system works" is a functional sign-off. "Users are ready to work in it" is a different one, and most programmes only ask for the first. My guide to SAP training strategies goes deeper on the training plan.

Adoption KPIs to agree before go-live

Set these during design, so there is a baseline to measure against:

1. Login rates by user group in the first 90 days.
2. Error rates in key transactions against the legacy baseline.
3. Support tickets by volume and category.
4. Workaround frequency: exports to spreadsheets, parallel records, manual approvals outside the system.
5. Manager-reported confidence from short pulse surveys.

The window is narrow. I have seen users quietly switch back to spreadsheets within weeks, not because the system was broken but because no one helped them through the change. A few months after go-live, workarounds become habits.

Digital adoption tools

SAP completed its acquisition of WalkMe in September 2024, for an equity value of about $1.5 billion. SAP said at the time that WalkMe's AI capabilities would add context-aware help to Joule across workflows. That means SAP now owns two adoption tools with different strengths:

• SAP Enable Now suits structured training content: record a process once and produce documentation, simulations and test scripts from it.
• WalkMe suits guidance inside the application at the moment of use, and it can span SAP and non-SAP applications.

Evaluate them together. Whatfix is the main independent alternative if you want adoption tooling that is not tied to SAP. None of these tools replaces a manager explaining why the change matters.

Even with good preparation, new friction appears. Over-controlling it usually backfires. The aim is to see it early.

The warning signs are missed workshops, silence in meetings, vague feedback in testing and key users building unofficial workarounds. Map each signal to the team it comes from, so you can act before it reaches the steering committee.

One practice that works: rotate change leads by phase. One person owning change across a two-year programme usually burns out and loses perspective. As the nature of resistance changes, so should the people dealing with it.

Above all, keep change management inside the programme structure. Behavioural outcomes belong in the project charter. People risks such as team overload and legacy distrust belong in the risk register next to the technical ones. When change management reports into a generic PMO update, it becomes a tick-box.

What should a change management plan include?

Seven parts: influence mapping, a change impact assessment, a communication plan with feedback loops, role-based training, leadership engagement, adoption KPIs and resistance monitoring. Each needs a named owner, and the plan should be linked to the charter, the design workshops and the quality gates.

What are the 5 C's of change management?

There are several versions. The one I use is clarity (people know what changes for them), consistency (leaders say the same thing), commitment (the sponsor stays visible), communication (relevant, timely and two-way) and capability (training, support and time to adjust). If any one is missing, people revert to old habits.

What are the 7 R's of change management?

They come from IT service management and are used to assess a change request before acting on it. Who raised it, the reason, the expected return, the risks, the resources required, who is responsible, and the relationship to other changes. They apply to technical change control rather than to the people side of a programme.

What is the difference between organisational and technical change management?

Organisational change management prepares people: communication, training and support through a change in how they work. Technical change management controls what changes go into the SAP system, through transports, approvals, testing and rollback. ERP programmes usually manage the technical side well; adoption failures come from the organisational side. My guide to SAP technical change management tools covers the technical side.

Should I use WalkMe or SAP Enable Now?

Often both. SAP Enable Now is stronger for creating structured training content before go-live. WalkMe is stronger for in-application guidance after go-live, especially when users move between SAP and other applications. Since SAP owns both, evaluate them together. Whatfix is the main independent alternative.

When should change management start on an ERP project?

At mobilisation, before the first design workshop. The early actions that matter most are mapping influence, collecting the informal history of past projects, putting behavioural outcomes in the charter and setting the sponsor's communication rhythm.