Problem Solving

Root Cause Analysis

Main Objective
• Introduce Problem Solving Basics
• Discuss developing a Problem-Solving attitude
• Look at Problem Solving Elements
• Discuss the advantages of a structured team-
based problem solving process.

Problem Solving is a Key Activity in Lean

Manufacturing

3
 Lean System

• Lean introduces a new concept of using time

– Traditional - We think there isn’t time to do things right
– Lean – There is no time to do things over!!

• We cannot afford to wait for someone to solve a

problem.
• We must act to solve the problem ourselves now.
• We need structure and discipline to solve a
problem and execute permanent countermeasures.

4
 What Is a Problem?
Desired State

(What you want to happen - standard)

Actual Situation A Problem is a gap

between the actual
situation and the
(What is currently happening) desired state.

A problem is not a problem until defined with data

“In God We Trust, everyone else bring data”
Dr. E. Deming
5
 Different Problem Styles
1 2
Sudden Deviation One Time Deviation
Standard Standard Standard

Change Actual
Actual
3 4
Change in Standard Day One Deviation

Standard
Change Standard

Standard Actual Actual

All
All44styles
styleshave
haveaaproblem
problemororaadeviation
deviationbetween
betweenwhat
whatshould
shouldbe
be
happening
happeningand
andwhat
whatactually
actuallyhappens.
happens.
6
Problem Solving

Process Overview

7
 Why Use Problem Solving?

• “No Problem” is a problem

– Problems are opportunities to learn
– Hiding problems undermines the organization
– The goal is to uncover problems and turn them
into improvement opportunities

• Shift the focus away from each other and

toward the white board and the data.
– Stress are reduced
– People like having the marker in their hands

8
 Problem Solving
Where Does Your Problem Solving Start?
11
Customer
Customer Sends Initiate Send
Parts Parts Discovers Trouble Problem Customer Implement Check
Produced Shipped Problem Report Solving Response C/M C/M

22
Initiate
Problem
Parts Problem Problem Solving Implement Check Standardize Parts
Produced Discovered Contained C/M C/M C/M Shipped

Problem Solving should be a Proactive Activity, not

Reactive.

9
 Reactive Problem Solving

INADEQUATE
INATTENTIO WARNING
N TO DETAIL SIGNS
(tell to pay (post new signs
attention) & don’t
UNKNOWN
remove old
(spin again, TRAINING
ones)
don’t tell (conduct more
anyone) training)

EQUIPMENT
HUMAN ERROR
FAILURE
(discipline
(fix
employee)
equipment)

BAD
PROCEDURE ASLEEP
(make (wake up and fire
procedure ACT employee)
longer) OF GOD
(pray for a
solution)

Spin-A-Cause - the fastest root cause analysis tool in

the world! Just a single spin and you have the root
cause and the corrective action for any incident.
10
 Narrowing Process
Initial Problem Perception
(large, vague, complicated problem)

Clarify the Problem

The “Real” Problem

Grasp the Analyze Current Situation

Situation
Possible Cause
Probable Cause
Why?
True Cause 5 Why/ 2H?
Basic Cause & Why?
Investigation of
Effect Underlying Cause
Why? the Root Cause
Investigation Why?
Underlying Cause

Why? Root Cause

Countermeasure
Evaluate
Standardize 11
 PDCA Problem Solving Cycle

What Definition of the Problem

Analysis of the Problem

Plan Why Identification of Causes

How Planning Countermeasures

DO Implementation

Check Confirmation of Results

Action Standardization

PDCA can’t stop until problem is permanently fixed.

12
Basic Problem Solving Stages

• Expose the
Problem

• Analyze the
Problem

• Solve the
Problem
13
 Expose The Problem
Identifying the Issue At Hand

• Everyone uses the same data to avoid

disagreement

• Avoid fire fighting by carefully defining and

discovering details creating the unacceptable
situation.

14
 Develop a Team

 Allow you to make needed changes

