SIPOC in Five Steps: A Practical Guide

Ask three people where a process begins and you will get three answers. The clerk says it starts when the request hits the inbox. The manager says it starts at budget approval. The customer says it started weeks earlier, when they first asked for something. Every improvement project inherits this confusion, and every good one resolves it early — usually on a single page called a SIPOC.

SIPOC stands for Suppliers, Inputs, Process, Outputs, Customers. It is a high-level map of a process: not the detailed flowchart with every decision diamond, but the aerial photograph — five to seven major steps, what flows into them, what flows out, and who stands at either end. Teams typically build one during the Define phase of a DMAIC project, in a single working session, before anyone collects data or proposes a fix.

The tool is modest and the payoff is not. A finished SIPOC settles scope arguments, exposes forgotten customers, and gives the team one shared picture they will point at for the life of the project. Here is how to build one in five steps — and how to avoid the habits that turn the exercise into wall decoration.

What a SIPOC is — and what it is not

A SIPOC is a scoping tool. Its job is to establish boundaries: the first step the project may touch, the last step, and everything the process depends on or delivers. It deliberately stays at high altitude. If your process column has fifteen steps, you have drawn a flowchart. If it has five to seven, you have drawn a SIPOC. Detail comes later, in Measure and Analyze, once the team knows which stretch of the process deserves it.

It is also not a solo exercise. A SIPOC drawn alone at a desk records one person’s assumptions, neatly formatted. Drawn with the people who actually run the process, it surfaces the disagreements that matter. It is far cheaper to discover in week one that finance and operations mean different things by “order received” than to find out in week nine, buried inside contradictory data.

The five steps, in the right order

The letters spell SIPOC, but nobody builds one left to right. The reliable sequence starts in the middle, with the process itself, and works outward. Outputs and customers come next, because they explain why the process exists. Inputs and suppliers come last, because you cannot know what feeds a process until you have agreed what the process is.

1. 01Name the process and fix its endpoints. Agree on the first step and the last step. These two decisions are your project scope, so argue about them now, in the room — not in week nine.
2. 02Fill in the middle. Add the four to six major steps between the endpoints, each one a verb and a noun: receive application, verify documents, approve request, issue equipment.
3. 03List the outputs. What does the process hand over when it is done — the product, the document, the decision, the data? Include the unglamorous outputs too, such as records and reports.
4. 04Name the customers. For each output, ask who receives it. Some are external and pay the bills; many are internal and simply live downstream. Both belong on the page.
5. 05Trace inputs and their suppliers. For each step, ask what it consumes — forms, information, materials, approvals — and who provides it. Suppliers can be vendors, other departments, or the customer themselves.

Timebox the session to about an hour. A SIPOC that takes an afternoon has drifted into flowcharting, and a team that polishes one for a week has confused the map with the journey. Rough and agreed beats beautiful and disputed.

A worked example: new-hire onboarding

Consider onboarding a new employee — a process nearly every organization runs and few run well. The team agrees the process starts when a signed offer letter arrives and ends when the new hire can do productive work on day one. The middle steps: create the employee record, provision accounts and equipment, schedule orientation, assign a first-week plan.

Outputs: an active employee record, working accounts and hardware, a scheduled first week. Customers: the new hire, the hiring manager, payroll, and the security team that audits access. Inputs: the signed offer, identity documents, role details, equipment requests. Suppliers: the recruiter, the candidate, the hiring manager, IT. Ten minutes into the exercise, someone notices that the hiring manager appears as both supplier and customer — and that nobody actually owns the equipment step. That discovery is the SIPOC earning its keep.

Five habits that make a SIPOC decorative

• Building it alone and presenting it for approval — you get compliance, not agreement
• Letting the process column sprawl past seven steps until scope quietly expands with it
• Listing only external customers and ignoring the internal ones who feel every defect first
• Skipping the arguments — an endpoint everyone silently disagrees with is not an endpoint
• Filing it away after Define instead of revisiting it whenever scope questions resurface

A project that cannot fit its process on one page does not yet understand what it is fixing.

From one page to a full project

The SIPOC is often the first tool a practitioner uses on a real project, and it rewards doing properly what it punishes doing casually. Our free White Belt program teaches the scoping toolkit — SIPOC, charters, and the DMAIC roadmap — in about six hours, ending with a 30-question exam and a verifiable certificate. When you are ready to lead the whole project the page describes, the Green Belt builds every phase around a simulated project across 35 hours. Either way, the next time someone asks where the process starts, you will have more than an opinion. You will have a method.