Lesson 1 of 3
Definition
A process is a repeatable sequence of work that transforms something — a request into a decision, a query into a resolution, an order into a delivery.
Not all work is a process. A one-off task is not. A process:
- Happens again and again (it is repeatable)
- Involves more than one person or step
- Has a consistent trigger — something that starts it
- Produces a consistent type of outcome — even if the specific result varies
A concrete test
Ask: Could I train someone new by describing this sequence of steps? If yes, it is a process. If the answer depends entirely on unique context every time, it is probably a one-off task rather than a repeatable process.
Example (process): Processing a supplier invoice is a process — it happens hundreds of times a month, involves Finance Clerks, Managers, and a Payment System, and always ends in either payment or rejection. The specific invoice changes; the sequence of steps does not.
Example (not a process): Fixing a one-off formula error in a specific spreadsheet. It happened once, involved one person, and the exact steps will never be repeated in the same way.
Four key questions for any process
Before drawing a single shape, answer these four questions in plain English:
| Question | What it reveals | Invoice approval example |
|---|---|---|
| What triggers it? | The start event — what sets the process in motion | A supplier submits an invoice |
| What does it produce? | The end event(s) — what comes out of the process | Invoice paid, or invoice rejected |
| Who does the work? | The lanes and pools — which roles and systems are involved | Finance Clerk, Finance Manager, Payment System |
| What can go wrong? | The exception paths — where the happy path may deviate | Invoice does not match PO; amount exceeds approval limit |
Exercise before BPMN
Take the leave request scenario and write it in plain English using only those four questions. Do not draw yet. Most beginners skip this step and wonder why their diagrams look tangled. Answering all four questions first typically takes five minutes and saves forty.
When a process description reveals gaps
If you cannot answer one of the four questions, the process is not yet ready to model. Common gaps:
- Missing trigger: 'We approve invoices when Finance receives them' — but how does Finance receive them, and from whom? That is the trigger.
- Vague outcome: 'We handle the invoice' — but what does handled mean? Paid? Filed? Queried? Each is a different End Event.
- Unknown actors: 'Someone approves it' — who? What role? That determines which lane the task belongs in.
- No exceptions listed: Every real process has exceptions. If none are mentioned, keep asking.
✓ When to use
- Any time you start a new modelling task — forces clarity before notation
- Stakeholder interviews — elicits the right information without leading
- Validating an inherited model — check that each question has a visible answer
✗ When not to use
- ✕Genuinely one-off tasks — a checklist is more appropriate
- ✕When the process is already well-documented and stable
- ✕Spending more than 15 minutes on this step for a well-understood process