Business Process Modeling: Techniques, Tools and Examples

Business process modeling is the practice of describing how a process works — its steps, decisions, roles, hand-offs and information flows — in a structured, usually visual notation that is precise enough to analyse, compare and improve. A process map shows roughly what happens. A process model shows it with enough rigour that two people reading it reach the same understanding, and that a system could, in principle, execute it.

This guide is written for operations, IT and HR leads at companies of 10–500 people who need to get a process out of people's heads and into a form that can be argued over, fixed and then run. It is not an academic treatment of notation. It covers the techniques that actually get used in mid-sized companies, when each one earns its keep, how to read and write enough BPMN 2.0 to be dangerous, and how to run a modeling exercise that produces an accurate as-is model and a defensible to-be model.

By the end you will be able to choose the right technique for the job, draw a model that practitioners recognise as their own work, analyse it for hand-offs, rework and delay, and — the part most guides skip — turn it into something that runs, so it does not become another diagram in a shared drive that nobody opens again.

What Is Business Process Modeling?

A process model is a structured representation of a business process: the activities performed, the order they happen in, the events that start and end them, the decisions that route work one way or another, the people or systems responsible, and the information that moves between them. The word "structured" is doing real work in that sentence. A whiteboard sketch of boxes and arrows is a picture of a process. A model uses a defined set of elements with defined meanings, so that a diamond always means a decision and a dashed arrow always means a message crossing an organisational boundary.

That distinction matters because the point of modeling is analysis, not decoration. Once every element has a fixed meaning, you can count things: how many hand-offs between departments, how many decision points, how many places work can loop back for rework, how long each segment takes. You can compare two versions of the process on the same terms. And if the notation is formal enough, software can read it and run it.

Most process modeling in practice sits at one of three levels of detail, and choosing the level up front avoids the most common failure, which is a model that is too detailed for executives and too vague for the people doing the work.

Descriptive models

A descriptive model shows the main path through a process at a level a new joiner or a director could follow in five minutes. Ten to twenty activities, the major decision points, the roles involved. It answers "what happens, roughly, and who does it". Most process documentation, and most process mapping, lives here.

Analytical models

An analytical model adds the detail needed to find problems: every decision with its branching conditions, every exception path, timing information, volumes, the systems touched at each step. This is the level at which you can measure cycle time, find the rework loop that nobody mentioned in the interviews, and show why the "two-day" approval actually takes nine.

Executable models

An executable model is precise enough for software to run. Every task has an assignee rule, every gateway has a machine-readable condition, every data item is typed. BPMN 2.0 was designed so that the same notation could scale from a descriptive sketch to an executable definition, which is a large part of why it became the standard.

Process Modeling vs Process Mapping vs Process Documentation

These three terms overlap enough that people use them interchangeably, and differently enough that the confusion causes real problems: a team asks for a "process map", receives a forty-element BPMN model, and files it unread. It helps to be precise about what each one produces and who it is for.

Process mapping is the discovery activity. You gather the people who do the work, walk through what actually happens, and draw it — usually as a flowchart or swimlane diagram — at a level everyone in the room can follow. The output is shared understanding and a first picture of the process. Mapping is fast, informal and collaborative, and it is usually the first thing you do.

Process modeling takes that picture and makes it rigorous. A model uses a formal notation, captures decisions and exceptions explicitly, and is built to be analysed, simulated or executed. Modeling typically follows mapping, and the map is often the raw material for the model. You would not model a process you had not first mapped, but you might map a process and never model it.

Process documentation is the written procedure: the standard operating procedure, the work instruction, the checklist. It tells one person how to perform their part of the process correctly. Documentation is derived from the model (or the map), but it is a different artefact with a different reader. A technician following a laptop-provisioning SOP does not need the BPMN gateway that routed the new hire to them; they need the fourteen steps to get the device configured.

For a small team with a simple process, mapping followed directly by a checklist is often the whole job, and this guide's sibling on business process mapping in seven steps covers that route. Modeling earns its extra cost when the process crosses several teams, has many decision points, is a candidate for automation, or is about to be redesigned and you need to prove the new version is better than the old one.

Why Model a Process at All?

Modeling is more work than mapping, so it needs a reason. There are four that hold up in practice.

Analysis

