Approach
The ten disciplines of a real implementation.
Software installs happen in the config screen. Business transformations happen across ten disciplines. Every one of them has a name, an owner, and an artifact — or it doesn't exist.
01 · Scope & Contract
What was sold, what's being delivered, and where the gaps hide. Every SOW and change order re-read with the CFO's eye, not the SI's.
02 · Testing & UAT
Scenarios anchored to real business processes, sequenced so each end-to-end block runs contiguously. Not a demo — a dress rehearsal.
03 · Data Migration
Active master data and open documents move. Detailed history stays where it lives. Subledgers and clearing accounts designed so nothing double-counts.
04 · Cutover
Executive-altitude milestones — production readiness, bank readiness, go-live, first operational day. Every one tied to explicit go / no-go authority.
05 · Integrations
Banking, tax, EDI, project scheduling, subsidiary systems. Each treated as a workstream with owners, testing, and fallback — not a checkbox.
06 · Security & SoD
Roles that match how the business actually works, with segregation of duties the auditors can defend. Delegation of authority in writing.
07 · Master Data
Cleanup rules, ownership, and readiness criteria before load. Because bad data doesn't get better once it's in D365 — it just gets harder to see.
08 · Reporting & Close
Reports and financial dimensions that support the close the CFO actually runs — not the one shown in the demo.
09 · Business Process
Named process owners for finance, cash & bank, purchasing, production, inventory, projects. Each with cleanup rules, validation, and exit criteria.
10 · Governance
Steering-committee cadence, decision logs, risk register, and an escalation path. So the program has a spine, not just a plan.
Early warning signs
If any of this is happening on your program, you are already going wrong.
Implementations should be repeatable. They should be based on best practice, standard business flows, and the accounting standards your auditors already expect. Your partner shouldn't be reinventing the wheel on your dime — and neither should you.
01
Your team is being asked to write the test scenarios, test cases, and user guides.
Standard test scripts and end-user documentation for D365 modules should come from your partner. They've implemented Finance, Supply Chain, and the rest hundreds of times. If they're telling your team to build all of that from scratch, you're paying twice — once for their fee, and once again for your own people to do the work they were hired to bring.
What good looks like: partner-provided baseline test packs and standard operating procedures for every in-scope module, then tailored with you for your specific business processes.
02
Twelve weeks in, and there is still no baseline system to walk through.
Within roughly twelve weeks of project kickoff, a competent partner should have stood up a base solution and walked you end-to-end through the standard best-practice flows: procure-to-pay, order-to-cash, record-to-report, plan-to-produce. If that hasn't happened, the program is drifting into open-ended design and configuration — and every week of drift compounds into your go-live.
What good looks like: a working baseline in a dedicated environment, a scripted walkthrough of standard flows, and a written gap list that becomes the fit-gap for your business.
03
UAT is being described as "scenarios your team will build."
UAT is a dress rehearsal, not a homework assignment. Your team validates that their business processes run correctly in the configured system — using a test-case foundation the partner has already provided. When UAT design starts from a blank page, timelines slip and coverage suffers.
04
Change orders are outrunning the original SOW.
Every “that’s a change order” conversation is a signal that scope, sequencing, and standard fit weren’t nailed down before contract. A handful of change orders is normal. A pattern of them is a governance problem, not a scope problem.
Every discipline has a name, an owner, and an artifact.
Or it doesn't exist.
See how your program scores.
An Implementation Health Check produces a red / yellow / green scorecard across all ten disciplines. Two to three weeks. Written report. No spin.