Every ERP program I’ve been part of eventually reaches the same fork in the road, usually early, usually in a procurement meeting. Someone asks whether change management should be bundled into the system integrator’s statement of work or contracted separately. It sounds like a purchasing decision. It’s actually one of the most consequential governance choices you’ll make on the entire program.
My strong recommendation, after watching this play out on both sides, is to keep your organizational change management (OCM) partner independent from the firm implementing your ERP. Not because system integrators are bad at what they do, but because the two roles are pulling toward different definitions of success, and you want both tensions represented at your steering committee table.
The incentives don’t point the same direction
An ERP implementer is measured, and paid, on delivery. Configuration complete, testing passed, go-live hit, hypercare closed. Those are technical milestones, and a good SI will move heaven and earth to reach them. That’s exactly what you’re hiring them for.
Change management is measured on something the SI’s contract usually doesn’t touch: whether people actually adopt the system, whether productivity recovers on the other side of go-live, and whether the business realizes the value that justified the investment in the first place. Those outcomes show up months after the implementer’s team has rolled off.
When the same firm owns both, the technical timeline almost always wins. It has to — that’s where the contractual pain lives. And when a program slips, as programs do, the first budget that gets quietly reallocated is the “soft” one. I’ve watched adoption workstreams get thinned to protect a go-live date more than once. If OCM sits under the SI, no one at the table is fighting for it.
You need someone who can tell you the implementation is the problem
This is the argument I care about most. A big part of what good change management does is surface the truth: where adoption is stalling, where end users are confused, where a process redesign isn’t landing. Sometimes the honest finding is that the training gap exists because the configuration doesn’t match how the business actually works — in other words, the implementer’s own decisions are part of the issue.
An OCM team that reports up through the system integrator is being asked to grade its employer’s homework. Even with the best people and the best intentions, that’s a structural conflict. Independent change partners will put uncomfortable findings in the status report. Embedded ones tend to soften them. When you’re spending eight figures, you want the uncomfortable version.
They are genuinely different disciplines
ERP implementation is a technical and functional craft. Change management is a behavioral one — stakeholder analysis, communications, adoption measurement, training design, leadership alignment. They require different skills and different types of people.
When OCM is bundled, it too often becomes a thin layer staffed by whoever was available, delivering templated communications and a generic training deck. Separating the contract forces change management to stand on its own merits and be resourced by people who do this for a living. You get a partner whose entire reputation rides on adoption, not one for whom it’s a line item.
Separation creates healthy accountability
Independent partners give your program a genuine set of checks and balances. Two vendors, two perspectives, two independent read-outs on program health. When the SI says the build is on track and the change partner says the business isn’t ready, that disagreement is a feature, not a failure — it’s exactly the signal your steering committee needs, and you’d never see it if both reports came from the same firm.
The obvious objection — and how to handle it
The strongest case for bundling is coordination. One vendor, one plan, one throat to choke, no finger-pointing when things go sideways. It’s a fair concern, and separation done carelessly can absolutely create seams.
But you manage that with governance, not by collapsing the roles. A few things that work:
- Put both partners under one integrated program plan and one master schedule, so change milestones are tied to technical ones rather than floating alongside them.
- Make the change partner accountable to the business sponsor, not to the SI’s program director.
- Build joint touchpoints into the cadence — shared design sessions, shared readiness criteria, a shared definition of “go-live ready” that includes adoption, not just cutover.
- Be explicit in both contracts that coordination is expected, and name the integration points.
Done well, you get the coordination benefits without surrendering the independent voice.
The bottom line
Bundling change management into your ERP implementation looks cheaper and simpler on the procurement spreadsheet. In practice, it quietly subordinates adoption to the technical timeline and removes the one partner whose job is to tell you the unvarnished truth about whether your people are coming with you.
Your ERP investment doesn’t pay off when the system goes live. It pays off when the organization actually uses it. Give that outcome its own advocate — with its own contract, its own budget, and its own reporting line.
If you’ve run these programs, I’d be curious where you’ve landed: bundled, separate, or somewhere in between. What tipped the decision for you?