Change Management Is the ERP Implementation Phase That Eats All the Other Phases

If you have been implementing ERPs for a decade, you have seen this movie.

You deliver a technically clean D365 Finance and Supply Chain implementation. Performance is fine. Integrations work. Security is tight. The system does what it is supposed to do.

Then you go live and the business quietly votes “no” with their behavior:

• Spreadsheet side quests multiply.

• Workarounds become the real process.

• The help desk becomes the new operations team.

• And someone, somewhere, asks if we can “make it work like the old system.”

That is why change management is not a “phase.” It is the operating system your whole implementation runs on. Microsoft’s own implementation guidance calls change management fundamental, right alongside process focus and ALM.

Also, the data is brutally consistent: Prosci reports that projects with excellent change management met or exceeded objectives far more often than those with poor change management (their published figures include 88% vs 13% on meeting or exceeding objectives).

So if you want the ERP to win, you have to build the conditions for humans to win.

And yes, this is the part where DynamicsDad makes the dad joke: ERP does not stand for “Enterprise Resource Planning.” It stands for “Everybody Resists Process.”

Why “change management” is the highest-leverage work in D365 F&O

D365 is not a UI swap. It rewires how accountability works. Let me say that again for those in the back. D365 is not a UI swap. It rewires how accountability works.

A few examples you already know, but the implications get missed:

• Role-based security is organizational design in disguise. Who can post, approve, release, reduce, scrap, or override is not “IT work.” It is power, risk, and trust encoded into the system.

• Workflow forces decisions into daylight. That is good. It is also threatening to cultures that survived on hallway approvals and “tribal memory.”

• Master data becomes a first-class citizen. If the org has treated data as a byproduct, D365 will expose it. Loudly.

• Standard processes remove “local hero” work. The people who built identity around saving the day with workarounds can feel like the new system is taking their value away.

When you hear “users are resistant,” what is usually happening is more specific:

• They do not trust the change.

• They do not understand the change.

• They do not believe they will be successful in the change.

• Or they believe the change will make them less important.

That is change management.

Microsoft’s implementation guide frames adoption and change management as a deliberate strategy to avoid low adoption, poor usage, and misaligned expectations.

The veteran mistake: treating change management like communications and training

If your “change plan” is a comms calendar plus end-user training two weeks before go-live, you do not have change management. You have theater.

Real change management in ERP has three jobs:

1. Design the new way of working (with consequences).

2. Transfer capability (so people can actually operate).

3. Make adoption measurable (so you can steer).

If you only do communications and training, you miss the first and third jobs, which are the hard ones.

The Change Management Spine (what actually works on D365 projects)

Here is the structure I have seen hold up on real implementations, including with battle-tested teams.

1) Start with a Change Impact Matrix that is tied to D365 objects, not vague statements

Most change impact assessments are too fluffy to be actionable. Veterans get value by tying impacts to concrete D365 realities:

• Business process area

• Security roles and duties

• Workflow touchpoints

• Reports and KPIs

• Data entities and ownership

• Integrations and “source of truth”

• Volume and frequency (daily vs monthly close is a different change)

A practical matrix looks like this:

Process	D365 feature/object	Personas impacted	What changes in daily work	Risk if not adopted	Mitigation artifact
AP invoice entry	Invoice capture / vendor invoice journal	AP clerks, AP lead	New exception handling and matching behavior	Late payments, duplicate invoices	Job aid + escalation path
Warehouse picking	Mobile device menus, work templates	Pickers, warehouse lead	Work-driven picking replaces paper	Missed shipments	Floor-walk coaching + KPI dashboard
Month-end close	Financial dimensions, posting profiles	Accountants, controller	More structure, fewer manual JEs	Close delays, audit issues	Close checklist + practice close

Veteran tip: put an owner on every row. Not a committee. A person.

This aligns with the “proportionality” concept Microsoft calls out: tailor change management effort to risk and complexity, but still treat it as fundamental.

2) Build a Super User network that is designed like an escalation system, not a popularity contest

Most projects pick super users based on who is available. That creates “nice people who attend meetings,” not adoption leaders.

Pick super users using three criteria:

• Process credibility: peers already go to them for help.

• Tolerance for ambiguity: they can operate without perfect instructions.

• Teaching instinct: they can explain without making people feel dumb.

Then design the network with intent:

• One super user per major role, per site, per shift if operations run shifts.

• A weekly cadence where super users bring themes, not tickets.

• A clear line between “how do I do the work” and “the process design is wrong.”

Veteran tip: give super users decision rights over work instructions and training artifacts for their area. If they cannot shape the materials, they become messengers, not owners.

