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

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!

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 systempolicy/practice contributing to Actual Root Cause

Actual Root Cause = previous process factorscontributing 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.

Root Cause Analysis LevelsLevel(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 ActionIdentifying “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

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)

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

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

Gap:

Material Man

Method MachineMother Nature

PROCESS:

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

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

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

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

Extrude

Store extruded pieces

Cutting

Assembly

Final inspection

Ship to customer

Is/Is Not AnalysisFocus Aspect Data to

CollectWhere 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

Process flow

Note processes where cracked tubes found

Cutting,customer

Extrusion, assembly, final inspection

See process flow

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

Customer service

Interview GM, (customer)

Other customers

Involved in related processes

Functions Process flow

Interview 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

Cracks on cut edge of

tube produced on 3rd shift on 4/28/08

Material Man

Method MachineMother Nature

PROCESS: Cutting

Fishbone Diagram

Possible Questions for 5 Why Analysis

• • • • • • • •