Leaderboard

We use the RCA method in Analysis phase of DMAIC , Plan phase of PDCA & D4 step in 8D approach. What is RCA? _ Root cause analysis is a class of problem solving methods aimed at identifying the root causes of problems or event. To analyze a root cause, you have to define a problem, gather data or evidence. Identify the issue that contributed to the problem and find root cause using 5 Whys. Difference between Causes & Root causes _ Simply causes or probable causes can identify easily based on our experience or available data & it's superficial in nature. We can't implement a systematic action which ensures that the action taken on these causes will remove the problem permanently (not proactive - Meaning problem can reoccur) Whereas identification of Root causes is not comparatively easy as normal/probable causes. To identify it one must have to go on Gemba & validate the Scenario/issue/data by asking “why” several times until we reach the fundamental process element that failed. Once we identify & implement an action on these RCAs that remove problem permanently meaning no reoccurrence of problem. Also it always leads us to the Process , Control mechanism & system failure oriented RCAs. Below is the right approach to conduct the 3Way5Why RCA : 1. Generation oriented RCA (Why-why analysis) _ Which gives us the root cause for " Why the issue/problem has generated". It leads us to the Source of issue leading us to "Process or System failure" 2. Detection oriented RCA (Why-why analysis) _ In this mode of investigation we aim to Identify RCA for " Why our Process is not able to catch/detect the issues/problem from product or service throughout our process flow". This leads us towards the "Control Mechanism failure". 3. System oriented RCA (Why-why analysis) _ As the last step of our investigation, we must focus our attention on the systems that support our processes. Tracing back defects to the systems that may have contributed to the failure will help us improve systematically throughout the organization. This step is just as important as finding out why the product or service failed in the first place and may have more impact on the bottom line. Example of 3Way5Why : Problem / Issue _ Battery charger failure 1st Way : Occurrence / Generation 1st: Why did the battery charger fail? - It had a defective flex cable. 2nd: Why was the flex cable defective? -The traces at the edge of the overlay opening of the flex cable were cracked. 3rd: Why were they cracked? - Excessive force used while manually bending the flex cable during assembly. 4th: Why was the flex cable bent excessively? - No jig to assist the manual operation of bending. Root cause in this instance? Not using a poka yoke jig to assist in this manual operation will leave it exposed to variation in the force applied to assemble the product. 2nd Way : Detection 1st: Why was the defective flex cable not detected? - Invisible trace open in flex cable was not detected electrically. 2nd: Why was this not detected electrically? -FVT tester was not able to detect this failure. 3rd: Why did the FVT tester fail to detect? - FVT tester did not have the program to check for this failure. 4th: Why did the FVT tester not have this program? - The test program was consigned, and was not developed to check for this failure. Root cause in this instance? The test program buy-off procedure did not cover this item. This should be addressed. 3rd Way : System 1st: Why did our systems/processes produce a faulty product? - The flex cable has assembly issues which made it vulnerable to cracking. 2nd: Why were we not aware of this vulnerability? -The potential failure mode of cracked cables was not properly assessed. 3rd: Why was this failure mode not assessed? - FMEA was performed, but did not consider this failure mode. 4th: Why did we not consider this in FMEA? - No training program in place to train QE and ME in correct FMEA completion. Root cause in this instance? We need to make or FMEA system more robust with training and accountability.