Definition
Process mapping records the real sequence of steps, decisions, handoffs, and waiting periods that make up a piece of work, as it happens rather than as the policy describes it. It is the prerequisite for improving or automating anything.
The gap between the documented process and the real one
Ask three people how a request gets approved and you will usually get three answers, all sincere, all partly right. There is the version in the policy document, the version people describe when asked, and the version that actually happens, including the workaround that exists because a system field was never fixed, and the step that only one person knows to do.
Process mapping captures the third version. That is the whole point, and it is why mapping done purely in a meeting room produces a document that is neat and wrong.
What a useful map records
A diagram of boxes and arrows is a start and not sufficient. The details that make a map actionable:
Who does each step, by role, and what happens when that person is away. How long each step takes, separating work time from wait time, because the difference is usually where the surprise lives. Where the decisions are, and what criteria are actually applied rather than the stated ones. Every handoff, because handoffs are where work stops moving and where information gets lost. The exceptions, and roughly how often each occurs. A process described only in its happy path is a process that will surprise you during automation. Which system holds what, since the number of system-to-system hops predicts most of the integration cost later.
The most revealing number on most maps is the ratio of work time to total elapsed time. A request that takes forty minutes of effort and six days to complete is not a work problem, it is a queueing problem, and automating the forty minutes changes almost nothing.
Mapping vs. mining
| Process mapping | Process mining | |
|---|---|---|
| Source | Observation and interviews | System event logs |
| Shows | Why things happen | What actually happened, at scale |
| Catches | Workarounds, judgment, undocumented steps | Variants, rework loops, true durations |
| Needs | People's time | Systems that log timestamps |
| Good for | Any business | Higher-volume, system-heavy processes |
They complement each other. Mining tells you that 30% of cases take a different path; mapping tells you why, which is the part you can act on.
Common mistakes
Mapping the process you wish you had rather than the one you have. Mapping only the happy path, then discovering the exceptions during the build. Producing a beautiful diagram nobody updates, which is stale within a quarter. And mapping without a purpose: a map made to improve something looks different from a map made to document something, and a map with no decision attached is an artifact rather than a tool.
How Automathing approaches it
We map from observation rather than description, because the documented process and the real one diverge in exactly the places that matter. We record wait time separately from work time, since most delay turns out to be queueing rather than effort. And we map to a decision, whether that is what to fix, what to remove, or what to automate, rather than producing documentation for its own sake.
Frequently asked questions
How long does process mapping take?
A single well-bounded process is typically a matter of days rather than weeks: a few conversations, some observation, and a session to validate the draft with the people who do the work. What takes longer is a process spanning several departments, where the interesting discovery is usually that each department believes a different version.
Do we need special software?
No. A whiteboard, a spreadsheet of steps with durations, or a simple diagramming tool covers most needs. Dedicated tools help when you are maintaining many maps or feeding them into a formal improvement programme, but the tool is never why a mapping exercise succeeds or fails.
Should we map before automating?
Yes, without exception. Automating an unmapped process locks in whatever inconsistency it currently contains, and the exceptions you did not discover during mapping will be discovered during the build, at a much higher cost. Mapping is also what frequently reveals that a step can simply be eliminated, which is a better outcome than automating it.
Who should be involved?
The people who do the work, not only their managers. Managers describe the intended process accurately and are often unaware of the workarounds that keep it running. The person who has done the task three hundred times knows where it actually breaks.