Root cause analysis

Corrective and Preventive action (CAPA)
Root Cause Analysis

Root Cause Analysis
• What is Root Cause Analysis?
- Refers to a problem-solving
methodology that identifies
and correct a problem’s
underlying cause(s).
- It assumes that the best way to
solve problems is by eliminating
their underlying causes
- It also works under the belief
that symptoms serves as
indicators for underlying
cause(s).

Root Cause Analysis
Symptom of the problem.
“The weed”
Above the surface
(Obvious)
The underlying causes
“The Root”
Below the surface
(not Obvious)
The word root, in root cause analysis, refers to the
underlying causes, not the one cause

Symptom verses Root Cause- An Analogy
• Symptom…..Fever
• Root Cause Analysis…..Flu
• Weeds
- if not properly eliminated will reappear
- spread to other areas

Types of problems
Quality related problems, potential problems
are classified in three categories:
• Systmic problems
• Process problems
• Product problems

Types of problems
Product problems have the following characteristics:
• Specification related
• Customer satisfaction related
Process problems have the following characteristics:
• Equipment related
• Material related
• Methods related
• Environment related
• Method related

Types of problems
Systemic problem have the following characteristics:
• They are recurring problem that seem to elude
solutions.
• Solutions to this group of problem tend to create
other problems (Compound problem)
• They tend to come and go

Steps for Root Cause Analysis
• Collection of data - Phase I
- A fact-finding investigation, and not a fault-finding mission
• Event Investigation - Phase II
- Objective evaluation of the data collected to identify any
causal factor that may have led to the failure
• Resolution of occurrence - Phase III
- Realistic assessment of the viability of the corrective action that
the previous phase revealed.
- The phenomenon must then be monitored periodically to verify
resolution.

Why do we need it
• Benefits of RCA
- Real cause of the problem can be found
- Problem recurrence will be minimized

Problem Mapping
Root Cause analysis

Problem mapping
Problem mapping deals with manufacturing
problems.
Example
• Too many integrated circuit chips were failing
• Inspections showed that the metal lines were
too narrow

Problem mapping
The Method:
• Go from left to right.
• Start off with the problem.
• Follow with the evidence.
• Attach the evidence to assumed causes.
• Confirm the cause by elimination through validation or
verification.

Problem mapping
Long line
at Ice cream shop
Too many customers
Not enough
Employees
Not enough Product
Slow service time
Evidence:
We must be able to handle
large crowds
Evidence:
Some employee
were standing around
with noting to do
Soft service ice cream
machine was
not able to freeze the
cream fast enough.
Evidence:
Non ice cream orders
were processed rapidly
Fix:
Added 2 more
ice cream machine

Failure Mode effect and Analysis
(FMEA)
Root Cause analysis

Failure Mode effect and Analysis (FMEA)
It is widely used in manufacturing industries
in various phases of the product life cycle and
is now increasingly finding use in the service
industry.

S.
No
.
Item /
Function
Potential
Failure Mode
(Failure Mode)
Potential Effect of Failure
(Effect)
Se
ve
rit
y
(S
)
Potential cause(x)
mechanism of Failure
Oc
cur
ren
ce /
Pr
ob
abi
lity
(O)
Current Control
D
et
ec
ti
on
(D
)
Risk
Priority
Number
(RPN)
Recommended
Action (x)
(S*O*D)
1 Vendor
Evaluati
on
No
information
from the
vendor on
changes
made in
process/faci
lity
1) Batch failure
2)
Regulatory impact
about the changes
made by the vendor
3) Non-
complaince
7 1) Lapse/ delay in
communication
from vendor to
share the
information to
QA
2) Delay in the
communication
from QA to
Regulatory 3)
Vendor
implementing the
changes
immediately
without providing
sufficient notice,
prior initimation
7 1) Vendors are
informed to provide
any changes in the
process/facility prior
to the
implementation 2)
QA sharing the
received information
to regulatory 3)
Process of execution
of Quality
Agreement or a
Supply agreement is
initiated
4 196 1) QA to
provide the
information
immediately
after receipt
from the
vendor the
about the
changes.
2) Blocking the
vendor/material
whenever the
changes are
noticed which
may impact the
quality.
3) Any specific
instructions
should be a part
of Purchase
Order.
FMEA Example