A formal model lets you see the process as a whole and count what matters. In a typical mid-sized company's purchase-to-pay process, the model is usually the first time anyone has noticed that a request touches five people before the person who can actually approve it, or that "rejected — please resubmit" sends the requester back to step one rather than to the step that failed. Hand-offs, queues and rework loops are almost invisible from inside a process and almost impossible to miss in a model of it.

Simulation and what-if

Once a model carries timing and volume data, you can ask what happens if volumes double, if the approval threshold changes, or if two sequential steps run in parallel — before you change anything. Full discrete-event simulation is overkill for most teams, but even a spreadsheet run against the model's segments ("if we remove the second approval, the median lead time falls from nine days to four") is a stronger argument than an opinion.

Communication and alignment

A process that spans finance, IT and HR has three partial owners, each of whom sees their own lane clearly and the others as a fog. A shared model, in a notation all three have agreed to read, is often the first time they see the whole thing. Many "process problems" turn out to be alignment problems, and the model resolves them simply by existing.

Automation readiness

You cannot automate what you cannot specify. Every business process automation effort — whether that means workflow automation in a platform, an integration between two systems, or an executable BPMN engine — starts with a model precise enough for a developer or a configurator to work from. Teams that skip modeling and go straight to the tool discover the decision rules and exceptions one at a time, in production, at the worst possible moment.

Business Process Modeling Techniques

There is no single correct notation. Each technique below answers a different question well, and most teams end up using two or three of them for different purposes. The descriptions focus on when each one is the right choice.

Flowcharts

The oldest and most widely understood technique. Frank and Lillian Gilbreth presented the "process chart" to the American Society of Mechanical Engineers in 1921, and the basic vocabulary — rectangles for steps, diamonds for decisions, arrows for flow, ovals for start and end — has barely changed since. Everyone can read one, which is the flowchart's great strength.

Use a flowchart when the process runs mostly within one team, has fewer than about twenty steps, and you need something anyone can follow without training. It is the right starting point for most process mapping sessions. Its weaknesses are that it says nothing about who does each step, it has no standard way to show parallel work, and its symbols are used so loosely that two flowcharts of the same process by two people can look completely different. Our guide to process flowcharts and how to create one covers the symbols and conventions in full.

BPMN 2.0

Business Process Model and Notation is the standard for formal process modeling, and if you learn one notation properly it should be this one. BPMN has four families of element:

Events are things that happen: a process starts when a form is submitted (start event), waits until a date (intermediate timer event), or finishes (end event). Events are circles; the border style and the icon inside say what kind. Activities are work: tasks (a single unit of work, drawn as a rounded rectangle) and sub-processes (a collapsed group of tasks, marked with a plus sign). Gateways are decision and synchronisation points, drawn as diamonds: exclusive (one path only), parallel (all paths at once), inclusive (one or more paths), and event-based (whichever event happens first). Swimlanes give structure: a pool is a whole participant (your company, a customer, a supplier), and lanes inside it are roles or departments.

Connecting them are sequence flows (solid arrows, the order of work within a pool), message flows (dashed arrows, communication between pools) and associations (dotted lines linking data or annotations to elements).

Use BPMN when the process crosses teams or organisations, has non-trivial decision logic, involves waiting on time or on external events, or will be executed by software. It is also the right choice when the model will be maintained for years and you want it to mean the same thing to whoever reads it next. Its cost is that the full notation has well over a hundred symbols, and a model that uses all of them is unreadable by anyone but a specialist. The descriptive sub-class — start and end events, tasks, sub-processes, exclusive and parallel gateways, pools, lanes, sequence and message flows, data objects — covers most real modeling and can be taught in an afternoon.

UML activity diagrams

The Unified Modeling Language, also maintained by the Object Management Group, is primarily a software design notation, and its activity diagram is the closest thing it has to a process model: rounded rectangles for actions, diamonds for decisions, thick bars for fork and join (parallel split and synchronisation), and "partitions" that work like swimlanes.

Use a UML activity diagram when your audience is developers, the process is largely inside a software system, or your organisation already models in UML and does not want a second notation. For a business audience, BPMN is usually clearer; for a system-behaviour audience, UML fits alongside the class and sequence diagrams they already read.

Swimlane (cross-functional) diagrams

A swimlane diagram is a flowchart divided into horizontal or vertical bands, one per role or department, with each step placed in the band of whoever performs it. Arrows crossing a lane boundary are hand-offs. It is not a separate notation so much as a layout applied to flowcharts (and, via pools and lanes, to BPMN).

