CAPA management, corrective and preventive action, Rootcause analysis, RCA, Problem mapping, FMEA, Failure Mode effect and Analysis, Fault Tree analysis, Fishbone : ISHIKAWA, CTQ Tree (Critical to Quality Tree), AFFINITY DIAGRAM, 5 Why’s, Human errors,

1. Corrective and Preventive action (CAPA)
Root Cause Analysis

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

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

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

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

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

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

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

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

10. Tools for Root Cause Analysis

11. Problem Mapping
Root Cause analysis

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

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

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

15. Failure Mode effect and Analysis
(FMEA)
Root Cause analysis

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

17. FMEA Example

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

19. Fault Tree analysis
Root Cause analysis

20. Fault Tree analysis
FTA representation

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

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

23. Fishbone : ISHIKAWA
Root Cause analysis

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

25. Fishbone : ISHIKAWA

26. CTQ Tree (Critical to Quality Tree)
Root Cause analysis

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

28. CTQ TREE

29. AFFINITY DIAGRAM
Root Cause analysis

30. THE AFFINITY DIAGRAM – Brain storming tool

31. THE AFFINITY DIAGRAM

32. 5 Why’s
Root Cause analysis

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

35. Understanding Why-Why Analysis :

36. Studying Human Errors
Root Cause analysis

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

38. • 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 :

39. • 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 :

40. How to perform
Root cause analysis

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

42. How to perform Root cause analysis
• 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

43. How to perform Root cause analysis
• Output
1. A Problem statement
2. Supporting data

44. •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.
How to perform Root cause analysis

45. How to perform Root cause analysis
• 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”.

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

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

48. How to perform Root cause analysis
• Step 3:
Collect data to support your statement
1. Establish your baseline
2. Establish your measure of success based on your
baseline

49. How to perform Root cause analysis
• Step 4:
1. Identify casual factors contributing to the problem
2. Determine whether the problem/s is/are systemic in
origin

50. How to perform Root cause analysis
• 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

51. How to perform Root cause analysis
• Step 6:
Identify the root cause (s)
1. Define the underlying cause of the problem
supported by the symptoms in step 4

52. How to perform Root cause analysis
• Step 7:
Identify possible solution to the problem
1. Verify the solution/s to the problem/s
2. Validate the solution

53. How to perform Root cause analysis
• Step 8:
Implement the solutions to the problem
1. Prepare an implement plan
2. Design
3. Implement
4. Monitor the progress and Effectiveness

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

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

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

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

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

59. Any Questions ??