How to map a business process without technical knowledge
A simple way to make a real workflow visible using people, decisions, handoffs and information instead of technical diagrams.
Map what happens, not what should happen
Begin with one recent example and follow it from the event that started the work to the result that ended it. Avoid writing the ideal policy from memory.
The differences between the documented process and the real process often reveal the most useful improvement opportunities.
Five elements are enough for a first map
You do not need specialised notation. Use consistent boxes and arrows, then capture the information people actually need at each step.
- Trigger: what event starts the process?
- Owner: who is responsible for moving it forward?
- Action: what work is completed?
- Decision: what changes the path?
- Outcome: how does everyone know the process is complete?
Add friction only after the path is clear
Mark waiting, duplicate entry, rework and unclear ownership in a second pass. Mixing every problem into the first drawing can make the process harder to understand.
Review the map with someone who performs the work. Their corrections are more valuable than making the diagram visually perfect.