Modelling processes
A process model is one picture that everyone in the room agrees is true. This lesson teaches the small part of BPMN that covers most real models, walks you through Mangrove Market's phone-order process as it is today, shows you how to find and measure the waste in it, and designs the future app process that removes it.
By the end you can
- Read and draw the core BPMN shapes: pools, lanes, events, tasks, gateways, sequence flow and message flow
- Model a current (as-is) process with lanes, following a few rules that keep models readable
- Find waiting, rework, hand-offs and re-keying in a model and put a number on each
- Tell cycle time from touch time and work out first-time-right from an event log with SQL
- Design a future (to-be) process and compare it with today in numbers
The everyday picture
Picture a busy restaurant. The waiter writes your order on a notepad, serves two other tables, then walks the note to the kitchen. The cook reads the handwriting, guesses that "2 sm" means two small plates, and starts cooking. When the plate reaches you, it is wrong, and it goes back. You waited 40 minutes for a meal that took 12 minutes to cook.
Nobody in that restaurant is lazy. The time goes in the gaps: the note in a pocket, the walk, the guess, the plate going back. Ask each person what they do and you never see the gaps. Draw one order's whole journey on one page, with a row for each person, and mark where it waits and where it is redone, and the gaps jump out. That drawing is a process model.
Why model a process, and how much to show
In Stakeholders and elicitation you collected dozens of facts from interviews, observation and credit notes. A process model puts those facts in order on one page. It does three jobs.
- A shared picture. The head of partner sales, a finance analyst and the DC manager each know their own part. The model shows them the whole order, and they correct each other in front of it.
- Hand-offs and waits become visible. Every time work crosses from one person to another, it can wait, get lost or get changed. With one row per role, each crossing is an arrow from one row to the next.
- A base for requirements. Each step in the future model becomes something the solution must do, and each decision becomes a business rule. You will write those in Requirements that work.
The BABOK Guide lists process modelling and process analysis among its techniques. You use them when you describe the current state and define the future state, which are tasks in its Strategy Analysis knowledge area, and when you specify and model requirements.
Decide the level of detail before you draw. The BPMN 2.0 standard describes three subsets of the notation: descriptive (the few shapes business people read easily), analytic (more event and gateway types) and common executable (enough detail for software to run the model). Business analysts work mostly at the descriptive level. Draw a high-level model that fits the whole order on one page in about 7 to 12 steps, then detailed models only for the painful steps, such as the credit check.
If you met service blueprints in Watching the work, a process model is their stricter cousin. BPMN has precise rules for decisions, parallel work and messages, so a developer at Lagoon Digital and a finance analyst read the same picture the same way.
Quick check
The head of partner sales asks for "the full process with every screen and field". What level should your first model be?
The first model must let everyone see the whole journey and agree it is true. Screens and fields hide the hand-offs and waits you are looking for. Zoom in later, one step at a time, where the waste is. An executable model is for software engines and far too detailed for this conversation.