Problem Solving & Quality · State
SIPOC Scoping
Map suppliers, inputs, process steps, outputs and customers on one line to agree where the problem lives — and where the study stops.
- Time45 min
- FormatTeam
- StageState
SIPOC Scoping: what it is and why it works
SIPOC is a one-page, high-level view of a process: Suppliers, Inputs, Process, Outputs and Customers. The process is described in five to seven steps between an agreed start and end point, outputs are linked to the customers who receive them, and inputs to the suppliers who provide them, including utilities, data and upstream departments. The team then marks where the problem is observed, draws the boundary of the study and writes down what is explicitly out of scope.
Its value lies in agreement, not detail. Cross-functional problems stall when each department assumes the issue starts somewhere else; a SIPOC built together makes the handoffs visible and shows which inputs could carry the problem into the process. It is the standard scoping tool of the Define phase in DMAIC and is quicker than a detailed map when the real question is 'whose process is this, and where does our study stop?' Once scope is agreed, the as-is flowchart adds loops, waits and workarounds at the level of detail needed for analysis, and the deviation statement pins down the gap inside the boundary.
What you need
- A draft problem description or deviation statement
- Representatives of each department that touches the process
- Existing procedures or process lists to name the high-level steps
- Knowledge of the key customers, internal and external, and their requirements
What you get
- A one-page SIPOC with five to seven process steps
- Start and end points agreed by all parties
- The location where the problem is observed, marked on the sheet
- An explicit in-scope and out-of-scope list
- A list of inputs and suppliers that could be sources of the problem
When to use it
When a problem touches several departments and nobody knows whose process it is.
How to do it, step by step
- Write the process name and its start and end points at the top of the sheet.
- List five to seven high-level process steps in the middle column.
- List outputs and the customers who receive them, internal or external.
- List inputs and the suppliers who provide them, including utilities and data.
- Circle where the problem is observed and draw the boundary of the study; note what is explicitly out of scope.
Worked example: Missing parts during planned haul-truck shutdowns
Illustrative scenario — figures are realistic but not from a real company.
At an open-pit copper mine, planned maintenance shutdowns on the haul-truck fleet overrun by an average of 14 hours because critical parts are missing on the day. Maintenance blames the warehouse, the warehouse blames purchasing, and purchasing blames late requisitions.
- The team named the process 'Parts provisioning for planned truck shutdowns', starting at release of the shutdown work package and ending with parts kitted at the service bay.
- Six steps were agreed: plan the work package, create material reservations, check stock, purchase non-stock items, receive and inspect, kit and stage.
- Customers were the shutdown crew (kitted parts) and the fleet manager (truck availability); suppliers included the planning group, the ERP, equipment dealers and the site receiving dock.
- The problem was circled at 'create reservations': records showed about 30% of reservations were created less than ten days before shutdown, while dealer lead times ran two to six weeks.
- Out of scope, by written agreement: dealer delivery performance and parts for unplanned breakdowns, left to a separate study.
Result. The SIPOC moved the discussion from the warehouse to the timing of work-package release. With planning, purchasing and the warehouse agreeing on one boundary, the follow-up study focused on a single handoff. A work-package release deadline of 35 days before each shutdown cut the average overrun from 14 to 5 hours over the next quarter.
Common pitfalls and how to avoid them
- Mapping too much detail.Stay at five to seven steps; decisions, loops and waits belong in the as-is flowchart.
- Forgetting less obvious inputs.Include utilities, data, specifications, tooling and information from other departments; problems often enter through these.
- Leaving the boundary implicit.Write the start and end points and the out-of-scope list on the sheet, and have each department agree to them.
- Building the SIPOC alone at a desk.Build it with people from each handoff; the disagreements it surfaces are part of the output.
Frequently asked questions
What is a SIPOC diagram used for?
A SIPOC is used to scope a process improvement or problem-solving project. It shows on one page who supplies what into a process, the main steps, what the process produces and who receives it. Teams use it to agree where the process starts and ends, which departments are involved and where the study will stop, before investing time in detailed mapping or data collection.
What is the difference between SIPOC and a process map?
A SIPOC is a high-level scoping tool with five to seven steps and no decisions or loops. A process map or flowchart shows the detailed flow: each task, decision point, wait, transport and rework loop. Build the SIPOC first to agree the boundary, then map in detail only inside that boundary, where the problem is observed.
Should you fill in a SIPOC from left to right?
Not necessarily. Many practitioners start with the process steps in the middle, then outputs and customers, then inputs and suppliers. Starting from the process and the customer keeps the team focused on what matters to whoever receives the output. Filling it strictly from left to right tends to produce long supplier lists before anyone agrees what the process actually is.
Origin
SIPOC — TQM and Six Sigma process-scoping practice since the late 1980s; no single author.
Related methods
- As-Is Process FlowchartDraw the process as it really runs today — with loops, workarounds and waiting — by walking it with the…
- Deviation StatementWrite one sentence: object, defect, expected value, observed value, since when. No cause, no culprit, no…
- DMAIC RoadmapDefine, Measure, Analyze, Improve, Control: a data-driven project roadmap for chronic variation problems…
More in “State”
Describe the problem as a measurable gap — no cause, no culprit, no solution yet.