Fault Tree analysis
Root Cause analysis

Fault Tree analysis
FTA representation

Fault Tree analysis
BARREL E
BARREL D
RESERVOIR
PIPE C
PIPE B
PUMP A
Construct a FTA Tree for the problem “No flow in to barrel E”

No Flow into barrel E
or
Barrel D
Empty
FTA Tree
or
and
Pipe B
Blocked
Pipe C
Blocked
Pump A
Broken

Fishbone : ISHIKAWA
Root Cause analysis

Fishbone Analysis
• Definition
- Technique to graphically identify and organize many possible
causes of a problem
• Advantages
- Helps to discover the most likely ROOT CAUSES of a problem
- Teach a team to reach a common understanding of a problem.

CTQ Tree (Critical to Quality Tree)
Root Cause analysis

CTQ Tree (Critical to Quality Tree)
What it is :
• A cause-and-effect tool that moves from left to right.
• It is linear
• It paints a clear picture of the sequence of events that lead to
symptoms of the problem, or potential problem

AFFINITY DIAGRAM
Root Cause analysis

THE AFFINITY DIAGRAM – Brain storming tool

The story is told that before an important battle a king sent his
horse with a groomsman to the blacksmith for shoeing.
But the blacksmith had used all the nails shoeing the knight's
horses for battle and was one short.
The groomsman tells the blacksmith to do as good a job as he
can. But the blacksmith warns him that the missing nail may
allow the shoe to come off.
The king rides into battle not knowing of the missing horseshoe
nail. In the midst of the battle he rides toward the enemy.
As he approaches them the horseshoe comes off the horse's hoof
causing it to stumble and the king falls to the ground. The enemy
is quickly onto him and kills him.
The king's troops see the death, give up the fight and retreat.
The enemy surges onto the city and captures the kingdom.
The kingdom is lost because of a missing horseshoe nail.
Understanding Why-Why Analysis :

Understanding Why-Why Analysis :

Studying Human Errors
Root Cause analysis

Studying Human Errors
Human error is never the root cause.
If you want to call human error the root cause, then
the only effective CAPA would be to eliminate the
humans from the process.
Eliminating people from the process is neither
realistic nor possible.
Focus on what controls were in place and how the
CAPA can either make human error more easily
detectable/correctable or preventable.

• Lack of communication
• Complacency
• Lack of Knowledge
• Distractions
• Lack of Teamwork
• Stress and Fatigue
• Lack of Resources
• Pressure
• Lack of Assertiveness
• Lack of Awareness
The main causes of human errors are :

• Pareto Analysis
• Scatter Plots
• Paynter Charts
• Is/Is Not Analysis
• Run chart
• Change analysis
• Barrier Analysis
• Reality Charting
• Storytelling Method
Other RCA tools :
• Hazard analysis
and critical control
points (HACCP)
• Hazard operability
analysis (HAZOP)
• Preliminary hazard
analysis (PHA)
Other RM tools :

How to perform
Root cause analysis

How to perform Root cause analysis
• Step 1:
“Identify what type of problem, or potential
problem you are dealing with.”
• System
• Process
• Product

• Step 2:
Define the problem. You should include the following
1. The issues and the effects of the issue at hand
2. The gap in performance (Where you are and where
you should be)
3. Be specific: Facts and data
4. Specify the dissatisfaction
5. Specify the measure of dissatisfaction

• Output
1. A Problem statement
2. Supporting data

•It is said that a well defined problem is a half resolved problem;
hence it is important to state the problem as clearly as possible.
•Whenever possible define the problem in terms of the
requirements that are not being met. This will add a reference to
the condition that should be and is not.

