Business Process Mapping with BPMN: A Practical Walkthrough

What is Business Process Mapping?

Business process mapping is the practice of visually documenting the sequence of activities, decisions, and handovers that make up a business process from start to finish. It creates a shared, unambiguous picture of how work flows through teams, systems, and departments — making the invisible visible.

While the terms are sometimes used interchangeably, there is an important distinction between process mapping and process modelling. Process mapping typically refers to creating a visual diagram of the current state of a process — a snapshot of how things work today. Process modelling goes further, using a formal notation (such as BPMN) to create structured, detailed representations that can be analysed, simulated, and even executed by process automation engines.

For UK organisations navigating regulatory requirements, digital transformation, and competitive pressures, well-documented processes are not a luxury — they are a necessity. The benefits are substantial and measurable:

Beyond efficiency gains, process mapping delivers visibility — everyone can see how the process works, where the bottlenecks are, and who is responsible for each step. It supports compliance — documented processes are essential for ISO 9001, FCA regulations, and UK GDPR accountability requirements. And it enables continuous improvement — you cannot improve what you cannot see.

Whether you are a business analyst, process owner, or change manager, process mapping is one of the most powerful tools in your professional toolkit. And BPMN 2.0 is the industry standard notation for doing it well.

Introduction to BPMN 2.0

Business Process Model and Notation (BPMN) is an international standard maintained by the Object Management Group (OMG) — the same body that oversees UML and other widely adopted modelling standards. BPMN 2.0, the current version, was released in 2011 and has become the de facto standard for process modelling across industries worldwide.

Before BPMN, organisations used a bewildering variety of process diagramming approaches — flowcharts, swim lane diagrams, EPC diagrams, data flow diagrams — each with different symbols, conventions, and levels of formality. This made it difficult to share process models across teams, departments, or organisations without extensive explanation. BPMN solved this problem by providing a single, standardised notation that is understood by business analysts, process owners, IT developers, and external stakeholders alike.

The power of BPMN lies in its ability to serve multiple audiences. A business stakeholder can read a BPMN diagram and understand the process flow without technical training. A software developer can use the same diagram as a specification for process automation. This bridge between business and IT is what makes BPMN uniquely valuable.

The Four Categories of BPMN Elements

BPMN organises its visual elements into four categories, each serving a distinct purpose in describing a business process:

You do not need to learn every element in the BPMN specification to create useful process maps. In practice, 80% of process models use only about 20% of the available elements. The core set — events, tasks, gateways, sequence flows, and pools with lanes — is sufficient for the vast majority of business process mapping needs.

BPMN Core Elements Explained

To create effective BPMN process maps, you need a solid understanding of the core elements and how they work together. This section provides a detailed reference for the elements you will use most frequently.

Events

Events represent something that happens during the course of a process. They affect the flow and usually have a cause (trigger) or a result. BPMN uses circles to represent events, with different border styles and internal markers to distinguish between types:

• Start Event (thin single border) — indicates where the process begins. Every process must have at least one start event. Common triggers include receiving a message, a timer firing, or a manual initiation.
• Intermediate Event (thin double border) — occurs between the start and end of a process. These can represent waiting points (e.g., waiting for approval), catching signals, or throwing messages to other processes.
• End Event (thick single border) — indicates where the process finishes. A process can have multiple end events to represent different outcomes (e.g., "Application Approved" and "Application Rejected").

Activities

Activities represent work that is performed within the process. They are shown as rounded rectangles and come in two main forms:

• Tasks — atomic activities that cannot be broken down further within the current model. BPMN defines several task types: User Task (performed by a person with system assistance), Manual Task (performed without system support), Service Task (automated by a system), Script Task (executed by a process engine), and others.
• Sub-Processes — compound activities that contain their own internal process flow. A sub-process is marked with a small "+" symbol and can be expanded to show its detail or collapsed to keep the parent diagram clean and readable.

Gateways

Gateways control the divergence and convergence of sequence flows — they are your decision points and parallel processing points. They are shown as diamonds with different internal markers:

Connecting Objects and Swimlanes

Sequence Flows (solid arrows) connect flow objects within a single pool, showing the order in which activities are performed. Message Flows (dashed arrows) show communication between separate pools — for example, a customer sending an order to a supplier. Message flows always cross pool boundaries; they never connect elements within the same pool.

Pools represent major participants in a process — typically separate organisations or distinct business entities. Lanes are subdivisions within a pool that represent different roles, departments, or systems. For example, a "Loan Application" pool might contain lanes for "Customer", "Branch Staff", "Underwriting", and "Core Banking System".

Creating an As-Is Process Map

An as-is process map documents how a process actually works today — not how it is supposed to work, not how the policy manual says it should work, but the reality on the ground. This distinction is critical. The gap between documented procedures and actual practice is often where the most significant improvement opportunities lie.

Before you open any modelling tool, you need to invest time in process discovery — the systematic gathering of information about how the current process operates. There are several proven techniques for this:

Process Discovery Techniques

