ASQ PALMETTO SECTION MAY 13, 2008 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

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!

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

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

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

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

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

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

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

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) 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!

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

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

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

Direct Process Root Cause Investigation 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)

Task Analysis Worksheet

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

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

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

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

Fishbone Diagram

Possible Questions for 5 Why Analysis