A SIPOC (suppliers, inputs, process, outputs, customers) diagram is a standard part of most Six Sigma projects for good reason: It helps a team to pose and answer important questions about customers, suppliers, requirements and dependencies. In many cases a SIPOC table and a simple process map can go a long way in discovering the process and providing the orientation needed to frame a project.

There are times, though, when those tools, used in their routine way, do not fit a situation and fail to bring out new and expected insights. Some software development processes may not, for example, fall right into a textbook rendition of SIPOC and process maps. In those situations a project team and the process owners may need to look to additional tools to communicate and uncover helpful information. For instance, value stream maps sometimes provide a better lens for getting process thinking started. In addition, the less-familiar integrated definition (IDEF) model and service-oriented architecture (SOA) also can help initiate the first fruitful discussions.

Different Process Types, Different Objectives

Obviously, all processes are not created equal. Table 1 outlines one way of describing the range of process types and objectives that practitioners might run into.

The first column in Table 1 outlines the common repetitive process, such as volume manufacturing operations and routine services. The objective of a project on this type of process is often to drive out the variation that makes an output different from the others, striving for uniformity. A repetitive process is the sweet spot for SIPOC and simple process mapping, and these tools are often taught with examples from this end of the process spectrum. In fact, in some cases in which SIPOC does not fit a particular process, it may be because a facilitator described and used the tool with too rigid a view of this kind of process in mind.

Situational processes, in the middle column of Table 1, do not always follow the same flow or easily reduce to a simple view of inputs and outputs. Software development process participants and owners often will see their work as more event driven or iterative. In those processes, the objective is not to do the same thing the same way for the same outcome, but to tailor a response to specific events and conditions. It is not differences between the outputs, but variation in things such as quality, and expected versus actual cost and cycle time that is more likely the enemy.

Practitioners in innovative processes, the last column in Table 1, such as research and development (R&D) and new product and service design may have to work harder to identify inputs, prospective outputs and the dynamics connecting them. Variation in understanding of things such as requirements, architecture and design choices may be more the nature of the enemy.

Facilitators using examples and thinking related to repetitive processes when introducing SIPOC to people with processes elsewhere in this continuum might find their team struggling to get the work to feel right and to yield useful results.

Looking at Additional Tools

Three tools beyond process maps can help initiate conversations between process participants and owners and help them to uncover some of the insights that SIPOC is reaching for.

1. Integrated Definition Thinking

Integrated definition modeling is a rich system for discovering, describing and modeling operations at any scope in an enterprise or other endeavor. The small but useful part of the tool focused on here is thinking connected with teasing out the controls and resources associated with a process or process step (Figure 1).

This type of modeling maintains the disciplined view that inputs are things that affected by both controls and resources, and are transformed into outputs. It separates controls and resources, which do flow into a process, but for different purpose and with different meaning, for separate consideration.

Controls are two-way signals that an activity uses to know things such as when to start or stop, how to measure or report progress and results, what to expect next, and so on. A process or step may communicate status and outcomes through controls.

Resources identify what a process or step activity depends on (e.g., people, energy or things) in order to keep operating well.

Sometimes all it takes to help improve a SIPOC discussion is to realize that the inputs being discussed are becoming a bit of a mishmash of inputs that are truly transformed into the outputs, in the integrated modeling sense, resources and controls. Seeing that more refined detail can help assure that process team members are not missing important inputs as the view of things that the process or step depends on widens. Facilitators do not need to leave SIPOC or introduce IDEF in a visible way; they simply can use the thinking to get unstuck. 

2. Value Stream Analysis

Value stream mapping is flexible enough to readily fit all of the process types outlined in Table 1. The “stream” sense of sequence is loose enough that it does not get in the way of iterative and event-driven cases, in which there is not one prescribed sequence for all situations.

Anyone in any process can think about waste, queues and constraints. Sometimes the focus on those issues through the value stream mapping motivates the best first conversations about a process area. If a group (perhaps with an innovative or situational process) is finding their first inputs and outputs discussion a little shallow and flat, they might find it easier to think in terms of activities, waste and constraints to flow. This can be a handy ally to SIPOC – once people have warmed up with a value stream view, they have increased insight and patience for a more input-output view. 

3. Service-oriented Architecture Thinking

SOA. In its initial form, SOA was about identifying processes (manual or automated) across an enterprise and moving them to a network-based distribution system. 

The thinking now takes a broader view across an enterprise, considering the capabilities that are important to be able to plug and play. This creates another perspective on the process space that SIPOC is interested in, but from an angle that starts with the functionality and measures conversation. 

In simple terms, a team looks at a domain and poses these questions: 

1. What does the user need to be able to do? Expressing these needs using the right verbs creates a functional view of important capabilities that need to be managed.
2. How should good performance be measured for each key functionality? The answers to this question outline the measures and their targets that comprise the service levels.

In a complex process area in which the SIPOC input-output view does not seem to be resonating at first, facilitators should consider bringing in some of this SOA thinking. It may still be possible to steer things to a useful SIPOC, but finding the insight and energy in this type of architecture may provide a helpful boost.

Teach to the Right Type of Process

Nothing explored here is a substitute for SIPOC, or needs to operate in the absence of simple process maps. The bottom line is, facilitators may have better results introducing SIPOC and process mapping to people in any kind of process if they first take some time to appreciate the nature of their students’ work. Blending SIPOC with some of the thinking outlined here can help a facilitator see and understand things that a routine repetitive-process cookbook approach might miss.