What are some best practices for conducting root cause analysis of quality problems?

Best practices for root cause analysis include using structured methodologies like the 5 Whys or Fishbone (Ishikawa) diagrams to systematically explore potential causes. Involve cross-functional teams to gain diverse perspectives, and gather comprehensive data before analysis. Prioritize finding the root cause rather than treating symptoms, and implement corrective actions with monitoring mechanisms to ensure the problem is resolved. Document findings and share lessons learned to prevent recurrence.

It is equally important to define what the problem is not, where and when the problem is not occurring. This kind of differential analysis is vital. I disagree with not including “who” with “what, where, when, how often”. For example, the problem could occur when less experienced operators are running the equipment. I disagree with including “how” with “who, what, when , where”. Addressing “how” a problem occurs during the problem definition requires building the assumption of a cause into the problem definition. I believe fish bone diagrams are a tool to help determine the root cause, but not to define the problem. Statistical analysis is a powerful tool to help determine and define the problem that was overlooked.

Who, what, when, where, why, how, and how much is a LEAN tool, with the acronym 5W2H, to help frame problem. All those parts may not be relevant while studying the symptoms to frame the actual problem. Also, Fishbone diagram and Pareto Charting are tools usually to conduct a RCA and rank issues, and likelt not to frame the problem, because it could become costly in time and resources.

Root Cause Analysis (RCA) is a comprehensive term encompassing a collection of problem solving methods used to identify the real cause of a non-conformance or quality problem. Root Cause Analysis is the process of defining, understanding and solving a problem.

Antes de utilizar cualquier herramienta, primero hay que analizar si realmente es un problema. Para esto, la pregunta crucial es ¿Por qué es un problema? La respuesta está en hacer una verificación del resultado obtenido contra las especificaciones y las normas. Si hay discrepancias, entonces si hay un problema y se procede a analizarlo: ¿En donde se encontró? ¿Quién lo encontró? ¿Cómo se detectó? ¿Cual es la magnitud del problema en cantidad física y económica?

Para la recolección de datos, se debe considerar el aspecto técnico y el aspecto administrativo. El aspecto técnico se enfoca en la generación del problema: ¿Por qué se produjo el problema? Mientras que el aspecto administrativo se enfoca en la fuga del problema: ¿Por qué no se detectó el problema? Analizar la situación actual con fotos, diagrama de flujo, planos, distribución del proceso, reportes estadísticos, reportes de lecciones aprendidas, hojas de control, reportes de mantenimiento y toda la información que crean conveniente se debe analizar.

Tão importante quanto descrever bem o problema de qualidade é coletar os dados e obter evidencias para melhor análise da não conformidade. A importância da obtenção de dados e evidencias é para melhor direcionamento das análises da causa raiz e ações corretivas a serem implementadas no processo. É valido destacar ainda que, amostras físicas contribuem significativamente para análise, assim como ir até o gemba e entender o problema.

I thought Cause-Effect diagram was visualized by Fishbone diagram to identify issues causing the symptoms under study or analysis.

A identificação da causa raiz é um fator preponderante de uma boa análise de não conformidade, pois é através desta análise que serão disseminadas as ações corretivas sistêmicas no processo. Gostaria de destacar que para identificação da causa raiz é imprescindível uma abordagem com técnica testada e validada e, as ferramentas da qualidade cumprem com este objetivo. Quero registrar que falha operacional não é causa raiz e treinamento não é ação corretiva.

De posse dos dados, informações e amostra do problema de qualidade, é o momento de analisar e determinar a causa raiz. Uma equipe multifuncional deve conduzir as análises, de preferência, no gemba. Ferramentas da qualidade como Diagrama de Causa e Efeito, 5 POR QUÊS ou Brainstorming devem ser utilizadas para determinar a causa. Após a detecção da causa, as ações corretivas e preventivas devem ser implementadas, importante destacar que a causa raiz deve ser sistêmica.

Selection of solution alternatives can be aided by brainstorming with stakeholders aided by tools like Pareto graphs. Likely, Affinity Diagrams can help categorize solution components once an approach is selected.

Após a implementação das ações corretivas, faz-se necessária a verificação da eficácia, ou seja, é necessário ir até o gemba e verificar se ainda há ocorrência da não conformidade e se o pessoal do processo está utilizando as contramedidas propostas no plano de ação. Eu adotaria a seguinte ação sistêmica, após identificar a causa raiz e propor as ações corretivas, depois de 10 ou 15 dias iria verificar se ainda existe e qual foi o impacto das ações nos indicadores de performance do processo.

Monitoring the implemented solution for benefit realization presumes that clear metrics were identified beforehand. That is Key step in PDCA cycle.

In my experience, Root Cause Analysis is an iterative process. Information learned at each step should be used to refine the previous steps whenever applicable. Additionally, information and solutions found from RCA should be examined across the board to other problems, processes, and products that are affected by the same root causes. This is how a corrective action can become a preventive action.

When conducting root cause analysis of quality problems, it's essential to follow some best practices to ensure effective problem-solving. Firstly, gather relevant data and information related to the quality issue. Then, utilize techniques such as the 5 Whys or Fishbone Diagram to systematically explore the underlying causes of the problem. Involve cross-functional teams to gain diverse perspectives and insights. Additionally, prioritize solutions based on their potential to address the root cause and prevent recurrence. Finally, implement corrective actions and monitor their effectiveness over time to ensure sustained improvement.

Esta é uma recomendação para todas as pessoas que analisam causa raiz de um problema de qualidade. Falha operacional não é causa raiz e treinamento não é ação corretiva! A abordagem de uma equipe multifuncional deve detectar uma falha sistêmica, ou seja, por que o modo de falha não foi mapeado no processo? Por que não foi considerado no FMEA e Plano de Controle? Por que não tem um plano de reação da Instrução de Trabalho?