Root cause analysis

1.436 visualizaciones

Publicado el

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,

  • Sé el primero en comentar

Root cause analysis

  1. 1. Corrective and Preventive action (CAPA) Root Cause Analysis
  2. 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. 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. 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. 5. Types of problems Quality related problems, potential problems are classified in three categories: • Systmic problems • Process problems • Product problems
  6. 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. 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. 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. 9. Why do we need it • Benefits of RCA - Real cause of the problem can be found - Problem recurrence will be minimized
  10. 10. Tools for Root Cause Analysis
  11. 11. Problem Mapping Root Cause analysis
  12. 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. 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. 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. 15. Failure Mode effect and Analysis (FMEA) Root Cause analysis
  16. 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. 17. FMEA Example
  18. 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. 19. Fault Tree analysis Root Cause analysis
  20. 20. Fault Tree analysis FTA representation
  21. 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. 22. No Flow into barrel E or Barrel D Empty FTA Tree or and Pipe B Blocked Pipe C Blocked Pump A Broken
  23. 23. Fishbone : ISHIKAWA Root Cause analysis
  24. 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. 25. Fishbone : ISHIKAWA
  26. 26. CTQ Tree (Critical to Quality Tree) Root Cause analysis
  27. 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. 28. CTQ TREE
  29. 29. AFFINITY DIAGRAM Root Cause analysis
  30. 30. THE AFFINITY DIAGRAM – Brain storming tool
  32. 32. 5 Why’s Root Cause analysis
  33. 33. 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 :
  34. 34. Understanding Why-Why Analysis :
  35. 35. Studying Human Errors Root Cause analysis
  36. 36. 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.
  37. 37. • 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 :
  38. 38. • 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 :
  39. 39. How to perform Root cause analysis
  40. 40. How to perform Root cause analysis • Step 1: “Identify what type of problem, or potential problem you are dealing with.” • System • Process • Product
  41. 41. 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
  42. 42. How to perform Root cause analysis • Output 1. A Problem statement 2. Supporting data
  43. 43. •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
  44. 44. 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”.
  45. 45. 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
  46. 46. 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?
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. 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.
  57. 57. 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.
  58. 58. Any Questions ??