3558D
• Based on the criteria established, does the ICA provide the best bal-
ance of benets and risks?
• How does this choice satisfy the following conditions?
• The ICA protects the customer 100% from the effect.
• The ICA is veried.
• The ICA is cost-effective and easy to implement.
• Have the appropriate departments been involved in the planning of
this decision?
• Have appropriate advanced product quality planning (APQP) tools
(e.g., FMEA, control plans, instructions) been considered?
• Have plans, including action steps, been identied? (Who needs to
do what by when?)
• Has a validation method been determined?
• Does the customer have a concern with this ICA (is customer
approval required)?
• Have we identied what could go wrong with our plan and have
preventive and contingency actions been considered?
• Are implementation resources adequate? This is a very important
consideration especially when third-party auditors (inspection
houses) do the ICA.
• Does the validation data indicate that the 8D customer is being protected?
• Can the ICA effectiveness be improved?
D4: Define and Verify Root Cause and Escape Point
D4’s purpose is twofold. The rst is to isolate and verify the root cause by test-
ing each possible cause against the problem description and test data. The sec-
ond is to isolate and verify the place in the process where the effect of the root
cause should have been detected and contained (escape point) but was not.
To appreciate the rationale of the D4, we must understand that a situation
was once problem free, but now is not. When this happens, the situation is
considered a change-induced condition. The process of identifying this change
is called problem solving. Various problem-solving techniques exist; see
Chapter13. However, they are all based on three basic strategies:
1. Fact-based, deductive approaches
2. Experientially based approaches
3. Creative approaches
356 Quality Assurance
A working knowledge of various problem-solving techniques is desirable.
The single veried reason that accounts for the problem is the root cause. The
cause explains all facts about the problem. It is veried by the ability to make
the problem come and go on demand.
Determining Root Cause
Information compiled at D2 is used to identify a set of possible causes. At D4,
the root cause is discovered. Problem-solving techniques are used to reduce
the time and confusion to systematically deduce the cause. All subsequent
8D objectives depend on the accurate diagnosis of the root cause. Therefore,
verication of the root cause is critical to the success of the 8D process.
Few things are more damaging to the problem-solving process than
assigning blame. Blaming leads to defensiveness and facts are then obscured
or kept hidden. Misinformation is often generated as a defensive measure.
Therefore, avoid all blame and concentrate on the process!
D4: Guidelines
As mentioned earlier, the fundamental purpose of D4 is to determine the
root cause and escape point of the problem. Therefore, the focus is to identify
both and verify them as the correct ones. Once identied, they are xed at
D6. This step identies and evaluates the correct process of problem solving
using the information of D2. The basic guidelines begin by the appropriate
denition of the root cause, which is the single veried reason that accounts
for the problem and is followed by the escape point, which is the earliest
location in the process, closest to the root cause, where the problem should
have been detected but was not. Other guidelines may deal with
• Verication, which helps to make certain that permanent corrective
actions are directed at the root cause and escape point. Time, money,
effort, and resources are not wasted on false causes.
• Band-aids, which can mask information needed to nd the root
cause. Look out for band-aid xes.
• The true root cause. Usually, the root cause is one change that caused
the problem. If previous problems were never xed at the root cause
level, then the problem may be the result of more than one change.
• Deductive reasoning (rst) to identify the possible causes. If this
method does not work (due to missing information), then use the
cause and effect diagrams and team members’ experience to pursue
other possible causes.
• Appropriate and applicable facts. You cannot identify root cause
without facts. The IS/IS NOT data must be correct and the process
ow diagram must be correct and up to date.
3578D
• All pertinent facts that are directly related to the root cause. The
root cause should explain all known facts about the problem.
Unexplained facts often indicate the presence of another root cause
that creates a similar problem. Ideally, you should be able to make
the problem come and go to prove you have identied the root
cause.
• New surprises. When the root cause is uncovered, other troubles
(which went unnoticed) are sometimes made visible. These other
troubles create the need for an improved ICA in D3 and/or a return
to D2.
D4: Evaluating Questions
When the team feels comfortable with having completed the D4 step, it is
a good practice to review the discussion with at least the following basic
questions:
• Has the factual information in the problem description been
updated?
• What sources of information have been used to develop the poten-
tial root-cause list?
• Is there a root cause (a single veried reason that accounts for the
problem)?
• What factors changed to create this problem? What data are avail-
able that indicate any problem in the manufacturing or design
process?
• How did we verify this root cause?
• Does this root cause explain all the facts compiled at D2?
• Has the root-cause analysis gone far enough? (Do we need to know
why this root cause happened?)
• Is there more than one potential root cause?
• Does each item on the potential root cause list account for all known
data? Has each item been veried (used to make the defect come
and go)?
• How did you determine assignment of percentage contribution?
• Combined, do the items on the potential root cause list account
for 100% of the problem? (Is the desired performance level
achievable?)
• If the level is achievable, has the team considered and reviewed
with the champion the benet of developing a separate problem
description (and, by denition, separate 8D) for each potential root
cause?
358 Quality Assurance
• If the level is not achievable, has the team considered and reviewed
with the champion the benet of alternate problem-solving
approaches?
• Approaches independent of an 8D
• Approaches as a compliment to an 8D
• Does a control system exist to detect the problem?
• Has the current control system been identied? Does this control
system represent a change from the original design?
• Has it been veried that the control system is capable of detecting
the problem?
• Is the identied control point closest to the root cause/potential root
cause?
• Is there a need to improve the control system?
Generic Simple Root-Cause Analysis
Root-cause analysis is based on a questioning process focusing on the
what, where, when, and how big, and answering the following concerns
about the cause using the IS/IS NOT method, identify differences, iden-
tify changes, and testing the outcome. Figure 21.3 shows the ow of this
analysis.
Determination of the Root Cause
In cases where should and actual were once the same but now are different,
the root cause will be a change of some type. The denition of root cause is
the single veried reason that accounts for the problem.
Two deductive approaches are available to lead the problem solver to the
root cause. Both approaches are based on a thorough defect prole built
around the problem statement. Both of these deductive approaches are a
series of questions that yield answers to which another question is applied.
The result is a steady reduction of the number of possible causes to be
investigated.
For comparison, the steps of the two approaches are shown side-by-side
in Table 21.2, having been anchored by the scope (problem statement and
problem description). The two approaches are identical with one exception.
Method B has an addition inserted in the third step.
Method A is best used when all changes are known. On the other hand,
Method B with the additional step eliminates consideration of changes com-
mon to both the IS and IS NOT listed in the problem description. Furthermore,
Method B provides a hint where to investigate for hidden changes.
During either Method A or B, the problem solver may have to collect miss-
ing information. The problem solver can use probing questions to gather
3598D
6. Verify root cause
5. Trial run theories
4. Develop theories
3B. Comparative
analysis
3A. List changes
on timeline
2. Develop the problem description using IS/IS
NOT method
1. Develop the problem statement
I. List differences
II. List changes in
differences
FIGURE 21.3
Determine root cause of the problem.
TABLE 21.2
Typical Comparison of Determining Root Cause Using Two Approaches
Approach A Approach B
1. Establish a problem statement. 1. Establish a problem statement.
2. Develop a problem description. 2. Develop a problem description.
3. List all known changes on timeline. 3a. List differences.
3b. List changes in differences (only).
4. Develop theories based upon the
changes.
4. Develop theories based upon the
changes.
5. Trial run the theories. 5. Trial run the theories.
6. Verify the root cause/potential root
cause.
6. Verify the root cause/potential root
cause.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.