Use a swimlane diagram when the question you are trying to answer is "who does what, and where does work change hands". Hand-offs are where processes lose time and information, and a swimlane makes every one of them a visible crossing. If a client onboarding process shows eleven lane crossings between sales, finance, delivery and support, you have found your problem before you have measured anything.

Value stream mapping

Value stream mapping comes from lean manufacturing and the Toyota Production System, popularised for Western readers by Mike Rother and John Shook's Learning to See (1998). A value stream map shows the flow of material and information from customer order to delivery, with a timeline underneath separating value-adding time (work being done on the thing the customer pays for) from non-value-adding time (waiting, moving, checking, rework). Inventory between steps is drawn explicitly.

Use value stream mapping when the problem is lead time rather than correctness — when the work takes three weeks end to end but only four hours of that is anyone actually doing anything. It was built for factories, but it applies directly to IT ticket queues, month-end close, and any service process where work sits in a queue between steps. CheckFlow's value stream mapping page covers the technique in the context of running the mapped process, and our guide to lean manufacturing principles explains the waste categories a value stream map is designed to expose.

SIPOC

SIPOC — Suppliers, Inputs, Process, Outputs, Customers — is a one-page table from the Six Sigma toolkit that defines a process at the highest level: who provides what into it, the five to seven major steps, what comes out, and who receives it. It deliberately ignores detail.

Use SIPOC when you are starting a modeling exercise and need to agree the boundaries before anyone draws a box. Half the arguments in a modeling workshop are really arguments about scope ("does onboarding start at offer acceptance or at contract signature?"), and a SIPOC settles them in twenty minutes. It is a scoping tool, not a model of the flow, and it should be followed by one of the techniques above.

Gantt charts and PERT

