An ERP implementation can meet its technical milestones and still fail to change how work gets done. Employees may continue using spreadsheets, managers may distrust reports, and teams may create workarounds when the new system does not fit their daily processes. These are not simply training problems. They are signs that the organisation has not managed the operational change around the technology.
ERP change management is the structured work of preparing people, processes and leadership for a new way of operating. It should be proportionate to the size and risk of the transformation: a focused finance-system upgrade does not need the same programme as a multi-country ERP replacement affecting procurement, manufacturing, warehousing and customer service.
Why ERP projects need a change management plan
ERP changes often alter approvals, data entry responsibilities, segregation of duties, reporting definitions, inventory transactions and the timing of handoffs between departments. A process that previously relied on a local spreadsheet may become a controlled workflow. A warehouse operator may need to scan each movement. A finance team may need to close periods using different controls.
If those changes are not understood before go-live, users can experience delays, managers may see inconsistent data, and the project team can spend its stabilisation period answering questions that should have been addressed during design and training. Microsoft’s implementation guidance stresses aligning change management with the organisation and the specific risks of the business application project rather than applying a generic programme: Microsoft Dynamics 365 change management guidance.
1. Identify who is affected and what will change
Start with an impact assessment by role, location and process. Do not limit the exercise to people who will log in to the ERP. Executives who approve budgets, suppliers who submit invoices, customers who receive order updates and support teams who handle exceptions may all be affected.
| Group | Potential change | Preparation needed |
|---|---|---|
| Finance | Chart of accounts, close process, approvals and reporting | Control walkthroughs, close simulations and reconciliations |
| Procurement | Supplier onboarding, purchase approvals and receiving | Role-based process training and exception scenarios |
| Warehouse | Scanning, locations, picking, put-away and stock adjustments | Hands-on practice using real devices and warehouse scenarios |
| Sales and customer service | Order entry, availability checks, pricing and returns | End-to-end order scenarios and customer communication guidance |
| Managers | Dashboards, approvals, accountability and team performance | Decision-focused reporting and management routines |
For each group, document the current process, future process, expected benefit, likely friction, training need and accountable process owner. This creates a practical basis for communication and readiness planning.
2. Establish visible sponsorship and process ownership
A project manager cannot substitute for an executive sponsor who explains why the organisation is changing. Sponsors should communicate the business outcomes, make decisions when departments disagree, provide resources for training and reinforce the new operating model after launch.
Appoint business process owners for critical workflows such as procure-to-pay, order-to-cash, record-to-report, plan-to-produce and inventory management. These owners should approve process design, resolve policy questions, sign off user acceptance testing and own performance after go-live. Local champions can support colleagues, but they should not become an informal substitute for accountable process ownership.
3. Communicate the reason for change, not just the launch date
Communication should answer four questions: why the organisation is changing, what will be different, what each employee needs to do and where help will be available. A launch announcement or monthly newsletter is not enough. Communication should follow project milestones and be tailored to the audience.
- At project initiation, explain the business problem and intended outcomes.
- During design, share which processes will change and invite structured feedback.
- Before testing, explain what users need to validate and how defects will be recorded.
- Before go-live, communicate cutover dates, downtime, new responsibilities and support channels.
- After launch, publish known issues, fixes, adoption progress and process reminders.
Be candid about what is not yet decided. Overpromising that the new system will remove every manual task damages trust when users encounter exceptions.
4. Build role-based training around real work
Training should teach people how to complete their responsibilities in the new process, not simply how to navigate menus. Use realistic scenarios and the data, terminology and approval paths employees will encounter. A warehouse picker needs practical device training; a finance controller needs to understand close controls and exception handling.
Use a blended approach where appropriate: instructor-led sessions for complex workflows, short videos for repeatable tasks, sandbox exercises for hands-on practice, job aids for infrequent activities and manager briefings for decision-makers. Train trainers and support teams early enough that they can help during user acceptance testing and cutover.
Measure competence through task completion, not attendance alone. Ask users to complete key scenarios without step-by-step assistance and record where they get stuck. Provide additional support for high-risk roles and processes.
5. Involve users in testing and readiness decisions
User acceptance testing is one of the best opportunities to expose the gap between a configured system and actual business work. Involve representatives from each affected function and location. Test normal transactions, exceptions, approvals, month-end or period-end activities, and cross-functional handoffs.
Readiness should be based on evidence. Confirm that critical scenarios pass, data is sufficiently accurate, users have access, training is complete for high-risk roles, support coverage is staffed and unresolved defects have agreed workarounds or go-live impact decisions.
6. Measure adoption after go-live
Do not use logins as the only measure of adoption. A user can sign in every day and still maintain a parallel spreadsheet or enter low-quality data. Combine system usage with operational outcomes and process compliance.
| Measure | What it reveals | Example signal |
|---|---|---|
| Transaction completion | Whether users are completing core work in the ERP | Share of purchase orders or receipts processed in-system |
| Process cycle time | Whether new workflows improve execution | Requisition-to-approval or order-to-ship time |
| Data quality | Whether users enter usable and complete information | Missing mandatory fields, duplicate suppliers or inventory exceptions |
| Workarounds | Whether teams still rely on parallel processes | Shadow spreadsheets or manual re-entry volumes |
| Support demand | Where users need help or system design needs attention | Ticket themes, repeat incidents and time to resolution |
| Business outcomes | Whether adoption is translating into value | Close duration, inventory accuracy or service-level performance |
Establish a baseline before implementation and set targets that reflect the business case. Review the measures by function and location; an overall adoption score can hide a department that is struggling.
7. Plan for hypercare and reinforce new behaviours
Go-live is the start of operational ownership, not the end of change management. Create a hypercare model with named business and technical owners, clear escalation routes, daily issue triage and a way to distinguish defects from training gaps or process decisions. Track recurring questions and convert them into updated job aids or targeted refresher sessions.
Microsoft’s transition guidance highlights knowledge transfer, training for the support organisation and continued measurement of adoption and use after deployment: transition and handover guidance. Make sure the internal support team can handle routine configuration, user access, reporting and process questions when the implementation partner steps back.
ERP change management plan: practical deliverables
- Stakeholder and role-impact assessment.
- Current-state and future-state process maps.
- Named executive sponsor and business process owners.
- Audience-specific communication plan and feedback channel.
- Role-based training matrix, materials and competence checks.
- User acceptance testing participation and readiness criteria.
- Go-live support model, escalation paths and knowledge transfer.
- Adoption dashboard with baseline, targets and review cadence.
How much should an organisation spend on change management?
There is no reliable universal percentage of ERP project cost that fits every organisation. The right investment depends on the number of affected users, locations, process changes, regulatory exposure, operational criticality and maturity of internal training and communications. Underinvesting can increase workarounds, support demand and delayed benefits; overengineering a large programme for a narrow change can waste budget.
Estimate effort by deliverable and risk: stakeholder analysis, process ownership, communications, training development, backfill for employees attending training, testing participation, local champions and post-launch reinforcement. Include business-user time in the project TCO rather than treating it as free capacity.
Common mistakes to avoid
- Starting training only a few days before go-live.
- Measuring attendance instead of task competence and process adoption.
- Assuming the implementation partner owns long-term business process decisions.
- Using the same communication for executives, warehouse staff and finance users.
- Ignoring local workarounds because system usage reports look healthy.
- Ending change management when the system goes live.
Final recommendation
Make change management part of the ERP delivery plan from initiation through stabilisation. Assign process owners, involve real users in design and testing, train against actual work, and measure whether business processes are improving. For related planning, read our guides to ERP implementation challenges, ERP implementation cost and TCO and ERP data migration readiness.
Author: Micah Phillips
