ERP User Adoption Is Decided Long Before Go-Live: A Client-Side View
In short Poor ERP user adoption is almost always a governance failure surfacing late, not user resistance. What determines it is decided in the first weeks of a project: who owns change, whose input shapes the design, and what training is actually scoped to do. If you only want the practical part, the questions worth asking before kickoff are at the end.
Most ERP projects find out they have a change management problem at the same moment. Three or four weeks after go-live, the support queue isn't clearing, spreadsheets have quietly reappeared alongside the new system, and month-end doesn't reconcile with anything anyone recognises. Somebody says the users are resisting, and a refresher training session gets booked.
Very little of that is about the users. When people work around a new system they are usually telling you something true about it: that it doesn't fit the job as they actually do it, that nobody asked them before the process was designed, or that they were trained in a demo environment bearing no resemblance to a real month-end. Those are design and governance outcomes, decided months earlier by people who weren't thinking about adoption at the time.
So the useful question isn't how to overcome resistance. It's what the project did, early on, that made resistance the rational response. On a Microsoft Dynamics 365 Finance & Operations implementation that comes down to three things: who owns the change workstream, how impact was assessed, and what training was scoped to achieve.
Who owns change management on your project?
Worth asking out loud at kickoff, because on most projects the answer is ambiguous in a way that costs money later.
Implementation partners generally include change management in scope, and their version of it is real work done by capable people. The difficulty isn't quality. It's that the scope is built around the deployment, and its measure of success is that the system goes live on the agreed date with users able to complete the transactions the system requires.
That's a legitimate objective. It isn't the same as yours. Yours is that the business runs better afterwards - that finance closes the period faster than before, that the warehouse doesn't need two people to do what one person did, that the investment returns something. A partner can hit their objective in full while yours is still some distance away, and the contract will show the work as delivered.
The gap between those two objectives is where client-side change management lives. In practice it resolves into one of three arrangements:
Partner-led, client-reviewed. Workable when the client genuinely has capacity to review critically - meaning someone senior enough to say the training plan is inadequate and make it stick, not someone attending a fortnightly call to receive a status update.
Client-led, partner-supported. The best outcomes in our view, and the hardest to staff, because it needs someone who understands both the business and the platform and has time to do the job properly.
Genuinely shared, clearly split. Workable only where the split is written down at role level rather than described as collaboration. Ambiguity here doesn't surface until something goes wrong, at which point it surfaces as a dispute.
What doesn't work is leaving it undefined and assuming it's covered. Change management is the workstream most likely to be quietly deprioritised when a project runs late, precisely because nobody's contract says it can't be.
What the frameworks tell you
ADKAR, the Change Curve and Lewin's model come up in every change discussion, usually as a list of things a project says it is using. They're more useful as diagnostic instruments, each answering a different question.
ADKAR tells you where someone has stalled. Most projects start at Knowledge - they train people - because that's the step with an obvious deliverable attached. If Awareness and Desire were skipped, the training lands on people who don't understand why any of this is happening. The Change Curve tells you the post-go-live dip is coming, so you resource for it rather than panicking through it. Lewin tells you whether anything was genuinely unfrozen, or whether this is a new system running old processes and old incentives.
All three are diagnostic. A completed ADKAR assessment filed in SharePoint isn't change management. Using it in week six to find that two departments never got past Awareness is.
We go deeper on applying these models on a live rollout in Change Management: de-risking your ERP implementation.
Impact assessment happens at role level
Most impact assessments are too coarse to be useful. "Finance is affected" tells you nothing you didn't already know. The question is what changes for a specific person doing a specific job on a specific day.
An accounts payable clerk who matched invoices against a paper purchase order and now enters vendor invoices that the system checks against both the purchase order and the product receipt, within set price tolerances, has had their job redesigned, not their software updated. A budget holder whose approvals arrived by email and now come through a workflow hierarchy has lost the ability to nudge things through informally, which they will notice on day one.
Two things worth watching. The roles that change most are frequently not the ones best represented on the project - teams get staffed from whoever can be released, and the team leader who has been in post fifteen years and knows every exception is usually both the person you most need in design workshops and the person the business is most reluctant to spare. And impact lands unevenly across sites: in a multi-country rollout, a template built around the largest entity routinely leaves smaller sites absorbing far more change than anyone budgeted for.
Training the software is not the same as training the job
Standard implementation training teaches transactions: here is the screen, here are the fields, here is the sequence. It's delivered in a sandbox with clean demonstration data, in a quiet room, by someone who knows the answer.
Real work is none of those things. It's the exception the process doesn't cover, at four o'clock on the last day of the month, with data that came across from the legacy system imperfectly, while three colleagues wait on the outcome. People taught only the click path have nothing to fall back on when the path doesn't apply - and workarounds established in the first fortnight are remarkably durable.
Training that holds up teaches the process rather than just the system, uses a realistic copy of the organisation's own data with sensitive values anonymised, and deliberately covers exceptions and error correction. Confidence comes less from completing a transaction correctly than from knowing how to recover when it goes wrong.
Change management doesn't end at go-live
Most change plans are funded to go-live and hypercare, then stop. Adoption problems mostly emerge after that, once the floorwalkers have gone and people are working an unsupported first full cycle.
This is where the decision about internal capability gets made, usually by default rather than deliberately. The organisation finds it still needs help, and the path of least resistance is to extend the contractors already on site who already know the system. It's quick, easy to approve, and postpones the problem indefinitely - capability stays outside the business, and the cost recurs every year.
The alternative takes more planning and less money over time: identify the people who will own the system and the processes, name them early, involve them in design rather than only in testing, and protect their time genuinely rather than nominally. A Centre of Excellence is what that looks like done properly - a small internal group owning process, configuration standards, training and continuous improvement, with external specialists brought in for specific work rather than retained to keep the lights on.
Microsoft's Success by Design framework, which grew out of its FastTrack programme, maps an implementation across five phases: Discover, Initiate, Implement, Prepare and Operate. Operate gets the least attention at planning time and determines most of the eventual return.
Questions worth asking before kickoff
If you are sponsoring a Dynamics 365 implementation, these are the questions we'd want answered before the project starts rather than after:
Who owns change management, by name, and is it written into the statement of work or assumed?
What does the implementation partner's change scope actually include, and where does it stop?
Which roles change most, and are those people in the design workshops or only in testing?
What does training use for data, and does it cover exceptions and error correction?
Who owns the system in this organisation twelve months after go-live, and do they know yet?
What is budgeted for the period after hypercare ends?
If several of those don't have clear answers, that's worth addressing now. It is considerably cheaper than addressing it after go-live.
Where we fit
ERP Advisers works on the client side of Dynamics 365 implementations. We are not a reseller, an implementation partner or a recruiter, and we have no product to sell you. We work either between you and your implementation partner or embedded within your own team, with one objective: that the project delivers what you commissioned, and that your organisation can run it afterwards.
If you're planning a Dynamics 365 Finance & Operations implementation, or you're partway through one and the change workstream has started to feel thin, we're happy to talk it through.
Comments