Make the work visible
What is business process mapping?
Business process mapping starts by having people walk through how they actually do the job and why they follow each practice. The map connects the trigger, people, systems, information, decisions, waits, exceptions, and confirmed result. Written SOPs are valuable evidence when they exist, but the current process must still be checked against real work. The goal is to understand the foundation before changing or automating it.
Scope
Choose a boundary people can follow
A map becomes useless when it starts with “customer needs help” and ends with “customer is happy.”
Define observable start and end states
Start with a business event that can be recognized, such as a validated inquiry, approved quote, received payment, or reported service problem. End with evidence that the selected outcome occurred, such as an accepted assignment, posted transaction, completed appointment, or closed exception.
Name what is outside the map. Upstream and downstream processes can be referenced without pulling the entire company into one diagram.
Identify the process owner and participants
The owner is accountable for the outcome and has authority to resolve policy. Participants include the employees, customers, vendors, systems, and automated services that perform or accept work.
Use roles in the map rather than only employee names so the design remains understandable when staffing changes. Record named exceptions separately when they matter.
Current state
Map what happens, not what the procedure claims
The official instructions and the working process are both evidence, but they are not always the same thing.
Walk real cases with the people involved
Ask the people doing the work to walk through recent normal, failed, delayed, and unusual jobs. Reconstruct the messages, records, approvals, spreadsheets, calls, system events, and manual workarounds, then compare that evidence with any written SOPs.
Ask what happened next, why that practice exists, who knew the work was ready, what information they needed, how they confirmed completion, and what they did when the normal path failed. Preserve legitimate differences instead of drawing the preferred process and pretending it is current.
Separate work time from waiting time
Record the time spent doing work and the time spent waiting in a queue, inbox, approval, schedule, or external system. A five-minute task can create a three-day cycle when ownership or readiness is unclear.
Also mark repeated entry, correction, searching, clarification, switching systems, duplicate outreach, and abandoned cases. Those costs often remain invisible in a polished flowchart.
Label policy gaps honestly
Distinguish current behavior, written policy, required control, and proposed improvement. When employees use different rules, do not draw one preferred route and call it current state.
An unresolved decision belongs on the map as an open policy question with an owner.
Decisions and handoffs
Show the information and authority behind each step
Boxes and arrows are not enough to explain why the process moves.
Document decision criteria
For each branch, record the question, required facts, authoritative source, permitted decision maker, possible outcomes, and what happens when information is missing or disputed.
Do not hide judgment behind labels such as approved, qualified, or complete. State the evidence that makes the label true.
Define handoff acceptance
A handoff needs a sender, receiver, package of information, readiness condition, acceptance evidence, expected timing, and fallback. Sending an email or changing a status does not prove the next role accepted responsibility.
Where systems exchange data, identify which system owns each fact, the relevant identifier, expected delay, and exception path.
Failure and rework
Exceptions belong on the map
The uncommon path may consume most of the effort or create the greatest risk.
Group exceptions without erasing them
List observed exceptions, then group those with the same owner and recovery behavior. Examples include missing data, duplicate records, rejected approval, unavailable staff, system failure, changed customer request, and work that exceeds its allowed wait.
Record whether the process retries, corrects, escalates, compensates, pauses, cancels, or completes manually. Include how the customer or affected participant learns the status.
Trace rework to its origin
When work loops backward, record what was wrong, where it was detected, who corrected it, and whether the earlier step could have prevented it. Avoid blaming the final person who noticed a defect created upstream.
Repeated exceptions are process evidence. They should influence the future state rather than remain informal hero work.
Shared evidence
Validate before redesigning
The people doing the work should recognize the map, including its uncomfortable parts.
Review the map against records
Walk the diagram with each participating role and compare it with representative cases. Resolve factual errors, preserve legitimate variants, and mark disagreements that require an owner rather than forcing false consensus.
Use BPMN or another formal notation when the audience, complexity, or implementation benefits from it. A simple diagram is valid when its meaning is unambiguous and the participants can use it.
Establish the baseline
Measure volume, cycle time, touch time, waiting time, handoffs, re-entry, error and rework rates, exception frequency, abandonment, customer effort, and confirmed outcomes where the data is trustworthy.
Document gaps in measurement. A missing timestamp should not become a confident estimate merely because an ROI calculation needs a number.
Improvement
Design the future state as a controlled change
Remove unnecessary work before deciding how to automate the remaining work.
Challenge every step
Ask whether the step protects a real requirement, creates customer value, supplies necessary information, or controls risk. Eliminate duplication, clarify ownership, simplify decisions, improve the source data, and move checks earlier where appropriate.
Then decide which parts should remain human, use an existing system feature, integrate systems, or require custom automation.
Pilot one complete slice
Define the changed boundary, owners, rules, exceptions, measures, test cases, training, monitoring, rollback, and review date. Compare the new path with the baseline using normal and failed cases.
ISO's process approach similarly emphasizes planning processes and objectives, implementing them, checking results, and acting on evidence. The map supports that cycle; it does not finish it.
Common questions
What business owners usually want to know.
Does a process map need formal BPMN notation?
No. BPMN can provide precise shared symbols for complex work and implementation, but the map must first be understandable to the people who perform and own the process. Use enough notation to remove ambiguity.
What is the difference between a current-state and future-state map?
A current-state map documents how work actually happens now, including workarounds and failures. A future-state map describes an approved change. Mixing them hides the baseline and makes the proposed design look proven.
How detailed should a process map be?
Detailed enough to explain ownership, decisions, handoffs, systems, waits, and exceptions inside the selected boundary. If the diagram is unreadable, split a complex portion into a subordinate map rather than removing consequential behavior.
Does process mapping prove what should be automated?
No. It reveals the current work and creates evidence for redesign. Automation still requires stable rules, trustworthy inputs, ownership, security, exception handling, maintenance, and a defensible benefit.
Research
Sources and further reading
Reviewed 2026-08-24. Use these references to check the details and continue your own research.
Need help applying this to your business?
Tell us where the process breaks down today. We will ask the questions needed to find the cause and decide what is worth fixing first.