Map and Analyse a Real Business Process

Proof required

Submit: the current-state process map in BPMN or swimlane notation; a scope document stating the process boundaries, how many people were interviewed or observed, and the total cycle time documented; and a verification note from at least one process participant confirming the map reflects how the process actually runs.

What gets checked

• Map shows all decision branches and what triggers each path — not a linear flow pretending the process never varies
• All handoffs between people or systems are explicitly labelled with the hand-off mechanism (email, ticket, verbal, etc.)
• At least one process participant has confirmed the map is accurate — desk-based mapping without validation is not sufficient

Common mistakes

• Mapping the process as it should work rather than as it actually works — the improvement analysis will then address phantom problems
• Using vague swim lane labels ('Team A', 'System') instead of specific roles and system names

Resources

What a verifier looks for

• Pick a decision point on the map and ask: 'what actually happens when condition B is true?' — does the map show it?
• Check that handoff mechanisms are specific: 'email to manager' rather than just an arrow
• Ask to see the verification note — was it written by someone who actually executes this process, not just their manager?
• Challenge the cycle time: ask how the total time was measured and whether it is the median or the exceptional case

You'll sign in first, then come straight back here.

Proof required

Submit: the annotated process map with waste categories clearly marked and the value-add versus non-value-add classification for each step; root cause analysis documents for the two highest-impact waste sources (5-Whys or fishbone diagrams going at least three levels deep); and a confirmation note from a process participant that the waste identification is accurate.

What gets checked

• Waste identification is confirmed by at least one process participant — not desk analysis alone
• Root cause analysis goes at least three levels deep for each waste source — not stopping at the first symptom
• Evidence (observation, time measurement, error log) is cited for each waste identified

Common mistakes

• Identifying waste through assumptions rather than observation — the 'obvious' waste is often not the highest-impact one
• Stopping root cause analysis at the first level ('it takes too long because the approver is slow') rather than finding the systemic cause

Resources

What a verifier looks for

• Ask: 'how did you confirm this was actually the highest-impact waste?' — push for evidence, not intuition
• Walk through one root cause chain and ask 'why?' at each level until the analysis stops — does it stop too early?
• Check the evidence cited: is it quantified (time, error count, rework frequency) or just observed?
• Ask whether the process participants agreed with the waste classification or whether there was disagreement

You'll sign in first, then come straight back here.

Proof required

Submit: the future-state process map in the same notation as the current-state map; an implementation roadmap (steps, owners, timelines); a quantified benefit estimate with conservative and optimistic scenarios; and a written record of the review meeting with the process owner's specific questions and your responses.

What gets checked

• Future-state map directly addresses the root causes from m2 — not generic simplification
• Benefit estimate includes a conservative scenario grounded in the measured waste data, not aspirational targets
• Process owner has confirmed the future state is technically and organisationally feasible — not just theoretically superior

Common mistakes

• Designing a future state that assumes tools or changes that are not in the team's control to implement
• Presenting improvement estimates without showing how they were calculated from the waste measurement data

Resources

What a verifier looks for

• Check that the future state directly removes or redesigns the root causes from m2 — not just generic simplification
• Ask the candidate to walk through the benefit estimate: how was the baseline waste measured and how is the improvement calculated?
• Verify the process owner attended the review — a presentation to a peer or the builder's manager is not valid
• Ask whether the implementation roadmap assigns named owners or uses generic 'team' responsibilities

You'll sign in first, then come straight back here.