in a short time.
 Focus on what is best for the
entire group, not just an individual
 Provide benefits for the individual
and the organization.

15
 Types of Teams
• Leadership Team
– Determine the company’s vision and, from there, set goals
• Project Teams
– Formed to work on a specific problem and disbanded
• Self-Directed Work Teams
– Include all members who work in a specific department on
a specific shift
– Are responsible for an entire work process
– Are permanent teams who have control and responsibility
for all aspects of their work area

Effective Problem-Solving Uses Self-Directed Teams

HINT: Find someone outside your area in a different
discipline for another point of view
16
Define and Clarify the Problem

 Problem Solving always begins with a

well written problem statement.
 You want to remove any confusion and
ambiguity about the issue by
describing in detail exactly what
occurred.
 This keeps your team focused
precisely on your issue, and stops any
“scope creep”.
 Your problem statement should never
detail a cause for the issue.

17
 Poorly Written Examples

• The widget is too long.

• There are too many errors in our reports.
• Our delivery time is horrible.

18
 Better Examples
• The last 10 production runs show the widget measured an
average of 41cm which exceeds the customer requirement
of 38cm +/- 2cm.
– Defines what, when the issue occurs, and the
requirement
• The past 2 months the quality reports contain more than 2
errors on average, greater than the 0 errors expected.
– Defines what, when, how many, and the expected
results
• On-Time Delivery to Customer X has been only 92% for
the last 4 months, less than the required 98.5%.
– Defines where the issue occurs, status, target, and
time frame

19
 Well Written Problem Statement
Ask Questions in 7 Areas

• Who • Why
– Who found the problem? – Why is it a problem?
• What • How
– What part has the – How was the problem
problem? found?
– What is wrong with it?
• How Many
• When – How many parts have the
– When was the problem problem?
first found? – How many defects on each
– When has the problem object?
recurred?
• Where
– Where were the problems
first observed?
20
 Well Written Problem Statement
Use the Narrowing Process to one specific problem
Only One Object, Only One Defect

21
 Study the Current Situation

 Use all available sources of information such

as flowcharts, 5W/2H, and check sheet data
to clarify the problem
 Be as specific as possible, indicate if you
need to collect more data.
 Answer specific questions in 4 areas
What Identity
Where Location
When Timing
Extent Size

22
 Process Flowchart
A flowchart is a diagram, that represents a process, showing the
steps as boxes of various kinds, and their order by connecting
these with arrows. Flowcharts are used in analyzing and
documenting a process.
Lamp Doesn’t work

Lamp Plugged In? Plug In Lamp

N
Y

Bulb Burned out? Replace Bulb

N
Y

Buy New Lamp

End

A flowchart is the first task in data collection. A process

flow diagram is used to obtain agreement and clarity on the
process steps by team members.
23
 Collecting Data

• Agree on the parameters for collecting data

• Decide who will collect the data, and how often
– Data collectors need process knowledge and time to
collect
– If they are not team members, educate them on your
project
• Design a check sheet that is clear and easy to use
• Collect data consistently and accurately according to your
plan.
• Chart the data to visually find trends

If reliable data is available, use it! If you

don’t have confidence in the data create
check sheets to collect current data.
24
 Checkpoint – At This point you should:

• Tell exactly what part/person/object or machine has the

problem.
• Describe exactly what is the specific defect.
• Explain in detail, actual, clear, specific information about the
problem.
• Illustrate how you found the problem (charts / graphs).

25
 Analyze The Problem
Focusing on the Problem is the Problem

• If you want to learn a new skill where is your focus?

• Focus on continuous improvement (PDCA) - one step at a
time.
• Digging deeply to just know what went wrong, misses the
opportunity to solve the problem.

Dig deeply to solve the problem.

26
 Root Cause Analysis

A non-conformance can occur in three

areas, and is applied independently to
each one.

Current Non-conforming Situation

Detection
Systemic

27
 Root Cause Analysis
