An ERP implementation can go live on schedule, stay within budget, and still struggle six months later.
The software works. The integrations work. The data migrated successfully. But employees are still keeping side spreadsheets. A few departments have created their own workarounds. Some users only log in when they absolutely have to. And the people who were comfortable during training are suddenly unsure what to do when a real-world exception comes up.
That is not necessarily a software problem.
It is often a change management problem.
A strong ERP change management plan treats implementation as more than a technical rollout. It recognizes that employees have to change habits, workflows, responsibilities, and sometimes the way they think about their jobs.
Training matters. But training alone is not enough.
If you want the ERP to become the system your team actually uses, you need a plan for what happens before go-live, during the transition, and after the implementation team stops talking about launch day.
Here is what that plan should include.
One of the easiest mistakes to make is waiting until training begins to think about adoption.
By that point, many decisions have already been made. Processes have changed. Responsibilities may have shifted. Familiar shortcuts may disappear. Employees who have spent years doing their work one way are suddenly being asked to operate differently.
That change needs context.
Before go-live, identify which roles will be affected, which workflows are changing, where employees are likely to experience friction, and which old processes will need to disappear.
This is also the time to answer a question employees may not say out loud: why are we changing this?
People are far more likely to adopt a new process when they understand the problem it is meant to solve. If an employee believes the ERP is simply adding extra steps to something that already worked, no amount of software training will completely solve the resistance.
Change management has to connect the system to the business reason behind it. Maybe the old process requires duplicate entry. Maybe reporting takes days because data lives across multiple systems. Maybe departments are working from different versions of the same information.
Make that connection clear early.
A training session that walks through every menu, field, and button may technically cover the system. It does not necessarily prepare someone to do their job.
A better ERP training plan starts with the employee's actual responsibilities. What does someone in accounting need to do every day? What does the warehouse team need to complete? What does operations need to review? What does management need to approve or monitor?
Training should follow those workflows. Instead of saying "here are the functions available in this module," show users how a real task moves from beginning to end.
A warehouse employee does not need to understand every function inside the ERP. They need to know exactly how receiving works, what happens when quantities do not match, where an exception goes, and what to do when something outside the normal process happens.
Those details matter because employees rarely abandon a new system when everything goes perfectly. They abandon it when something unusual happens and the old workaround feels easier.
ERP training is often concentrated around go-live. That makes sense operationally, but it creates a problem. Employees are trying to absorb a large amount of information before they have enough real experience to understand which questions they should be asking.
A stronger approach uses several stages. Before launch, focus on the basic workflow and why the process is changing. Around go-live, focus on practical execution. After launch, return to the workflows with real questions, exceptions, and mistakes employees have encountered. Then reinforce the areas where adoption is weaker.
The goal is not simply to complete training. The goal is proficiency. Those are two very different things.
Someone can sit through a two-hour training session, check the completion box, and still have no confidence using the ERP the following week. That is why training completion should be treated as one indicator, not proof of adoption.
A professional services firm initially trained employees through a single four-hour session, supported by documentation and a helpdesk. After 60 days, user adoption was only 34%.
The company then introduced a more practical approach, including role-based training, regular support sessions, internal champions, and advanced workshops over 12 weeks.
The result? Adoption increased from 34% to 89%, and employees became more confident using the system.
The lesson is simple: completing training doesn't mean employees are ready. Real adoption requires ongoing support and practice.
When an employee runs into a problem, who do they ask?
If the answer is always the implementation consultant, IT team, or project manager, you may be creating a support bottleneck.
This is where internal ERP champions become valuable. A champion is someone inside a department who understands the new process well enough to help reinforce it. They do not need to become ERP experts. They do need to understand how the system affects their team's daily work.
You might have a champion in finance, another in operations, one in the warehouse, and another in customer service. Their role includes answering common process questions, helping teammates follow the new workflow, identifying recurring confusion, reporting friction back to the implementation team, and reinforcing the decision to use the ERP instead of old workarounds.
Champions also create something a training manual cannot: local trust. Employees may be more comfortable asking a colleague "how are you handling this?" than submitting a support ticket.
That feedback can also help leadership identify problems much faster. If three people in the same department are bypassing the same workflow, the issue may not be resistance. The workflow itself may need clarification, configuration changes, or additional training.
If leadership cannot measure adoption, it is very easy to assume everything is fine. The ERP is live. No major complaints are coming in. People attended training. So the implementation must be working.
Maybe.
But silence is not the same as adoption.
A useful ERP user adoption plan defines the signals you will watch after go-live. Those metrics will vary by organization, but they may include user activity, role-based training completion, time to proficiency, the percentage of key workflows completed inside the ERP rather than outside it, the number of manual workarounds still being used, support ticket patterns, error or rework rates, process compliance, and adoption rates by department.
The important part is not tracking every possible metric. It is choosing metrics that tell you whether the new process is becoming normal.
Login activity alone may not tell you much. Someone can log in every morning and still complete half of their real work in spreadsheets. A more useful question is whether the transactions that should happen inside the ERP are actually happening there. That gets much closer to real adoption.
One of the clearest warning signs after an ERP launch is the return of shadow systems.
A spreadsheet reappears. Someone maintains a separate customer list "just in case." A department starts tracking orders outside the ERP because it feels faster.
One workaround may not seem serious. But once a workaround becomes part of the team's routine, it becomes harder to remove.
This is why the first weeks and months after go-live matter so much.
Do not assume every workaround is employee resistance, either. Sometimes people create a workaround because they do not understand the correct process. Sometimes training missed an important scenario. Sometimes the ERP workflow needs adjustment. And sometimes the old habit is simply more comfortable.
Your change management process should help you determine which problem you are actually dealing with before deciding how to fix it.
A distribution company introduced a new warehouse management system, but employees struggled with the picking process. The system followed a standard workflow that didn't match the warehouse's actual layout.
After two weeks, productivity had dropped by 22%, and picking errors had tripled. The warehouse manager returned to the old picking method, using the new system mainly for data entry.
Instead of treating this as employee resistance, the team examined the actual workflow and adjusted the picking sequence to match the warehouse's three product zones.
Following those improvements, the company reported user adoption increasing from 37% to 96%, alongside improved productivity and accuracy.
The lesson? When employees return to old processes, the problem isn't always resistance. Sometimes the new system needs to fit the way work actually happens.
ERP adoption affects different leaders in different ways.
A CFO may care about reporting accuracy, close processes, data integrity, and whether teams are still maintaining offline financial information. A COO may focus on process consistency, operational visibility, bottlenecks, and whether departments are following the workflows the business designed. IT may be looking at support patterns, system usage, permissions, recurring technical questions, and configuration issues.
These views should connect. If IT sees a spike in support requests for one workflow while operations sees employees bypassing the same process, that tells you something.
The goal is not to create another giant dashboard nobody reads. It is to give the right people enough visibility to recognize adoption problems while they are still fixable.
A practical ERP change management plan can be thought of in three stages.
Stabilize. Before launch, remove as much uncertainty as possible. Identify affected roles. Document process changes. Look for likely resistance points. Clarify what old workflows will be retired. Give employees a clear picture of what is changing and why.
Catalyze. Around go-live, turn knowledge into behavior. Use role-based training. Activate internal champions. Create clear support channels. Reinforce the new workflows as employees begin working inside the ERP for real. Listen carefully during this stage. Questions and mistakes are data.
Maximize. After launch, measure what is actually happening. Where is adoption strong? Where are workarounds appearing? Which teams need additional training? Which processes need refinement? The implementation does not become successful simply because the system went live. It becomes successful when the organization can operate through it consistently.
Go-live gets a date on the project plan. Adoption does not. That is one reason it is so easy to underestimate.
Successful ERP implementation requires employees to stop relying on familiar processes and begin trusting a new way of working. That does not happen because someone attended a training session or received a login.
It happens through repetition, support, accountability, feedback, and measurement.
That is what a good ERP change management plan is designed to create.
If you are preparing for an ERP implementation, the best time to think about adoption is before your team has a reason to resist it. Build the training cadence. Identify your champions. Define the metrics you will watch. Decide how you will respond when someone starts creating workarounds.
The software is only one part of implementation. The other part is making sure the business knows how to work differently once the software arrives.
If your organization is preparing for an ERP implementation and wants to build adoption into the plan from the beginning, a Catalyst360 Discovery Session helps you identify the people, process, training, and measurement requirements before they become post-launch problems.
Because the teams that adopt well aren't the ones with the best training materials. They're the ones whose implementation plan treated change management as seriously as configuration.
Schedule Your Discovery Session →
See how PTP approaches ERP implementation and adoption →