The Lobbi Delivery Team
Operational Systems Engineering
If you've ever drawn a flowchart and felt that something was missing, the missing thing is almost always a person. Standard flowcharts are great at "what happens" — circles, rectangles, arrows. They are bad at "who does it." And almost every interesting failure mode in a real business lives at the seam between two whos.
That's the thing swimlanes get right.
What the lens answers
A BPMN swimlane diagram is a flowchart with one extra constraint: every task has to live in a horizontal lane named after a role. Sales lane. Operations lane. Customer lane. Approver lane.
That single constraint changes everything. Now, every time work crosses from one lane to another, the diagram shows it visibly. The arrow has to physically jump down (or up) to a new lane. That visual jump is a handoff. Every handoff is a place where work waits, gets re-formatted, gets re-explained, gets approved, gets rejected, or gets dropped.
If you draw a process and the diagram has 14 tasks but only 3 lane jumps, you have a clean process. If you draw it and you have 14 tasks and 11 lane jumps, you have a process with a handoff problem — and almost certainly a wait problem and an accountability problem too.
Why this is the second lens, not the first
We don't draw swimlanes until SIPOC and RACI are done. The reason is that swimlanes assume you already know which roles to draw. If your RACI says "the AR team owns invoicing," the swimlane has an "AR Team" lane. If your RACI is wrong — if invoicing is actually three people in three different functions taking turns — the swimlane will be wrong in the same shape.
So: scope first, ownership second, then handoffs.
What we look for
The most common pathologies we draw out with swimlanes:
— Ping-pong handoffs. Sales → Ops → Sales → Ops → Sales. Each round is a re-explain. — Phantom approvals. A task that lives in one lane but cannot complete without an undocumented sign-off from a lane that isn't drawn. — Lane chasms. Two lanes that hand off to each other six times across the diagram, with no shared system, no shared document, and no SLA. — Single-person dependencies. A lane occupied by one named individual whose unavailability stops the whole process.
None of those are visible in a non-laned flowchart. They jump off the page in a swimlane.
How we use BPMN inside an engagement
We use the BPMN 2.0 notation strictly — not because the symbols matter, but because BPMN's strict rules force precision. Every task is a rounded rectangle. Every decision is a diamond. Every event is a circle. Every handoff is a sequence flow with an arrow.
The strictness matters because the diagram is going to be read by ops people, by engineering, by execs, and by an automation team. Ambiguous notation costs us a meeting per stakeholder group; strict notation buys us alignment for free.
Once the swimlane is on a wall (literally or in Miro), every "but what about…" question that comes up either lives somewhere on the diagram or doesn't. There is no third option. That's the diagnostic power.
Every interesting failure mode in a real business lives at the seam between two whos. Swimlanes are the only diagram that draws the seams.
Sources
Topic clusters