The Shiny ERP Trap: How to Make Your Dynamics 365 Project Actually Deliver Value
If you’ve been around ERP implementations long enough, you’ll recognise this pattern.
A project kicks off with a technical goal: “Replace the old system.” “Get onto the new platform.” “Go live on Dynamics 365.”
Everyone’s busy. The plan looks solid. The system goes live.
And six months later the business is asking the awkward question: So… what did we actually get out of this?
The system might be working, but the value is fuzzy. Adoption is patchy. “Phase two” has become a polite way of saying never.
This is the shiny ERP trap.
The real problem isn’t configuration. It’s that the project was launched around technology, not measurable business outcomes.
Why measurable benefits matter more than the go-live date
Dynamics 365 can absolutely improve efficiency, controls, and visibility. But it won’t do it automatically just because you implemented it.
When benefits are unclear, a few things happen fast:
💠Decision-making gets messy Without agreed outcomes, design workshops turn into opinion contests. The loudest voice wins, not the best outcome.
💠Solution design drifts Teams start optimising for “what’s possible” instead of “what will move the needle”.
💠Success becomes impossible to prove If you don’t define measures up front, you can’t credibly quantify ROI after go-live. You end up with anecdotes instead of evidence.
And that matters, because post go-live is where Dynamics 365 either becomes a capability… or a daily frustration.
Set goals at the onset (and make the whole team understand them)
One of the strongest moves you can make early is painfully simple:
Define the business reasons for implementing Dynamics 365 Document the benefits you’re targeting. Agree how you’ll measure them.
And then make sure the entire project team knows them. Not just the sponsor. Not just the PM. Everyone.
Because benefits and measures don’t just sit in a slide deck. They guide solution design and act as objective criteria when trade-offs show up (and they always do). In practice, benefits become your filter. Every project hits moments like these:
Do we customise or stick to standard? Do we prioritise speed or controls? Do we accept a manual step for now or automate it? Do we push this to phase two?
If you’ve got measurable outcomes, those decisions get easier. If you don’t, you end up with “it depends” and a growing backlog.
A simple way to frame it is:
If this requirement doesn’t improve one of our agreed measures, why are we building it?
Examples of measurable goals that actually help. You don’t need dozens. You need a handful that reflect business pain.
Here are examples that tend to work well for Dynamics 365 Finance and Operations projects:
✅ Financial close
- Reduce month-end close from X days to Y days
- Cut manual journal entries by X%
- Reduce reconciliation effort (hours) by X%
✅ Procure-to-pay
- Reduce invoice processing cycle time from X to Y
- Increase straight-through processing (no-touch invoices) to X%
- Reduce duplicate/incorrect supplier invoices by X%
✅ Order-to-cash
- Reduce billing errors by X%
- Reduce days sales outstanding (DSO) by X days
- Reduce credit and collections rework by X%
✅ Inventory and supply chain
- Improve inventory accuracy to X%
- Reduce backorders by X%
- Improve on-time in-full (OTIF) to X%
✅ User adoption and quality
- X% of users completing role-based training by go-live + 30 days
- X% reduction in support tickets after 60 days
- Reduce “workarounds” (tracked via tickets/process audits) by X%
The point isn’t the exact metric. It’s having something measurable that ties directly to how the business runs. Don’t forget success factors and adoption metrics.
Most projects track timeline and budget. Few track whether people actually changed how they work.
If you want Dynamics 365 to deliver value after go-live, user adoption needs its own measures, not vague hope.
A few practical options:
- Process adherence: are users following the designed process or doing side spreadsheets?
- Training completion and proficiency checks by role
- Support trends: ticket volume, repeat issues, and where the workarounds appear
- Time-in-process: how long key tasks take before vs after
These can feel “softer” than finance measures, but they’re often the leading indicators of whether ROI will show up later. Benefits aren’t a nice-to-have document. They’re a control mechanism.
It’s strongly recommended to discuss and document targeted project benefits early, then establish the metrics to measure objectives, success factors, and user adoption.
Without that clarity, you reduce your ability to make strategic decisions during the project, and you risk being unable to quantify success afterwards.
A practical approach you can use this week.
If you’re about to start a Dynamics 365 project (or you’re in the first few weeks), try this:
- Write the top 5 business outcomes on one page No solutions. Just outcomes.
- Add a measure to each outcome. Baseline it if you can. If you can’t, agree how you’ll capture it.
- Assign an owner per outcome. A real business owner, not “the project”.
- Use the outcomes as a design gate. In workshops, ask: which outcome does this decision support?
- Revisit measures at 30/60/90 days post go-live That’s when the “technically successful” projects start drifting, or start improving.
Closing thought
Dynamics 365 is a platform. It’s not the goal.
If the goals are clear, measurable, and shared across the whole team, go-live becomes the start of value - not the end of the project.