3.4 PER MILLION
Reviving the Process Map
by T.M. Kubiak
Recently, I was conducting a series of project reviews at a client site. Several Green Belt (GB) teams, their project Black Belts (BBs) and Champions, and two Master Black Belts (MBBs) participated in the reviews.
Toward the end of the reviews, I quietly leaned over to one MBB and asked why the teams were using basic flowcharts instead of process maps. The MBB nonchalantly replied that process mapping took too much time and basic flowcharts were much easier to use and understand for all concerned.
Imagine my surprise! Here was an MBB essentially discounting the use of one of Six Sigma’s most fundamental tools. Concerned by this, I spoke with several different colleagues later that same week only to find they have noticed the same alarming trend. They, too, were being told that:
- Flowcharts are easier to build.
- Process maps take longer to complete. The delays hamper the ability to show results quickly.
- Teams don’t like all the details associated with process maps. The process maps seemed cluttered.
After reflecting on this input, my initial reaction was to conclude that I was drawing too fine a distinction between flowcharts and process maps. Should I really care? After all, didn’t they both use the same symbols? Didn’t both depict the flow of the process and define the decisions that have to be made? The answer, of course, was a resounding yes.
Still unsettled and uncomfortable with pushing my concern aside so quickly, I continued to ponder the issue. Process maps reveal much more about a process than flowcharts do, and they provide the GB team and project BB with more guidance. Process maps address the key foundational concept of Six Sigma: the concept of Y = f(X), or simply, outputs are a function of inputs.
You’re saying to yourself, “Hey, we all know this. Let’s move on.” At some cognitive level, this might be true. Perhaps the basic concept of process maps has not been sufficiently internalized by practitioners, allowing it to become an underused tool, perceived as being inefficient and cumbersome. Instead, it should be the foundational concept.
Categorizing and Classifying Process Input Variables
Let’s explore the basic anatomy of a process map, as shown in Figure 1. Input variables, the X’s, flow into a transform function called a process. One or more desired outputs flow from the process.
Notice the inputs appear below the flow line while outputs appear above the flow line. This is simply a matter of aesthetics.
Otherwise, inputs and outputs appearing on the same line would significantly clutter the map, particularly when multiple process blocks appear adjacent to one another. This setup isn’t earth-shattering, but eliminating it is helpful.
Notice the list of input variables. They should be familiar, because they represent the typical categories (also known as the 6Ms) of the main bones in a fishbone diagram.
You’ll note some authors include management as another category and call the list the 7Ms. Using the 6M’s as a structured approach provides some assurance that few inputs will be overlooked.
Table 1 identifies each of the M’s, along with alternative terminology that might be used in service or transaction based industries, for example. Commentary and insight about each M also has been included.
One important aspect regarding input variables not visible in Figure 1 is their classification. Classifying input variables helps practitioners focus on those inputs that are controllable and guides practitioners away from spending time and energy on those that are not.
An example of a common classification scheme is shown in Table 2. Properly classifying input variables requires recognizing the need to fully understand a process in relation to the culture and business needs of the organization.
Let’s assume a technician represents the manpower required to perform a given process. What classification or variable designation from Table 2 should a GB team assign it?
- If the team determines the skill and experience level of the assigned technician can be appropriate to the needs of the process, then the team would classify the technician as a controllable input variable. It would appear in the process input list as “technician (C).” The input variable is followed by the classification designation in parentheses.
- If the team determines management will never invest in training technicians and the technician assigned to the process is fixed, the team might consider classifying the technician as a noise input variable. If this is the case, then it would appear in the process input list as “technician (N).”
This example illustrates the need to revisit processes periodically because organizations continually change and evolve. New and insightful management might recognize the need to grow and improve the skill level of its technicians. Hence, input variables previously classified as noise might now be considered to be controllable. Likewise, the opposite might become true.
When counseling teams, I have generally found it more effective to focus on addressing whether an input variable can be controlled instead of trying to determine whether it will ever be controlled. This avoids the complications of having a team second guess management.
Gaining Insights From Process Maps
Figure 1 demonstrates the basic architecture and components of the process map. If we expand Figure 1 to represent a series of linked processes or even subprocesses, we obtain something such as the map in Figure 2.
Though still simple in nature, Figure 2 depicts a representation of processes we are more likely to encounter in any organization. For the sake of convenience, inputs and outputs in Figure 2 have been defined simply as letters. Since input variable classifications are not the focus of this section, they have been omitted.
Upon reviewing Figure 2, several immediate observations can be made, including:
- Processes should have boundaries. Define them.
- Identical inputs might be re-quired for different processes.
- Multiple process outputs might occur.
- Outputs of one process might become inputs of another pro-cess.
- Some outputs might be linked to processes outside the process boundaries.
Table 3 summarizes these observations to each of the variables in Figure 2. Note that some of the comments in Table 3 are essentially statements of fact, while others demand action, seek information or require further investigation.
Perhaps this column has provided motivation and a call to action for the Six Sigma practitioner to revive the process map and use this simple qualitative tool to extract information and guidance not present in a basic flowchart.
A set of starting categories useful for identifying input variables was presented, and an input variable classification scheme was suggested. The process map was reconnected to the fundamental equation of Six Sigma: Y = f(X). Additionally, input and output variables identified on a process map were analyzed in the context of a bounded process.
I have seen where the absence of a process map—or the preferred use of a flowchart—has delayed, or in some cases, caused a project to fail. And I’ll bet you have seen it, too.
A well-developed process map can help avert these failures. It can serve as an effective communication tool and be a constant reminder of where a team should focus its time and energy.
- Benbow, Donald W., and T.M. Kubiak, The Certified Six Sigma Black Belt Hand-book, ASQ Quality Press, 2005.
- Galloway, Diane, Mapping Work Processes, ASQ Quality Press, 1994.
T.M. KUBIAK is an independent consultant in Charlotte, NC, and the co-author of The Certified Six Sigma Black Belt Handbook. Kubiak serves on many ASQ boards and is the immediate past chair of the Publication Management Board. He is a senior member of ASQ.