Before you can improve a process, you need to agree on what the process is. This sounds obvious. It isn't. Ask five people on the same team to describe their process and you'll get five different answers — different starting points, different endpoints, different ideas about who's involved, and very different opinions about what matters.
SIPOC (Suppliers, Inputs, Process, Outputs, Customers) is the tool that forces alignment. It's a high-level map that defines a process in one page, answering the five questions that every improvement effort needs answered before any real work begins.
The Five Columns
A SIPOC diagram is a table with five columns, read left to right:
Suppliers — Who or what provides the inputs? These are the upstream sources: departments, vendors, systems, or even other processes that feed yours.
Inputs — What materials, information, or resources enter the process? Raw materials, data, forms, requests, approvals — anything the process needs to function.
Process — What are the major steps? Not every sub-step and decision point — just the 5-7 high-level stages that describe the workflow from start to finish.
Outputs — What does the process produce? Finished products, reports, decisions, services, data — the deliverables that go to customers.
Customers — Who receives the outputs? Internal teams, external clients, regulators, downstream processes — anyone who depends on what this process produces.
That's it. One row per major process step, five columns, usually fits on a single page. The simplicity is the point.
Why It Matters
SIPOC solves three problems that derail improvement projects before they start:
1. Scope Creep
Without clear boundaries, improvement teams inevitably expand their focus. "We're improving the order fulfillment process" becomes "We're improving order fulfillment, and also the way orders are entered, and also the vendor selection process, and maybe the returns process too." Six months later, nothing is improved.
SIPOC draws the line. The process column defines what's in scope. Everything to the left (suppliers, inputs) and right (outputs, customers) defines the boundaries. If an issue falls outside those boundaries, it's out of scope — documented, acknowledged, and deferred. Not ignored, just disciplined.
2. Stakeholder Blindness
Most teams have a narrow view of their process. The production team sees manufacturing. They don't see the sales team that enters the orders, the warehouse that ships the product, or the customer service team that handles complaints about late deliveries. Each group optimizes their slice and wonders why the whole system underperforms.
The Customers column is where this blindness gets corrected. When you explicitly list everyone who receives the output of your process, you discover stakeholders you'd forgotten about — or never knew existed. The compliance team that needs your reports. The finance group that reconciles your data. The downstream process that can't start until yours finishes.
You can't satisfy customers you don't know you have.
3. Input Ambiguity
Processes fail when inputs are wrong, incomplete, or late. But most teams don't have a shared understanding of what their process actually needs to function. The Inputs and Suppliers columns make this explicit.
"We need the customer order form" isn't specific enough. Which fields are required? In what format? From which system? Who's responsible for making sure it's complete? SIPOC doesn't answer all of these questions at the detailed level — that comes later — but it surfaces them. You can't investigate input quality if you haven't first agreed on what the inputs are.
Building a SIPOC
The process works best as a team exercise. Get the people who actually do the work in a room (or a call) and build it together. Here's the sequence:
Step 1: Name the process. Be specific. Not "Manufacturing" but "Assemble and Test Model X Widget." The name should make the scope obvious.
Step 2: Define the Process column first. List 5-7 major steps. Start with the trigger (what kicks off the process) and end with the final deliverable. Resist the urge to list every sub-step. If you have more than 7 steps, you're too detailed. If you have fewer than 4, you're too abstract.
Step 3: Identify Outputs. For each process step, what's produced? Focus on the final outputs that leave the process, not intermediate work products (unless those go to external customers too).
Step 4: Identify Customers. For each output, who receives it? Think broadly: internal departments, external clients, regulatory bodies, other systems.
Step 5: Identify Inputs. What does the process need to function? Materials, data, approvals, specifications.
Step 6: Identify Suppliers. Who provides each input? Trace the source.
Starting with the Process column and working outward ensures you define the core before the periphery. Starting with Suppliers or Inputs often leads to scope expansion because you start mapping upstream processes instead of your own.
The Conversation Is the Product
The SIPOC diagram itself is useful. But the conversation that builds it is more valuable. Here's what typically surfaces:
Disagreements about scope. "I thought our process started when the order is approved." "No, it starts when the order is entered." These disagreements exist whether you surface them or not. SIPOC just makes them visible so they can be resolved instead of silently causing confusion.
Missing inputs. "Wait — we need the engineering specification for this step, but nobody sends it to us consistently." This is a real problem that was invisible until the Inputs column forced the question.
Unknown customers. "The compliance team audits these outputs? I had no idea they used our data." Now you know whose requirements you've been unknowingly failing to meet.
Redundant steps. "Why do we have a separate approval step here when the manager already signed off two steps ago?" Even at the high level, redundancy becomes visible.
Supplier reliability issues. "Our biggest delays come from waiting for inputs from the IT team, but we've never formally communicated our requirements to them." The Suppliers column turns implicit dependencies into explicit relationships.
One team session building a SIPOC will surface more actionable insights than a month of status meetings.
SIPOC in Practice
Manufacturing Example
| Suppliers | Inputs | Process | Outputs | Customers | |-----------|--------|---------|---------|-----------| | Raw material vendors | Steel sheets, fasteners | 1. Cut to specification | Finished assemblies | Assembly line (Station 4) | | Engineering | Design specs, tolerances | 2. Form and shape | Quality test reports | Quality department | | Quality team | Inspection criteria | 3. Weld components | Scrap/rework data | Operations management | | Maintenance | Calibrated equipment | 4. Inspect and test | | | | | | 5. Package for next station | | |
Service Example
| Suppliers | Inputs | Process | Outputs | Customers | |-----------|--------|---------|---------|-----------| | Customer | Loan application, financial docs | 1. Receive application | Approval/denial decision | Applicant | | Credit bureaus | Credit reports | 2. Verify information | Loan terms document | Loan servicing team | | Underwriting guidelines | Policy criteria | 3. Assess risk | Risk assessment record | Compliance/audit | | Employer verification | Employment confirmation | 4. Make decision | | Regulatory reporting | | | | 5. Communicate result | | |
Software Development Example
| Suppliers | Inputs | Process | Outputs | Customers | |-----------|--------|---------|---------|-----------| | Product management | Requirements, user stories | 1. Plan sprint | Working software | End users | | UX/Design | Wireframes, designs | 2. Develop features | Release notes | Product management | | DevOps | CI/CD pipeline, environments | 3. Test and review | Test reports | QA team | | QA | Test cases, bug reports | 4. Fix and iterate | Deployment artifacts | Operations/DevOps | | | | 5. Deploy to production | | Support team |
When to Use SIPOC
At the start of any improvement project. Before you map the detailed process, before you collect data, before you brainstorm solutions — build the SIPOC. It takes 30-60 minutes and prevents weeks of wasted effort on the wrong scope.
When teams disagree about the process. SIPOC is a neutral framework that gets everyone looking at the same picture. It's harder to argue about abstractions when the specifics are written on the wall.
When onboarding new team members. A SIPOC gives someone new a complete mental model of a process in five minutes. Who provides what, what happens, what's produced, and who cares about it.
During organizational change. When processes are being restructured, merged, or transferred, SIPOC documents what currently exists so nothing falls through the cracks.
When defining requirements for new systems. Before building or buying software to support a process, the SIPOC ensures you understand the inputs, outputs, and stakeholders the system needs to serve.
Common Mistakes
Too much detail in the Process column. The process steps should be high-level stages, not a detailed flowchart. "Receive order, validate order, check inventory, allocate stock, generate pick list..." is too granular. "Receive and validate, fulfill, ship" is the right altitude. Save the detail for the process map that comes after the SIPOC.
Confusing outputs with outcomes. Outputs are tangible deliverables — reports, products, decisions. Outcomes are the results of those outputs — satisfied customers, revenue, compliance. SIPOC captures outputs. Outcomes matter enormously, but they belong in the project charter, not the SIPOC.
Forgetting internal customers. Most teams list external customers and stop. But internal customers — the next department, the management team reviewing your reports, the finance group reconciling your data — are just as important. Their requirements shape your process just as much.
Building it alone. A SIPOC created by one person reflects one person's view. The value comes from the team conversation. If you must draft it alone, validate it with the team before treating it as agreed.
Treating it as permanent. A SIPOC is a snapshot. Processes change. Suppliers change. Customers change. Review and update it when the process changes, or at minimum when starting a new improvement cycle.
From SIPOC to Action
A completed SIPOC isn't the end — it's the launchpad. It tells you:
- Where to map in detail. The Process column identifies the stages worth drilling into with a detailed process map or simulation model.
- Where to measure. The Inputs and Outputs columns tell you what to measure. Are inputs arriving on time and complete? Are outputs meeting customer requirements?
- Where to look for problems. Mismatches between what suppliers provide and what the process needs. Gaps between what the process outputs and what customers expect. These are where improvement opportunities live.
- Who to involve. The Suppliers and Customers columns are your stakeholder list. These are the people who need to be part of the improvement conversation.
The best process improvement projects start with clarity. SIPOC provides that clarity in an hour. No process is too complex to summarize in five columns — and no improvement effort should begin without it.