Swimlane diagram

What is a swimlane diagram?

A swimlane diagram is a process drawing cut into parallel lanes, one per role, department or system, with every step in the lane of whoever performs it. Along its length you read the order of the work. Across it you read who is responsible. Microsoft calls the same picture a cross-functional flowchart in Visio, where a lane is a functional unit such as a department or a position.

It became a management tool in 1990, when Geary Rummler and Alan Brache published Improving Performance: How to Manage the White Space on the Organization Chart with Jossey-Bass. The subtitle is the argument: the org chart shows the boxes, the trouble lives in the white space between them.

What the lanes show that a flat flowchart hides

A flowchart tells you what happens. A swimlane tells you what happens and whose desk it lands on next. Every arrow that leaves one lane and enters another is a moment where the work changed hands. The Lean Enterprise Institute puts handoffs first in its list of wastes in product and process development, with the waste coming from misunderstanding what was transferred and from waiting for feedback.

So the picture hands you a number. Count the crossings before you discuss the steps. In many workshops that count is the whole finding, and people who have run the process for years have never seen it stated as a number.

Four things fall out of the count: the approval that happens twice because two lanes both want to sign, the step nobody owns because each lane assumes the other has it, the two systems recording the same fact in two lanes, and the scope for an automation project, since a handover with a system on both sides is a candidate and one that needs judgement is not.

Pools and lanes in BPMN

The OMG specification defines a swimlane as a graphical container for partitioning a set of activities from other activities, and gives you two types of them.

A pool is the graphical representation of a participant in a collaboration: a company, or a role such as buyer or seller. It can also be a black box, an empty band for a party you know is involved but whose internal work you cannot see. A lane is a sub-partition inside a pool that runs the full length of it, horizontally or vertically, and organises the activities.

The rule that matters most in practice: sequence flows, the solid arrows carrying the order of the work, may cross the boundaries between lanes of a pool but never the boundary of a pool. Between pools you use message flows, the dashed arrows. Your own departments are lanes in one pool, and a customer or supplier is a second pool that you talk to rather than instruct.

The specification also says the meaning of the lanes is up to the modeller and that BPMN does not specify their usage, naming roles, systems and departments as the usual choices. So agree in the team what a lane means before the first workshop.

How to draw one honestly in a workshop

The failure mode of a process workshop is that the room describes the process it wishes it had. Four moves keep the drawing honest, and one closing rule.

1. Start from one real case. Not "how do we handle an order", but "walk me through the order that came in last Tuesday". Then draw a second case that went badly.

2. Name the lanes before the first step. Roles, not people. A lane called Sofie stops being true the day Sofie changes job.

3. Give the outside party a lane. Much of the waiting is your company waiting on a customer or a supplier, and if they are not on the paper that waiting has nowhere to sit.

4. Mark every crossing, then count the dots out loud. Write beside each dot how the work travels: a mail, a phone call, a status field in the ERP. Handovers with no system behind them are the ones that go missing for a week. Then ask, per dot, why the work has to change hands there.

Finish with the two most frequent exceptions, because a diagram with only the happy path describes a process nobody runs. And an AI agent that performs a step gets its own lane, because a lane is about who does the step and an agent is a who.

A purchase-to-pay example in four lanes

A company of sixty people buys a machine part. The lanes are requester, manager, purchasing and finance, with the supplier as a separate pool. The requester writes the request, the manager approves the budget, purchasing picks a supplier and orders, the supplier delivers, the requester confirms the delivery is right, finance matches the invoice against order and receipt, the manager approves the invoice for payment, finance pays.

Count the crossings: requester to manager, manager to purchasing, purchasing back to the requester for the receipt confirmation, requester to finance, finance to manager for the payment approval, manager back to finance. Six handovers, each a moment where a document sits in an inbox.

Which two do you attack? The last two go together and they go first. The manager approved the amount at crossing one, and if the invoice matches order and receipt there is nothing new to approve. A tolerance rule replaces the round trip: a match within an agreed margin means finance pays without asking, and only a mismatch goes back to a person. Six crossings down to four.

The second target is the receipt confirmation, the step nobody owns. The part arrives at the warehouse, the requester confirms it whenever they next open their mail, and the invoice cannot be matched until they do. Give it a deadline with a reminder, or let whoever signs for the delivery register it at the door. Neither fix asked anyone to type faster.

Workshop drawing versus a mined process graph

A swimlane drawn by people in a room and a process graph discovered by process mining answer different questions, so hold both. The drawing captures intent and responsibility: what should happen and who is accountable, which no event log can tell you because logs record user accounts rather than roles. It also holds the steps that leave no trace, like a phone call or a correction in a spreadsheet.

The mined graph captures reality and volume. Process discovery reads timestamps out of the ERP or the ticketing tool and shows which paths cases took, how often, and how long each gap lasted. It cannot tell you why, and it is blind to any step no system recorded.

Expect them to disagree, and treat the disagreement as the finding. The drawing has a check the log never shows, so the check is not being done. The log has a loop the drawing does not, so there is rework nobody had named.

What to watch out for with swimlane diagrams

Thirty lanes. A lane per individual turns the diagram into an org chart with arrows. Above seven or eight lanes we find people stop reading it, so group individuals into roles or split the process in two.

A lane called "the system". One named application in its own lane is normal. A catch-all lane holding three applications and a nightly job hides exactly the handovers you drew the picture to find.

Steps at different altitudes. "Approve the order" next to "click Save in the ERP" makes the diagram unreadable and suggests the two are comparable amounts of work.

No owner for the drawing. A swimlane nobody updates goes quietly out of date, and then people trust the wrong picture. Give it to the process owner together with the number you measured.