Master ERP change management planning with this guide. Secure leadership buy-in, manage resistance, and ensure successful ERP implementation and high user adoption.
Change management on an ERP project is usually treated as communication. An email announcing the project, a presentation at a town hall, some posters, and then training in the final fortnight. That is not change management, it is publicity, and it produces very little.
Real change management is the work of making sure that when the system goes live, people can and will use it the way it was designed. That is a considerably larger job, it starts much earlier, and it is mostly not about communication at all.
This article covers what actually needs planning, in what order, and what separates the projects where people adopt the system from the ones where they work around it.
Start by being precise about the change, because the scale of the effort follows from it.
For some people the change is trivial. They will enter a timesheet in a different screen and nothing else about their week alters.
For others it is substantial. Their entire process changes, the sequence is different, they lose a spreadsheet they built and relied on, and they have to learn where information now lives.
And for a few it is existential in a way people are reluctant to say out loud. A role built around manually assembling something the system will now produce automatically is a role that changes fundamentally.
Mapping this properly, person by person or at least group by group, tells you where to spend the effort. Treating everybody as equally affected wastes attention on the people who need none and starves the people who need most.
Resistance gets framed as an attitude problem to be overcome, which is both unhelpful and usually inaccurate.
Somebody avoiding the new system is generally making a rational calculation. The old way is faster for them, or the new way loses something they needed, or nobody has explained why the discomfort is worth it.
Occasionally resistance is about status or control, and even then it is worth understanding rather than overriding, because that person usually has influence over others who will follow their lead.
The practical move is to ask rather than to push. What is harder now than it was. What could you do before that you cannot do now. About half the time the answer reveals a genuine gap in the design, and the other half it reveals something the system does that nobody showed them.
Executive sponsorship is invoked in every methodology and rarely defined, which makes it easy to claim and hard to deliver.
In practice it means three specific behaviours. Using the system themselves where their role involves it, because a leader who exempts themselves communicates clearly that it is optional for everybody else.
Protecting the time their people need for design, testing and training, rather than leaving them to find it alongside a full workload.
And being visible when something goes wrong rather than only when it goes well, since the first difficult week is when people are watching most closely.
It also means resolving the process decisions that only leadership can resolve. A great deal of what looks like resistance is people improvising because nobody has decided how the process should actually work.
Every team has people whose view carries disproportionate weight, and they are frequently not the managers.
They are usually long tenured, competent, and the person everybody asks when they are unsure. If they are sceptical, the team is sceptical. If they are genuinely on board, most resistance evaporates without further effort.
Identify them early and engage them properly. Not by telling them the project is happening, but by involving them in design and taking their objections seriously enough to change something as a result.
Where an influential person remains opposed after genuine engagement, that is worth understanding rather than working around, because they are usually opposed for a reason that will affect everybody else too.
The single largest driver of adoption is whether the system fits how the work actually happens, and that is settled during design rather than during training.
A design produced by asking managers describes the process as it is supposed to work. The people doing it daily know the exceptions, the workarounds and the reasons behind them, and the exceptions are where design decisions live.
Where those people are involved, the system accommodates reality and adoption largely follows. Where they are not, the system encodes an idealised process and everybody works around it from the first week.
Involving them is not a consultation exercise. It means having them in design sessions, having them react to working configuration, and changing things when they say something will not work.
Change communication usually stays general, and general reasons motivate nobody.
Better visibility for the business does not answer the question the person in front of you is actually asking, which is what this means for me and my week.
The honest answer varies by role and is worth working out for each. For some people the new system genuinely makes their job easier, and you should say exactly how and be specific.
For others it makes their job slightly harder while making somebody else's considerably easier. Say that too. People accept a change that costs them something when the reason is explained and the trade off acknowledged. They do not accept being told something is better when their direct experience says otherwise, and the credibility lost there is difficult to recover.
Communication matters and it is the supporting act rather than the main event, so the aim is a steady rhythm rather than a campaign.
Early on, explain why the business is doing this at all, what problem it solves, and roughly when things will happen. Vagueness here creates rumour, and rumour is always worse than the truth.
Through the middle of the project, keep people informed about progress in a way that is honest rather than uniformly positive, because a project that reports only good news loses credibility the moment something visible goes wrong.
Approaching go live, get concrete and practical. Dates, what changes for you specifically, what you need to do, where to get help.
And afterwards, keep communicating, particularly about what has been fixed in response to feedback, because that is the message that converts sceptics.
Training is where change management becomes tangible, and its design determines whether people can act on everything else you have told them.
Build it around processes rather than modules, so it maps onto what somebody actually does rather than onto how the software is divided.
Cover the exceptions, because standard training covers the straightforward path and real work is mostly exceptions. The first time somebody meets an exception they were not shown, they revert to the old method.
Schedule it against first use rather than against go live, so that month end training happens before the first month end and periodic activities are trained before their first occurrence.
And use realistic practice data, because exceptions that appear during training are the ones people will meet, and dealing with them in a session is worth more than being told they exist. Our training service is built this way.
The period immediately after go live sets the attitude that persists for years, and it is the most commonly under resourced part of the whole programme.
People need help within minutes rather than within days. A question that goes unanswered for two days is solved with a workaround, and that workaround becomes permanent.
Experienced people available in the working area, physically or virtually, catch the questions people will not raise formally, which are frequently the important ones.
Expect a productivity dip and say so in advance. A dip people were warned about reads as normal. The same dip unannounced reads as evidence that the system does not work.
Where the old way remains available, a meaningful proportion of people will keep using it, and the two versions of the truth will diverge.
Switch off legacy systems on a defined date rather than leaving them accessible indefinitely. Read only access for historical reference is reasonable. Continued transacting is not.
Retire the spreadsheets the system was supposed to replace, which first requires knowing they exist, which requires asking rather than assuming.
Do this with notice rather than abruptly, since removing a tool somebody depends on without warning creates exactly the resistance you were trying to avoid.
And be honest where the system genuinely does not yet do something. Removing the alternative before the replacement works produces justified anger and lasting damage.
Nothing builds adoption faster than a demonstrated willingness to change the system when somebody raises a genuine problem.
The first few weeks generate a stream of issues, and how they are handled determines whether people keep raising them or quietly stop.
Triage quickly, distinguish configuration problems from training gaps, and communicate what is being done even when the answer is that it will not change and here is why.
Where something is fixed, say so publicly and credit the person who raised it. That single behaviour converts more sceptics than any amount of planned communication.
Feedback forms measure how people felt about a session. What matters is what they do afterwards.
Manual journal volume is a useful proxy, since each recurring one usually indicates a process people cannot complete as designed.
Spreadsheet exports indicate reporting that either does not exist or is not trusted, and both are actionable once you know which.
Approval bypass or rubber stamping indicates a design that does not match how decisions actually get made.
And support question topics, grouped, tell you exactly which process needs attention, which is considerably more useful than an average satisfaction score.
Most change management guidance skirts the hardest case, which is people whose jobs are materially reduced by the system.
Pretending this is not happening is both dishonest and ineffective, since the person concerned works it out well before you tell them and behaves accordingly.
The better approach is to have the conversation early and specifically. What their role becomes, what new capability they would need, and what the business is prepared to invest in getting them there.
Frequently the answer is genuinely good, because the person who spent years manually assembling a report understands the underlying business better than anybody and is well placed to do the analysis instead.
Where the answer is not good, saying so early is still better than letting somebody discover it during go live.
Change management usually stops at go live, and the population turns over.
Within a year a meaningful proportion of the people you trained will have moved on, and their replacements learn informally from whoever sits nearby, which propagates workarounds faster than correct method.
Build reusable material during the project rather than afterwards. Recorded walkthroughs of each core process, a short guide per role, a first week checklist.
And make onboarding somebody's defined responsibility, because where it is nobody's job the quality varies with whoever happens to be available and patient.
A useful change management plan is short and specific rather than long and generic.
An impact assessment by group, naming what changes for each and how significant it is.
A named sponsor and a named change lead, with time allocated rather than assumed.
The list of influential people to engage and how they are being involved.
A communication rhythm with dates and audiences rather than a set of intentions.
The training plan, separately budgeted and separately dated so it cannot be quietly compressed.
A support model for the first weeks, with names and hours. And the behavioural measures you will use afterwards to tell whether it worked.
Change management is not communication and it is not a workstream that runs alongside the project. It is the accumulation of decisions about who was involved, what was explained honestly, how training was built and how quickly problems were fixed.
If you are planning an implementation, the highest value investment available is involving the people who do the work in design. It costs nothing beyond their time and it changes the outcome more than any communication plan will.
If you are already live and struggling, start by cataloguing the workarounds, because each one is a specific and fixable problem rather than evidence of a general attitude.
Our pieces on user adoption and the adoption communication plan cover specific tactics.
If you would like help planning the change side of your project, get in touch.
