How to scope a process with SIPOC
Scoping a process means agreeing on its first and last step before mapping it: what triggers it, what result it delivers, who receives that result and who takes part. A SIPOC (suppliers, inputs, process, outputs, customers) puts this on one page. Half an hour of scoping saves hours of discussion in the workshop.
Why scoping matters
Without a clear start and end, process mappings tend to grow. The discussion about incoming invoices drifts into supplier selection, the hiring process into onboarding and IT accounts. Each extension is interesting, but the analysis loses focus and the numbers become incomparable.
A clear scope also decides what the metrics mean. A lead time “from need identified to goods booked” is a different number from one “from purchase order sent to goods booked”. Both are legitimate, but everyone has to know which one is meant.
Trigger and result
The trigger is the event that starts a case: an invoice arrives, a customer sends a request, a department reports a need. Formulate it as an event that can be observed, not as an activity. The result is the state at the end: the invoice is paid, the quotation is with the customer, the goods are received and booked.
A useful test: could you count how many cases started and how many reached the result last month? If not, the trigger or the result is still too vague. That count is also the case volume you need later. See volumes and case counts.
SIPOC on one page
SIPOC is a simple table with five columns, filled in before the detailed mapping:
| Column | Question | Example: purchasing |
|---|---|---|
| Suppliers | Who supplies what the process needs? | Departments, suppliers |
| Inputs | What comes in? | Purchase requisition, quotations |
| Process | Which five to seven main steps? | Request, approve, order, receive, book |
| Outputs | What comes out? | Booked goods receipt |
| Customers | Who receives the output? | Departments |
Participants and roles
List every role that does a step, plus external parties whose answers the process waits for. In the purchasing example these are the requester in the department, the cost center manager who approves, purchasing, the supplier and goods receipt. Each of them becomes a lane in the diagram. See swimlane diagram.
For each internal role, ask how many people do this work and what share of their working time is available for this process; annual leave and public holidays are not part of this share, they are already taken out of the working days per year. That gives the capacity needed for the staffing calculation. External partners, customers and IT systems are shown as lanes too, but they are not counted as a bottleneck.
Where to draw the line
A few rules of thumb help when the boundary is disputed:
- One process, one result. If there are two different results, there are probably two processes.
- Stop where responsibility changes completely. Payment runs, for instance, often belong to a separate treasury process.
- Include the waiting for external parties if the case is blocked during that time; it is part of the lead time the customer experiences.
- Keep neighboring processes as a single step or a note rather than mapping them in full.
Example: scoping a hiring process
Suppose an HR team wants to know why filling a vacancy takes so long. The first draft of the scope reads “recruiting”. In the scoping session the group sharpens it: the trigger is “a department submits an approved job requisition”, the result is “the employment contract is signed by both sides”. Onboarding, IT accounts and the first working day are a separate process and stay out.
The participants follow from that: the hiring department, HR, the works council where its consent is required, the line manager who conducts interviews, and the candidate as an external party whose replies the process waits for. The SIPOC lists the requisition and the job profile as inputs and the signed contract as output. With this frame, the lead time question becomes precise: how many working days from approved requisition to signed contract – and which part of it is waiting for interview dates or signatures. The hiring template draws the line differently: it starts earlier, with a position to be filled and its approval by the managing director, and ends when the new employee is hired and set up – a reminder that the scope is a decision, not a given. See what process analysis is.
Scoping in the app
In the settings of a process you record the trigger, the result and the SIPOC frame next to the volume (cases per period), working hours per day and working days per year. These framework data appear with the process, so everyone who opens it sees what was in scope. The purchasing template comes with a filled-in SIPOC and can serve as an example.
Once the scope is agreed, the actual mapping begins. See mapping the current process.
Try it in the editor
Purchasing via purchase requisition · 500 / month
The purchasing template has trigger, result and SIPOC filled in (departments and suppliers, requisition and quotations, booked goods receipt) and five lanes from requester to goods receipt.
Open the example in the editorFrequently asked questions
What does SIPOC stand for?
Suppliers, inputs, process, outputs, customers. It is a one-page overview of a process and its boundaries, created before the detailed mapping.
How detailed is the process column of a SIPOC?
Five to seven main steps are enough. The details come in the swimlane diagram; the SIPOC only shows the frame.
Who should agree on the scope?
The process owner, ideally together with the person who commissioned the analysis. Otherwise the scope gets reopened in every workshop.
Self-test
Keep learning
Would you like to map or improve a process together with us? Contact