# Root Cause Analysis Method Selector > Source: https://netray.co/tools/root-cause-analysis-method-selector-reference > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Compare common root cause analysis methods by best use, effort, evidence needed and limits so you pick the right one for the problem in front of you. ## Category quality ## Audience - Quality manager - Quality engineer - Continuous improvement lead ## Tool **Kind:** worksheet **Mode:** reference **Columns:** #### Method **Key:** method **Type:** text #### Best used when **Key:** best_for **Type:** text #### Effort **Key:** effort **Type:** text #### Evidence needed **Key:** evidence **Type:** text #### Main limitation **Key:** limit **Type:** text **Rows:** **Method:** 5 Whys **Best for:** Single-thread problems with a likely linear cause chain **Effort:** Low **Evidence:** Process knowledge and checks at each why **Limit:** Can follow one path and miss parallel causes **Method:** Fishbone (Ishikawa) diagram **Best for:** Brainstorming many possible causes across man, machine, method, material, measurement, environment **Effort:** Low to medium **Evidence:** Team input, then data to test each candidate **Limit:** Lists possible causes, does not prove which one is real **Method:** Is / Is Not analysis **Best for:** Narrowing a problem by what, where, when and how big **Effort:** Medium **Evidence:** Defect location, lot, time, shift and quantity data **Limit:** Needs good data on the good units too **Method:** Pareto analysis **Best for:** Choosing which defect type or supplier to attack first **Effort:** Low **Evidence:** Counted defects by category over a period **Limit:** Shows where, not why **Method:** Fault tree analysis **Best for:** Safety-critical or complex failures with several contributing events **Effort:** High **Evidence:** Design and failure data, event probabilities where available **Limit:** Needs skilled facilitation and a clear top event **Method:** FMEA review **Best for:** Checking whether a failure mode was anticipated and why detection failed **Effort:** Medium **Evidence:** Current PFMEA or DFMEA, control plan **Limit:** Only as good as the existing FMEA **Method:** Change analysis **Best for:** Problems that appeared suddenly after something changed **Effort:** Medium **Evidence:** Change records, ECNs, tooling and supplier change history **Limit:** Fails if changes were not recorded **Method:** Design of experiments **Best for:** Confirming which of several process factors drives the defect **Effort:** High **Evidence:** Planned trial runs and measurement capability **Limit:** Needs production time and capable measurement **Method:** Process flow and walk-through (gemba) **Best for:** Finding where reality differs from the written process **Effort:** Low to medium **Evidence:** Direct observation, interviews, standard work **Limit:** Observation can change behaviour **Method:** Barrier analysis **Best for:** Explaining why a defect escaped to the customer **Effort:** Medium **Evidence:** Inspection points, control plan, escape history **Limit:** Does not explain how the defect was created **Method:** Comparative analysis (good versus bad) **Best for:** Intermittent defects where good and bad units can be compared **Effort:** Medium **Evidence:** Measurements of paired good and bad units **Limit:** Needs enough bad units to compare **Method:** A3 problem solving **Best for:** Structured one-page reporting of problem, cause, countermeasure and follow-up **Effort:** Medium **Evidence:** Data supporting each section **Limit:** A reporting format, not a cause-finding technique on its own **Notes:** No single method is right for every problem. Many investigations combine a Pareto to choose, an Is/Is Not to narrow, a fishbone to list candidates and a 5 Whys or test to prove the cause. ## Content **Intro:** Choosing the wrong root cause method wastes days. This table helps you match the method to the problem, so a sudden defect gets change analysis and a safety event gets a fault tree. **Sections:** #### How to use the selector **Body:** Start with the situation, not the tool. Is the problem new after a change, intermittent, one of many defect types, or a failure with possible serious consequences? Search the Best used when column for words that describe your case, compare effort and evidence needed with the time you have, and note the limitation. Export the shortlist to Excel and paste it into your investigation plan so the team agrees on method before the first meeting. #### Combining methods **Body:** Good investigations use methods in sequence. A Pareto picks the biggest defect. An Is/Is Not analysis shows where and when it occurs. A fishbone collects candidate causes, and testing or a 5 Whys confirms the true cause. A barrier analysis then explains why detection missed it. Treat brainstorming tools as hypothesis generators only, and insist on data before a cause is accepted into a CAPA record. **Bullets:** - Pareto to choose the problem - Is/Is Not to narrow it - Fishbone to list candidates - Test or 5 Whys to confirm - Barrier analysis for escape point #### Common mistakes **Body:** The most common mistake is stopping at human error. Operator error is a symptom of a process that allowed the mistake, so ask what made the error possible and why the system did not catch it. Another is using a fishbone and picking the cause the loudest person prefers. Require each candidate cause to be checked with a measurement, a trial or records before it is accepted, and record that evidence in the report. **Cta:** If your root cause data lives across ERP lots, inspection results and maintenance logs, we can help build a read-only view that supports the investigation. **Faq:** #### Is 5 Whys enough for a customer complaint? **Answer:** Sometimes, for simple problems with a clear chain. For recurring or complex complaints, customers usually expect more evidence, such as a verified cause, an escape point and a link to the FMEA. Combine 5 Whys with data checks. #### What is the difference between a fishbone and a fault tree? **Answer:** A fishbone groups possible causes by category for brainstorming. A fault tree is a logic diagram that shows how combinations of events lead to a defined top failure, and can be quantified. Fault trees take more skill and data. #### When should I use design of experiments? **Answer:** Use it when several process factors might interact and you need to know which ones matter, and when you can afford planned trial runs with a capable measurement system. It is rarely the first step of an investigation. #### How do I know a root cause is real? **Answer:** A real cause can be demonstrated: when you introduce it the defect appears, and when you remove it the defect goes away. If you cannot test directly, show the data pattern that matches the cause and rules out the alternatives. ## Search terms root cause analysis methods, which rca method to use, 5 whys vs fishbone, fault tree analysis vs fmea, is is not analysis, root cause analysis techniques manufacturing, rca tools comparison, problem solving methods quality --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json