350 Quality Assurance
• To uncover the changes, the key question is, What has changed
in, on, around, or about the difference and when did the change
occur? A good guideline to develop changes is to:
− List all changes that occurred related to difference regardless
of date or their potential for cause
− Consider the categories of people, methods, materials,
machines, measurement, and Mother Nature (environment)
Once the IS/IS NOT analysis is nished, the team is ready to begin the
identication and/or the development of possible cause (change-how theo-
ries). At this stage, theories are
• Statements of ways that the changes may have created the trouble
• A limited form of brainstorming
• Simply a listing of possible causes not probable causes
• To develop theories, the key question is, How could this change
have caused the effect on the object? (Alternatively, in what ways
might this change have caused the effect on the object?) A good
guideline to develop change-how theories is to
− List each theory individually.
− Do not reject or qualify the theory based on its practicality
or probability.
− List single change/single variability theories rst.
− Develop more complex variability theories second.
− Continue to prompt the problem-solving team with the above
question until all possible theories are developed.
− Defer critical thinking until the next step.
At this stage, the team is ready to check the theories. This is done with trial
runs such as
• Critical evaluations of theories against the sets of IS/IS NOT data
• Test of the plausibility, not remote possibility, of each theory
• A test of the likelihood of the theory
• A process of elimination
• To test the theory, the key question is, Does the change–how
theory explain both the IS and the IS NOT? A good guideline to
develop change–how theories is to
− Test the theory against each individual set of IS and IS
NOT.
3518D
− If the theory accounts for both the IS and the IS NOT phe-
nomena, record with a + (plus) symbol.
− If the theory cannot plausibly explain either the IS or the IS
NOT phenomenon, record the result with a – (minus) symbol
and note the reason for the rejection.
− Test the theory against all sets of IS and IS NOTs. Do not stop
testing a theory prematurely.
− Test all the theories in and of themselves. Consider each
“change-how” theory a separate theory.
− Avoid testing interactive changes and highly complex theo-
ries to the end of the trial runs. Test the simplest theories
rst.
− If the plausibility of the theory is uncertain (+ or –) use a
question mark (?) to record the uncertainty. Note why the
theory is uncertain.
This simple approach does not suggest that the team may not use any
advanced statistical techniques. The team is free to use any methodology or
any tool that may provide the problem.
To nish the requirements of the D2, the last item should be to verify the
root cause by
• Describing the optimum method to passively, and then actively, ver-
ify the root cause
• Conducting the verication in the appropriate setting
• Recording the results
D2: Evaluating Questions
When the team feels comfortable with having completed the D2 step, it is
a good practice to review the discussion with at least the following basic
questions:
• Can the symptom be subdivided?
• Has a specic problem statement been dened (object and defect)?
• Have repeated whys been used?
• What is wrong with what?
• Do we know for certain why that is occurring?
• Has IS/IS NOT analysis been performed (what, where, when, how big)?
• When has this problem appeared before?
• Where in this process does this problem rst appear?
352 Quality Assurance
• What, if any, patterns are there to this problem?
• Are similar components and/or parts showing the same problem?
• Has the current process ow been identied? Does this process ow
represent a change?
• Have all required data been collected and analyzed?
• How does the ERA affect the data?
• Is there enough information to evaluate for potential root cause?
• Do we have physical evidence of the problem?
• Has a cause and effect diagram been completed?
• Does this problem describe a something changed or a never been
there situation?
• Has the problem description been reviewed for completeness with
the 8D customer and affected parties? (Has concurrence been
obtained from the 8D customer and the affected parties?)
• Should this problem be reviewed with executive management?
• Should nancial reserves be set aside?
• Should any moral, social, or legal obligations related to this problem
be considered?
D3: Develop the Interim Containment Action (ICA)
The D3’s purpose is to dene, verify, and implement the ICA to isolate effects
of the problem from any internal/external customer until PCAs in D6 are
implemented. Validate the effectiveness of the containment actions. In other
words, the D3’s predominant function is to protect the customer from the
problem until it is resolved at D6.
The customer is whoever gets your output as their input. The customer
could be internal to the company as well as external. If the customer cannot
accept the defect, then an interim containment action (CA) is required. An
ICA is intended to protect the customer from getting the problem because a
root cause is not yet known. It must be understood that an ICA is always a
temporary measure. It is a non-value-added operation. Commitment to com-
pleting the 8D remains in force. An ICA is effective when, from the custom-
er’s point of view, the defect is no longer evident. ICAs are often compared to
quick xes or hidden factories, but containment actions are actually
• Veried to work before implementation
• Validated that the ICA is working after implementation
3538D
• Validated independently, in addition to the customer’s conrmation
of effectiveness
• Documented to exist (i.e., made visible) by amendments to the orga-
nization’s process ow diagrams, procedures, process instructions,
and so on
• Replaced by a PCA at D6
• Implemented without creating other troubles downstream
• Formal temporary xes; care is exercised to ensure that all support-
ing functional areas/departments are involved in planning and
implementation
• Implemented only with the clear approval of the champion and
customer
• Managed through comprehensive planning and follow up
Another important feature of D3 is that prudence may require contain-
ment action (an ERA) before Dl and D2 are completed. However, after D2 is
completed, the ERA should be reviewed. The D2 data may suggest a more
effective interim containment action (DS3).
An ICA should not be implemented by a team without the champion’s
knowledge or involvement. A subtle but signicant feature of the 8D process
is that the authority to implement an ICA is retained by the champion. It is
not delegated to the team. Likewise, the champion is responsible for cross-
functional communications. Some team problem-solving guidelines imply
the team itself would assume this responsibility. The 8D process promotes
action within the organization’s chain of command. It does not promote cre-
ation of an articial command structure, which bypasses the normal author-
ity structure.
D3: Process Guidelines
As mentioned earlier, the fundamental purpose of D3 is to protect the cus-
tomer from receiving a defective part while the supplier is determining the
source of the cause. Steps and questions during D3 include
• Is the D3 step necessary? Sometimes it may not be, especially if the
ERA is sufcient to control the product.
• If implemented, can the D0 ERA be improved?
• Which action is best?
• Choose the best containment action.
• Will the containment action work (i.e., eliminate 100% of the problem
from reaching the customer)? (Is verication valid and accurate?)
• Follow the management cycle–PDCA cycle
354 Quality Assurance
• Plan (in detail) the containment action and verify.
• Implement the containment action.
• Record the results.
• Evaluate the ICA; did it work? (Validation)
• Document the actions and communicate how to do it to all who need
to know about it.
• Continue to monitor its effectiveness throughout the time it is in place.
• The champion must be involved before the ICA is implemented and
during implementation.
• This is the only optional step in the entire 8D process.
• It is temporary, not permanent. It is costly, not cost-effective. It is
containment, not mistake proof.
• D3 works against the problem, it is not the root cause.
• It increases costs while the ICA is used.
• D3 may be done while other members of the team are working on D4
(Determine Root Cause).
• D3 may require additional members be added to the team in order
to complete all of D3.
• It looks like a quick x, but its actions are documented, later
removed, and checked for effectiveness. The team must ensure that
the actions will not create other problems for departments and cus-
tomers downstream of the D3 action.
• More than one D3 action may be required to fully protect the cus-
tomer (internal or external).
• After D3, the team’s membership might change. This is true at all steps.
• D3 may occur before Dl or D2. If done before D2, then the D3 ICA
should be reviewed after the D2 data is compiled. Better D2 data
may prescribe the need for an improved D3 ICA.
D3: Evaluating Questions
When the team feels comfortable with having completed the D3 step, it is
a good practice to review the discussion with at least the following basic
questions:
• Are ICAs required?
• Is a service action required as part of the ICA?
• What can we learn from the ERA that will help in the selection of
the best ICA?
• Based on consultation with the 8D customer and champion, have
criteria been established for ICA selection?
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.