A process diagram answers "what happens next", and its grammar is small enough to state completely. A rectangle is a step, meaning something is done. A diamond is a decision, meaning the path branches, and every diamond has at least two exits, each one labelled with the condition that takes you down it. An arrow is sequence. A loop is an arrow that returns to an earlier step, and it must point at one specific step, never at a general region of the page. A rounded terminator marks the start and the end. You don't need anything else, and every mark you add beyond those five costs more than it gains.
Why does the decision diamond matter in a process diagram?
The commonest defect of all is a decision hidden inside a step box. "Match invoice to purchase order and receipt" looks like one step and is two: a match attempt, and a branch on whether it matched. Hide the branch and you hide the whole economics of the process, because in most operational processes the exception path is where the time and the money go. Take a receiving-to-pay process at a mid-size distributor, at a scale that makes the point without exaggeration. Of 1,000 invoices a month, the three-way match succeeds on 87.4 percent. So 874 flow straight through in four steps and 126 fall into an exception path of nine steps. The weighted average is 0.874 × 4 + 0.126 × 9 = 4.6300 steps. At 3.0 days straight through and 11.5 days for an exception, the weighted average cycle time is 4.0710 days. Both averages are unremarkable. The distribution behind them isn't, and only a diagram that shows the diamond shows the distribution.
Now put money on that diamond, and the process diagram stops being documentation and starts being an argument. Exception handling costs $18.40 an invoice, so 126 exceptions cost $2,318.40 a month and $27,820.80 a year. Worse, 78 of those exceptions close after day 10 and lose a 2 percent early-payment discount on an average invoice of $4,860.00. That's $97.20 each, $7,581.60 a month and $90,979.20 a year. The discount leak is 3.2702 times the handling leak, and that ratio is the finding. The total at that one node is $118,800.00 a year. Label the diamond with 87.4 percent and 12.6 percent, label the exception branch with the annual cost, and you've handed the reader the recommendation without ever stating it.
Advertisement
When do you need swimlanes in a process diagram?
Swimlanes add an actor dimension. Each horizontal band belongs to one party, and a step goes in the band of whoever performs it. A lane costs vertical space and one more thing to track, so the test for adding lanes is whether the handoffs matter. In the receiving-to-pay case they matter completely. Four lanes, supplier, carrier, receiving dock and accounts payable, produce five handoffs. That's two more than a strict relay would give, because the supplier sends its invoice straight to accounts payable instead of down the chain, and the exception path sends work back. In 126 of 1,000 cases, the handoffs are where the exception is created. Without lanes, you'd see a process that occasionally fails. With lanes, you see that it fails at the boundaries between organisations. That's a different problem, and it has a different fix.
Lanes come with rules of their own. Order them by first appearance rather than by seniority, so arrows run mostly forward and downward and crossings stay rare. In a strict relay, n lanes produce n − 1 handoffs, so four lanes produce three and six lanes produce five. If any lane can call any other, the ceiling is n(n − 1), which is twelve for four lanes and thirty for six. That ceiling explains why a six-lane diagram usually reads as a tangle. The notation permits thirty crossings and the eye can follow about five. When a process really does have six actors, the better move is often two diagrams, one per phase, instead of one diagram with six lanes.
How do you draw a loop in a process diagram?
Loops are the last piece, and they're the piece most often drawn wrongly. A rework loop that returns to "receive goods" says the goods are received again, which is false. It should return to "re-match", the step that's actually repeated. Draw the loop to that step and label the arrow with the condition that triggers it. If a loop can run more than once, say so in the label, because a reader assumes a single pass unless you tell them otherwise.
The flow diagram, and the check that catches an error
A flow diagram is a special case of a process, one where what moves is a quantity: money, goods, tonnes, headcount, transactions. It adds very little to the grammar and a great deal to the rigour, because a quantity that moves obeys a conservation law. What leaves a node arrives somewhere, is consumed, or is lost. If it does none of those, the diagram is wrong.
Worked example: a four-bank payment flow
Take one day in a synthetic four-bank retail payment system. The banks are Meru, Sarayu, Nila and Tamra, and all values are in ₹ crore. Four nodes admit twelve ordered pairs, and all twelve carry traffic. Meru's customers push ₹70.80 crore out and receive ₹70.50 crore in, so Meru's net position is −0.30. Sarayu sends 72.00 and receives 75.10, a net of +3.10. Nila sends 54.30 and receives 65.40, a net of +11.10. Tamra sends 49.40 and receives 35.50, a net of −13.90. Gross value is ₹246.50 crore in both directions, which is the first check. The four nets sum to zero, which is the second.
Those two checks aren't ceremony. Imagine the same drawing with one leg transcribed wrongly, so Nila's net reads +9.80 instead of +11.10. The picture looks just as it did. But the nets now sum to −1.30, and that single non-zero number is your entire error-detection system. It fires without anyone knowing which leg was wrong, and it fires before the slide is presented, which beats finding out in the meeting. Every flow diagram you draw should carry a stated conservation identity and a printed residual. A residual of zero printed on the page is a promise you've kept.
Then the netting arithmetic produces the message. Two banks owe on net, Meru at −0.30 and Tamra at −13.90. Two are owed, Sarayu at +3.10 and Nila at +11.10. The two sides tie at ₹14.20 crore. That figure is the settlement funding requirement, the cash that has to be available at the settlement window, against ₹246.50 crore of gross payments. Netting efficiency is 1 − 14.20/246.50 = 94.2394 percent, and it's the number the diagram exists to deliver. If a reader takes away only "the system settles 94.2 percent of value without cash moving", they've taken away the point.
How should you label a flow diagram?
Node labelling decides whether the diagram works. Print each bank's net on its node and the funder is visible at once. Leave the nets off and the reader is back to twenty mental operations across four banks. Arrow labels carry the leg values. Arrow thickness shouldn't try to, because thickness encodes magnitude poorly and readers can't compare widths reliably enough to justify losing a legible label. Where you have both a value and a direction, print the value and let the arrowhead do the direction.
Scale context belongs on the diagram too, in one printed line, so it isn't left in the speaker's head. Those ₹246.50 crore moved across 420,000 transactions, an average ticket of ₹5,869.05. That tells the reader at once that this is retail flow, and it heads off a question that would otherwise eat two minutes. One computed line can retire a whole line of questioning, and the habit of finding that line is the difference between a diagram and an illustration.
A diagram you can't check is a diagram you're asking people to trust. Conservation is how you stop asking.