Process modelling: a practical playbook (without the fluff)

Spencer Humphrys
Jan 20
5 min read

If you’re trying to improve performance, productivity, or patient flow, you’ll hear the same phrase over and over: “We need to fix the process.”

But most organisations don’t actually have a process. They have a collection of habits, workarounds, and heroic efforts that somehow get the job done — until it doesn’t.

The proper name is Business Process Modelling (BPM), which makes it sound more formal and difficult than it actually is. BPM just helps to turn “how we think it works” into “how it really works”, and then into “how it should work”.

What BPM (business process modelling) actually is

Business process modelling is the discipline of making processes visible: the steps, decisions, handoffs, information, and systems involved in delivering an outcome. It’s a way to look at a workflow end to end, not in isolated bits.

A good model usually captures two versions of the same process:

As-is: what happens today (including the awkward bits people don’t write down)
To-be: the future design once you’ve removed waste, reduced risk, and made it easier to do the right thing

This matters because improvement conversations go nowhere when everyone is carrying a different mental picture of the same workflow.

When it’s worth modelling a process

Not everything needs a diagram. But, it is worth modelling when:

The work repeats frequently, with lots of handoffs
Performance varies depending on who’s on shift / which team is involved
Delays, rework, or errors are common
The process crosses departments or organisations
You’re trying to digitise or automate something (automation amplifies bad processes fast)

A simple rule: if it’s expensive, risky, or frustrating, model it.

What you get back for the effort

When process modelling is done properly, you don’t just get a diagram. You'll get:

Shared understanding and clarity: one agreed picture of the work
Faster improvement: bottlenecks and duplication become obvious
Better decisions: it’s easier to see where to invest time, money, and people
More reliable delivery: consistency increases without turning teams into robots
Better change adoption: because frontline reality is built into the design, not added as an afterthought

And in health and care settings, there’s a bigger upside: clearer processes reduce variation — and variation is where harm and delays tend to hide.

Picking the right modelling technique (keep it simple)

The goal isn’t to produce the most beautiful process map. It's about bringing people together and increasing the shared knowledge of the process and problems. It’s about creating something that helps people understand what's actually happening, in a way that is useful for the people doing the work.

Here are the main tools, and when they earn their keep:

1) Flowcharts

Best for: making a process understandable quickly.

Use when: you need clarity and alignment more than technical precision.

2) SIPOC

SIPOC stands for Suppliers, Inputs, Process, Outputs, Customers. It’s a high-level framing tool that stops teams from disappearing down rabbit holes.

Best for: defining boundaries and scope before you draw anything detailed.

Use when: you need a clear, structured understanding of the process inputs and outputs, and how they lead to customer (or service user) experience.

3) IPO (Input–Process–Output)

Best for: simplifying conversations about what goes in, what happens, and what must come out.

Use when: teams are arguing about the “how” without agreeing on the “what”.

4) Data flow diagrams

Best for: understanding how information moves (and where it breaks).

Use when: system and data issues are the real constraint.

6) Process mapping

Process mapping is probably the most common tool, but also probably the one most people get wrong.

Best for: developing a detailed understanding of a small process, or part within a larger process.

Use when: you know what part of your process is causing the most problems, but you need a better understanding of that process step.

5) Value stream mapping

Value stream mapping is a Lean approach that focuses on end-to-end flow, at a high level, including where time and effort are wasted and where data flow.

Best for: getting a complete view of a process or pathway when you're trying to reduce delays and improve throughput.

Use when: you need a detailed end-to-end understanding of a process.

Our tip: start with simple. There's always time to make things more detailed if you need it.

Our step-by-step playbook for process modelling

This is the approach we use when we want models that lead to real-world improvement — not just documentation.

Step 1: Define the purpose (and success)

What are you trying to achieve: reduce delays, improve safety, cut costs, increase capacity, improve experience? Pick and agree on 2–3 measurable outcomes that you want to change so the model has a job to do.

Step 2: Choose the process and set boundaries

Decide:

Where the process starts and ends
What’s in scope vs out of scope
Who the key stakeholders are. A SIPOC is perfect here.

Step 3: Gather evidence (not opinions)

Do short interviews, review documentation, and pull basic data. Your first draft will always be wrong — evidence tightens it quickly. And remember - you must go and observe the work first hand.

Step 4: Map the as-is with the people doing the work

This is non-negotiable. If you model a process without the people delivering it, you’ll model fantasy.

Include:

Handoffs
Decision points
Queues/waiting
Systems used
Rework loops

Step 5: Validate and stress-test

Walk through real scenarios:

“What happens when it’s busy?”
“What happens when the system goes down?”
“What happens when we don’t have capacity?” Fix the model until it matches reality.

Step 6: Find the constraints and waste

Look for:

Bottlenecks and queues
Duplicated effort
Unclear roles
Avoidable variation
Failure demand (work created by something not being right earlier)

Step 7: Design the to-be

Build a future process that:

Removes as much non-value adding work as possible
Reduces handoffs
Builds in safety checks
Makes the “right way” the easy way. Then test again with real scenarios.

Step 8: Make it stick (ownership + governance)

A model without ownership dies quickly.

Assign:

A process owner
Measures (a small set)
Agree how frequently the process and it's performance will be reviewed. And keep it updated as the service changes.

Common mistakes (and how to avoid them)

Modelling for its own sake → tie every model to a decision or improvement goal
Too much detail too early → get alignment first, detail second
Trying to please everyone → define scope clearly and stick to it
No ownership → if nobody owns it, nobody improves it
Tool obsession → choose the simplest method that gets you to action