Foundation · 12 min
Work is a process, and somebody is waiting at the end of it
After this you can
- describe a piece of work as a process with inputs, steps and outputs.
- identify who the customer of a process is and state what they actually want from it.
Assumes you have done Signal or noise: reading a number that moves.
The problem
A finance team was praised for cutting invoice approval from four days to one. Six months later, supplier complaints had gone up. The team had hit their target by rejecting any invoice with a missing purchase-order number instead of chasing it — a rejection takes ninety seconds and stops the clock. Every rejected invoice came back a fortnight later and started again. Approval time fell. Time to get paid rose from eleven days to twenty-six. Nobody had ever written down who the customer of the invoice process was.
The idea
Everything that happens at work is a process, whether anyone has described it as one or not.
A process is a sequence of steps that turns inputs into outputs. That is the whole definition, and it applies to a production line, an invoice, a diagnosis, a support ticket and a recruitment decision alike.
Describing work this way is not bureaucracy. It buys you three specific things:
You can see the handoffs. Almost all delay in office and service work happens between steps, not inside them. Until the steps are written down there is nothing to point at.
You can measure it. "Finance is slow" cannot be measured. "Time from invoice arriving to payment leaving" can.
You can tell whose problem it is. A step that is fast but hands rubbish to the next step is not performing well, however good its own numbers look.
The customer, and what they actually want
The customer of a process is whoever receives its output. Not always someone who pays; often the next team along. Every process has at least one, and most have several.
The word that does the work here is actually. There is what you assume the customer wants, and there is what they would say if you asked. They differ far more often than anybody expects, and the gap is where improvement projects go to die:
- The invoice team assumed suppliers wanted fast approval. Suppliers wanted to be paid.
- A hospital assumed patients wanted the earliest possible appointment. A large number wanted an appointment they could actually get to, and were quietly not attending the early ones.
- An IT desk assumed users wanted fast ticket closure. Users wanted the problem to not come back, which is why the reopen rate was the real measure.
In every one of those, the process was hitting its target and failing its customer. That is not a coincidence — it is what happens when a measure is chosen from inside the process rather than from the customer's need.
SIPOC
The standard way to write all this on one page is a SIPOC: Suppliers, Inputs, Process, Outputs, Customers. Five columns, filled in from the middle outwards.
Two things make the difference between a SIPOC that helps and one that decorates a wall:
State where the process starts and ends. This is the most valuable line on the page, and most templates leave it off. A project without stated boundaries expands until it cannot be finished, and every person in the room will remember agreeing to a different scope.
Keep the process column short — four to seven steps. A SIPOC is not a process map. If you find yourself writing fourteen steps you have stopped agreeing the scope and started drawing the detail, and you are doing it before anyone has agreed what is being improved.
Write each step as an action, starting with a verb. "Receive referral", not "Referral received". A state cannot be timed, staffed, or removed; an action can.
Worked example
Take the invoice process from the Hook and write it properly.
Starts with: invoice arrives in the accounts inbox. Ends with: payment leaves our account.
Already this changes the project. The old boundary was "invoice arrives → invoice approved", which is precisely why rejecting invoices looked like success.
| S — Suppliers | I — Inputs | P — Process | O — Outputs | C — Customers |
|---|---|---|---|---|
| Supplier | Invoice | Receive invoice | Approved invoice | Supplier |
| Purchasing team | Purchase order | Match to purchase order | Payment | Purchasing team |
| Budget holder | Budget approval | Resolve any mismatch | Exception report | Finance reporting |
| Obtain approval | ||||
| Release payment |
Five steps. Every one starts with a verb.
Now the column everybody skips — what each customer actually wants:
| Customer | What they actually want |
|---|---|
| Supplier | To be paid within the agreed terms, without having to chase |
| Purchasing team | To know immediately when an invoice cannot be matched, not a fortnight later |
| Finance reporting | Accurate accruals at month end |
Read the supplier's row against the old target. "Approval within one day" does not appear anywhere in it. The measure and the need were never connected, and the fix that hit the target — rejecting mismatched invoices — made the need worse.
Look at the purchasing team's row too. It says the rejection is not the problem; the silence is. That is a completely different improvement, and it only became visible once somebody wrote the sentence down.
What the SIPOC does not tell you. It does not say where the time goes, how much of the work is rework, or which step causes the mismatches. It is not supposed to. It tells you what you are improving and for whom, so that the measuring which comes next is aimed at something real.
Your turn
The canvas opens with a real-shaped first attempt at a SIPOC for an outpatient referral process. The tool names eight findings across six kinds.
- Look at what it says before you change anything. Fourteen process steps, no boundaries, two steps written as states, two customers with no stated need, four outputs against two customers — and one you may want to argue with: it flags "Patient" as a supplier that also appears in the process. That is a judgement, not an error. A patient really does hand something in and really is acted on, and the tool would rather raise it and be wrong than stay quiet about a column that is describing the process to itself.
- Fill in "starts with" and "ends with" first. Notice how much easier the process column becomes once the boundaries exist — most of the fourteen steps turn out to be outside them or below the level a SIPOC works at.
- Cut the process column to five or six verb-first steps. Rewrite "Referral received" as "Receive referral" and watch that finding clear.
- Now write what each customer actually wants — in their words, not yours. This is the hard one, and it is the only part of the canvas that reliably changes what a team does next.
The tool does not score you. It points at structural gaps and says why each one matters; if you think a flag is wrong for your process, you are probably right.
SIPOC Canvas
practiceWho hands something in, before the process starts.
What they hand in.
4–7 steps, each starting with a verb. Not a process map.
What comes out. Every one goes to somebody.
Who receives an output — and what they want.
scopeNo start or end point. This is the single most valuable line on the canvas: a project whose boundaries are unstated will expand until it cannot be finished, and everyone will believe they agreed to a different scope.
process14 steps. A SIPOC keeps the process column to about 4–7 so the conversation stays on scope. Past that you are drawing a process map, and you are drawing it before anyone has agreed what is being improved — which is the order that produces maps nobody uses.
process"Referral received" describes a state, not something a person does. Start with a verb — "Receive order", not "Order received". A state cannot be timed, staffed or removed; an action can.
process"Letter generated" describes a state, not something a person does. Start with a verb — "Receive order", not "Order received". A state cannot be timed, staffed or removed; an action can.
customers"Patient" has no stated need. Naming a customer without saying what they want is how a team ends up optimising for what is easy to measure. Write the sentence — it is usually the moment somebody says "actually, that is not what they care about".
customers"Referring GP practice" has no stated need. Naming a customer without saying what they want is how a team ends up optimising for what is easy to measure. Write the sentence — it is usually the moment somebody says "actually, that is not what they care about".
outputs4 outputs but only 2 customers. Every output goes to somebody. An output with no named recipient is either work nobody needs — which is worth knowing — or a customer who has been left off the canvas.
suppliers"Patient" also appears in the process column. A supplier is upstream — it hands something in. If it is doing the work, it belongs in the process, and the real supplier is whoever gives it what it starts with.
How this is calculated
No statistics — this is a structural completeness check, and it deliberately produces no score. A canvas graded out of ten teaches people to fill boxes until the grade goes up.
- Every column has at least one entry, and the start and end are stated.
- The process column holds 4–7 steps. More than that and you are drawing a process map before anyone has agreed what is being improved.
- Each step starts with a verb — “Receive order”, not “Order received”.
- Each named customer has a stated need.
- There are not more outputs than customers to receive them.
Source: George, M. et al. (2005), The Lean Six Sigma Pocket Toolbook, SIPOC; Rasmusson, D. (2006), The SIPOC Picture Book.
Saved runs can be attached to a project deliverable as evidence. Both what you entered and what the tool computed are stored, so the result can be checked again later.
Check yourself
No hints. Wrong answers are explained, not softened.
Which of these is written as a process step rather than a state?
A team improving the recruitment process names the customer as 'the hiring manager'. What has been missed?
A support desk measures 'average time to close a ticket' and hits its target every month, while user satisfaction falls. What is the most likely explanation?
Worth remembering
What is a process?
A sequence of steps that turns inputs into outputs. Writing it down makes the handoffs visible, makes the work measurable, and shows whose problem a failure is.
Why must a SIPOC state where the process starts and ends?
Without stated boundaries a project expands until it cannot be finished, and everyone remembers agreeing to a different scope. It is also what stops a team hitting a target by moving work outside the boundary.
How many steps belong in the process column of a SIPOC, and how are they written?
Four to seven, each starting with a verb. More than that and you are drawing a process map before anyone has agreed what is being improved.
Can you do this now?
Rate yourself honestly. We compare your rating with how you actually answered — the gap is more useful than either number alone.
I can describe a piece of work as a process with inputs, steps and outputs.
I can identify who the customer of a process is and state what they actually want from it.
Your rating is recorded alongside your drill results. Neither alone marks the competency as met.