You cannot build software for a process you do not understand. And most organisations do not really understand their processes. Different people have different understandings. Knowledge lives in heads, not documents. Workarounds exist that nobody questions. Exceptions are handled through tribal knowledge. The result: software built on assumptions that do not match reality, systems that fight the way people actually work, and expensive rework when the gaps become undeniable.
Process mapping changes this. It makes the invisible visible. It creates shared understanding before a single line of code is written. It reveals problems that were felt but never articulated. And it provides the foundation for software that actually fits.
Definition: Process mapping is the discipline of documenting how work actually flows through an organisation: who does what, in what sequence, with what decisions, using what information, producing what outputs. The map becomes the shared reference that guides both improvement and system design.
When Processes Are Invisible
Most businesses run on processes nobody has ever written down. People know their part, but nobody sees the whole. Ask three people how something works and you get three different answers. Each person's answer is correct for how they do it. None of them captures how the organisation actually operates.
The problems multiply over time:
Process mapping makes the invisible visible. You can finally see how work actually flows, where it gets stuck, and where it could be better. Everyone looks at the same picture. Disagreements surface and get resolved. Shared understanding emerges.
The Mapping Mindset
Before we discuss techniques and notation, we need to establish the mindset that makes process mapping valuable. The map itself is a tool, not the goal. The goal is understanding that leads to better decisions.
Map reality, not theory. We document how the process actually works, not how it is supposed to work. The workarounds, the exceptions, the "sometimes we do it this way." Reality is where software must operate. The official procedure manual is often fiction; the map should be documentary.
Find the problems. Mapping is not just documentation. It is analysis. Where does work queue up? Where do handoffs fail? Where do decisions lack clear criteria? Problems revealed are problems we can solve. A map that shows no problems is either incomplete or dishonest.
Include the people who do the work. The map must be built with those who actually execute the process, not just those who manage it. Staff know details that managers do not see. The discrepancies between what managers think happens and what actually happens are often the most important insights.
Accept that the first draft will be wrong. Initial maps are hypotheses. They get refined through review, observation, and challenge. The iteration is part of the value. Resist the urge to present a polished map before it has been validated.
Design from understanding. Software built on accurate process understanding fits the work. Software built on assumptions fights reality. The investment in mapping pays off many times over in reduced rework, faster implementation, and higher adoption.
Choosing the Right Diagram Type
Different processes call for different visual approaches. The goal is clarity, not adherence to a particular notation. Choose the format that communicates most effectively to your audience.
Basic Flowcharts
Sequential steps with decision points. The most common and widely understood format.
Best for: Linear processes with clear start and end points. Processes that a single person or role executes.
Key elements:
- Rectangles for activities
- Diamonds for decisions
- Ovals for start/end points
- Arrows showing flow direction
Swimlane Diagrams
Flowcharts with horizontal or vertical lanes for different roles, departments, or systems.
Best for: Cross-functional processes. Processes where handoffs between teams are important. Processes where accountability needs to be explicit.
Key insight: Every time the flow crosses a lane boundary, you have a handoff. Handoffs are where information gets lost and delays accumulate.
State Diagrams
Focus on the states something moves through rather than the activities that move it.
Best for: Order lifecycle, application processing, case management. Anything with a clear status progression.
Example states: Order: Draft, Submitted, Approved, Fulfilled, Invoiced, Closed. The transitions between states (and what triggers them) become the focus.
Value Stream Maps
Show processing time, wait time, and cycle time at each step. A lean manufacturing technique adapted for service processes.
Best for: Identifying waste. Understanding where time is actually spent versus where value is added.
Key metric: Process efficiency = value-adding time / total cycle time. Often shockingly low (5-10% is common).
Most mapping exercises benefit from multiple views. A swimlane diagram shows responsibilities and handoffs. A state diagram shows the lifecycle. A value stream map shows where time goes. Each reveals different insights about the same process. This principle of showing the same information through different lenses is central to visual intelligence.
Notation and Symbology
Consistent notation makes maps readable. Anyone looking at the diagram should understand what each shape means without needing a legend. These conventions have become standard through decades of process improvement practice.
Standard Flowchart Symbols
| Symbol | Name | Usage |
|---|---|---|
| Rectangle | Activity/Task | A step where work is performed. Label with verb-noun: "Review application", "Update record", "Send notification". |
| Diamond | Decision | A point where the flow branches based on a condition. Label with the question being asked. Outgoing arrows labelled with outcomes (Yes/No, Approved/Rejected, etc.). |
| Oval/Pill | Start/End | Entry and exit points of the process. "Start" or "End", or a specific trigger/outcome: "Customer enquiry received", "Order fulfilled". |
| Parallelogram | Data/Document | Information input or output. Forms, reports, emails, records. Shows where data enters the process and what outputs it produces. |
| Circle (small) | Connector | Links parts of the diagram when the flow needs to jump. Labelled with matching letters or numbers. Avoids crossing arrows. |
| Wavy rectangle | Delay/Queue | Where work waits. Explicit representation of queuing time. Critical for value stream mapping. |
Swimlane Conventions
Swimlanes add a dimension of responsibility to the flowchart. Each horizontal band represents a different actor: a person, role, department, or system.
Annotation Best Practices
The diagram itself shows structure and flow. Annotations add the detail that makes the map useful for analysis and system design.
- Time annotations: Processing time (how long the step takes when being worked), wait time (how long work sits before being picked up), and total cycle time.
- Volume annotations: How many items flow through per day/week/month. Where volumes vary, note the range.
- Exception rates: What percentage of items take the "unhappy path" at decision points. If 40% of applications require rework, that changes priorities.
- System references: Which software supports each step. Where data lives. What integrations exist or are needed.
- Pain points: Mark known problems directly on the map. Visual proximity to the source of the problem aids discussion.
Capturing Exceptions and Edge Cases
The happy path is easy to map. The value is in documenting what happens when things do not go as planned. Exceptions reveal where processes are fragile, where workarounds have emerged, and where software must be flexible.
Critical insight: Software built only for the happy path will fail on the first exception. And exceptions are often more common than you think. Ask "What happens when this goes wrong?" at every step.
Types of Exceptions to Capture
Input Exceptions
What happens when inputs are incomplete, incorrect, or missing entirely? A customer submits an application without required documents. An order arrives with an invalid product code. A form has contradictory information. The map should show the remediation path: who handles it, how they resolve it, how long it typically takes.
Conditional Branches
Decision points where multiple outcomes are possible. Some are well-defined (Approved/Rejected). Others are fuzzy ("needs further review"). Document all the real outcomes, not just the official ones. Include the criteria for each branch, especially when judgment is involved.
Escalation Paths
What happens when someone cannot handle a case? To whom does it escalate? What triggers escalation? What authority does the escalation point have? Escalation paths reveal both the complexity of decisions and the concentration of authority.
Rework Loops
Where does work circle back due to errors or rejection? Rework is expensive. The map should show where rework originates, where it returns to, and how frequently it occurs. High rework rates indicate quality problems at earlier stages.
Techniques for Uncovering Exceptions
Staff who execute the process daily know the exceptions. They handle them routinely. But they often do not think to mention them unprompted, because workarounds have become normalised.
Ask "What can go wrong?" At each step, explicitly ask what failures occur. Not what could theoretically happen, but what actually does happen. Get specific examples.
Ask "What do you do when that happens?" The informal exception handling process is often more interesting than the official one. Document reality.
Review recent problem cases. Pull examples from the last month where something went wrong. Walk through what happened and how it was resolved. These real cases reveal exceptions that hypothetical questioning misses.
Shadow the work. Observation catches things interviews miss. Watch for the moments when someone pauses, checks something unexpected, or does something "just to be safe." Those are often undocumented exception handling routines.
Stakeholder Involvement in Process Mapping
A map built in isolation will be wrong. Process mapping must involve the right people at the right time, in the right ways. The involvement serves multiple purposes: getting accurate information, building buy-in, and creating shared ownership of the result.
Who Needs to Be Involved
| Stakeholder | What They Contribute | How to Involve Them |
|---|---|---|
| Process executors | Ground truth about how work actually happens. Details that management does not see. Knowledge of workarounds and exceptions. | One-on-one interviews. Observation sessions. Validation workshops. |
| Supervisors/Team leads | Context about why processes evolved. Knowledge of variations across team members. Awareness of common problems. | Interviews. Participation in validation sessions. |
| Process owners | Authority to validate the map as accurate. Decision rights about future state changes. Accountability for process performance. | Review sessions. Sign-off on completed maps. |
| Adjacent process owners | Understanding of inputs and outputs. Knowledge of integration points and handoffs. Upstream and downstream perspective. | Boundary review sessions. Handoff validation. |
| System administrators | Knowledge of current system capabilities and constraints. Understanding of data flows and integrations. | Technical validation sessions. |
Facilitation Approaches
Different situations call for different approaches to gathering process information.
Individual interviews work best for initial discovery. People speak more freely without colleagues present. You can probe into individual variations and personal workarounds. Plan 45-60 minutes per interview.
Group workshops are powerful for validation and reconciliation. When people see the draft map together, disagreements surface. "That's not how I do it." These disagreements are valuable. They reveal inconsistency and spark discussion about which approach is correct.
Observation sessions validate what interviews revealed. Watch the process happen in real time. Note the gaps between what people said and what they do. These gaps are not lies; they are blind spots. Routine behaviours become invisible to those who perform them.
Validation checkpoint: The map is ready when staff at every level look at it and say "Yes, that is how it works." Not "That is how it should work." Not "That is close enough." Actual recognition of their daily reality.
Current State vs Future State Mapping
Process mapping typically involves two distinct artefacts: the current state map (how things work today) and the future state map (how things should work after improvement). These serve different purposes and should be created in sequence.
Current State Map
Documents how the process actually works today, including all the workarounds, exceptions, and inefficiencies.
Purpose:
- Create shared understanding
- Identify problems and opportunities
- Establish baseline for improvement
- Capture institutional knowledge
Future State Map
Documents how the process should work after improvements are implemented. A vision that guides design and development.
Purpose:
- Define the improvement target
- Guide system requirements
- Align the team on direction
- Enable change management
Common Problems the Current State Map Reveals
Mapping the current state is diagnostic. The problems that emerge fall into recognisable patterns.
Designing the Future State
The future state map is not wishful thinking. It is a realistic target that addresses the problems identified in the current state while respecting constraints.
Start with the problems. List what the current state map revealed. Prioritise by impact and feasibility. The future state should explicitly address the most important problems.
Apply improvement patterns:
- Eliminate steps that add no value
- Automate manual steps where feasible
- Reduce handoffs by expanding role scope
- Push decisions earlier with clearer criteria
- Add quality checks where errors originate
- Parallelise steps that do not depend on each other
- Remove approval gates that add delay without adding value
Validate feasibility. The future state must be achievable. Review with the team: Is this realistic? What barriers exist? What dependencies must be resolved? A beautiful future state map that cannot be implemented helps no one.
Define the gap. Compare current and future state maps explicitly. What changes? What systems must be built or modified? What training is needed? What policies must change? The gap analysis drives the implementation plan.
From Maps to System Requirements
Process maps are not just documentation. They are design inputs. When software needs to support a process, the map shows what the software must do. Each element of the map translates into system requirements.
Translation Patterns
| Process Element | System Requirement | Example |
|---|---|---|
| States | Status field with defined values. Workflow engine states. | Order status: Draft, Submitted, Approved, Fulfilled, Invoiced, Closed |
| Transitions | Workflow rules. State change logic. Validation on transition. | Can only move to "Fulfilled" if all items have ship dates |
| Decision points | Business rules engine. Conditional logic. Threshold definitions. | Auto-approve orders under £1,000; route others to manager |
| Handoffs | Assignment rules. Notifications. Queue management. | On approval, assign to fulfilment queue and notify warehouse |
| Data inputs | Form fields. Validation rules. Required fields per stage. | Customer PO required before submission; delivery address validated |
| Wait times | SLA monitoring. Age alerts. Escalation triggers. | Alert if pending approval > 24 hours; escalate at 48 hours |
| Roles/swimlanes | User roles. Permission sets. Role-based views. | Sales can create; Finance can approve; Warehouse can fulfil |
| Exceptions | Error handling. Exception workflows. Override permissions. | Invalid address triggers address review sub-process |
Automation Opportunity Assessment
The map shows where automation adds value. Not every step should be automated. Focus on steps that are high-volume, rule-based, error-prone, or time-sensitive.
High-volume, repetitive tasks
Steps that happen frequently with consistent logic. Data entry, status updates, routine notifications. Automation eliminates tedium and reduces errors.
Rule-based decisions
Decisions with clear, documentable criteria. Approval thresholds, eligibility checks, routing rules. The system applies the rules consistently, freeing people for judgment-based decisions.
Error-prone manual steps
Steps where humans make predictable mistakes. Transcription errors, calculation mistakes, missed handoffs. Automation enforces correctness.
Time-sensitive triggers
Actions that must happen promptly. SLA reminders, escalations, scheduled follow-ups. Systems are more reliable than human memory for time-based actions.
Integration Point Identification
The map shows where data must flow between systems. Every arrow that crosses a system boundary is a potential integration point.
- Data inputs: Where does information come from? External systems, user entry, automated capture?
- Data outputs: Where does information need to go? Downstream systems, reports, notifications?
- Synchronisation needs: What data must stay consistent across systems? Master data, status updates, transaction records?
- Real-time vs batch: Does data need to flow immediately or can it batch? Real-time integration is harder and more expensive.
How We Create Process Maps
Our approach to process mapping follows a structured sequence. Each step builds on the previous, moving from initial discovery through validation to actionable output.
Scope and frame
Define the process boundaries. What triggers the start? What constitutes completion? What is in scope and out of scope? Clear boundaries prevent scope creep and ensure focus.
Talk to the people who do the work
We interview staff at every level. The person doing the work knows details that managers do not see. The manager knows context that staff do not have. Both perspectives matter.
Observe the process in action
Interviews tell us what people think happens. Observation shows what actually happens. The gaps are revealing. We watch for undocumented steps, informal decisions, and habitual workarounds.
Draft the map
Create an initial visual based on interviews and observation. This is a hypothesis, not a finished product. Expect it to be revised substantially during validation.
Validate with participants
We show the map to people who do the work. Does this match reality? What is missing? What is wrong? We iterate until the map is accurate and participants recognise their work in it.
Identify problems and opportunities
Analyse the validated map. Where are the bottlenecks? Where does rework occur? Where is time wasted? Annotate the map with findings. This analysis drives improvement priorities.
The outcome is not just a diagram. It is shared understanding, documented problems, and a foundation for improvement. The map becomes a reference that guides decisions about process change and system design. For processes that will be automated, the map becomes the specification for workflow engines.
Maintaining and Evolving Process Documentation
A process map is only valuable if it stays current and actually gets used. Too many mapping exercises produce beautiful diagrams that gather dust. Living documentation requires ongoing attention.
Keeping Maps Current
Making Maps Useful
Documentation that nobody looks at might as well not exist. Process maps should be actively used, not filed away.
Training material: New staff learn from the maps. The visual shows how their work fits into the larger process. Onboarding becomes faster and more consistent.
Problem-solving reference: When something goes wrong, the map shows where to look. It provides context for diagnosis and helps identify root causes.
Improvement discussions: Process improvement starts with the current state map. Proposed changes can be sketched on the map. Impact of changes becomes visible.
System change requests: When software needs modification, the process map shows the context. Developers understand why the request matters and how the change fits the workflow.
Evolution Over Time
Processes change. Markets shift, technology evolves, organisations restructure. Process documentation must evolve with them.
Scheduled reviews: Quarterly or semi-annual reviews catch drift before it becomes severe. Compare the map to current reality. Update where they diverge.
Change-triggered updates: System deployments, reorganisations, and policy changes should trigger documentation review. Build this into change management procedures.
Continuous improvement integration: When process improvements are implemented, update the map to reflect the new state. The map should always represent how things work now, not how they used to work.
What You Get
Process mapping as part of our work delivers tangible outcomes that persist long after the mapping exercise is complete.
-
Shared understanding Everyone sees the same picture of how work flows. Disagreements surface and get resolved. Assumptions become explicit.
-
Visible problems Bottlenecks and inefficiencies revealed, not hidden. Problems that were felt but not seen become explicit and discussable.
-
Better software design Systems built on accurate process understanding. Requirements derived from reality, not assumptions. Fewer surprises during implementation.
-
Smoother implementation Software meets reality without conflict. Users recognise their work in the system. Adoption is faster because the system fits the work.
-
Preserved knowledge Critical process information documented and accessible. Not trapped in individual heads. The organisation becomes more resilient.
-
A foundation for improvement Maps that enable ongoing refinement. Baseline for measuring improvement. Reference point for future changes.
Understanding comes before building. Building is faster and better as a result. The investment in mapping pays returns throughout the software lifecycle.
Further Reading
- BPMN 2.0 Specification - Official standard for business process modelling notation.
- Value Stream Mapping Guide - Authoritative explanation of VSM from the Lean Enterprise Institute.
- Miro Process Mapping Templates - Free collaborative templates for online process mapping workshops.
Map Your Processes
We map processes as part of designing software that supports them. Current state analysis that reveals problems. Future state design that guides development. Documentation that enables ongoing improvement. Not just pretty diagrams. Working tools that make complex processes visible and buildable.
Let's talk about mapping your processes →