Model the process that happens, not the one that is written down
The documented process is a description of how the organisation would like to believe it works. The performed process is what people do when the documented one does not fit the case in front of them, and that difference is where nearly all of the cost sits. If you build a to-be design on the documented version you will produce something that fails on contact with the work, because you will have designed away the informal steps that were holding the process together.
Getting at the performed version takes deliberate technique, because nobody volunteers a workaround. A workaround feels like an admission that you are not following the rules, so people describe the official path when asked directly. What surfaces it is asking about specifics rather than about the process: walk me through the last one you handled, not a typical one. Ask what you do when the reference number is missing. Ask what the spreadsheet on your second monitor is for. Ask what you would have to explain to a new joiner that is not in the training material. Then sit and watch a few cases end to end, because observation catches steps people have stopped noticing they perform.
Two artefacts are reliable tells. Any shadow spreadsheet or personal tracker means the system of record is not answering a question somebody needs answered. Any step whose real mechanism is an email or a chat message means there is no handoff in the process where one is needed, and the work is being carried by somebody's memory.
Swimlanes, because delay lives in the handoffs
Draw the as-is with one lane per role or system rather than as a single flowchart. The reason is not tidiness. Work sitting inside a lane is usually being worked on; work crossing a lane boundary is usually queued, waiting for someone who does not yet know it has arrived. Handoffs are also where information is re-entered, where context is lost, and therefore where errors are introduced. Counting lane crossings is a crude but genuinely predictive measure of how bad a process is.
Take supplier invoice approval at a manufacturer. The documented process is three steps: invoice received, cost-centre manager approves, payment scheduled. The as-is model, drawn from twelve observed cases, looks like this.
| Step | Lane | What happens |
|---|
| 1 | Supplier | Emails invoice to a shared AP mailbox |
| 2 | AP clerk | Matches to a purchase order; keys header data into the ERP |
| 3 | AP clerk | If no PO match, emails the buyer to ask which PO applies |
| 4 | Buyer | Replies, sometimes after a chase, sometimes with a new PO raised retrospectively |
| 5 | AP clerk | Logs the invoice in a personal spreadsheet so nothing gets lost while waiting |
| 6 | Cost-centre manager | Approves by replying to an email |
| 7 | AP clerk | Records the approval in the ERP on the manager's behalf |
| 8 | Treasury | Picks up approved invoices in the weekly payment run |
Five lanes, seven crossings, and two steps (3 and 5) that do not exist in any documentation. Step 7 is the interesting one: the approval control the auditors believe exists is actually a clerk transcribing an email, which is a finding in its own right regardless of what the to-be design turns out to be.
The happy path is a minority of the work
Steps 1, 2, 6 and 8 are the happy path, and if you only model those you will conclude the process is fine. Suppose the ERP shows 2,000 invoices a month and that 38 per cent of them have no clean PO match on arrival, so roughly 760 a month go through steps 3 to 5. The exception path is a third of the volume and, because it waits on a human reply, the overwhelming majority of the elapsed time and the clerk effort.
This inverts how you spend your design attention. The question is no longer how to make approval faster; it is why a third of invoices arrive unmatchable, which is a purchasing-discipline problem that no workflow tool will fix. Model each exception path as a named branch with a volume against it. An exception without a number attached gets waved away as an edge case, and edge cases that occur 760 times a month are the process.
Quantify before you propose
Three measures are enough to make the argument, and all three come from the as-is model rather than from opinion.
Cycle time is elapsed time from the customer's trigger to the outcome they care about — here, invoice received to payment authorised. Report median and 90th percentile, never the mean, because a process with a long exception tail has a mean that describes no actual case. Say the median is 11 days and the 90th percentile 34 days.
Touch time is the hands-on effort in the same case. If AP handling is about 18 minutes per invoice, then against an 11-day median roughly a tenth of a per cent of the elapsed time involves anybody doing anything. That single comparison usually ends the argument about whether the bottleneck is staff productivity.
Rework rate is the proportion of items that re-enter a step they have already passed. Here it is the 38 per cent PO-match failure plus any invoices bounced back after approval. Rework rate is the measure that most reliably points at a root cause upstream of where the pain is felt, which is why it is worth establishing before anyone starts sketching screens.
Take the baseline before you show anyone a to-be diagram. Once a solution is on the table the conversation moves to the solution, and you lose the chance to measure the thing you will later be asked to prove you improved.
Where to-be designs go wrong
The failure to guard against is delivering the same process with software wrapped round it: a workflow tool that emails the buyer instead of the clerk emailing the buyer, a portal where the spreadsheet was, an approval screen replacing the approval email. Cycle time improves a little, the 38 per cent still fails to match, and you have now made the workaround permanent and expensive to change. This is the outcome sponsors ask for by default, because automating what exists is the request that requires no organisational change from anyone.
Avoiding it is a matter of sequence. Before drawing the to-be, take each as-is step and ask whether it can be eliminated, and only then whether it can be simplified, combined, or automated. Steps 3 to 5 in the example are not automation candidates at all; they exist because purchase orders are raised after the fact, so the fix is at requisition, and doing that removes a third of the volume from the process entirely. Step 7 should be eliminated by having the manager approve in the system, which is a control improvement rather than an efficiency one. What is left for automation is small, and it is the part that survives scrutiny.
Then show the two models side by side with the measures attached: lane crossings from seven to three, exception volume from 760 a month to an estimate you can defend, median cycle time target derived visibly from the queue times you removed. A to-be design presented as a diagram invites debate about the diagram. Presented as a delta against a measured baseline, it invites a decision.
The deliverable is not the to-be diagram, it is the pair of models plus the numbers that connect them. If you cannot say what the current process costs, you have no way to argue that the new one is better and no way to tell afterwards whether it was.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).