Root cause analysis (RCA) is a technique for finding and
correcting the most important reasons for problems.

• RCA is not troubleshooting

• RCA is directed at underlying issues, and eventually the root
cause.
Symptom of the
problem
(“the weed’)
Above the surface
(the obvious)

The Underlying Causes

(“the root’)
Below the surface
(not as obvious)

The root in Root Cause Analysis refers to the underlying

causes, not the one obvious symptom
28
 Different Methods For Developing Root Cause(s)

• Brainstorming
Always

• 5WHYs Simple
Problems

• Fishbone Diagram Pick

whichever
you feel
• Why Tree
works the
best
• Mind Mapping
29
 Cause & Effect Diagram
A C&E Diagram helps identify, explore and display in increasing
detail, all the possible causes related to a problem or condition
in order to discover its root cause(s).

Types of Causes:
– Possible – Found after brainstorming, any and all causes
to be considered.
– Probable – After initial sifting of possible causes
the ones transferred to the analysis chart.
– True – When investigation in to probable
causes proves correct. (1st Why is answered).
– Underlying – Subsequent answers to Why?
Why?
– Root – Last underlying cause that can
be countermeasured.

30
 Cause & Effect Diagram (Fishbone)
Material Machine

Problem

What could cause this?

Possible cause
Man Method Possible cause 2 What could cause this?
Possible cause 3
What could cause this?
Possible cause 4
Possible cause 5 What could cause this?

Material Machine

Problem

Possible cause 1 Could this cause that (1)?

Man Method Possible cause 2
Could this cause that (2)?
Possible cause 3
Could this cause that (3)?
Possible cause 4
Possible cause 5 Could this cause that (4)?

31
 Cause & Effect Diagrams
A Cause and Effect diagram considers all production variables
and shows the step-by-step creation of a problem, much like a
process diagram shows the steps of a process.

Production System Variables (4Ms)

1. Material – no defects or shortages

2. Machine – no breakdowns, defects, or unplanned stoppages

3. Man – good work habits, necessary skills, punctuality, and no

unscheduled absenteeism

4. Method – Standardized processes, maintenance, and

management

32
 Basic Elements of Production System Variables
• Material • Management
– Defective raw material – Training or education lacking
– Wrong type for job – Poor employee involvement
– Lack of raw material – Poor recognition of hazard
• Machine – Previously identified hazards were
– Incorrect tool selection not eliminated
– Poor maintenance or design • Mother Earth (Environment)
– Poor equipment or tool placement – Orderly workplace
– Defective equipment or tool – Job design or layout of work
• Man – Surfaces poorly maintained
– No or poor management involvement – Physical demands of the task
– Inattention to task – Forces of nature
– Task hazards not guarded properly • Measurement
– Other (horseplay, inattention....) – Uncalibrated measurement tools
– Stress demands – Inaccurate measurements
• Method – Insufficient measurement data
– No or poor procedures
– Practices are not the same as written
procedures
– Poor communication 33
 5 Whys
• The 5 Whys is a question-asking method used to explore the
cause/effect relationships underlying a particular problem.
• The real key is to avoid assumptions and go upstream in
increments (repeatedly asking “Why” 5 times) from the effect
through the underlying causes peeling away symptoms and
getting to the root cause.

• Benefits Of The 5 Whys

– Quickly identify the root cause of a problem.
– Determine the relationship between different root
causes.
– Learned easily and doesn't require statistical analysis to
be used.
• When Is 5 Whys Most Useful?
– When problems involve human factors or interactions.
– In all types of business situations whether solving a lean
manufacturing or for any other business problem.
34
 How To Complete The 5 Whys

1. Write down the specific problem.

Writing the issue helps you formalize the problem and
describe it completely. It also helps a team focus on the
same problem.
1. Ask Why the problem happens and write the answer under
the problem.
If the answer you provided doesn't identify the root
cause of the problem, ask Why again and write that
answer down.
If the answer you provided is not in your control, don’t
write the answer down, go back and ask the same Why
again.
1. Keep asking Why until the team is in agreement that the
problem's root cause is identified.
This may take fewer or more times than five Whys.
35
 5Why Example
