A SIPOC diagram is a one-page, high-level map of a process that lists its Suppliers, Inputs, Process, Outputs, and Customers. It is used in the Define phase of a Six Sigma project to set the boundaries of what is being improved before any detailed mapping begins.
SIPOC is the tool you reach for when a room full of people cannot agree on where a process starts and stops. It forces the team to name, in five columns, who feeds the process, what they feed it, the handful of steps that turn inputs into outputs, what comes out, and who receives it. Nothing more. It is deliberately shallow, and that shallowness is the point: you are drawing a fence around the work, not surveying every blade of grass inside it. SIPOC is one of the most useful early tools in lean manufacturing and Six Sigma precisely because it stops a project from quietly ballooning into "fix the whole plant."
What Does SIPOC Stand For?
SIPOC is an acronym read left to right across five columns. Each column answers one plain question about the process you are scoping.
- Suppliers. Who or what provides the inputs? Upstream departments, vendors, a prior operation, a customer submitting an order. If an input crosses into your process, something supplied it.
- Inputs. The materials, information, people, and specifications the process needs to run: raw stock, a work order, a torque spec, an operator, a calibrated gauge.
- Process. The process itself, captured in roughly four to seven high-level steps. Not a detailed flowchart. If you need more than about seven boxes, you are already too deep for a SIPOC.
- Outputs. What the process produces: a finished part, a filled pallet, a test result, a released lot. Outputs are things, not activities.
- Customers. Who receives the outputs? The next operation, shipping, an external buyer, a regulator. Customers set the requirements that make an output "good."
A close cousin, COPIS, is the same tool written back to front, Customers, Outputs, Process, Inputs, Suppliers. Teams build it in reverse when they want to start from what the customer actually needs and work upstream to the suppliers that must deliver, which keeps the map anchored to demand rather than to whatever the plant happens to make.
Why Build a SIPOC Before Detailed Process Mapping?
Because scope, not analysis, is what kills most improvement projects. A team that skips the fence-drawing step starts mapping and, three weeks later, is arguing about a supplier problem that was never theirs to solve. SIPOC settles four questions up front: where the process begins (the first input), where it ends (the last customer), who owns the pieces, and what "good" means at the boundary. Once those are on the wall and agreed, the deeper work, a detailed flowchart or a full value stream map has a container to live inside.
SIPOC also surfaces the customer requirements early, which is where most quality problems actually originate. When you name the customer of each output and ask "what makes this output acceptable to them," you are drafting the critical-to-quality characteristics the rest of the project will measure. A process that produces outputs nobody downstream wants is a scoping failure a SIPOC catches on day one, long before a control chart would.
How Do You Build a SIPOC Diagram?
Build a SIPOC with the people who run the process, on a wall the whole team can see, in one sitting. The order below keeps the map honest and stops the process column from swelling into a flowchart.
- Name the process and its trigger and end point. Write one verb-noun name ("mold and pack closures") and agree on the first step and the last. Everything outside those two points is out of scope, on purpose.
- Map the Process column first, in four to seven steps. High level only. If a step needs sub-steps to make sense, you are drilling too far. Post the boxes before touching the other columns so they anchor the map.
- List the Outputs of the process. For each, ask "what thing comes out," not "what do we do." Include the obvious deliverable and the quieter ones like inspection records or scrap.
- Identify the Customers of each output. The next operation counts as a customer. External buyers, QA, and regulators do too. Name who receives each output and, in a margin, what they need it to be.
- List the Inputs the process consumes. Materials, information, specifications, energy, people. If a step cannot run without it, it is an input.
- Trace each input back to its Supplier. Vendors, upstream cells, planning systems, even the customer who submits the order. Every input has a source; naming it exposes handoffs where problems hide.
- Validate against reality and stop. Walk the process once with the map in hand, correct what is wrong, then freeze it. A SIPOC that keeps growing has stopped being a SIPOC.
The discipline in that list is knowing when to stop. The most common failure is a team that treats the Process column as a place to prove how much they know about the line, ending up with twenty boxes and a map that scopes nothing.
What Does a Filled-In SIPOC Look Like?
Take a closure-molding cell as a worked example. The process is "mold and pack closures," triggered by a released work order and ending when a full pallet is staged for shipping. The Process column holds five steps: load resin, mold, trim, inspect, pack. The Outputs are a finished closure, an inspection record, and regrind scrap. The Customers are Fill Line 3 (the immediate next operation), the warehouse, and QA, each with a different requirement, the fill line cares about dimensional fit, the warehouse about pallet count, QA about the record being complete. The Inputs are resin lot, the work order, the mold and its dimensional spec, a calibrated caliper, and an operator. Tracing those back, the Suppliers are the resin vendor, the scheduling system, tooling, the calibration lab, and the shift roster. That single page tells a project team exactly what is in bounds, and that the resin vendor's lot quality is a supplier issue they will have to manage but not re-engineer. Everything the team touches lives between "load resin" and "stage pallet," and nothing outside it gets to expand the project.
Notice what the example does not contain: machine settings, changeover steps, the exact caliper procedure, cycle times. Those belong in the detailed map that comes next. The SIPOC's job was to fence the work and name the customers, and it did both in one page.
How Is a SIPOC Different From a Process Map or Value Stream Map?
All three describe a process, but at different zoom levels and for different jobs. A SIPOC is the aerial photo; a process map is the street map; a value stream map is the street map with traffic data. Mixing them up is why so many "process maps" end up as unusable wall-sized murals nobody updates.
| Tool | Zoom level | Best question it answers | Typical detail |
|---|---|---|---|
| SIPOC | Highest / boundary | What are we improving, and where does it start and stop? | 5 columns, 4-7 process steps |
| Process map / flowchart | Middle | What is the exact sequence of steps and decisions? | Every step, branch, and handoff |
| Value stream map | Deep / whole flow | Where are the waste, delay, and inventory across the flow? | Cycle times, WIP, lead time, data boxes |
In a Six Sigma project the sequence is usually SIPOC first to define the scope, then a detailed process map to see the steps, then cycle time and data collection to feed statistical process control once the improve and control phases arrive. Skip the SIPOC and the detailed map has no agreed edges; it just spreads.
By the Numbers
SIPOC is a standard tool of the Define phase in DMAIC, the five-phase problem-solving cycle (Define, Measure, Analyze, Improve, Control) that structures most Six Sigma projects and their bodies of knowledge (ASQ, Six Sigma resources; ASQ, SIPOC). The whole point of putting it in Define is sequence: you cannot measure a process whose boundaries the team has not agreed on. A SIPOC deliberately caps the process at roughly four to seven steps, which is what keeps it to one page and one hour, the constraint is the feature. For the deeper mapping that follows, see the value stream mapping guide, and for how SIPOC feeds a full project, the Six Sigma belts breakdown.
What Are the Most Common SIPOC Mistakes?
The failures are predictable. The process column turns into a flowchart, so the map takes an afternoon instead of an hour and scopes nothing. Outputs get written as verbs ("inspecting") instead of things ("inspection record"), which blurs what actually crosses the boundary. Customers get reduced to the external buyer, ignoring the next operation that is the real, immediate customer of most outputs. And the map gets built by one person in an office instead of by the team at the wall, so it captures how the process is imagined rather than how it runs. A SIPOC drawn alone is a guess with columns.
Where this connects to running a plant: a SIPOC is only as true as the process it describes, and on most floors that process lives in tribal knowledge and paper logs. Harmony captures what actually happens at each step, the real inputs consumed, the real outputs and records produced, so the boundaries you draw on the wall match the process on the floor rather than the one people remember. See how that works on a running line in the CLS case study or the platform overview. Once the map is real, tools like the spaghetti diagram and standard work have something solid to build on.