What is process mapping? (And why the map is never the process)

What is process mapping?

Process mapping documents how work actually gets done: every step, who owns it, what triggers it, and where it hands off. Teams draw an "as-is" map of the current process, then a "to-be" map of the target. The gap between the two is the automation backlog.

The notations that matter

Four show up in practice. BPMN 2.0, adopted by the Object Management Group in December 2010, is the formal standard, precise enough to convert into running software. Swimlane diagrams, popularized by Rummler and Brache in 1990, put each owner in a lane so handoffs become visible. SIPOC compresses a process into five columns (suppliers, inputs, process, outputs, customers) for a one-page view. Value stream mapping tags each step as value-adding or waste, which is where cycle-time reduction comes from.

The part nobody warns you about

Map the process you have and you usually discover the process nobody follows. The documented version is the one someone wrote for an audit; the running version has undocumented exception paths, a spreadsheet, and one person everyone messages directly. This is why process mining exists: conformance checking compares an event log against the documented model specifically to find the discrepancies. The methodology is old, going back to Frank Gilbreth's 1921 flow process chart, so the constraint has never been the technique.

Map before you automate, and map from what the systems log, not just from what people say in a workshop. Automating a map that reflects the described process ships an automation your team routes around.

For team leads

Expect the first map to be wrong. Treat the review as the deliverable: the corrections people make are the real process.