Problem Statement: You are on your way home from work and
your car stops in the middle of the road.

1. Why did your car stop?

– Because it ran out of gas.
2. Why did it run out of gas?
– Because I didn't buy any gas on my way to work.
3. Why didn't you buy any gas this morning?
– Because I didn't have any money.
4. Why didn't you have any money?
– Because I lost it all last night in a poker game.
4. Why did you lose your money in last night's poker
game?
– Because I'm not very good at "bluffing" when I don't
have a good hand.

36
 5Why Example

Production Operator Defective Undersized Cause Cause

Rate Below Work Material
Standard interrupted
Missing
Hole

Dirty

Non- Debris on Cause Cause

standard Floor
cleaning
Chips in
molds Cause Cause

Machine Cause Cause Cause

Stops

37
Select & Prioritize Countermeasures

Any Action Taken To Correct

the Root Cause Should
Ensure The Undesired Event
or Problem Will Not Re-occur
How many times do we solve the same
problem over again….
38
 Countermeasures
• Actions which keep problems “in control”
• Hard Countermeasure ( Can’t Make)
– Reduces the probability of producing a defect to zero.
– The possibility of a faulty action is eliminated
– Designed into the process permanently

• Soft Countermeasure (Can’t Cycle, Accept or Pass)

– Signals the operator to stop the process because a faulty
action occurred
– Prevents further processing, but allows a defect to be
produced
– Must be used constantly to avoid the problem.
– Soft countermeasures cannot be removed until an error-
proofing method is designed to obsolete the
countermeasure.
39
 Countermeasure Selection

Look at both short-term and long-term

countermeasures
• Short-term
• What would reduce the problem immediately?
• Implement while developing long-term countermeasures
• Long-Term
• Does it really achieve your goal?
• Will it prevent recurrence of the problem?
• Remove the short-term countermeasures as soon as
possible.

40
 Countermeasure Selection

• Include all countermeasures you are planning to

implement
• Countermeasure selection
– Use decision matrix to select the most effective
countermeasures
– Don’t overdo the solution, countermeasures do cost money.
– Make sure the countermeasure is in your control to
implement.
• Know who will be responsible for implementation.
• It's often easier to break large actions into bite-
sized tasks delegated to employees who can be
assigned responsibilities, resources, due dates, and
reviews.

41
Countermeasure Planning

Planning Ensure Success

 Communicate early and often
 Stay focused on the causes
 Get creative
 Make change happen

The better the plan, the more likely

the action is to be successful.
42
Problem Solving Observation

Expert
Expert trouble-shooters
trouble-shooters develop
develop the
the
ability
ability to
to know
know what
what information
information is
is missing
missing
when
when solving
solving problems.
problems.
The
The novice
novice takes
takes the
the information
information thatthat is
is
given
given them
them and
and tries
tries to
to solve
solve the
the problem.
problem.

43
 Solve The Problem
Use Experiences of Everyone to Develop a Solution

• Operators are a wealth of knowledge

• Check other departments and other plants in the

company.

• Use the Proactive Approach by using mistake

proofing.

Use all Available Resources, think about eliminating

the problem completely.

44
 Countermeasure Testing & Verification

Define necessary actions

 List actions required
 Sequence of actions required
 Specify who will do what,
when, and where
 Include specific instructions
for non-team members to
ensure they understand the
objective

When Testing countermeasures, effective

implementation cannot be assumed.
45
 Common Verification Points
• Did the actions address problem causes, instead of just
symptoms?
– The single biggest reason for problem-solving failure is action on
symptoms instead of true causes.

• Are the actions fully implemented?

– You can't verify effectiveness until actions have been fully carried
out.

• Are products or outcomes improved?

– What do records and data indicate, hearsay and verbal affirmations
can't be used to prove that products have been improved.

