Business process mapping is the practice of drawing how a piece of work moves from start to finish: the steps, who performs each one, the systems and documents involved, the decisions, and the exceptions. Nearly every process map in use was drawn from what people said about their work in interviews and workshops, and that is the source of most of the problems with them. The problem shows up even in carefully built collections. Jan Mendling and colleagues checked the SAP reference model, a library of 604 process models published by the software company as a template for its customers, and found errors in the logic of at least 34 of them, 5.6 percent, such as paths on which the process could get stuck, a count the authors describe as a lower bound. These were models built by specialists with every reason to get them right. A map of a mid-market company's accounts payable process, drawn in an afternoon from a manager's description, carries more risk than that.
What business process mapping produces
A process map answers four questions about a piece of work: what the steps are, who or what performs each one, what triggers a step and what it produces, and where the paths divide. Maps come at different levels of detail. A high-level map shows a whole cycle, such as order to cash, as a handful of stages. A process-level map shows the steps inside one stage, the hand-offs between teams and the main decision points. A procedure-level map shows the clicks, fields and checks inside a single step, which is the level an automation has to work at.
Companies draw maps for different purposes, and the purpose decides the level. Training a new hire needs a process-level map of the normal path. Designing a control needs the points where an error could enter and where it would be caught. Deciding what to automate needs the procedure level, the exception paths and their frequencies, because the exceptions set the cost of the automation.
The common methods, from flowcharts to BPMN
The oldest method is the process chart. Frank and Lillian Gilbreth presented it to the American Society of Mechanical Engineers in December 1921, in a paper titled Process Charts: First Steps in Finding the One Best Way to Do Work, as a record of how a piece of work is done step by step, and the flowchart used in offices today descends from it. The swimlane diagram adds one lane per team or role, so every hand-off between lanes is visible, and hand-offs are where work waits. A SIPOC table, used in Six Sigma projects, lists suppliers, inputs, process steps, outputs and customers, and it is useful for agreeing the scope of a process before anyone draws it in detail.
A value stream map follows one product or service from request to delivery and records the time at each step. Mike Rother and John Shook set out the method in Learning to See, published by the Lean Enterprise Institute in 1998, and its main use is separating the time that adds value from the time spent waiting. The formal end of the range is BPMN, the Business Process Model and Notation, a standard maintained by the Object Management Group that became an international standard, ISO/IEC 19510, in 2013. BPMN has precise symbols for events, gateways and message flows, and a model drawn in it can be read by software as well as by people.
How a process map is usually built
The usual method has five steps. Scope comes first: where the process starts, where it ends, and which variants are in or out. Then interviews and workshops, where the people who do the work and the people who manage it describe the steps. Then a draft map, drawn by an analyst or a consultant. Then validation, where the draft goes back to the participants for correction. And then analysis, where the map is used to find the delays, the rework and the hand-offs that can be removed.
Every step after the first depends on what people say. The interview is the data collection, the workshop is the reconciliation, and the validation checks the draft against the same memories that produced it. The method works well for agreeing on how a process should run. It works less well for learning how it does run.
Why maps drawn from interviews drift from the work
People describe their work less accurately than they do it. Michael Polanyi's observation that "we can know more than we can tell," in The Tacit Dimension, is the interviewer's problem in a sentence: people skip the steps they have automated in their own heads and leave out the exceptions they handle without thinking. Richard Nisbett and Timothy Wilson showed in a 1977 paper in Psychological Review that people reporting on their own mental processes draw on plausible theories of what they must have done. The analyst adds variance of their own: a study in the journal Information Systems gave 89 novice analysts one identical written scenario, and the diagrams it analyzed fell into five distinct styles, from text to pictures.
Time adds the rest. Processes change while they are being mapped and keep changing afterwards: a new supplier sends a different invoice format, a system upgrade moves a field, a new hire finds a workaround and teaches it to the next one. A map drawn once records the process on the day of the workshop. We describe how the documented version of a process falls behind the performed one in why documented processes rot.
Mapping from evidence: event logs and desktop capture
Two sources of evidence produce maps that match the work. The first is the event log. Every ERP, CRM and ticketing system records when a record changed state, and process mining reconstructs the paths the work took from those timestamps, including the variants and how often each occurred. The IEEE Task Force on Process Mining stated the principle in its 2011 Process Mining Manifesto: few processes are in steady state, and the goal is to keep the model current with the work rather than fix it once. The difference between the documented process and the mined one can be large. When Wil van der Aalst and colleagues mined the invoice-handling log of Rijkswaterstaat, the Dutch public works agency, covering 14,279 invoices, they found that more than 17 percent of invoices had bounced back and forth at least once at points where the process was not meant to loop, loops the predefined process model could not show, and that 45 percent of those loops had been started by the workflow system itself after two weeks without activity. In a study published in The Accounting Review, process mining of a global bank's procurement log found payments made without approval and segregation-of-duties violations that the bank's internal auditors had not detected with their usual procedures. Event logs have a limit, which is that they record only what happens inside systems, and much back-office work happens between them, in email, spreadsheets and PDFs.
The second source covers that gap: capture of the desktop work itself, with the participants' consent, which shows the steps between systems that no log contains. This is process improvement, not performance monitoring. What such a capture agent records, and what it is built to discard, is set out in what a capture agent records. Combined, the two sources produce a map with the steps, the exception paths and their frequencies, and they can be run again next quarter to show what has changed. We make the case that this changes the economics of the whole discovery phase in the length of the discovery phase is a business-model decision.
A reasonable counter, answered
A reasonable counter is that the workshop map is valuable because it is drawn together: the people in the room agree on how the process should run, find the hand-offs that annoy them, and leave committed to the changes, and a map generated from logs and observation skips that agreement. The agreement is real and worth having. It is agreement about the process as the room understands it, though, and when that understanding differs from what the records show, the difference is the most useful thing a mapping exercise can find: the exception path nobody mentioned, the approval that takes four days, the step done twice. Build the map from evidence first, then hold the workshop on the evidence. The room then spends its time deciding what to change rather than reconstructing what happens.
Common questions
- What is business process mapping?
- Business process mapping is the practice of drawing how a piece of work moves from start to finish: the steps, who performs each one, the systems and documents involved, the decisions, and the exceptions. The result can be a simple flowchart, a swimlane diagram that shows hand-offs between teams, or a formal model in a notation such as BPMN. Companies map processes to train people, to find delays and rework, to design controls and to decide what to automate. A map is useful for as long as it matches how the work is done.
- What is the difference between a process map and a value stream map?
- A process map shows the steps of a process and the paths between them, including decisions and exceptions, and it can describe any kind of work. A value stream map, from the Lean tradition set out by Mike Rother and John Shook, follows one product or service from request to delivery and records the time spent at each step, separating the time that adds value from the time spent waiting. Process maps are used to understand and redesign how work flows, and value stream maps are used to find delay and waste. Many improvement projects draw both, the value stream first to find where the time goes and a process map to fix the step that loses it.
- How do you keep a process map up to date?
- By building it from records the work produces rather than from what people remember, and by rebuilding it on a schedule. System event logs, such as the timestamps an ERP writes when an order or invoice changes state, show the paths the work took and how often each one occurred. Capture of the desktop work fills in the steps no system logs, such as reading an email or checking a spreadsheet. A map rebuilt from those sources each quarter shows the drift as it happens, where a map drawn once in a workshop goes stale without anyone noticing.