Section 41. SIPOC


41. SIPOC

Overview

The SIPOC is a simple map of the process and, despite that simplicity, is a powerful tool in the Lean Sigma toolkit. SIPOC stands for

  • Suppliers Who provides the Inputs for the Process?

  • Inputs What goes into the Process?

  • Process How is the Process performed?

  • Outputs What comes out of the Process (and, based on the Outputs, how it could be measured)?

  • Customers Who receives the Outputs of the Process?

SIPOC appeared in many earlier incarnations of Process Improvement, but its use in Lean Sigma is subtly different, or at least the map is recognized for what it truly achieves. SIPOC is also known under other anagrams, most commonly COPIS and POCIS. These variants are the same tool but involve filling in the columns in a different order (see "Roadmap" in this section).

When Teams are first formed there is typically a great deal of passion around objectives, potential solutions, and sometimes who is perceived to be to blame for the poor process. Sometimes it's even difficult for the Team to agree on what the process is and what it achieves. The SIPOC helps the Team reach consensus on the simple scope and purpose of the process and the project. Also, because the Team is actively focused on a reasonably objective tool, the early project problems of storming and venting are somewhat alleviated. It has been described as "the bright shiny object used to distract the Team while the project progresses past step zero." To that end it is a potent change management tool.

The useful outputs of the tool are

  • A more unified Team

  • An agreed process scope

  • An agreed process purpose

  • The beginnings of a list of Customers to feed into VOC work (which is expanded in the Customer Matrix)

  • The beginnings of a list of Xs to feed the Y = f(X1,X2,..., Xn) approach (which is expanded in the Process Variables Map)

An example SIPOC is shown in Figure 7.41.1.

Figure 7.41.1. An example of a SIPOC for a hotel reservations process.[80]


[80] Source: SBTI Transactional Process Improvement methodology training material.

Logistics

Creating an SIPOC is absolutely a Team activity and cannot be done by the Belt alone. The Belt should not be tempted to create a straw man of the map prior to the Team session; it should be created from scratch in the Team environment.

It takes the Team about 6090 minutes to construct the map; remember, it is the process of creating the map and not so much the map itself that is important. It is typically best to create the SIPOC on a flipchart-sized page in landscape orientation using sticky notes rather than writing directly on the page.

Roadmap

There are two accepted ways to construct the SIPOC:

  • Start with the Customers and work to the left, always keeping the Customer as the focus (the sequence is thus COPIS). This can be confusing if the process isn't achieving its desired intent, because there is a significant mismatch between what the process does look like and what it should look like when the Team gets back to the Process column. Often this method is useful in Process Design, as opposed to Process Improvement.

  • Start with the Process and work outward (effectively POCIS). This is generally more intuitive for Team members and is the more accepted approach in Process Improvement. This approach is used here.

The steps to construction based on the second approach are as follows:

Step 1.

Begin with the Process column. Brainstorm the high-level process steps and place on sticky notes on the page in the P column. A maximum of 57 steps are used because the Team is going to dig down later. List the steps sequentially using the structure "Verb Noun Modifier," for example "Enter Order In System."

Step 2.

Identify the Outputs of the whole Process, not each Process Step. A common novice Belt mistake here is to try to create horizontal logic for each Process Step. Outputs, written as nouns, are typically one or more of

  • Products or Services

  • Information

  • Decisions

  • Documents

And should be tangible, in that it should be possible at any time to identify whether the process has generated an output or not.

If applicable, consider the Outputs for both internal and external Customers. For example, for an invoicing process the external Customer output might be the invoice itself, whereas the internal Customer output might be an Accounts Receivable transaction.

It is also useful at this point to begin to consider measurable outputs for the process, the potential Big Ys for the process (see "KPOVs and Data" in this chapter).

Step 3.

Identify the Customers who receive the Outputs of the Process. To identify all the Customers, it is useful to ask

  • Who pays for the process?

  • Who represents the VOC?

  • Who are the relevant end users for the process or product?

  • Who represents the Voice of the Business (VOB)?

  • Who are the relevant internal Customers who use the product or process downstream?

  • Who typically pays for the product or service?

  • Which external companies, such as vendors, does the process impact?

Step 4.

Identify the Inputs required for the Process to function properly. Inputs are written as nouns and are usually

  • Physical objects

  • Information

Factors that influence the process.

If applicable, consider inputs from both internal and external Customers; for example, in an invoicing process an external Customer input might be a purchase and an internal Customer input might be pricing information.

Step 5.

Identify the Suppliers of the Inputs that are required by the Process. Suppliers could be

  • Any person or organization that provides an input to the Process

  • Internal Suppliers

  • Co-workers that provide inputs to the process in the same or different departments

  • External Suppliers, such as vendors

Sometimes, Customers are also suppliers and in this case the Customer/Supplier becomes a vital partner in process success.[81]

[81] More common in Transactional and Service processes than in Manufacturing processes.

Interpreting the Output

As mentioned before, the importance of the SIPOC is having the Team going through constructing it, not necessarily the physical end resulting SIPOC map itself.

Based on the SIPOC, the scope of the process (thus the scope of the project) should be clearly defined. Examination of the Outputs of the process should guide the Team to what might make sensible Big Ys for the process.

Do not try to read much more than this into it. The tendency is for Teams to want to base significant improvement decisions on the SIPOC result, when it is really only a tool to help frame the project. The SIPOC represents only current Team thinking; it does not include true Customer inputthat comes later.




Lean Sigma(c) A Practitionaer's Guide
Lean Sigma: A Practitioners Guide
ISBN: 0132390787
EAN: 2147483647
Year: 2006
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net