• Direct Observation — Watch the process being performed in real time. This reveals the actual steps, workarounds, and pain points that people may not mention in interviews because they have become so habitual they are invisible. Shadow different team members to capture variations in practice.
• Structured Interviews — Speak to the people who perform the process daily. Ask open-ended questions: "Walk me through what happens when..." and "What do you do when things go wrong?" Interview people at different levels — frontline staff, supervisors, and managers often have very different perspectives on the same process.
• Document Review — Examine existing procedure manuals, work instructions, training materials, and system documentation. These provide the intended process, which you can then compare against observed reality. Pay attention to version dates — outdated documents may describe processes that have evolved significantly.
• Process Mining — For digitised processes, extract event logs from IT systems (ERP, CRM, workflow tools) to reconstruct the actual process flow from data. Process mining reveals the true process, including variants and deviations that no single person may be aware of. Tools like Celonis and Disco are widely used in UK organisations for this purpose.
• Workshops — Bring together a cross-functional group of process participants and use facilitated techniques (such as brown-paper mapping or digital whiteboarding) to collaboratively build the process map. This surfaces different perspectives and resolves conflicting understandings in real time.

Defining Process Boundaries

Before mapping begins, clearly define the scope and boundaries of the process. Determine the trigger (what starts the process), the outcome (what constitutes a completed process), and the participants involved. A well-defined scope prevents the common trap of scope creep during mapping — where you keep following the process further and further until you are mapping the entire organisation.

Mapping the Current State

With your discovery data in hand, build the as-is BPMN diagram step by step. Start with the happy path — the normal, expected flow from start to finish when everything goes right. Then layer in exceptions and alternative paths — what happens when an approval is rejected, when information is missing, when a system is unavailable. Finally, capture workarounds — the unofficial steps that people take to get around system limitations or process gaps.

Designing the To-Be Process

The to-be process map represents your redesigned, improved future state. It is the bridge between identifying problems in the as-is process and implementing tangible changes that deliver measurable benefits. Designing the to-be process is where business analysis, lean thinking, and stakeholder engagement come together.

Gap Analysis: From As-Is to To-Be

Begin by systematically analysing the as-is process map to identify gaps, waste, and improvement opportunities. Common problem patterns include:

• Unnecessary handovers — each handover between people or departments introduces delay, potential for error, and loss of context
• Redundant approvals — approval steps that exist for historical reasons but no longer add value
• Manual data entry — information being re-keyed from one system to another, introducing errors and consuming time
• Waiting time — process steps where work sits idle waiting for input, approval, or resources
• Rework loops — steps that frequently produce errors, requiring work to be sent back and repeated

Improvement Strategies

There are several well-established strategies for improving processes, many drawn from lean and business process improvement methodologies. The table below summarises the most common improvement patterns:

Redesigning with BPMN

When creating the to-be BPMN model, work collaboratively with process participants and stakeholders. The to-be map should be validated against business requirements, compliance obligations, and technical feasibility before it is treated as the target state. Key principles for effective to-be design:

• Start with the customer outcome — Design the process backwards from the desired result. What does the customer (internal or external) need? Every step should contribute to delivering that outcome.
• Minimise handovers — Each handover is a potential failure point. Where possible, keep work within a single team or enable self-service.
• Design for exception handling — Do not just map the happy path. Explicitly model how exceptions, errors, and edge cases will be handled in the new process.
• Include measurable targets — Annotate the to-be model with target cycle times, SLAs, and quality thresholds so that improvement can be measured after implementation.

Tools and Implementation

Choosing the right tooling is an important practical consideration for any process mapping initiative. The market offers a wide range of options — from free drawing tools to enterprise-grade Business Process Management Suites (BPMS) that can execute your BPMN models directly.

BPMN Modelling Tools Compared

The right tool depends on your needs: are you creating diagrams for communication and documentation, or do you need to automate and execute processes? The table below compares popular options available to UK organisations:

From Model to Execution

For organisations ready to move beyond documentation, Business Process Management Suites (BPMS) can take your BPMN models and execute them directly — routing work to the right people, enforcing business rules, integrating with systems via APIs, and tracking performance in real time. This is the ultimate value of BPMN: the same model that business stakeholders use to understand the process can be deployed as a running application.

However, process automation is not always the right first step. Many UK organisations achieve significant improvements simply by documenting, standardising, and optimising their processes before investing in automation technology. The BPMN model itself becomes a powerful management tool — a shared reference point for training, compliance, auditing, and continuous improvement.

Measuring Improvement

Process improvement must be measured to be meaningful. Define Key Performance Indicators (KPIs) for each process before implementing changes, then track them after the to-be process is in place. Common process KPIs include:

• Cycle time — Total elapsed time from process start to completion
• Processing time — Actual time spent working (excluding waiting)
• First-time-right rate — Percentage of cases completed without rework
• Throughput — Number of cases processed per unit of time
• Customer satisfaction — Internal or external customer ratings of the process outcome
• Cost per transaction — Total cost of resources consumed per process instance

UK Regulatory Considerations

UK organisations should be aware of several regulatory and standards frameworks that intersect with process documentation:

• UK GDPR and Data Protection Act 2018 — Article 30 requires organisations to maintain records of processing activities. BPMN process maps that show data flows are an excellent way to demonstrate compliance and support Data Protection Impact Assessments (DPIAs).
• ISO 9001 Quality Management — Requires organisations to determine and manage the processes needed for the quality management system. BPMN provides the ideal notation for documenting these processes to the level of detail required by ISO auditors.
• FCA requirements — Financial services firms regulated by the Financial Conduct Authority must demonstrate that their processes meet conduct and prudential requirements. Documented BPMN models provide auditable evidence of process design and controls.
• NHS and public sector — NHS Digital and central government departments increasingly require documented processes for clinical pathways, service design, and operational procedures.