You can launch an ERP system on time and under budget and still miss the result you expected. I’ve seen it happen more than once. The system works fine. The people using it don’t change how they work, and the investment stalls.
The same thing happens with AI. You give your team access to a tool, and productivity barely moves.
Neither failure is a technology problem. It’s a gap in ERP change management, or in AI adoption, that looks a lot like it.
If you run a small or midsized professional services firm, don’t treat change management as a training and communication exercise you bolt on at the end of a project. It’s the work that turns a system or a tool into a new way of running your business. Here’s what that work actually involves, what to build before you approve a project, and how to know if it’s working.
Start with the business result, not the software
Before you approve an ERP or AI project, I want you to answer three questions.
- What business problem are you solving?
- What has to change to solve it?
- Who has to work differently as a result?
An ERP project might exist to improve project profitability reporting, replace spreadsheets, standardize project setup, strengthen revenue forecasting, improve resource planning, or cut manual finance work. An AI project might exist to reduce administrative work, speed up research, improve access to internal knowledge, draft routine documents, or improve consistency.
Bain & Company built its own ERP migration around a clear business case rather than treating it as an IT swap. Its finance and IT teams framed the project as a chance to simplify operations while supporting rapid growth, not just a system upgrade. Can your project team explain the business change behind your project that clearly? If they can’t, don’t expect your employees to understand why they should change how they work.
Assess what people will actually do differently
The core change management activity isn’t writing update emails. It’s assessing the impact of every major decision on the people who have to live with it.
For each significant process or system decision, I start with who it affects. I look at what those people do today versus what they will do after launch. Something starts, something stops, and responsibilities shift to someone else. Approvals change too. Then I check the skill gap: do people have what they need to do this, or not? Last, I ask whether anything could stop them from adopting the new process even if the system works perfectly.
Say your firm is moving project forecasting out of spreadsheets and into your ERP. You need to define who prepares the forecast, how often, what data your project managers maintain, how finance reviews it, whether spreadsheets remain acceptable anywhere, and who follows up when a forecast goes missing. That’s not a hypothetical exercise. It’s the work that shapes your training, your testing, and your adoption targets.
Put change management inside the project, not next to it
Change management in ERP implementation only works if it sits inside the project, not on its edge. Whoever leads adoption needs to be in the room for process design workshops, configuration reviews, testing, and cutover planning, because those meetings decide how your people will actually work. Join after those decisions are made, and all you can do is explain them. You can’t challenge whether they’ll hold up in practice.
Bain built a group of high-performing super-users from finance and IT specifically to catch and fix problems during its own implementation. Its leadership described the project as a change in employee behavior first, technology second. Microsoft’s case study on Speedy Services, a UK equipment hire firm, shows a similar pattern: a formal adoption program with a center of excellence and dedicated change manager, running alongside the Dynamics 365 rollout rather than after it.
Treat AI change management differently, not as an afterthought
AI raises questions that most ERP training plans never cover. Which AI uses have you approved? What can employees put into the tool? What must a person check before relying on the output? Who owns the outcome when the tool gets it wrong?
The UK Government’s Assist tool, a generative AI assistant for government communicators, is a useful reference point precisely because the team treated adoption as seriously as the build. Their rollout included dedicated training, risk assessment, and ongoing monitoring, and it shows in the numbers: over 200 government organizations using the tool, a 70% adoption rate, a 180% increase in AI training completion, and a 23% improvement in reported user confidence following targeted interventions.
Your firm is smaller. The questions are the same. Who checks the output? Who’s accountable when it’s wrong? What happens when someone uses the wrong tool for the job?
Measure behavior, not attendance
Training attendance doesn’t prove adoption. A login doesn’t prove your project managers stopped using spreadsheets. An AI license doesn’t prove anyone uses the tool safely or well.
Define success before go-live (what you’d expect to see if the project were working), then measure that:
- Process completion
- Use of legacy spreadsheets
- Data quality
- Forecast completion
- Approval compliance
- AI output review
- Time saved on defined tasks.
Bain tracked clear indicators throughout its rollout so the team could course-correct mid-project rather than find out at the end.
Before you approve your next ERP or AI project, ask your team who owns adoption, when you’ll assess role and process impacts, how employees will influence the design, and what you’ll measure after go-live. If the answers are all about announcements and training, the plan isn’t finished yet.
Learn More:
Frequently Asked Questions
ERP change management is the structured work of preparing your people for new processes, responsibilities, data requirements, and technology. It covers stakeholder engagement, change impact assessment, sponsorship, communication, training, readiness checks, go-live support, and adoption measurement, not just a training session at the end.
An ERP change manager identifies affected stakeholders, assesses role and process impacts, supports sponsors and managers through the transition, plans communication and training, runs readiness assessments, coordinates go-live support, and measures adoption after launch. The role works alongside the project manager, process owners, and business leaders, not underneath them.
Change management should start during planning and discovery, before major design decisions are locked in. Early involvement lets you identify impacts, engage managers, and influence process design while it’s still possible to change course, rather than after configuration is finished.
Measure whether employees follow the new process and whether the business result you expected actually shows up, not whether they attended training. Useful measures include process completion rates, continued use of legacy spreadsheets, data quality, approval compliance, and support ticket volume by role.
A complete plan includes your business objectives, a stakeholder analysis, a change impact assessment, a sponsor action plan, a communication plan, role-based training, readiness assessments, go-live support, adoption measures, and a post-launch reinforcement plan. The level of detail should match your firm’s size and the project’s risk.
AI change management needs more focus on human review, accountability, data protection, and approved use cases, because the tool’s output changes every time and the risk of misuse is less visible than a broken ERP workflow. Employees need clear rules on when they can use an AI output and what they must verify before they rely on it.
Employees usually resist because nobody explained what changes for them specifically, or because the new process asks them to give up a workaround that was actually working for their day-to-day job. Resistance is rarely about the software. It’s almost always about an unclear or unaddressed change in their role.
Manage AI change the same way you’d manage any operating-model change: define approved use cases, set clear review and accountability rules, train people on what the tool can and can’t do, and monitor actual usage and output quality after rollout, not just license activations.
A change impact assessment identifies which roles are affected by a specific process or system decision, what those people do today versus after launch, what responsibilities or approvals move, and what skills or support they’ll need to make the switch. It’s the input that shapes your training and communication plans, not a document you file away.
No. Training gives employees the skills to complete a task. Change management also covers leadership alignment, process impact, role clarity, resistance, readiness, accountability, and reinforcement after go-live. Training is one output of change management, not a substitute for it.
Contact us
If you’re contemplating a major ERP or AI change and want a second opinion on your adoption plan before you commit budget to it, contact us:
Want a straight read on whether your business is ready for AI?
Need a starting point for your communication plan?
Further Reading
Bain & Company, “With a Strategic ERP Migration to the Cloud, Bain Walks the Talk.” Bain’s own account of its ERP migration business case and change management approach.
SAP News Center, “Successful Change Management at Bain & Company.” Details on Bain’s superuser program and leadership’s framing of the project as a behavioral change initiative.
Microsoft Customer Stories, “Speedy Services creates a platform for further improvement with Dynamics 365.” Speedy Services’ change management and adoption program alongside its Dynamics 365 rollout.
GOV.UK, “The People Factor: A human-centred approach to scaling AI tools.” Adoption, training completion, and confidence figures for the UK Government’s Assist AI tool.