• What is the customer's perception of an improvement?

– If customers have not noticed an improvement.
• Has the problem reoccurred?
– If the problem continues to occur at the same level as before, then
the corrective action is not effective.
46
Countermeasure Standardization

 Have procedures been revised or

developed?
 Are employees aware of and
knowledgeable about the changes?
 Has measurement or monitoring been
established?
 Apply error proofing so that
countermeasures may be removed.

47
 Errors are Inevitable
• Errors are inevitable, a part of human nature.
• Understanding human limits is essential.
• These limits include:
– Vision: People vary in ability to distinguish details, colors
or adjust vision to lighting.
– Hearing: Individual upper and lower thresholds of
hearing change when background noise is added.
– Repetition Ability: Muscular efficiency and mental
tracking decrease as rates of repetition increase.

So How Do We Prevent Human Errors

From Becoming Defects?
48
 Poka-Yoke (Error-Proofing)
• In a lean production system, Poka-Yoke is a
process improvement designed to prevent a
specific defect from occurring. Poka-Yoke:
– Prevents personal injury
– Promotes job safety
– Eliminates faulty products
– Prevents machine damage.
• Sometimes known as, Mistake-proofing or Fool-
proofing (Baka-yoke).

"Quality comes not from inspection, but from

improvement of the process." W. Edwards Deming
49
Establishing the Process

 Follow PDCA
 Select Quality Tools
 Develop a Problem Solving Process
 Design Supporting Tools
 Educate Everyone
 Make it Part of your Daily Routine

50
 PDCA Problem Solving Cycle

What Definition of the Problem

Analysis of the Problem

Plan Why Identification of Causes

How Planning Countermeasures

DO Implementation

Check Confirmation of Results

Action Standardization

PDCA can’t stop until problem is permanently fixed.

51
Basic Quality Tools

Brain Storming
Checksheets
Pareto Diagrams
Histogram (and Bar Chart)
Cause & Effect Diagram
Flow Diagrams and Process Maps
Run (Trend) Chart
Control Chart

52
 Root Cause Analysis Techniques
Which One To Use?

5 WHYs Barrier analysis

Bayesian inference
Change Analysis

Pareto Analysis Casual Factor Tree analysis

Kepner Tregoe Fault Tree Analysis

Ishikawa Diagram Current Reality Tree

Failure Mode and Effect Analysis (FMEA)

53
 Four Improvement Strategies
PDCA Our Problem Solving 8D 5P TWI
Steps
1. Develop a Team 1. Form a Team 1.Problem 1. Find and
2. Define & Clarify the Definition Clarify the
Problem Problem
3. Analyze the Current
Situation
PLAN 4. Root Cause Analysis 2. Define 2. Identify 2. Find the Root
5. Select & Prioritization CMs Problem Root Cause Causes
6. Countermeasure Planning 3. Identify and
implement
countermeasures
3. Containment
DO 7. Countermeasure Testing 4. Root Cause 3.Corrective 3. (cont’d)
5. Corrective Countermeasur
Action es
CHECK 8. Countermeasure Verification 6. Prevention 4.Confirm 4. Confirm and
7. Verify Countermeasur follow up
es
ACT 9. Countermeasure 5. 4. (cont’d)
Standardization Feedback/Fee
d Forward
10. Planned Goal vs. Actual 8. Congratulate
54
 Educate

• Develop different levels

– Manager
– Leader
– Participant (Operator)
• Remember to hone education to learning styles of
each audience
• Implement education continuously

56
 Proactive– Requires A Change in Thinking
Concentrate on the Facts, Not the Who of the Problem

Promotes
Problem Solving

Full Acceptance of Responsibility

Partial Acceptance of Responsibility

Problem Solving Someone Else is Responsible to Fix it.
May happen
We have No Time or Money to Solve it.

No Solution. We have always done it this way.

Blame Others for It

Deny the Problem Exists

Ignore the Problems

57