• Characteristics of a good problem statement:
1. It is measurable (Quantifiable)
2. It is specific
3. Focused on the symptom
4. Focused on the gap between “what it is” and
“what it should be”.

How to write a problem statement
1. Who - Who does the problem affect?
• The entire organization
• Departments
• Customers
2. What - What are the boundaries of the problem? Or potential
problem (Impact if it wasn’t solved?)
• Quality system
• Process
• Products
• Equipment
• Work Instructions
• Methods

How to write a problem statement
3. When - When does the issue occur?
• Period
• Associated events
4. Where - Where is the issue occurring?
• Specific location, or site
• Specific products
• Specific customer, or supplier
• Specific process
5. Why - Why is it important that we fix the problem?
• What impact does it have on the business or customer?
• What impact does it have on all stakeholders?

• Step 3:
Collect data to support your statement
1. Establish your baseline
2. Establish your measure of success based on your
baseline

• Step 4:
1. Identify casual factors contributing to the problem
2. Determine whether the problem/s is/are systemic in
origin

• Step 5:
Choose the tool for your analysis
1. It should be appropriate for the job at hand
2. It should produce results that can be defined

• Step 6:
Identify the root cause (s)
1. Define the underlying cause of the problem
supported by the symptoms in step 4

• Step 7:
Identify possible solution to the problem
1. Verify the solution/s to the problem/s
2. Validate the solution

• Step 8:
Implement the solutions to the problem
1. Prepare an implement plan
2. Design
3. Implement
4. Monitor the progress and Effectiveness

CAPA: Structured Problem Solving
Define Problem and Write
Objectives Statement
Analyze Contributing
And Root Causes
Develop Alternatives
Select Action(s)
Design/Develop
Action(s)
Compile Evidence
Monitor Effectiveness
Implement Actions

There once was a firm that had a nagging recurrence of microbial failures in one
of their intermediates.
The susceptibility of the intermediate to microbial contamination was well
known, and the firm continually retrained its operators (the ubiquitous corrective
action) on the approved cleaning procedures.
However, it was not until a significant number of batches were rejected, along
with a growing customer backorder, that an investigative team of engineers and
quality professionals were deployed to look deeper into the problem.
It was discovered that a dead leg in the process piping was seeding the batch with
the persistent microorganism. When this root cause was finally identified, and the
dead leg was removed, the problem did not recur.
Determine the Root Cause of the Presenting Problem

Determine The Extent of the Problem
A firm was cited by the FDA for failure to maintain purity of the product due
to paint chips noticed in a mixing bowl.
The firm identified the paint chip as having flaked off the mixing equipment.
The firm dutifully blasted down the metal, and polished it to the original
surface to correct the problem.
However, the manager could not get the funds approved to remedy two other
mixers in the same condition.
As one could have predicted with almost certainty, the problem recurred in
another area. FDA noted it again on a subsequent inspection as “failure to
correct the problem,” which invited a Warning Letter

Prevent Recurrence at a System Level
An investigator observed a note in a batch record that a deviation was
required to permit the use of a piece of equipment, although the calibration
check was overdue by a month.
The investigator asked to review the justification for the deviation, which
simply stated “no product impact – OK per Quality Assurance (QA).”
A further inquiry into the frequency of such a deviation revealed that it was
not only a common practice, but that a standard form with this preprinted
justification had been developed to handle these routine deviations.
Looking deeper into the matter not only revealed that the system was
deficient, but that there was no one truly responsible for managing the
system, schedule, or delinquency reports.

Prevent Recurrence at a Corporate Level
There was a firm that had multiple sites where it manufactured its
drug products.
The firm was surprised to be party to a consent decree of permanent
injunction for one of its sites following what it had considered to be a
minor FD-483 for computer system validation.
There were no previous Warning Letters issued at the site. What the
firm failed to realize was that other FD-483’s had been written many
times over the previous years for the same issue at other sites.

Root cause analysis

More Related Content

What's hot (20)

Similar to Root cause analysis (20)

Root cause analysis

Editor's Notes