1. ASQ PALMETTO SECTION MAY 13, 2008
Finding the Root Cause Identifying the Context for Root Cause Investigation
ASQ PALMETTO SECTION
MAY 13, 2008

2. 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

3. 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

4. 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

5. 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

6. 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.

7. 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

9. 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.

10. 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!

11. Audit findings are typically identified at Plan & System level
Process Hierarchy
Products/Services = output of producing Processes
Producing Processes to accomplish Plans
Planning Processes apply System
to fulfill customer requirements
System Processes = Policies, Objectives & Practices
(how an organization does business)
Audit findings are typically identified at Plan & System level

12. 4 Levels of Root Cause Defect/Detection Cause = Product level
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

13. Dig! How Deep?
Management decides on depth of root cause investigation through the establishment of SMART goals for each problem solving effort.

14. Effective Problem Solving is based on
Problem Solving Goals
Define problem’s 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

15. Root Cause Analysis Levels
(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

16. 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

17. Step 3B: Interim Action Identifying “Product-level” Root Cause (Defect Detection Cause)
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
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

18. 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

19. Control Barrier Analysis Worksheet

20. 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)
Team’s 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 don’t typically do anything about addressing the root cause!

22. 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.

23. Process Cause vs. System 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

26. 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

27. Cause & Effect Diagram Apply to problem’s process of origin
Gap is head of fish
Major cause categories – 5M’s
Potential causes brainstormed are process factors existing at the problem’s process of origin
Define potential causes specifically
When confirmed, these will be known as direct process/trigger causes

28. Fishbone Diagram

29. 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

30. Direct Process Root Cause Investigation Plan & Results
Process of Origin:

31. 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)

32. Task Analysis Worksheet

33. Change Analysis Worksheet

34. 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

35. 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

37. 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

38. 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?

39. 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

40. 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

42. 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

43. A Key Outcome of Every Problem Solving/Root Cause Investigation. . .
Expansion of Knowledge

44. 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

45. 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)
Don’t 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

46. 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

47. 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, ($$$)

48. Widget Making Process Flow

49. Is/Is Not Analysis Is/Is Not Analysis Worksheet 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?
Geographically
Processes where cracked tubes found
Note processes where cracked tubes found
Cutting,
customer
Extrusion, assembly, final inspection
See process flow
On output
Location on part
During containment
Concentration 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
Interview
GM, (customer)
Other customers
Involved in related processes
Functions
Cutting operator on 3rd shift
Other cutting operators, other processes
Refer to process flow
Customers
How much?
Quantity affected
Quantity cracked tubes
Containment
Containment plan
5% of parts contained
95% of parts contained
How often?
Recurring problem
# previous incidents
Customer complaint files, final inspection reports
Review data from previous 6 months
No previous incidents of cracked tubes
Previous customer complaints, final inpsections

50. Fishbone Diagram

51. Possible Questions for 5 Why Analysis