Finding the Root Cause Identifying the Context for Root Cause Investigation

1. Finding the Root CauseIdentifying 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. 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.

6. 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 Step 3A: Containment – support identification of Process of Origin

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

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

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

10. Defect/Detection Cause = Product level Direct Process Cause = at Process of Origin Actual Root Cause = previous process factors contributing to Process Root Cause, (planning) System Root Cause = management system policy/practice contributing to Actual Root Cause 4 Levels of Root Cause

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

12. Root Cause Analysis Levels

13. Failure Modes & Effects Analysis(FMEA) – Clues for Root Cause Investigation

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

15. Control Barrier Analysis Worksheet

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

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

18. Fishbone Diagram

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

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

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

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

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

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

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

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

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

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

30. Widget Making Process Flow

31. Is/Is Not Analysis Worksheet Is/Is Not Analysis

32. Fishbone Diagram

33. Possible Questions for 5 Why Analysis