Skip to content
All tools
OperationsIntermediate

Business Process Model and Notation

Represent process events, activities, decisions and handoffs with a shared notation.

In one minute

Represent process events, activities, decisions and handoffs with a shared notation.

Use a bounded BPMN diagram with events, tasks, gateways, sequence flows and pools or lanes. Model only the detail needed for the decision; validate semantics with process participants.

The problem it addresses

A process description hides who waits for whom and what happens after an exception.

A hospital laboratory loses urgent samples between collection and analysis. The written procedure lists steps but no acknowledgment at the courier handoff.

When to use it

  • Use Business Process Model and Notation when a process description hides who waits for whom and what happens after an exception.
  • The team can examine: A process boundary, observed event traces, roles, decision rules and exception evidence.
  • A relevant situation is: A hospital laboratory loses urgent samples between collection and analysis. The written procedure lists steps but no acknowledgment at the courier handoff.

When not to use it

Do not use it to replace evidence, accountable judgement or affected people's participation.

Mistaking a neat diagram for observed practice, or modelling every detail before the boundary is agreed.

Inputs required

A process boundary, observed event traces, roles, decision rules and exception evidence.

Step-by-step process

1. Bound the decision and name its owner.

Write the scope, decision owner and people who can veto or revise the result before starting the workshop.

2. Collect the necessary evidence and affected perspectives.

Collect and date the necessary evidence: A process boundary, observed event traces, roles, decision rules and exception evidence.

3. Name the start event and desired end state.

Pick one real triggering event and the condition that ends the process; keep the model's boundary explicit.

4. Trace actual tasks and responsible participants.

Observe the work and place tasks in the lane of the person or system that actually performs them.

5. Add gateways only where a rule changes the path.

For each split, write the rule that selects a path and check that every path can reach an end or recovery state.

6. Mark handoffs, waits and exception routes.

Mark messages between participants, waiting time, failed acknowledgments and exception handling explicitly.

7. Walk real cases through the diagram and revise.

Walk ordinary and urgent cases through the diagram with frontline staff; correct the model where reality differs.

8. Record the output, next test and review trigger.

Store the artifact with its evidence links, owner, bounded next test and date or trigger for review.

AI automation lens

AI may sort authorised notes and expose missing evidence. It must not invent observations, silently decide for affected people or present a generated map as validated.

Visual model

Text alternative: Name the start event and desired end state; Trace actual tasks and responsible participants; Add gateways only where a rule changes the path; Mark handoffs, waits and exception routes; Walk real cases through the diagram and revise.

Interactive example

Scenario: A hospital laboratory loses urgent samples between collection and analysis. The written procedure lists steps but no acknowledgment at the courier handoff.

Worked answer: Map collection, labeling, courier acceptance and lab receipt with an explicit missing-receipt exception and escalation owner.

Facilitation notes

Record disagreements before synthesising; ask whose evidence is missing; state who may revise the result.

Expected output

  • An inspectable decision artifact, its assumptions and evidence, a responsible owner, a bounded next test and a review date.
  • Walk real cases through the diagram and revise.
  • A named owner, test and review date.

Common mistakes

Mistaking a neat diagram for observed practice, or modelling every detail before the boundary is agreed.

Quality checklist

  • The decision and system boundary are explicit.
  • Affected people and alternative accounts are included.
  • Each important claim has a source or is marked as an assumption.
  • An owner, safeguard and disconfirming signal are named.

Template

Open the working template.

Knowledge check

Question: What mistake would undermine this method in the scenario?

Answer: Mistaking a neat diagram for observed practice, or modelling every detail before the boundary is agreed.

Related tools

References

  1. Business Process Model and Notation — method source (opens in a new tab). Accessed 2026-09-28.
  2. Independent practice reference (opens in a new tab). Accessed 2026-09-28.

Method profile

The method structures a discussion and a test; it does not establish causal proof or guarantee success.