Business process mapping for Dynamics 365

A Dynamics 365 implementation needs to understand the customer's business processes — how things actually flow today and how they should flow tomorrow. Business process mapping is the discipline that creates this understanding. Done well, it bridges requirements to design; done poorly, it produces wallpaper that nobody reads.

Why map processes.

• Common understanding — stakeholders see the same flow.
• Gap identification — where standard fits, where customisation needed.
• Design input — FDDs reflect mapped processes.
• Training material — onboarding new users.
• Audit evidence — what the system is designed to do.

Process hierarchy. Three levels typically:

• Level 1 (Strategic) — major process areas: "Order to Cash", "Procure to Pay", "Hire to Retire".
• Level 2 (Operational) — sub-processes: "Sales order processing", "Vendor invoice processing".
• Level 3 (Procedural) — detailed steps: "Create sales order", "Apply credit check".

Different audiences need different levels.

Notation choices.

• BPMN (Business Process Model and Notation) — formal, standardised.
• Flowchart — simpler, more universally understood.
• Swim-lane diagrams — show actors / systems clearly.
• Value stream map — for transformational analysis.

BPMN strikes balance for most Dynamics implementations; specialised analysts trained in it.

BPMN essentials.

• Tasks — activities (rectangles).
• Events — start, intermediate, end (circles).
• Gateways — decisions, parallel paths (diamonds).
• Sequence flow — arrows showing order.
• Pools and lanes — actors / systems.

A few hours of training makes BPMN readable; intuitive notation.

As-is vs to-be. Two complete mappings:

• As-is — current state warts and all.
• To-be — designed future state.

The gap drives implementation scope.

As-is mapping techniques.

• Process owner interviews.
• Observation of people doing the work.
• Document review — existing procedures.
• System exploration — what current systems do.
• Workshop facilitation — group reconstruction.

Each captures different aspects; combine for completeness.

To-be design.

• Future state vision discussions.
• Best practice review — how others do it.
• Standard Dynamics process — what comes out-of-box.
• Customer-specific differentiators — what must remain unique.

The to-be reflects both standard and the customer's reality.

Process modelling tools.

• Microsoft Visio — most common.
• Lucidchart — collaborative.
• Bizagi Process Modeler — BPMN-focused.
• Microsoft Process Advisor — process mining + modelling.
• Specialised consulting tools.

Tool choice affects collaboration efficiency but not fundamental quality.

Process scenarios. Per process:

• Happy path — normal flow.
• Variant flows — common alternatives.
• Exception flows — error handling.
• Edge cases — unusual but possible.

Documenting only happy path misses where things actually break.

Documentation per process step.

• Step name and ID.
• Role / actor.
• System interaction.
• Inputs and outputs.
• Decision criteria (if gateway).
• Duration estimate (for analysis).
• Cost (where relevant).

Detail level matches the purpose — overview vs operational manual.

Process measurement.

• Cycle time — total duration.
• Process time — value-add time.
• Wait time — between steps.
• Volume — frequency.
• Cost per execution.

Quantifying current process supports improvement decisions.

Integration with requirements.

• Each process step generates functional requirements.
• Non-functional requirements emerge from analysis (volume, latency).
• Process maps feed FDDs.

The artefacts compose; process maps are early, FDDs are later refinement.

Common process patterns to recognise.

• Sequential — step A → B → C.
• Parallel — A and B simultaneously; both complete before C.
• Conditional — A → (if X then B else C).
• Loop — A → B → A until condition met.
• Subprocess — A → [reusable subprocess] → B.

Standard patterns improve modelling efficiency.

Process governance.

• Maps maintained.
• Updates when process changes.
• Owner per process.
• Periodic review cycle.

Without governance, process maps drift from reality within months.

Process mining vs process mapping. Different but complementary:

• Mapping — manual, subjective, based on stakeholder description.
• Mining — data-driven, objective, based on system event logs.

Mining reveals what really happens; mapping captures intent. Combine for richer insight.

Common pitfalls.

• Over-detailed. Hundreds of pages; nobody reads.
• Under-detailed. Vague; doesn't guide implementation.
• Wrong audience. Technical detail for execs; high-level for developers.
• No updates. Maps frozen at project end; reality moves on.
• No ownership. Documents exist; nobody maintains.
• One person's view. Not validated across stakeholders.

Validation.

• Walkthroughs with process owners.
• Stakeholder review.
• End-user sanity check.
• System validation — does the system actually do this?

Iterate; first draft rarely captures reality fully.

For ALM and operations. Process maps remain valuable post-go-live:

• Onboarding — new users learn the process.
• Audit — evidence of process control.
• Continuous improvement — baseline for refinement.
• Change management — context for system changes.

Strategic positioning. Process mapping is investment in understanding. The understanding is the actual deliverable; the diagram is the artefact. Mature implementations have process documentation that survives the project as operational asset.

For implementation teams:

• Map what matters at the right detail.
• Validate with the people who do the work.
• Keep maps current.
• Use maps as living documentation.

The discipline produces clearer designs, better-trained users, and audit-ready evidence of process control. Without it, projects build to assumed processes that may not match reality.