Gantt charts (Henry Gantt, 1910s) and PERT charts (developed for the US Navy's Polaris programme in the late 1950s) are project scheduling techniques: they show tasks against time, with dependencies and, in PERT's case, optimistic, expected and pessimistic durations. They are often listed as process modeling techniques, and they are useful for one specific case.

Use a Gantt or PERT chart when the process is really a project — a one-off or rarely repeated piece of work such as an office relocation or a system migration — and the question is scheduling and critical path rather than flow and decision logic. For a repeatable process that runs fifty times a year, they model the wrong thing.

BPMN 2.0 Symbol Cheat Sheet

The elements below are the working vocabulary of BPMN's descriptive sub-class plus the handful of analytic-level elements that come up constantly in real processes. If your model uses only these, anyone who has read this table can follow it.

Three conventions catch out almost everyone the first time. First, gateways do not make decisions; the task before them does. The gateway just routes based on a condition that already exists, so label the outgoing flows with the conditions ("value > £5,000", "value ≤ £5,000") and make sure they are mutually exclusive and cover every case. Second, a parallel split needs a parallel join. If you fork three paths and only rejoin two, the model says the third one never finishes. Third, one start event and one end event per happy path is the default; add more only when the process genuinely can start or end in different ways, and label them so the difference is clear.

Process Modeling Tools: The Four Categories

The tool market is crowded and the brand names change every couple of years, so it is more useful to understand the categories than to compare products. Almost every tool you will encounter falls into one of four groups, and most companies of 10–500 people need one from the first group and one from the fourth.

General-purpose diagramming tools

Whiteboarding and diagramming applications with flowchart and BPMN shape libraries. They are cheap or free, everyone already knows how to use them, and they are ideal for mapping workshops and descriptive models. What they do not do is enforce the notation: nothing stops you connecting a message flow inside a single pool or leaving a parallel gateway unjoined. The diagram is a picture, not a validated model. For most mapping and a good deal of modeling, that is fine.

Dedicated BPMN modeling suites

Tools built around the BPMN 2.0 standard. They validate the model as you draw, export the standard XML interchange format, hold a repository of versioned models with ownership and review workflow, and often support simulation with timing and cost data. They are the right choice when process models are a managed corporate asset — regulated industries, large transformation programmes, organisations with a process-excellence function. For a 40-person company they are usually more governance than the problem needs.

Process mining platforms

Process mining, a field largely built on the work of Wil van der Aalst and colleagues from the late 1990s onward, reverses the usual direction: instead of people drawing how they think the process runs, the software reconstructs the actual process from event logs in your systems — every ticket status change, every purchase order state, every approval timestamp. The result is an as-is model based on evidence, complete with the variants nobody admits to and the exact points where work waits. Process mining needs systems that log events reliably and enough volume to be statistically meaningful; below a few thousand process instances a year it rarely pays for itself, and above that it is frequently the fastest way to a truthful as-is.

Execution platforms

Workflow and business process management software that runs the process: creates an instance when the trigger fires, assigns each task to a named person, enforces the order and the conditions, tracks completion and records who did what. Some execute BPMN directly; most, including CheckFlow, use a checklist-based model that is simpler to build and easier for non-specialists to maintain, and that maps cleanly onto the descriptive-level BPMN most teams actually produce (see the conversion table below). This is the category that turns a model into an operational control rather than a document.

The practical combination for most mid-sized teams: map and model in a diagramming tool, then build the to-be process in an execution platform. If you are choosing the second half, our guide to business process management covers what to look for.

How to Model a Business Process in 8 Steps

The steps below assume a cross-functional process with real decision points — the kind that justifies modeling rather than a quick map. For a simpler process, steps 1, 3, 4 and 8 are enough on their own.

Worked Example: Employee Onboarding, As-Is and To-Be

The following example is illustrative — a composite of onboarding processes at professional-services and technology companies of 50–150 people — but the shape of it will be familiar. The process starts when a candidate accepts an offer and ends when the new hire has working equipment, system access, payroll set up and a completed first-week plan.

The as-is model

Modelled in descriptive BPMN with a single pool for the company and five lanes: HR, hiring manager, IT, finance and the new hire. The as-is has 23 tasks. HR receives the acceptance, creates the HRIS record, and emails the hiring manager, IT and finance. Everything else is triggered by those emails, which is the first finding: there are three message-like hand-offs that are really just "someone remembers to email someone".

The hiring manager's lane contains the equipment request, but the model shows it starting only after the manager has read HR's email and found the request form, typically three to five days after acceptance. IT's provisioning sub-process (create directory account, create mailbox, assign licences, image laptop, ship laptop, set up MFA) cannot begin until the equipment request arrives, and it runs sequentially because the engineer is also the service desk. Finance's payroll set-up waits for a bank-details form that HR sends to the new hire by email, and which comes back in a median of six days.

There are two rework loops. The equipment request is returned for missing information in roughly a third of cases (the form does not ask which software the role needs). Payroll rejects the bank-details form when the new hire has used the old template, which the HR email still links to. Counting the model: 23 tasks, 9 lane crossings, 2 loops, 0 parallel gateways, and one exclusive gateway (permanent vs contractor) that sits near the end, after most of the work it should have affected. Walking through four real instances gave a median of 12 working days from acceptance to fully provisioned, against a typical notice period of 20, which explains why laptops arrive on day one only when the notice period is long.

The to-be model

The redesign keeps the same boundaries and lanes. The start event is still "offer accepted", but it now triggers a single parallel gateway with three outgoing paths — HR, IT and finance — instead of three emails. The exclusive gateway on contract type moves to immediately after the start, so that IT's path already knows whether it is provisioning a permanent employee's laptop or a contractor's virtual desktop. A second exclusive gateway on role family (engineering, sales, other) selects the software bundle, which removes the free-text software question that caused the rework loop.

The equipment request disappears as a separate task: the information it collected is captured once, by HR, at the start, and flows to IT as a data object. IT's sub-process is split so that account creation and licence assignment run in parallel with laptop imaging. A timer intermediate event in IT's lane is set to five working days before the start date, so shipping is scheduled relative to the deadline. Finance's path starts immediately and its bank-details form is a link inside the task, with the template versioned in one place. The new hire's lane gains a "confirm receipt and first login" task, which provides an actual end event rather than an assumption.

Counted on the same terms: 18 tasks, 4 lane crossings, 0 rework loops, 2 parallel gateways properly joined, both exclusive gateways at the front. Applying the as-is durations to the new structure projects a median of 5 working days, with the critical path now the laptop supplier's lead time rather than internal queueing. That is the number that goes in front of the leadership team, alongside the honest caveat that it is a projection until the to-be has run for a quarter.

Running the to-be is where the model pays off. Our employee onboarding checklist guide shows what this process looks like as a running checklist with the same parallel structure, and the conditional logic in checklists guide shows how the two exclusive gateways become branching questions rather than separate templates.

Common Business Process Modeling Mistakes

Most modeling failures are not failures of notation. They are failures of purpose, scope or follow-through, and they recur so reliably that they are worth naming.

From Model to Execution

A model describes what should happen. Execution is what makes it happen and proves that it did. The gap between the two is where most process work stalls, so it is worth being concrete about what an execution platform adds to a model and how the elements of one map to the other.

A running process does five things a diagram cannot. It starts itself — on a schedule, on a form submission, on a webhook from another system — so no one has to remember. It assigns each task to a named person, not to a lane. It enforces order and conditions, so a task that depends on another cannot be completed first and the branch not taken is never shown. It records every completion with who and when, which is the audit trail an auditor, a client or a post-incident review will ask for. And it shows the whole thing live, so a manager sees the instance that has stalled at day three without asking anyone.

Before converting a model, check that it is ready:

• Every task is in a lane, and every lane maps to a role that exists in the organisation and can be assigned in the platform
• Every exclusive gateway's outgoing flows are labelled with conditions that are mutually exclusive, cover every case, and depend on information captured earlier in the process
• Every parallel split has a matching join, and nothing downstream of the join can start before all branches finish
• Every timer is expressed relative to something the platform knows — the start date, the trigger date, a previous task's completion — not as a calendar date
• Every data object is a field someone fills in or a system supplies, with a name, a type and a task that produces it
• Every sub-process has been expanded at least once, so you know it is not hiding twelve tasks and a decision
• The start event names a trigger the platform can detect: a schedule, a form, a webhook, an integration event
• The end event names an outcome someone can confirm, not just "process complete"

The mapping from descriptive BPMN to a checklist-based execution platform is close to one-to-one, which is why the modeling effort transfers directly:

This conversion is usually quicker than the modeling that preceded it, and the first run of the executed process is the real validation of the model. Expect to find two or three things the workshop missed, adjust the template, and run it again. That loop — model, execute, learn, adjust — is what process management actually looks like in a team that does it well.

Free Process Templates to Model From

Each template below is a to-be process already broken into ordered, assigned tasks with the decision points built in. Use one as the executable target for your own model, or reverse it into a starting model if you have not mapped the process yet.

Employee Onboarding Checklist

The onboarding process from the worked example as a running template: HR, IT and finance tasks in parallel, driven by the start date.

Project Management Documentation Checklist

Captures the scope, process models and sign-offs a project needs at each stage, so the modeling work is versioned rather than lost.

IT Change Management Checklist

A gateway-heavy process — risk classification, approval routing, rollback — expressed as conditional tasks rather than a diagram.

The full template library covers onboarding, offboarding, change management, incident response, month-end close and recurring compliance work, and every template can be edited in the template designer to match your own to-be model.

How CheckFlow Fits

CheckFlow is an execution platform: the place a modelled process goes to run. It does not draw BPMN, and it does not try to. It takes the output of the modeling work described above — lanes, tasks, order, decisions, timers, data — and turns it into a template that creates a tracked, assigned run every time the process is needed.

Each lane in your model becomes a role or a named assignee on the relevant tasks, so that when a run starts, work lands with the person responsible rather than with "IT". Sequence flows become task order and dependencies. Exclusive gateways become conditional logic: a question answered early in the run shows or hides the tasks on each branch, so a single template handles permanent hires, contractors and interns without three separate versions. Parallel gateways need no special handling — tasks without dependencies between them simply run at the same time in different people's queues.

Timer events become dynamic due dates. A task can be due a fixed number of days after the run starts, or relative to a key date captured in the run such as the start date or the change window, which is how "ship the laptop five working days before day one" becomes a rule rather than a reminder. Timer start events become recurring schedules: a template set to run on the first working day of each month creates the month-end run itself, assigned and dated, with no one remembering to copy last month's.

Message start events become triggers from outside: a form submission, a Zapier action from your HRIS or ticketing system, or a call to the API. Service tasks become automations that fire when a step completes. Every run keeps a complete audit trail — who completed each task, when, with what data — and the real-time dashboard shows every active run, with overdue tasks surfaced, so the manager sees the onboarding that has stalled in finance without sending an email to find out.

The result is a process that runs as modelled, produces data on every run, and gives you a real as-is for the next round of improvement — one based on timestamps rather than interviews. CheckFlow's business process management software starts from $10 per user per month, with a 14-day free trial and no credit card required.