Process Mapping Basics: Seeing Your Business as Systems
Every business is a set of processes wearing a logo. Work comes in one side — an enquiry, an order, a job — moves through hands and systems, and leaves the other side as something a customer paid for. Process mapping is nothing more exotic than drawing that flow so you can see it.
The payoff is that problems that feel like personality ("things just get dropped") turn out to be structure: a handoff nobody owns, a bottleneck through one person, an approval that adds three days and no value. You can't see any of that in your inbox. You can see all of it on a map.
The three maps worth drawing
| Map | What it shows | When to use it |
|---|---|---|
| SIPOC (high level) | Suppliers, inputs, the process in 5–7 blocks, outputs, customers | First pass on any process; agreeing scope before detail |
| Flowchart | Every step and decision in sequence | Preparing to write an SOP, train someone or automate |
| Swimlane | The same flow split by who does each step | Finding handoff failures and unclear ownership between people or teams |
For a business under about twenty people, a whiteboard photo or a simple diagram file is plenty. The thinking is the asset, not the artwork.
How to map a process
- Pick one process with a clear trigger and end. "Customer enquiry to booked job" is mappable; "sales" is not.
- Walk it with the people who do it, following a real recent example end to end. Map what actually happened, including the workarounds — the workarounds are the honest map.
- Write each step on its own line or sticky note as verb + object: "log enquiry", "send quote", "chase deposit".
- Mark the decisions where the path forks, and what decides the fork.
- Mark the waits. Anywhere work sits in a queue — an inbox, an approval, a supplier — note roughly how long. Most process pain lives in the waits, not the work.
- Circle the single points of failure: any step only one person can do, any system only one person can access.
Reading the map
Once it's drawn, interrogate it: Which steps would a customer happily pay for, and which exist only because of how you're organised? Where does work queue? Which handoffs have no agreed format — the "I texted him about it" transfers? Which steps depend on one person's memory or one login?
From map to manual
Maps and SOPs are two altitudes of the same thing. The map shows the route; the SOP is the turn-by-turn navigation for one leg of it. Map first, then write procedures for the steps that are recurring, delegated or dangerous — in that order. If a step touches employment, tax or safety obligations, anchor the SOP to current guidance at business.gov.au or the relevant regulator rather than baking today's rules into the diagram.