Вы находитесь на странице: 1из 51

Finding the Root Cause

Identifying the Context for


Root Cause Investigation
ASQ PALMETTO SECTION
MAY 13, 2008
The Journey Ends (almost). . .
Review of previous presentations on
addressing audit nonconformance's
Refresher of CREI problem statement
format
Every problem originates in a process
Containment and Interim Actions
Root Cause Analysis
In Previous Episodes. . .
The preparation shop makes four types of
Widget blanks for the assembly shop,
named Type A, B, C and D
Blanks are plastic tubes of various
diameters made on two extruders
They are temporarily stored in plastic bins
After storage they are transported to
cutting machines where they are cut to
different lengths
In Previous Episodes. . .
The assembly shop puts the plastic tubes
together with other products to make a
final assembly
They are sold to the automobile industry,
specifically Ford and GM
The Widgets must be at the correct length
(+/- 2mm) and be free of cracks
CREI Problem Statement
A valid problem statement includes:
Concern: what is wrong; statement of
nonconformity
Requirement: what should be;
documented requirement or reference to
Evidence: data demonstrating that
something is wrong; objective evidence
observed that supports statement of
nonconformity
(Impact): how significant is the problem
from a performance and/or cost standpoint
Getting to the Process of Origin
Where was the problem found?
Where is the first process the problem
condition could occur?
Go to these and any processes in between
to collect data recognizing where the
problem is actually first observed; this is
the process of origin!
Use a process flow diagram to make this
investigation visual.
Step 3A: Containment support
identification of Process of Origin
Purpose: to isolate the
effects of the problem from
downstream processes and
customers; also a source of
data collection for
understanding with depth
and breadth of the problem
and identifying Process of
Origin
Methods:
Planning of containment
Quarantine of product
Evaluation
Data collection
Inputs:
CREI statement
Process flow
Timeline
Data to collect for Is/Is Not
Analysis
Outputs:
Data re: scope of problem,
(e.g. how many parts are
actually affected)
Data for completion of Is/Is
Not Analysis
Other opportunities
Identify all
(potentially)
affected product
Determine how
problem condition
will be identified
Establish
evaluation/
measurement
criteria
Define process for
performing
containment
Determine what
data to collect from
containment
Test effectiveness
of containment
plan
Train personnel
performing
containment action
Perform
containment action
Collect results of
containment for
use in root cause
analysis
4/8/2007
Disciplined
Problem Solving
Containment
A Root Cause is. . .
A process factor which directly defines
the reason for the problem when it is
present and is having an influence on
the process and its output.
Root Cause Analysis
Systematic investigation
of a process to identify
the root cause of the
gap, and take corrective
action to eliminate the
gap and keep it from
occurring again in the
future
The Process of Origin
must be identified,
(using data), before
Root Cause Analysis
can proceed!
Process Hierarchy
System Processes = Policies, Objectives & Practices
(how an organization does business)
Audit findings are typically identified at Plan & System level
Planning Processes apply System
to fulfill customer requirements
Producing Processes to accomplish Plans
Products/Services = output of producing Processes
4 Levels of Root Cause
System Root Cause = management system
policy/practice contributing to Actual Root Cause
Actual Root Cause = previous process factors
contributing to Process Root Cause, (planning)
Direct Process Cause = at Process of Origin
Defect/Detection Cause = Product level
Dig! How Deep?
Management decides
on depth of root
cause investigation
through the
establishment of
SMART goals for
each problem solving
effort.
Problem Solving Goals
Define problems
boundaries/depth of
solutions
Identify right people to
solve problem
Establish measures of
end results
Develop plan of how to
accomplish the goal
Tie problem solving
goals to organizational
objectives/targets
Provided to team by
Management
Effective Problem Solving
is based on
SMART Goals:
Specific
Measurable
Agreed upon by team as
attainable
Relevant to organization
and results-oriented
Timing defined
Root Cause Analysis Levels
Level
(Deep)
Root Cause Consideration Tools Other
(Wide)
Product
Defect/Detection
cause
Condition of
controls to
detect problem
Control
Barrier
Analysis
What other
products have
similar
controls?
Process
Direct process
cause, (trigger at
process of origin
Factors at
process of
origin triggering
problem, (5Ms)
Fishbone,
(cause &
effect)
What
processes
have similar
trigger cause?
Plan
Actual root cause,
(led to trigger
cause)
Linkage to
planning
processes that
trigger cause
5 Why with
Hypothesis
testing
What other
processes
affected?
System
weakness in
mgt. policies or
practices
Linkage of mgt.
system to
actual cause
System
Cause
Analysis
Other affected
mgt. policies
Failure Modes & Effects Analysis
(FMEA) Clues for Root Cause Investigation
Process
Function
Requirements
Potential
Failure
Modes
Potential
Failure
Effects
Potential
Failure
Causes
Current
Product &
Process
Controls
Process of
origin
Technical
definition of
problem
Symptom Process
factors = root
causes
Interim
actions
Step 3B: Interim Action
Identifying Product-level Root Cause
(Defect Detection Cause)
Purpose: to understand why
the problem condition escaped
the process/organization;
evaluation of existing process
controls for
weaknesses/deficiencies;
addressing this cause does not
prevent recurrence of the
problem
Methods:
Control barrier analysis
Planning of interim actions
Inputs:
CREI statement
Process flow
FMEA
Control plan
Outputs:
Defect, (detection), cause,
(why problem escaped
existing controls)
Interim controls
Data for Is/Is Not Analysis
Methods for monitoring interim
controls to collect data for
problem solving effort
Other opportunities
Control Barrier Analysis
(Defect/Detection Root Cause)
How did the problem
escape the process
and/or organization?
Was the problem
anticipated in
advance?, (FMEA)
Were controls defined
to recognize and
contain the problem?,
(control plan)
At which process are
the planned controls
applied?, (process flow,
control plan)
Were the planned
controls in place?
Were the planned
controls working?
What is the capability
of these controls?
Assists in identifying
appropriate interim
actions as well as
identifying the
defect/detection root
cause
Process Condition Control Status Capability Observations Actions
Other Opportunities:
Control Barrier Analysis
Worksheet
Results of Control Barrier Analysis
May recognize missing controls or controls not working
as planned
Interim actions represent solutions to addressing these
concerns but should not be accepted as the
permanent solution
When the results of this analysis uncover additional
problems, refer these to the team champion for
direction on addressing, (Other Opportunities)
Teams main focus at this point is to implement some
type of control to protect downstream processes from
continuing to experience the problem
Solutions based on this level of root cause
investigation mainly are reactive in nature; they only
improve our ability to detect the problem condition but
dont typically do anything about addressing the root
cause!
4/8/2007
Disciplined
Problem Solving
Interim Action
Determine need
for interim action
Identify process
from which
problem is
originating
Can interim
control be
added to this
process?
Identify
subsequent
process where
interim control can
be added
Plan type of
interim control,
(extra inspection,
etc.)
Establish accept /
reject criteria
Define interim
control method
including collection
of results and
identification of
product
Prepare temporary
process deviation
or update control
plan
Train process
personnel re:
interim control
Test effectiveness
of interim control
Implement/perform
interim control
Collect results of
interim control for
root cause
analysis
Remove interim
control when
permanent corrective
action has been
verified as effectively
implemented
No
Yes
Note on Interim Actions
Management may chose to
accept the Interim Action as the
solution at this point when
Operational Definition is known
due to scope/impact of problem
and priority of other problems to
be solved
Keep in mind that Interim
Actions do not improve the
process nor do they solve the
problem
Interim actions are mainly a
stop-gap
Some interim actions may be
chosen as the solution to
address the root cause, (one of
the 3 possible solutions)
Interim actions should not be
considered permanent until root
cause analysis and solution
selection confirms their validity.
Process Cause vs. System Cause
Process Cause
What factor of the
process of origin is
triggering the undesirable
output
What other processes
and their factors are
causing the trigger?
Relates product output,
(symptom), to process
parameters, (causes)
System Cause
Addresses how the
management system
allowed the process to
become out of control
Relates process factor
causes to weaknesses
in management systems
policies/practices
4/8/2007
Disciplined Problem
Solving
Process
Root Cause Analysis
Identify process
from which
problem originated
Review data from
operational
definition,
containment and
interim action
Identify potential
causes
contributing to the
problem
Develop plan to
test if potential
cause actually
leads to problem
Conduct test and
collect data
Analyze data from
test
Does potential
cause directly
lead to problem
condition?
Select other
potential causes
Can cause be
controlled or
eliminated?
Identify possible
actions to monitor
process for
problem condition
Identify possible
actions for either
controlling or
eliminating cause
No
Yes
No
Yes
Identify
management
policies related to
process from
which problem
originated
4/8/2007
Disciplined Problem
Solving
System
Root Cause Analysis
Review existing
policies for existing
controls
Do current policies
define controls to
prevent the cause of
the problem?
Identify possible
management
policy controls to
address cause
Investigate if these
controls are in
place
Identify other
processes affected
by these policies
Controls
working?
Identify how these
controls and/or
policies can be
changed
Analyze why
controls are not
working at the
process where
problem originated
No
Yes
No
Yes
Direct Process Cause
(Trigger Cause at Process of Origin)
Must confirm process of origin in order to conduct
investigation of process-level root cause!
Relates one or more factors of the affected
process, (process of origin), not behaving as
required to obtain the desired output result at that
process
Use Cause & Effect diagram, (fishbone technique)
Direct process causes, (trigger causes), are the
starting point for identifying actual root cause
Some action may be required to address the direct
process/trigger cause but actions should not be
taken until actual root cause is known
Cause & Effect Diagram
Apply to problems
process of origin
Gap is head of fish
Major cause categories
5Ms
Potential causes
brainstormed are
process factors existing
at the problems
process of origin
Define potential causes
specifically
When confirmed, these
will be known as direct
process/trigger causes
Fishbone Diagram
Fishbone Process
Involve personnel from process of origin in
brainstorming of potential causes at the process of
origin triggering the problem
Develop a sketch/list of the process factors, (man,
material, machines, methods, mother nature), related
to the process of origin
After brainstorming, review each identified cause to
establish:
If the cause is actually a factor at the process of origin
If the cause makes sense based on the operational definition
of the problem
Prioritize remaining causes as to their possible
contribution to the problem condition
Develop hypothesis test to evaluate each potential
cause at the process of origin
P i i
P i l

l

?
i l

i l
i i i ?
P i i

i

i i
l i i




















Confi o investi te vi 5 W nal sis:
Di ect P ocess Root Cause
Investi ation Plan & Results
Process of Origin:
Problem Understanding Tools
(especially useful in identifying system causes)
Task Analysis reviews process in detail;
helpful for operator dependent process
Change Analysis identifies differences;
extension of Is/Is Not analysis; expands on
application of timeline
Both these tools must be applied with a
location context, (process of origin)
St t t Q t
Task Analysis Worksheet
Change Fact r Difference/Change Effect Q esti ns t Answer
What (conditions,
acti ity, equipment)
When (occurrence,
status, schedule)
Where (physical
location,
environmental
conditions, steps of
procedure)
How (work practice,
omission, extraneous
action, out of
sequence, poor
procedure)
Who (personnel
involved, supervision)
Change Analysis Worksheet
Actual Root Cause
Explains why trigger cause/condition exists at the
process of origin
Typically found in previous planning processes
Use 5 Why Analysis with Hypothesis testing to identify
and confirm, (collect data!)
Many problems have multiple causes
Usually only one over-riding cause that when addressed,
can significantly reduce the problems impact on the
organization
Very complex problems may have interacting causes but
these are typically viewed as isolated problems that only
repeat infrequently, (often managed as Just Do It), until
resources allow necessary time to discover interaction
through data collection, analysis and experimentation
5 Why Analysis
Ask Why does this
happen? for each identified
process cause from Cause &
Effect diagram
Differentiates between
process, (direct) cause and
underlying root cause
Each level of causes
identified in 5 Why analysis
must also be confirmed via
testing in order to verify root
cause
Deeper levels of 5 Why
Analysis which get into
Planning processes will
require interview-type data
collection
5 Why Analysis Worksheet

Process
of Origin
Cause
Plan/Data
to confirm
Results 2
nd

level
Cause
Plan/Data
to confirm
Results 3
rd

level
Cause
Plan/Data
to confirm
Results 4
th

level
Cause
Plan/data
to confirm























Test Potential Root Causes
Validating cause
guesses by
collecting and
analyzing data
Test under controlled
conditions
Turn the problem on
and off by
manipulating the
suspected cause
Hypothesis Testing
Design hypothesis and select methods for testing
hypothesis - state how potential cause could result
in described problem; decide what data to collect that
would prove potential cause; establish acceptable
risk of decision outcome; determine sample size;
develop action plan for study
Prepare to test hypothesis - organize and prepare
materials required to conduct study; collect data
during study
Analyze results of test - analyze data using
appropriate statistical tools, (t, F, Chi-squared tests)
Interpret results - conclusions from study; does data
establish potential cause as reason for problem?
Root Cause Analysis Plan
Identify causes to be investigated
What data supports each cause?
Can cause be introduced and removed to
confirm presence/absence of problem?
What tests will be performed to confirm root
cause?
What is the statistical confidence of these
tests? (i.e. how much data is needed?)
Results of tests recorded and analyzed with
conclusions drawn
System Causes
What in the system allowed this problem/cause
to occur
Identifies why the process root causes occurred
based on current management policies/practices
Often not readily measurable
Data obtained through interview
By identifying system causes, systemic
improvement can be made in order to prevent
recurrence of problem in other similar processes
Typically addressed once process root causes of
problem are known and confirmed
System Cause Analysis Worksheet

Operational Definition:


Process of origin cause:


Process root cause:


Which management system process is the process root cause related
to


Who is responsible for this management system process


What documentation/policies are available describing actions and
controls for this management system process


Does this documentation/policy recognize the possibility for this
problem to occur


Are there any current management system controls in place to
prevent or detect this problem


Has this management system process been associated with previous
problems


What other processes within the organization are driven by this
management system process

Possible Management System Level Solutions: 1) Create new policy
2) Change existing policy 3) Reinforce/re-apply current policy
As a result of Root Cause Analysis
Product-level cause, (related to current controls),
identified and confirmed along with appropriate
interim controls to protect downstream
processes/customers
Trigger cause at process of origin identified and
confirmed
Actual root cause, (what allowed the trigger
cause to exist at the process of origin), known
and confirmed
System root cause identified, relating actual root
cause to management policies/practices
A Key Outcome of Every Problem
Solving/Root Cause Investigation. . .
Expansion of Knowledge
Next Steps, (Next Year?)
Solution identification, (3 possible
solutions to every problem), and
evaluation/selection for each root cause
level
Implementation of selected solutions
Verification of the effectiveness of
implemented solutions
Lessons learned
Other Opportunities
Identified typically while collecting data for Is/Is Not
Analysis, Root Cause investigation/confirmation, solution
evaluation
Record these other problems/opportunities
Share these problems/opportunities with team champion
to get direction on how to address: (change scope of
current problem solving effort to include; management
assigns another team to address)
Dont allow these other opportunities to distract from the
focus of the problem solving effort
These Other Opportunities become the Bonus of an
effective problem solving effort
Your Turn for Root Cause Analysis
For previous case study on widget
manufacture:
CREI statement, (given)
Process flow, (given)
Is/Is Not analysis, (given; process of origin
known)
Fishbone potential causes at process of origin
Create questions for 5 Why investigation
Widget CREI
Concern: customer complaint from GM
re: cracked tubes, (widgets)
Requirement: per GM drawing #123,
assembly should be free from cracks
Evidence: GM customer complaint
Impact: assembly leaks, (performance),
GM is requiring contained shipping, ($$$)
Widget Making Process Flow
Is/Is Not Analysis
Focus Aspect Data to
Collect
Where to
Collect
How to
Collect
Results
IS
Results
IS NOT
Comments
What? Problem
condition
# cracked
tubes
Process
flow
Visual
evaluation
Visible
cracks on
tubes
Other
defects
Refer to
requirement
Where? Geographicall
y
Processe
s where
cracked
tubes
found
Process
flow
Note
processes
where
cracked
tubes found
Cutting,
customer
Extrusion,
assembly,
final
inspection
See process
flow
Where? On output Location
on part
During
containmen
t
Concentratio
n diagram
Cracks at
edge of
tube
Cracks
along
length or
in other
locations
Refer to
problem
condition
When? First seen Problem
report
Customer
service
Review of
customer
complaints
4/28/08,
(date of
customer
complaint
)
Prior to
this date
Refer to
timeline
Who? Identified
problem
Names,
positions,
contact
info
Customer
service
Interview GM,
(customer
)
Other
customers
Involved in
related
processes
Functions Process
flow
Interview Cutting
operator
on 3
rd
Other
cutting
operators,
Refer to
process flow
Fishbone Diagram
Possible Questions for
5 Why Analysis