“Don’t use Six Sigma to tackle special cause variation!”
is one of the common phrases being repeated by Lean Six Sigma coaches and a very important recommendation for the management, too.
The Six Sigma methodology is indeed targeting variation that is an inherent part of the process – common cause variation that has been expected and tolerated due to its unknown and supposedly complex root causes. Understanding this variation and analysing the real root causes before implementing improvements is a fundamental pillar of the methodology and driver for its success. Collecting data over time and going through the project work tool by tool take time – normally some month, sometimes more than half a year.
This is time we cannot effort to invest in case that something unexpected, something special jeopardises our process and its output, endangers our employees or compromises our relationship with our clients. This situation requests quick turnaround from recognising the symptoms of the problem to implementing corrective actions. The Six Sigma methodology won’t be appropriate in this situation because there might not be enough data that can be analysed using the powerful toolbox and there is definitely not the time to do so.
However, unstructured fire-fighting is not a promising solution either. When we are pressurised to seek a solution without a structural framework, we often ignore or miss out relevant information that could be crucial to solving the problem. The “fire fighting” mindset tends to force us to pay attention to information that we can understand and knowledge that we can articulate, and downplay and ignore those information that we do not comprehend. While we may reach a perceived “solution”, it is usually an action that provides a temporary relief in our pressing need to give an explanation and propose a way-out to our management. The problem will usually bounce back quickly later, but under the disguise of another “problem”.
What is the way out? The “Problem Analysis” method proposed by Charles Kepner and Benjamin Tregoe, or “Hypothesis Testing” approach proposed by Morgan D. Jones (Former CIA analyst) offer useful and systematic concepts for such situations. The first-mentioned method provides a comprehensive thinking process that guides a problem solver from defining the problem towards finding the root cause. It prevents our minds from making wrong assumptions and from being misled by a false understanding of the situation. The process could be simplified into four key steps:
1. Define the problem
2. Identify possible causes
3. Evaluate possible causes
4. Verify probable cause
Here is an example of applying the process to a problem that the author encountered some time in Jan 08: Problems with some metal panels coming out from the powder coating section. Few batches of panels were rejected as there were dusts found embedded underneath the powder coating. It was puzzling as such problem has not existed before.
1. Define The Problem
Here you gather information that defines the problem. Information gathered were sorted and organized into four areas: “What”, “Where”, “When” and “How Much”. Separating them into “Is” and “Is Not” provides a useful way for comparison and stimulating the mind to generate ideas on possible causes. Let us take a look at the problem definition on the powder coating example using this method:
What IS: Metal panels after powder coating were found with dust underneath the powder coat
What IS NOT: Other defects (colour, tone, texture, etc) on powder coating
Where IS: Outputs from both spray chamber: C1 and C2 (new set up in Oct 07 to meet increasing demand) Workers in C1: Avg 3yrs, Workers in C2: Avg 3mo. Dusts scattered randomly under powder coat.
Where IS NOT: Dusts scattered throughout the entire surface or in certain pattern under powder coat.
When IS: Since Dec 07 till now.
When IS NOT: Before Dec 07
How Much IS: Random batches from both chambers with overall reject rate at around 30%
How Much IS NOT: 100%
2. Identify Possible Causes
When the information under “Is” and “Is Not” were carefully examined by a small team, several possible causes were suggested:
a. Work environment was dusty
b. Powder coating material was faulty
c. Temperature in oven was not set correctly
d. Time in oven was too short
e. Lower skill level of new workers
f. The panels were not properly cleaned before powder coating
g. The panels were contaminated by workers prior to powder coating
3. Evaluate Possible Causes
In this step, those possible causes identified in step 2 were checked against the information gathered during step 1 in our problem definition. For a possible cause to be the root cause, it must be consistent with all the information that defines our problem. (2a) to (2e) were eliminated as probable root causes as they were not able to explain all the information gathered. Only (2f) and (2g) are consistent with the problem definition and one of them could lead to the root cause of the problem.
4. Verify Root Causes
Knowing the two probable causes, an observation study was arranged without the knowledge of the workers. The powder coating section was buzzed with activities during the observation period. It was found that the workers tended to do a rough cleaning for panels prior to lunch and dinner time. Discussion with the management on the observation revealed that the company has implemented a new policy that required the workers to punch their job cards during lunch and dinner time in order to ensure that the workers leave and return on time from lunch and dinner. However, this rigidity has driven those workers to rush their cleaning jobs that resulted in those “dust” problems on powder coated panels.
Conclusion
The “Problem Analysis” method enhances the problem solving skills of a “Lean Six Sigma” expert. It offers an alternative approach for problems that appear suddenly and need to be solved rapidly. Instead of going through a typical Lean Six Sigma project, it offers a smart way to quickly guide a problem solver moving in the direction of determining root cause and solving the problem.
Having alternative Problem Solving methodologies for different kinds of problems not only helps to use resources economically, but it also avoids frustrated project teams not being able to deliver what is needed for the business.
Print
