How to Map a Business Workflow for Free

Most business processes live in somebody's head. That works until they are on holiday, or until you want to automate part of it and nobody can agree on what actually happens.

Mapping a process is not a big exercise. It is writing down what triggers it, what happens next, where somebody has to make a decision, and where it ends. An hour of that is usually enough to see the problem.

The five kinds of step

Nearly every process is built from the same small set of pieces. Naming them is what turns a vague description into something you can reason about.

• Trigger. What starts it. A form submission, an email arriving, a date, somebody asking.
• Action. Something that happens, usually automatically. Sending a confirmation, creating a record, issuing an invoice.
• Decision. A point where the path splits. These are the steps worth being precise about, because they are where processes disagree with themselves.
• Manual. Something a person has to do. Approving, checking, phoning. These are the steps that cost time.
• System. Where the work sits. Your inbox, a spreadsheet, an accounting package, a CRM.

How to map one

1. 1

   Start at the trigger, not at the middle

   Write down what actually kicks the process off. If there are two ways it can start, that is two triggers and probably two slightly different processes.

2. 2

   Follow it one step at a time

   Add each step in the order it really happens, not the order it should happen. The gap between those two is the interesting part.

3. 3

   Branch at every decision

   Label the edges leaving a decision with the answer that leads down them. "Yes" and "No" is usually enough.

4. 4

   Mark where it ends

   Processes often have more than one ending, and one of them is usually "it gets dropped". Write that one down too.

What to look for once it is drawn

• Manual steps in the middle of automatic ones. Every hand-off between a system and a person is a queue, and queues are where time goes.
• The same decision twice. If two people check the same thing at different points, one of those checks can go.
• A step nobody can explain. Usually a rule that made sense years ago and has outlived the reason for it.
• Re-typing. Anywhere data leaves one system and is typed into another is the most obvious candidate for automation there is.
• Branches that go nowhere. The path where an approval is refused often has no defined ending, which is why those requests quietly disappear.

Common mistakes

• Mapping the process you wish you had. Map the one you have, then draw the second version separately.
• Going too deep. Twenty steps you can read beats sixty you cannot. Split a large process into two maps rather than one unreadable one.
• Leaving the decisions unlabelled. A branch with no condition on it is a diagram that only makes sense to the person who drew it.
• Skipping the failure paths. What happens when something is rejected, missing or late is usually the part worth fixing.