Process discovery from records
Most systems already record when each step happened. Read those records and the real process draws itself, detours and all.
About 5 minutes to read.
Key idea
Ask a team to draw its process and you get the process as people believe it runs. Ask the systems and you get the process as it actually ran. Ticketing tools, order systems, case management and finance software usually keep a history: which item, which step, and when. That history is called an event log.
From an event log, process discovery rebuilds the map: every path items took, how often each path occurred, where items waited and where they looped back. It is the same idea that large process mining tools use, applied to a simple export.
The records only tell you what was recorded. Work done outside the system, a phone call or a corridor chat, will not appear, so pair the discovered map with a conversation with the people who do the work.
Example: IT support tickets
Six paths, not one
An IT service desk believes its process is simple: logged, assigned, fixed, closed. The export of three months of tickets tells a richer story. Most tickets follow that path, but a sizeable share bounce back from Fixed to Assigned because the user says the problem is still there, and some sit in Assigned for days because nobody owns the queue at weekends.
Neither finding was on the drawn map. Both are easy to act on once seen.