An ERP changes the way people do their jobs. It changes what they type, who they ask for approval, which screen they check and sometimes how they feel about their own work. The software can be configured well and still fail if the people who use it are not prepared. ERP change management is the practical work that prepares them.
This article covers the people side of an ERP project: mapping the change role by role, choosing champions, communicating in ways people can use, training by role and task, supporting the first weeks and keeping support useful once the launch has settled. It is written for managers and project leads in UK small and mid-sized businesses.
The suggestions are general. The size of the change depends on how far your processes move, how many people are affected and how much they already rely on systems.
ERP change management starts with mapping the change role by role
Before planning communication or training, work out what changes for each group of users. A generic message that the system is changing tells people very little. A clear statement of what changes in their role tells them what to learn and what to stop doing.
What changes for each person
For each role, list the tasks that will change, the new steps, the tasks that disappear and the screens each person will use. Include the people who approve work, not only those who enter it. Approvers often feel the change when they are asked to review something they used to see in an email.
Capture the answers in a short list for each role:
- Tasks that stop completely
- New steps and the screens they use
- Approvals they give, and who they now hand over to
- Information they used to gather by hand that now appears in the system
Gains for some, lost shortcuts for others
Some people gain straight away, because the new system removes a task they disliked. Others lose a shortcut they relied on, such as a private spreadsheet that answered their questions. Plan for both groups. The second group usually needs the most explanation and the most practical help.
Champions: people who make the change credible
A champion is a colleague who understands the work, is trusted by others and helps them through the change. Champions do not replace the project team or management. Their value is that people ask them questions before they go to the project manager.
Choosing champions from the floor
Pick champions for their credibility with the people they work alongside, not for their seniority. Someone who handles daily orders or invoices will know where the new process is likely to catch people out. Confirm that each champion is willing to take the role, because reluctant volunteers rarely help.
What a champion is asked to do, and what they are not
A champion can test training, collect questions, report repeated problems and encourage colleagues to try the new process. A champion should not be asked to change the configuration, make project decisions or carry the whole support load alone. Write the role down so it stays manageable.
Protecting time for champions
Champions need time in their diary for training, testing and answering questions. If the role is simply added on top of a full workload, it tends to fade quickly. Agree the hours with each champion's line manager at the start of the project, and review them when the workload changes.
Communication people can actually use
Many people skim project updates. They want to know what is happening to them, when it will happen and what they should do in the meantime. Communication that answers those three questions is more useful than frequent announcements that do not.
A simple message calendar
Plan messages in advance: what is coming, to whom, through which channel and from whom. Keep the rhythm steady, so people learn to expect updates rather than dread them. A short regular note, plus a message before each milestone that affects someone's work, is often enough.
Saying what is not changing
People worry about what they might lose as well as what they will gain. State clearly which parts of their work are staying the same, such as the customers they serve, the products they handle or the approval limits that remain in place. Clear boundaries calm rumours faster than general reassurance does.
A channel for questions and a visible answer log
Give people one place to ask questions, such as a shared mailbox, a chat channel or a short form, and publish the answers in a log they can search. A visible log means a question is answered once rather than repeated by several people. Check that the most common questions get fast replies.
Training by role and by task
Generic training that walks through every screen tends to be forgotten quickly. Training works better when it follows the tasks people perform, in the order they perform them, using examples that look like their own work.
A training matrix that matches the roles
Build a matrix that lists each role against the tasks it performs, then decide what each role must learn before go-live and what can wait. Many users need a small number of core tasks done well. Approvers and administrators need a wider view of how the process links together.
Practice environments with realistic data
People learn by doing. Provide a training environment with realistic but non-live data, such as typical orders, common exceptions and products the team already knows. Practice should happen before anyone is given live access, and it should cover the mistakes people are most likely to make.
If training data includes personal details, UK GDPR still applies, so agree how that data is protected and take advice for your own situation.
Short refreshers and quick reference
After the first session, people need short refreshers at the moment they need them: a one-page guide for each core task, a recorded walkthrough of a single process or a brief session before month-end. Keep each one focused on one task. Long documents tend to sit unread in a shared folder.
Go-live support: being present where the work happens
The first weeks after go-live decide whether the new system is accepted or quietly bypassed. People are most likely to fall back on old habits when they feel unsure and nobody is nearby to help.
Floor support and a dedicated channel
Arrange people who can sit with users during the first days, whether they are project staff, champions or a support partner. Keep a channel open for urgent questions, with named people who answer at set times. Make it clear who to contact for what.
Short daily check-ins in the early weeks
A short stand-up each morning during the first weeks lets the team spot patterns quickly, such as a step that confuses several people or a report nobody can find. Record each issue with an owner, and close it visibly once it is resolved.
Triage: fix, work around or explain
Sort each issue into one of three groups. Some need a fix, such as a broken link or a wrong default. Some need a workaround for now, with a date for the proper solution. Others are a training gap, which is solved by explaining the process again. Mixing these up wastes effort and frustrates users.
Support after go-live: the long tail
Once the launch settles, support changes character. Urgent questions give way to requests for changes, new starters who need training and questions about parts of the system that were rarely used before.
A support model with clear ownership
Decide who handles first-line questions, who deals with system faults and who decides on changes. Write the model down with contact points and response expectations. Without it, questions go to whoever is nearest, and the project team ends up doing routine support indefinitely.
A knowledge base written from real questions
Create short guides from the questions people actually asked during go-live, using the words they used rather than the product's menu names. Review the list each month and retire any guide that no longer matches the system.
New starters, changes and refreshers
Build training into onboarding, so new starters learn the system in their first week. Plan a refresher whenever a process changes, and check that people who move between roles receive the training their new role needs. This is easy to overlook, and it is often where habits start to drift.
Measuring ERP change management: adoption without guesswork
Adoption is not a feeling. It shows in the data and in the workarounds people still use. The aim is to see where the new process is working and where people have quietly gone back to the old way.
Signs of use that matter
Look at whether transactions are entered on time, whether approvals happen inside the system and whether reports are pulled from it rather than rebuilt by hand. Those signs say more than attendance at training, which only shows that people turned up.
Listening to workarounds
When a workaround appears, ask why it exists. It may point to a missing field, a slow screen or a rule that does not match how the work is done. Treat workarounds as feedback on the design, not as a failure by the people who created them.
A review once things settle
Plan a short review about two or three months after go-live, with champions and process owners. Compare what was planned with what happens, list the changes that matter and agree what to fix next. A review held too early only catches first-week problems.
FAQ
What is ERP change management?
ERP change management is the planning and support work that helps people adopt a new enterprise resource planning system and the processes that come with it. It covers communication, training, champions, support and the measurement of adoption. Treating the people side as part of the project from the start works better than adding it at the end.
Who should be a champion during an ERP project?
Champions should be trusted colleagues from the teams that will use the system, chosen for their credibility rather than their seniority. They help colleagues, test training and report repeated problems. The role needs protected time and a clear description of what it does not include.
How should ERP training be planned?
Plan training around roles and tasks, using a practice environment that looks like real work. Schedule it close to go-live, so people use the skills soon after learning them. Follow up with short refreshers and quick reference guides at the points where people need them.
How long should support continue after an ERP go-live?
There is no single answer, because it depends on how much has changed and how the business works. The most intensive support usually covers the first few weeks, after which a steady model with named owners should take over. Plan that handover before the launch, not during it.
How can a business tell whether an ERP is being adopted?
Look at what people do in the system, such as whether transactions are recorded on time, approvals happen inside it and reports come from it. Watch for workarounds, which show where the design or the training needs attention. Attendance at training is not, on its own, evidence of adoption.
Do staff need training if the ERP looks simple?
Yes, although the amount varies. Even simple screens can hide different rules for different roles, and people need to learn when to use the system as well as how. Short, practical sessions on real tasks are usually enough for straightforward roles.
Final thought
ERP change management decides whether the software is used the way it was designed. It is practical work: understanding what changes for each role, choosing champions with care, communicating clearly, training on real tasks and staying close to people after the launch.
Good plans tend to share a few habits. They start early, they say what is staying the same as well as what is changing, and they treat questions as design feedback. None of this needs special tools. It needs time in the plan and people trusted to speak for the work.
Mirex Agency works with UK small and mid-sized businesses on ERP projects, including the people side of change. If you want to shape the training and support around your team, write to hello@mirexagency.com.