3) Convert training from “feature training” to “role performance”

Feature training is: “Here is how a purchase order works.”

Role performance is: “Here is how you keep production fed with materials without setting the building on fire.”

The difference is everything.

Build training around:

• Top 10 transactions per role

• Top 10 exceptions per role

• Top 5 “what changed” moments per role

Microsoft’s guidance hub explicitly emphasizes training and adoption as the mechanism to get users to embrace Dynamics 365, not just have access to it.

Veteran tip: your best training content is not slides.

It is:

• a short job aid,

• a recorded walkthrough,

• and a live practice scenario with realistic data.

If you have Task Recorder outputs, do not stop at the recording. Turn it into:

• a role-based job aid,

• a “what to do when it fails” appendix,

• and a short quiz that forces comprehension of exceptions.

4) Treat security role mapping as a change management deliverable

Security is usually handled like technical setup. It is not. It is behavior design.

A strong practice:

• Start with a role catalog by persona.

• Map roles to responsibilities, not to people.

• Validate with managers using real scenarios, not screenshots.

Then publish a simple “who does what now” artifact that includes:

• what they can do,

• what they cannot do anymore,

• and how escalations work.

Veteran tip: resistance often shows up as security complaints. Sometimes that is legitimate. Often it is grief.

5) Make adoption measurable with leading indicators (before go-live)

Most teams wait until go-live to discover adoption problems. That is late.

Adoption has leading indicators you can measure during SIT, UAT, training, and cutover:

• Training completion (weak signal, but useful)

• Scenario proficiency checks (strong signal)

• UAT participation rate by role and site

• Defect patterns that scream “process misunderstanding”

• Help desk rehearsal outcomes (how fast can the org self-serve)

Microsoft’s implementation lifecycle is staged, but many tasks span all stages. Adoption work is one of those cross-cutting tasks.

Veteran tip: track exceptions, not transactions. People can memorize the happy path. Exceptions reveal readiness.

6) Run a People Readiness Gate as part of go-live governance

If you do go-live readiness without a people gate, you are only validating the system, not the business.

A People Readiness Gate can be brutally simple:

Must be true to pass:

• Every role has named trained coverage (including PTO reality).

• Every site has super user coverage for the first two weeks.

• Top 10 exception paths are trained and documented.

• Cutover communications are acknowledged by impacted leaders.

• Hypercare triage model is staffed and understood.

If you cannot pass these, you are choosing a chaotic go-live.

The hard part: resistance is usually rational

Here are four resistance patterns that show up in ERP specifically, and what actually works.

“This will slow me down.”

Reality: it might, at first.

Counter: measure time-to-competency, not day-one speed. Give them job aids that remove cognitive load. Put super users on the floor, not in meetings.

“We are different.”

Reality: sometimes they are. Often they are protecting special treatment.

Counter: force the conversation into data: volume, compliance risk, cost of variation, audit exposure. Make exceptions expensive and explicit.

“IT built this, not us.”

Reality: when the business is not truly owning process decisions, they are not wrong.

Counter: publish decision logs with business names on them. If leaders will not sign decisions, you do not have governance.

"I am going to look incompetent.”

Reality: ERP go-lives threaten identity.

Counter: normalize the learning curve publicly. Build practice environments and guided scenarios that let people fail safely before go-live.

Hypercare that does not turn into “forevercare”

Hypercare is change management in its most operational form.

If you want hypercare to end on time, do three things:

1. Triage by category: “how-to,” “bug,” “data,” “access,” “process gap.”

2. Shift-left aggressively: super users handle how-to and basic process questions.

3. Publish a daily top 10 issues post: not for blame, for alignment and repetition.

Veteran tip: if your hypercare tickets are mostly “how do I,” you did not train for role performance, you trained for features.

Quick hits that experienced implementers still underestimate

• Data ownership is change management. If the business is not accountable for master data quality, D365 will become a very expensive data entry tool.

• Cutover is a change event, not a checklist. People need a minute-by-minute plan that includes who is communicating what, to whom, and what the backup plan is when something slips.

• Executive sponsors need an operating cadence. A sponsor who “supports” but never makes decisions is not a sponsor. They are a spectator.

If you steal nothing else, steal this

Change management is the discipline of turning D365 from “software we installed” into “how we run the business now.”

If you want the implementation to work, treat change management as:

• process ownership

• capability transfer

• and measurable adoption, from day one

POCTaMAFDO for short

DynamicsDad sign-off:

If you wait until the end to start change management, that is like trying to teach your kid to ride a bike by handing them a helmet after you pushed them downhill.

Peace out, girl scout

Dad-cephous aka DynamicsDad