ERP change management is the planned work of moving people from the old way of working to the new system: explaining why it is changing, giving each role the training and support it needs, naming owners for each process, and measuring whether work is actually being done in the ERP. Adoption is measured by transactions, not attendance at training.
Most ERP projects that disappoint do not fail because the software cannot do the job. They fail because purchase orders are still raised in email, stock is still tracked in a spreadsheet on someone's desktop, and month-end still depends on manual adjustments that bypass the system. This guide is about preventing that. It applies to packaged suites and to custom ERP software alike, although a custom build gives you one extra lever: you can change the screens to fit how people work, rather than only training people to fit the screens.
Why do staff resist a new ERP?
Staff rarely resist an ERP because they dislike change in general. They resist because the new system makes their own day harder, at least at first, and nobody has explained what they get in return.
The common causes are specific and fixable:
- More data entry for the person, benefit for someone else. A warehouse team asked to scan every movement sees extra clicks; the benefit (accurate stock) lands in purchasing and finance.
- Lost workarounds. Experienced staff have shortcuts in the old system or spreadsheet. The new process removes them before people trust its replacement.
- Fear of visible mistakes. In an ERP, an error posts to the ledger and other teams see it. In a spreadsheet, it stayed private.
- Training too early or too generic. A two-hour demo six weeks before go-live, covering every module, is forgotten by the first live day.
- No one to ask. When the first question on day one has no quick answer, people go back to the old way and stay there.
A change plan addresses each of these deliberately, rather than relying on a launch email.
Who needs to be involved? Build a stakeholder map
A stakeholder map lists every group affected by the ERP, how much the change affects them, how much influence they have, and what they need from the project. It turns "manage the change" into a list of named actions.
| Group | Impact of change | Influence | What they need | Main risk if ignored |
|---|---|---|---|---|
| Executive sponsor | Low daily, high accountability | High | Progress against business goals, decisions escalated early | Project loses priority when trade-offs appear |
| Finance team | High: new ledger, close process, reports | High | Early say on chart of accounts, reports and controls | Parallel spreadsheets for the close |
| Purchasing and stores | High: requisitions, receipts, stock moves | Medium | Fast screens, clear approval rules | Off-system orders, stock drift |
| Sales and customer service | Medium: orders, pricing, credit checks | Medium | Quick order entry, stock visibility | Orders kept in email or CRM only |
| Line managers | Medium: approvals, team dashboards | High locally | Approvals that work on mobile, clear limits | Approvals bottleneck, then bypassed |
| IT or systems team | High during project | Medium | Integration and support plan | Unsupported workarounds |
| External accountant or auditor | Low | Medium | Audit trail, reports at year end | Late surprises at audit |
Fill it in during the first weeks of the project, not at go-live. Revisit it at each phase; groups that looked low-impact sometimes turn out to carry a critical process.
What do ERP champions do?
Champions (sometimes called super users) are respected people inside each team who learn the system early, help shape it, and become the first point of help for their colleagues. They are the single most effective adoption measure because questions get answered by someone who knows the team's real work.
How to choose and use champions
- Pick credible people, not available people. The person colleagues already ask for help is the right choice, even if they are busy.
- Give them time. Agree with their manager how many hours per week they spend on the project during testing and the first month live. Without that agreement, the role exists only on paper.
- Involve them in design and testing. Champions should write and run user acceptance tests for their area (see our ERP UAT testing plan). People defend a process they helped shape.
- Give them a direct line to the project team so issues they raise are fixed or answered quickly, and they can tell colleagues what happened.
- One champion per team or site, plus a backup. Multi-site and multi-entity businesses need local champions in each location.
Who owns each process after go-live?
Every end-to-end process needs one named process owner in the business who decides how it works, approves changes and answers for its results. Without owners, every disagreement escalates to the project team, and after the project team leaves, nobody decides.
| Process | Typical owner | Owner decides |
|---|---|---|
| Procure-to-pay | Head of procurement or finance controller | Approval limits, supplier onboarding rules, three-way match tolerances |
| Order-to-cash | Head of sales operations or credit controller | Pricing rules, credit limits, invoicing timing |
| Record-to-report | Financial controller | Close calendar, journal approval, report definitions |
| Plan-to-produce | Operations or production manager | Bills of materials, routings, work order rules |
| Inventory | Warehouse or supply chain lead | Locations, counting cycle, adjustment approval |
| Hire-to-pay (if in scope) | HR or payroll lead | Employee master data, leave and pay rules |
Process ownership is separate from data ownership, although the same person often holds both. Our ERP data migration plan covers data owners in detail. Approval rules are one of the most common sources of friction; our approval workflow design guide explains how to set limits that people will not try to bypass.
If you are planning a new system and want adoption designed in from the start, our custom ERP development service builds screens and approval flows around each role's real work, starting with the processes that matter most.
How should ERP training be planned?
Train by role and by task, close to go-live, in the system people will use, with their own data. Generic module tours do not change behaviour.
A role-based training plan
- List roles, not departments. "Accounts payable clerk", "stores receiver", "approving manager" and "sales order desk" each need different content.
- For each role, list the five to ten tasks they do every week. These become the training modules. Rare tasks get a short written guide instead.
- Write task cards: one page per task, with the screens in order, what to check, and who to ask. Keep them in the system's help or a shared folder.
- Train in a copy of the system loaded with migrated data from the latest trial load, so people see their own customers, items and suppliers.
- Time it two to three weeks before go-live, with a short refresher in the final week. Earlier training is forgotten; later training leaves no time to fix confusion.
- Test understanding with real tasks, not a quiz: each trainee completes their weekly tasks in the training environment, and the champion signs them off.
- Plan for new joiners. After go-live, the task cards and champions become the onboarding path for new staff.
Managers need their own session on approvals, dashboards and what they should look for in the first weeks. A manager who keeps asking for the old spreadsheet report signals to the team that the old way is still acceptable.
How do you communicate an ERP change?
Explain the reason in terms each group cares about, tell people what changes for them and when, and keep telling them through go-live. A single kick-off announcement is not enough.
- The why, once and clearly, from the sponsor: what problem the business is solving, for example a slow month-end, stock that is never right, or growth the current tools cannot support.
- The what-changes-for-me, by role: a short note per team listing the tasks that move, the date, and what happens to the old tool.
- The timeline: training dates, the freeze window, go-live, and when the old system becomes read-only.
- The support route: who the champion is, how to log an issue, and the hours the support desk runs during hypercare.
- Wins after go-live: report early improvements honestly, such as an approval that now takes minutes, so people see the point.
How do you measure ERP adoption?
Measure what people do in the system, not whether they attended training. Adoption shows up as transactions created in the ERP, a falling number of off-system workarounds and a close that relies on fewer manual adjustments.
Adoption measures to track weekly for the first three months
| Measure | What it shows | Warning sign |
|---|---|---|
| Share of purchase orders raised in the ERP versus outside it | Procurement adoption | Invoices arriving with no matching PO |
| Active users per role versus licensed or expected users | Who is not logging in | A whole team with low activity |
| Transactions backdated or entered in batches | Whether work is recorded as it happens | Large batches on Friday or at month-end |
| Manual journals at month-end | Whether sub-ledgers are trusted | Rising count, or adjustments for the same issue each month |
| Stock adjustments after counts | Whether movements are recorded | Large or repeated adjustments in one area |
| Support tickets by type | Where people struggle | "How do I" tickets that do not fall after week two |
| Spreadsheets still in use for an in-scope process | Shadow systems | Reports rebuilt outside the ERP |
A custom system or a well-configured package can report most of these directly from its audit trail. Agree the measures with process owners before go-live and review them at a short weekly meeting. If you need a view of the numbers, our guide to designing business dashboards around KPIs covers how to pick a small set that drives action.
Illustrative scenario: a distributor where receiving kept slipping
This is an illustrative example, not a client case. A distributor goes live with a new ERP. Within three weeks, purchasing reports that stock on hand looks wrong. The adoption measures show the cause: goods receipts are being entered in a batch each evening from paper notes, so daytime stock is out of date and some receipts are missed.
The fix has three parts. The receiving screen is simplified to a scan and a quantity, on a handheld device at the dock. The warehouse champion runs a short session on the new screen with each shift. The process owner sets a rule that receipts are recorded before goods are put away, and the weekly review tracks the number of receipts entered more than an hour after delivery. The issue is a people-and-process problem first, and a screen design problem second; it is not solved by sending a reminder email.
ERP change management checklist
Before build
- Executive sponsor named, with time committed
- Stakeholder map completed and reviewed
- Process owners named for each end-to-end process
- Champions chosen per team and site, with agreed hours
During build and testing
- Champions involved in design reviews and user acceptance testing
- Role list and weekly task list per role completed
- Task cards written and checked by champions
- Communication plan by role, with dates
Before go-live
- Role-based training delivered two to three weeks before go-live, with migrated data
- Managers trained on approvals and dashboards
- Support route published: champions, issue log, hypercare hours
- Date set for the old system or spreadsheets to become read-only
- Adoption measures agreed, with a baseline where possible
After go-live
- Weekly adoption review with process owners
- Workarounds logged and either fixed in the system or formally retired
- Refresher sessions where tickets show confusion
- New-joiner onboarding using task cards and champions
When is heavy change management not needed?
A small business moving a handful of users from an accounting package to an ERP with similar workflows may need only role-based training and a named owner, not a formal programme. Over-engineering the change effort, with long surveys and slide decks, can delay go-live without improving adoption.
The opposite trade-off matters too. Change management cannot rescue a system that genuinely slows people down. If champions and adoption data show a task takes much longer in the new system, fix the design or configuration rather than training harder. That is one reason to judge working software early; our article on why ERP implementations fail covers how design and adoption problems compound.
How to start
Before your project begins, prepare three things: a list of roles and the tasks each does every week, the names of likely champions and process owners, and the processes where workarounds exist today. Our software requirements brief template helps you write these down so any supplier can respond to the same picture.
If you want to see how your team reacts to a new system before committing, Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so champions can test real screens with real tasks. Discuss your project with us, or read how we plan delivery on our ERP implementation services page.