Process Mapping
Why it matters
Work cannot be delegated, automated or improved until it has been made explicit. Writing it down exposes duplicate steps, hidden waiting time and steps that survive only out of habit. None of that is visible while the process lives in one person's head.
A cleaned-up map also becomes the raw material for a standard operating procedure or an automation, so the effort turns directly into something another person or a piece of software can run.
How to apply it
- Map what really happens, not the version that ought to happen. Ask the person who does the work.
- Start at the trigger, such as "a contract is signed", and end at a clear outcome.
- Record the owner, the tool and any decision or handoff for each step.
- Keep the format as simple as the process allows. A numbered list is enough until branches appear.
- Question every step that exists only because it has always been done.
- Turn the improved map into a checklist or a workflow automation, and review it every few months.
What it is
A process map is a plain record of how work happens today. It can be a numbered list, a table or a flowchart. For each step it shows what triggers it, who does it, what tool they touch and what comes out. Where the path splits or work changes hands, the map shows that too.
Say a founder wants to hand off client onboarding but has never written down what she does. She lists each step from signed contract to the client's first login. Along the way she finds two approval steps that exist only because one client asked for them years ago.
Common mistakes
- Mapping the ideal process instead of the real one.
- Going into so much detail that nobody reads the result.
- Leaving the map in a document and never running the work from it.
