I have watched a go-live go off without a single technical defect and still fail. The integrations held. The data reconciled. The cutover ran on schedule, and by every measure the technical team would recognize, it was a success. Two weeks later, finance was closing the month in spreadsheets, the warehouse had gone back to its old workarounds, and the help desk was drowning. The system worked. The people weren't ready.
That gap is where ERP value is actually won or lost. You can spend two years and tens of millions of dollars building exactly the right system, and if the people who have to use it on Monday morning don't trust it or don't know how, you have bought an expensive way to do what you were already doing. Change management is not the soft part of the program. It is the part that determines whether any of the rest of it pays off.
What change management is not
Let me be blunt about how this usually gets done, because most of what passes for change management on these programs is theater. It is a set of posters in the break room. It is a launch email from the CIO that nobody finishes reading. It is a training video pushed out the week before go-live, watched at 1.5x speed with the sound off so someone can mark a box that says ninety percent completed.
None of that changes behavior. It exists so the program can report that change management happened, not so that change actually occurred. When you treat it as a checkbox, it does not fail loudly, it fails quietly. Adoption numbers look fine on paper while people route around the system in the background, and you don't find out until the quarter closes wrong.
Done properly, change management is not a workstream you bolt on at the end. It is a discipline that runs the length of the program: understanding who is affected, preparing them honestly, and staying with them well past the day the system turns on.
Sponsorship is not a logo on a slide
The single biggest predictor of whether a program is adopted is visible, active executive sponsorship. Not a name on the steering committee. Not a quote in the kickoff deck. Active, meaning the sponsor shows up, uses the language, makes the hard calls, and holds their own leadership accountable for the change in their part of the business.
Change cascades from the top or it does not cascade at all. People take their cue from their direct manager, and that manager takes the cue from theirs, all the way up. If a division head privately signals that the old way is fine for now, their entire organization hears it, and no amount of training reaches them. I have seen one skeptical executive quietly sink a deployment that the project team did everything else right.
So when a sponsor tells me they are fully behind the program, my next question is what they are personally willing to do, which meetings they will attend, which exceptions they will refuse to grant, which of their peers they will challenge. If the answer is vague, the sponsorship is decorative, and I would rather know that early.
Know exactly who you are changing
You cannot prepare people you have not bothered to understand. Real stakeholder analysis is unglamorous and it is the work: mapping who is affected, how much their actual day changes, and where the resistance genuinely sits, which is rarely where the org chart suggests.
A readiness assessment answers the questions that matter before you commit to a date. The change is not uniform. For some people it is a new button on a familiar screen; for others it is a complete redefinition of how they do their job, and pretending those are the same is how you lose the second group.
- Who is affected, and how much their day actually changes, a few clicks for one team, a new operating reality for another.
- Where the resistance really sits, often the long-tenured expert whose hard-won mastery of the old system is about to be reset to zero.
- Why they are resisting, fear of looking incompetent, a workload that is already at capacity, or a past program that promised the same things and burned them.
That last point is worth dwelling on. Most resistance is not irrational. It is a sensible response to a real cost the person sees clearly and the program has not acknowledged. Name the cost honestly and you can usually work with it. Pretend it isn't there and it goes underground.
Training that actually sticks
Generic training delivered once is the most reliable way to waste a training budget. A vendor deck walked through in a conference room, far from go-live, covering features in the abstract, people forget it before they ever need it, and it teaches them nothing about their own job.
Training that sticks is role-based and hands-on, in the real system, on the data and the tasks the person will actually face. It happens close enough to go-live that the knowledge is still warm when they need it. And, the part almost everyone skips, it is reinforced afterward, because the questions people have on day three are the ones that determine whether they keep going or quietly give up.
You can ship a technically perfect system and still fail. If nobody on the floor trusts it or knows how to use it, you haven't delivered a thing, you've just made everyone's job harder and called it progress.
Build the support structure for after go-live with the same seriousness you build the system. Floor support in the first weeks, super-users embedded in each team, a clear and fast path to get an answer. The first time someone hits a wall and can't find help, they stop trusting the system, and trust is far harder to win back than it was to lose.
Measure adoption, don't assume it
Here is the discipline most programs lack: they declare victory at go-live and stop looking. Go-live is the start of the part that matters, not the finish line. Whether the change actually landed is a question you answer with evidence, not optimism.
The evidence is there if you look. Usage data tells you who is in the system and who is not. Support patterns tell you where people are stuck. And the workarounds people invent, the shadow spreadsheet, the offline log, the one person everyone quietly asks instead of using the tool, are the clearest signal you will ever get that the change has not taken. People build workarounds when the official path is failing them. Treat those as the most honest feedback the program produces, not as a compliance problem to stamp out.
Then sustain it. Adoption is not a moment; it decays without attention. New hires arrive who never saw the old way and never got the training. Processes drift. Without someone owning adoption past go-live, the organization slowly reverts toward whatever felt comfortable, and the value you measured at launch quietly leaks away over the following year.
The part worth leading deliberately
The technology, for all the attention it gets, is the easy part. It is bounded, it is testable, and there are plenty of people who can build it well. The hard part, the real program, is getting thousands of people to work differently, willingly, and to keep doing it after the consultants have gone home.
That is not a side effect of a good implementation. It is the implementation. Treat it as the thing you are actually here to do, and lead it as deliberately as you would lead anything else you have staked your reputation on. Everything else is just software.