Most BPMN Diagrams Get This Wrong

What we walked through

1. 01

   Lanes add accountability

   A process without lanes still shows the logic and flow. Lanes add the organisational dimension: who is responsible for what, and where do handovers happen?

2. 02

   More lanes can reveal organisational friction

   If a relatively simple process involves ten departments, that's not just a modelling detail. It shows how many handovers, approvals and organisational boundaries sit between the work and the outcome.

3. 03

   Don't mix organisational and system views

   Using departments and systems as lanes in the same model may be technically valid BPMN. But it mixes two different modelling intentions and makes the model harder to interpret consistently.

4. 04

   Business level: show responsibilities

   At the higher, business-oriented level, use lanes for departments, teams and functions to show responsibilities and collaboration. Between lanes, sequence flow is enough. Decompose further when you need more detail.

5. 05

   System level: show interactions

   At a more technical level, model systems as pools to make their interactions explicit, including integration points and APIs. Message flows are for communication between these separate pools.

6. 06

   Consistency beats correctness

   A theoretically perfect BPMN model doesn't help much if every team models the same thing differently. Pick a convention for each level, then stick to it. That's how models become something people can actually use.