Many times, we solve a problem only to have it recur either on the same product or process, or on other products or processes in our organization.
When this happens over and over again, it appears as if we are simply unable to let them go! I sometimes call this “being addicted” to our problems.
The cause of this is fairly straightforward. It occurs because problems are frequently “solved” by addressing symptoms rather than root cause(s) of the problem. Additionally, we typically do not “fix the system” to prevent recurrence in other areas of our organization.
In order to solve problems permanently, the root cause(s) must be resolved, and, the conditions which allowed the problem to occur in the first place must be changed in such a way as to eliminate any possibility of recurrence.
This is not as complicated as you might think.
Most mid to large companies have a corporate problem solving methodology. These tools typically have anywhere from four to 8 steps, and are given catchy names like 8-D, 7-D, 5-D, Four-Step Program, etc. Any of them can work well if used as designed. Unfortunately, this rarely occurs. Often, the form is used as a reporting tool rather than as a framework or process for solving a problem.
One can postulate that there are really twelve steps to solving a problem, just like there are twelve steps to overcoming an addiction. These steps are:
- Admit that you have a problem
- Form a team to work on the problem
- Describe the problem
- Determine who are the downstream operations and customers affected by this problem.
- Containment - Devise temporary solutions to isolate the problem from downstream operations and customers, i.e. “How do we protect the customers”
- Verify that your containment actions are effective.
- Root cause analysis and verification
- Identify potential permanent corrective actions
- Permanent Corrective Action
- Verify the effectiveness of Permanent Corrective Action(s)
- Implement Preventive Actions (also known as “Fix the System”)
- Congratulate the Team
In spite of there being 12 steps in this process (or whether you use a 5 step, 8 step, or 30 step process), if you skip the basics of fully defining the problem, getting the right people involved, protecting your customer in the short term, reaching true root cause, and changing the conditions which allowed the problem in the first place, guess what?
You have not gotten rid of the problem! It will be back!
In our 12 step approach to problem solving, we are not attempting to make light of addiction, but wish to highlight that recurring problems can be likened to having an “addiction” to the problem. It’s something you just can’t seem to get rid of, no matter what you try.
Most corporate problem solving tools in use today combine the steps listed above into fewer steps. However, when you study the actual methods, all the steps included here are generally included. In this article, I have chosen to keep them separate to illustrate their importance.
Here’s how it works!
- Admit you have a problem
In the 12 step programs used for alcohol or drug addiction, or for other addictions, the first step is to admit that you have a problem. Only then can you have any hope of resolving it.
In our 12-step problem solving process, the first step in solving any problem is also admitting that the problem exists and that we “own” it.
Stand up and announce it to yourself and your co-workers – “Hi, this is John, WE HAVE A PROBLEM!!!”
If you can’t admit the problem exists and that you “own” it, you don’t have a prayer of solving it.
Let’s face it, most or all of us have “solved” problems only to have them come back over and over again.
Admitting “ownership” is critical. Whether we think it’s a customer issue, a supplier issue, or we’re not sure, if we don’t decide that we own it and are going to resolve it once and for all, the problem will persist.
- Form a team to work on the problem
So, who should work on your problem?
The short answer is “anyone who can provide positive input and help solve it”. You may be surprised at who these people might be.
Think carefully and solicit input from co-workers to see what functional areas besides your own could be affected by or contribute to the resolution of the problem. What areas might be causing the problem? People with specific knowledge can help ensure that solutions are comprehensive, get to the true root cause(s), protect downstream operations and customers, and prevent similar problems from occurring in other areas of the company.
Initially, start with those directly affected or with a clear relationship to the problem. Once you define the problem better (in step 3), you can refine the membership of your team. You may revise the membership of your team as you go through the different steps of solving the problem as some members are no longer able to contribute or you need the input and contributions of people who are not needed in earlier stages.
It is OK if the membership of the team is fluid, as long as you remember that having the proper team working on the problem at each stage of the process is critical.
- Describe the problem
Oftentimes, you will find that thoroughly describing the problem in excruciating detail will lead you to both containment and the root cause.
There are many schools of thought about what constitutes a thorough description, but a good “rule of thumb” is that if you can describe what is called the “5W2H”, you have a pretty good handle on the problem.
What is 5W2H?
5 W refers to “Who”, “What”, “Where”, “When”, “Why”.
2H refers to “How”, and “How Many”.
“Who” – Who discovered the problem? Who is affected? Who can have or has an effect (positive or negative) on the problem? Who, both inside and outside the company, is already aware of the problem? Who needs to be aware of the problem? Did one of our line operators find the problem? Did our customer find it? Did someone else find it? Who?
“What” – What happened? This should include the effects both inside and outside the company. Potential effects should be included. How did the parts fail? What was the net effect on the product, operations, customer, etc.?
“Where” – Where did we find the problem? Where were affected parts made and detected? Where do we need to go to contain these parts? Warehouse, customer’s incoming area, production line, raw goods warehouse, etc. are examples.
“When” – When did we detect the problem the first and subsequent times? When did we notify our customer (or worse, were notified by our customer!) that the problem was found? When were the suspect parts (or business process output, etc.) produced?
“Why” – Why is this failure or defect important? Why is it of significant enough interest to justify creating a team to solve it? Why is it important to solve it?
“How” – How did we find the problem? Did our part fail in our final test? Did parts fall apart on our line? Did we find it through an out of control condition on an SPC (Statistical Process Control) chart?
“How Many” (How Much, How Often) – Quantify the problem in objective terms! How many parts were found at the customer? How many were found in our process? How many are in our warehouse or in process right now? How many are in transit to our customer, or in the case of parts from suppliers, how many are on their way to our facilities? How many parts have failed and where did they fail? How many do we estimate will fail based on statistical analysis or other quantitative methods? How often does the problem occur? Does it occur only 2 days after the full moon? Quantify, it may lead you to a repeatable pattern.
Of course, 5W2H is not the only method which can be used for describing problems.
There are many other methods such as “IS-IS NOT”; “5 WHY”; “Multiple Branched 5 WHY”, which are effective when used properly.
The bottom line is that comprehensively describing the problem and everything you know (or don’t know!) about it will help you in both containing the problem and reaching root cause(s).
A sample problem description incorporating the 5W2H might look something like this:
“On December 15, 2005, around 6:45pm, the second shift widget installer (John Smith) at the Jacksonville Assembly Plant found 2 of our widgets with inadequate surface finish.
Mr. Smith rejected both parts immediately and notified his supervisor, Jane Smith. Ms. Smith called our resident engineer (Jason Smith), who came to the plant immediately.
Jason inspected the parts and determined that they had pinholes in the paint around the second carbuncle lead on the inboard side (see attached pictures). He immediately inspected all parts waiting for assembly as well as inspecting the parts in the Assembly Plant’s incoming area and raw goods storage area, but didn’t find any additional parts out of 800 inspected.
Jason called Ole Smith at our Tampa plant, who immediately brought in a crew to sort all parts in the warehouse. Ole determined that there were no parts in transit to the customer at this time. During the sort, 3 more parts were found of 1500 parts inspected.
Examination of the parts indicated that all had pinholes in the same area as the 2 parts found at Jacksonville.
Initial indications are that the pinholes are occurring during the painting process. This is based on examination of the edges of the pinholes, which show that air bubbles were present. This may be caused by several factors, including drying time or temperature, paint mix, contamination on the base parts, or paint spray process.
Summary:
Date/Time problem found: 12/15/05, Second Shift, 6:45pm
Location: Jacksonville Assembly Plant
Total defects found: 5/2300 or 0.217%
At Customer: 2/800 (0.25%)
At our plant: 3/1500 (0.2%)
In Transit: 0 (no parts in transit)
Defect: Pinholes in the paint around the second carbuncle lead on the inboard side (see attached pictures)”
This problem description covers all of the 5W2H, and provides the basic facts of “what happened” so that the team working on the problem is all on the same page and can work effectively. It also provides enough information so that the makeup of the team can be determined, or, if the team has already been formed, can be “fine tuned” to ensure that there is someone from the paint department, someone from quality, someone from the dock auditing activity, etc. on the team.
This description could be expanded by adding “Is-Is Not” or any other descriptive method.
- Determine downstream operations and customers affected by the problem.
Let’s define what is meant by “downstream operations” and “customer”.
Downstream operations include any operation that occurs in the company after the operation where this problem may have occurred or been detected. If the problem occurs at operation # 4 of a manufacturing process, then downstream operations would be any operations numbered 5 or higher.
“Customer” can (and should!) be very broadly defined as the recipient of the product or process. A downstream operation can be a customer as can an actual purchaser of the final goods or services be considered a customer.
Without the understanding of “who are ALL the affected customers”, it is impossible to reach a “containment”, or “protection” solution that will enable the problem to be isolated and kept from causing further damage.
- Containment – implement temporary solutions to isolate the problem from downstream operations and customers, i.e. “Protect the customer(s)!”
This is a critical step. Once a problem has been detected, it is crucial that our customer never see it again! It is our responsibility to protect the customer!
“Containing” the problem at this point can save hundreds of thousands, or millions of dollars, depending on the impact of your “customers” receiving the defective output of your process.
In the automotive industry, an uncontained problem can cause an assembly plant to be shut down at a cost of millions of dollars per day. This is obviously unacceptable, and has been known to cause automotive suppliers to go out of business.
If you do nothing else, you MUST contain your problem and protect your customer. You must make sure that your containment action does not cause additional problems, and you must verify that it is effective.
Your containment actions must remain in place until your permanent corrective action(s) have been implemented and verified.
Some methods for containment of problems include 100% sorting of finished goods, double and triple in-process inspections, 200% and 300% dock audits, temporary process changes, enlisting suppliers’ help in certifying their supplied parts, rework of non-conforming parts, and re-stocking plans to swap out suspect inventory at the customer locations. There are other actions which can be taken, but these give the general flavor of what must be done.
Typically, you should keep your customers informed of the actions you have taken, especially if the problem was discovered by your customer. This leads to customer goodwill.
You might be surprised at the number of customers who appreciate a supplier stepping up, accepting responsibility for a problem, and then keeping the customer informed about the resolution of the problem.
Remember. The most critical element of containment is that the customer is protected and never receives any more defects of this type!
- Verify that your containment actions are effective
Although it may sound redundant, it is critical to prove that your containment actions are indeed effective.
You can use SPC charts, check-sheets, inspection results, designed experiments (DOE), test results, or any other applicable method, but the end result is that you need to be able to prove beyond a reasonable doubt that your customer is not going to receive ANY non-conforming product. There is nothing worse than having your customer call you and tell you “um, we found 10 more parts with the same defect in your certified stock”. Gulp. Now what? In many cases, the next step is for your customer to demand extensive protections, third party interventions, or removing your company from their approved supplier list. Dire and costly consequences indeed!
Determine what measurable product and/or process parameters can be used to verify that the problem is or is not contained, then measure and track those parameters!
Keep strict records of the results to be able to prove to your customer that you are protecting him! Before and after comparisons are absolutely critical!
- Root cause analysis and Verification
Once you are certain that your customer is protected, it is time to determine the root cause of the problem.
There are two types of root cause which must be addressed.
The first is “WHY or HOW did the problem occur in the first place?”. This is also known as the root cause of the “Occurrence”.
The second is “WHY and HOW did the defective parts escape from our process?”, or the root cause of the “Escape.
Both of these are key and must be addressed to ensure that the problem does not recur and that this or similar problems, if they did occur, could not possibly escape.
There are many tools which can be used to determine root cause. These include (but are not limited to) Fishbone Diagrams (also known as Ishikawa Diagrams), 5-Why, Multi-legged 5-Why, Designed Experiments (DOE), Fault-Tree Analysis, Process Mapping, Cause and Effect Matrixes, Brainstorming, Check-Sheets, etc.
The best way to start is to use the problem description (see, you knew we were going to use it for something, right?!) as a basis for discussion.
Try to determine where in your process the problem is occurring. From this information, quantify the problem even further. Is it happening only on a specific shift? With a specific operator? Is it random (i.e. all shifts, all operators)? Is it due to the way parts are received from a supplier? Do the parts need to be clean?
Refer to the Design and Process FMEA’s and the Control Plan. Are they up to date and being followed? Are operators following their standardized work instructions? Do standardized work instructions exist?
Check the SPC for this process, if it exists. Did the process go out of control?
Map the process in excruciating detail. Have the team examine the process flow to see if there are steps which could allow this defect to occur.
Develop a Cause and Effect (Fishbone) Diagram. This is a method frequently used to help you identify contributing elements of the problem by sorting them into “People”, “Material”, “Methods”, “Equipment/Tools”, “Environment”, and “Measurements”.
Perform a designed experiment (DOE) once you have a better idea of the variable inputs to the problem. This can help pinpoint the degree to which specific elements contribute to the problem.
Do not be afraid to challenge the “conventional wisdom”. If your analysis leads you to determine that the root cause is due to a design flaw or oversight, then that is where it leads! It is important to be objective and let the data drive your conclusions (as opposed to having your conclusions drive your data!).
In short, there are many methods which can be used for root cause analysis. Pick those that are appropriate to the problem at hand and which you feel comfortable using. The method(s) used are not the critical element here – getting to the root cause is.
Verification of the root cause can be done in many ways. The best is by running “confirmation experiments” in which you can turn the problem on and off at will.
If you are able to correctly and precisely predict the results of modification to the process or design parameters, then (and only then!) will it be clear that you truly understand the root cause of the problem.
As an example, let’s suppose that your problem is bubbles in potting material. This occurs intermittently in your process.
If you truly understand the root cause, you should be able to run your production with and without bubbles simply by modifying whatever process or product characteristics you’ve attributed to root cause.
If the root cause is excessive heat in your process, you should be able to precisely determine what level of heat is the threshold for turning bubbles on or off.
Turning a problem on and off for the first time can be a truly enlightening experience for many people who until now have thought that “knowing” the cause without physically verifying it was sufficient.
- Identify Potential Permanent Corrective Actions
Once the root cause of the problem has been determined and verified, it is time to identify potential permanent corrective actions.
These actions must address the root causes of both the occurrence and the escape of the problem.
In some cases, the containment action can be a permanent corrective action. This is more typically found where the problem description has been so thorough that it has highlighted an obvious root cause.
Typically, however, permanent corrective actions will involve changes to the product design, manufacturing process, gages, testing, standardized work instructions, or all of the above!
One action which is frequently necessary should never be considered the entire corrective action – that is “Train the Operator”. As a permanent corrective action, this is not effective in most cases. Operators change, processes change or move, people get tired, get distracted, or simply forget to perform a process step.
Effective corrective actions should make it impossible to cause the problem again. The best approach is to change the design in such a way as to make it impossible to build or assemble it incorrectly – the part will simply not go together unless assembled correctly.
The next best approach if a design change is not possible is to use an assembly fixture or jig that makes it impossible to assembly the product incorrectly.
Failing that, the minimally acceptable method is to make it impossible for an incorrectly built or assembled part to leave the station in which it was assembled.
Together with the team, put together a list of potential actions which will correct the root causes. The team should list as many potential solutions possible and should then rank them by effectiveness, cost, timeliness, etc. to help in determining the “best” solution. Remember that solutions are needed for both “Occurrence” and for “Escape”!
- Implement Permanent Corrective Action(s)
Once the team has determined which corrective actions will be taken to eliminate the causes of occurrence and escape, those actions must be implemented as expeditiously as possible.
One reason for doing this quickly is that containment actions are typically temporary and not as robust or cost-effective as the permanent actions.
Contrast the long-term costs of doing 300% inspection over two shifts (i.e. six additional operators) vs. implementation of a simple assembly jig and/or error-proofed assembly fixture.
- Verify Permanent Corrective Action(s)
- Implement Preventive Actions (also known as “Fix the System”)
- Congratulate the Team