The name “SIPOC” is an acronym for Suppliers, Inputs, Process, Outputs, Customers and it is a tool most of us with any process improvement experience or education have learned to use. It can be used very efficiently and effectively for other dilemmas as well and it doesn’t require us to summon a team and declare an event to use the logic to help us answer important questions.
In particular, I find the SIPOC is very useful for settling arguments about roles and responsibility and identifying gaps in expectations that lead to other arguments. What’s more, it can be a ten-minute exercise; it doesn’t need to be an hour-long ordeal.
Let’s understand the tool briefly in its usual context. I’ll take the opportunity to share some quick tips to get the most out of it for less work. Then I’ll explain how it can also be one of those ubiquitous tools that you find yourself doing in your head to solve an everyday problem.
The SIPOC tool, like many others, has evolved many forms, and the guidelines vary, but the most common version is simply a diagram of five columns organized with each of the acronym words for headings. The designed purpose of the tool is to clearly identify, and achieve consensus about, the critical expectations of a process step and who is setting those expectations and who is responsible for meeting them. It’s one of my favorites because it quickly and effectively organizes and communicates vital information to address or solve a problem.
To construct the diagram properly, we must build it from the middle out. I have seen several resources declare that it must be built right-to-left, but in my experience, we can’t really do that unless we already know the answers. If your resources tell you to build it from left-to-right, throw it in the wastebasket. Start in the middle by filling in the Process column.
In the Process column, or box as many diagrams use, insert a single entry which is the name of the process step under scrutiny. Here is an important piece of advice. Write it in the form of a verb-noun phrase. Don’t write, “Work Order Process.” That noun-only definition could be a single process step or dozens. It lack boundaries, and it misses a huge opportunity to get some real benefit out of the tool, as we will see.
For our example, which we will construct for the discussion, we will fill in the Process box or column with, “Issue Work Order.” The verb-noun statement defines a specific task and, therefore, describes a meaningful context for the team using the tool. There is more it enables, which we will see.
Let’s consider a scenario for the rest of the SIPOC explanation because a little context can go a long way toward communicating understanding. Let’s say that a business is having difficulty because work orders, and the subsequent activities they are supposed to trigger aren’t getting done, or aren’t done on time, or aren’t done correctly.
We want to fix the problem, but before we can fix it we need to understand where it comes from. When we ask everyone involved what the issues are we get a lot of finger pointing. Everyone blames everyone else for making mistakes or setting them up for failure.
So, we started with “Issue Work Order” as our process step to investigate since it appears to be at the heart of the problem. The next step is to determine the Outputs of the Issue Work Order process step. Let’s say that there are three.
There is a production ticket that is produced to schedule and trigger the production of the item requested. There is a purchase request to acquire materials and parts for the item to be produced. There is a production and qualification schedule that is published. We list each of these in the “Output” column of our SIPOC.
For each Output we should then identify the primary or critical customer for each. It is important to focus on the critical or primary customer for a very good reason. The customer determines the expectations of the output.
In our case, the production team is the “Customer” for the production ticket. The sourcing or purchasing team is the “Customer” for the purchase request, and while anyone involved with the item or project is interested in the schedule, the project manager or program manager is the key “Customer” since he or she is ultimately responsible for the on-time delivery of the item.
So for each Output, we now list the single key Customer in the “Customer” column of the SIPOC. Now we can begin to discuss the power of the simple SIPOC tool. By determining who the key customers are for the outputs of the activity, we can settle the disagreements over who is responsible for what, and who is to blame for poor performance (if blame is what you are interested in).
The customers get to dictate what is important, essential, and proper for each output based on what they need in order to do their own activities correctly the first time, without needing to ask for clarity or for more information or instruction. The person doing the activity in the Process box doesn’t get to dictate, the customers do.
That is the important element to understand because it makes it very clear who is responsible for doing what, and what a good output looks like. It settles a great many arguments right away. Ending arguments is always powerful.
Now, let’s put that power to work on the rest of the tool’s information. Recall that we used a verb-noun format to define the Process. Let’s enhance that definition by adding a subject. Let’s change it to a who-does-what format. Our activity or Process label becomes, “Production Planner Issues Work Order.” Now we have a clear definition of another role and responsibility, if it wasn’t apparent already.
If the outputs of the activity are defective in the judgment of the customers, it is the production planner that is responsible. With that in mind, let’s now ask the question, “What does the production planner need to be able to do the activity right the first time?” The answers to this question go into the “Inputs” column.
Of course, we need to identify who is responsible for providing those inputs correctly and in good condition and on time. We put those roles in the “Suppliers” column. Therefore, we might identify that the project engineer provides the engineering drawings and data for the item and also the completed work request form. The production planner needs data from the inventory or supply database, which the materials department is responsible for keeping accurate.
Naturally, the production planner gets to set the expectations for the Inputs, and the Suppliers are expected to meet those expectations. Bottom line, the SIPOC concisely diagrams the key, critical pieces of information necessary to accomplish an activity and who is responsible for each of those inputs and outputs. The ability to quickly answer those questions, identify those gaps, and settle those arguments is what makes the SIPOC powerful.
So, if it is powerful for ironing out wrinkles in process activities, can we use that same power for other challenges? Of course we can. The SIPOC is useful any time we need or want to clarify ownership of an activity or understand or come to consensus about roles and responsibilities.
Imagine that your team and your team leader are in a meeting and you need to prepare a quick presentation. Suppose it is a proposal for an upgrade or some new equipment for your team. We can let the overly ambitious team member who volunteers for everything do it alone, or we can make a better plan.
Use a quick SIPOC approach to make your assignments. You can draw it on the white board, or you can just talk through the logic. What is the activity (process)? It’s a proposal/request to purchase new equipment. What information needs to be communicated (outputs)? Who is vitally interested in each piece of information (customers)? Who else is involved in making or influencing the decision to approve our request (more customers)? What information is vital to them (more inputs)?
Do you see how this works, yet? What information or data do we need to be able to address the critical interests of our decision makers (inputs)? Who on our team is best suited to acquire or assemble or produce each of those inputs (suppliers)? Finally, who is best to present?
Tada! A ten-minute SIPOC discipline, whether you took the time to write it down or not, just helped you and your team leverage itself to its best capability to plan and deliver that important proposal. That is just one example. It works any time that you are either confused about or need to assign roles and responsibilities.
If you don’t know who should make the rules or set the expectations for a form, use SIPOC. If people point fingers instead of get work done, use SIPOC. If you just need to know who to approach for information or to discuss a problem, use SIPOC. It can be done in your head. It should not be complicated. A complicated SIPOC is a misuse of the tool and discipline.
The many tools, such as SIPOC, that we learn for the purposes of process improvement are just ways or organizing and communicating information. Once we understand how a tool facilitates information and focus, we can use it for any application where the same facilitation need appears.
Make yourself and your team highly effective, every day. Learn to use the tools not just in process improvement events, but to resolve everyday challenges. The best tools are simple. Simple is versatile. Leverage that versatility to help you be more critical in your analysis, to assemble the complete picture, and to be more decisive. You might be surprised how easy and effective it is and how much it can affect your personal and team performance.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com
Filed Under: Rapid prototyping