Análisis de causa raíz: 5 porqués, diagrama de Ishikawa y análisis de árbol de fallos

El método de los 5 porqués

Los 5 porqués es una técnica de cuestionamiento iterativo desarrollada por Sakichi Toyoda y popularizada a través de su uso en el Sistema de Producción Toyota. El método consiste en tomar una declaración del problema y preguntar “¿por qué ocurrió esto?” y luego preguntar “¿por qué?” de nuevo sobre cada respuesta sucesiva hasta llegar a la causa raíz subyacente. El número cinco es una guía, no una regla: algunos problemas tienen causas raíz en el tercer porqué, otros en el séptimo.

El método se ilustra mejor con un ejemplo. Una prensa de estampado produce piezas con un defecto dimensional:

Porqué 1: ¿Por qué las piezas están fuera de tolerancia? Porque el troquel está desgastado.

Porqué 2: ¿Por qué está desgastado el troquel? Porque funcionó más allá de su intervalo de reemplazo programado.

Porqué 3: ¿Por qué funcionó más allá de su intervalo de reemplazo? Porque el programa de mantenimiento no se actualizó cuando aumentó el volumen de producción.

Porqué 4: ¿Por qué no se actualizó el programa de mantenimiento? Porque no existe un proceso para revisar los intervalos de mantenimiento cuando cambian los parámetros de producción.

Porqué 5: ¿Por qué no existe tal proceso? Porque las funciones de mantenimiento y planificación de producción no tienen un protocolo de comunicación formal para los cambios de parámetros.

La causa raíz no es un troquel desgastado (que es un síntoma) ni siquiera un evento de mantenimiento omitido (que es una causa próxima): es una brecha organizacional en cómo se comunican los cambios de producción al mantenimiento. La acción correctiva a este nivel crea una solución duradera; reemplazar el troquel sin abordar la brecha de comunicación producirá el mismo fallo de nuevo.

El análisis eficaz de los 5 porqués requiere disciplina. El modo de fallo más común es detenerse en la causa próxima (porqué 2 o porqué 3) e implementar una acción correctiva a ese nivel. Un segundo modo de fallo es la ramificación: en algunos niveles de porqué puede haber múltiples causas contribuyentes, cada una de las cuales merece su propia cadena de porqués. Un diagrama de espina de pescado se utiliza a menudo junto con los 5 porqués para capturar cadenas causales ramificadas.

Diagrama de espina de pescado (Ishikawa)

El diagrama de espina de pescado, desarrollado por Kaoru Ishikawa en la década de 1960, es una herramienta visual para organizar las causas potenciales de un problema en categorías. El diagrama toma su nombre de su forma: la declaración del problema (el efecto) se sitúa en la cabeza del pescado, y las categorías principales de causas se ramifican de la espina dorsal como huesos. Las causas específicas potenciales se añaden como ramas más pequeñas de cada hueso de categoría.

Las categorías de causas estándar en contextos de fabricación siguen el marco de las 6M:

• Mano de obra (Personas): habilidad del operador, capacitación, fatiga, cumplimiento de procedimientos, error humano.
• Máquina: condición del equipo, herramientas, calibración, estado de mantenimiento, capacidad.
• Material: propiedades del material entrante, variación del proveedor, variación de lote a lote, condiciones de almacenamiento.
• Método: instrucciones de trabajo, parámetros de proceso, métodos de medición, procedimientos de configuración.
• Medición: capacidad del calibre, calibración, técnica de medición, precisión de recopilación de datos.
• Medio ambiente: temperatura, humedad, vibración, limpieza, iluminación.

El diagrama de espina de pescado se utiliza en la fase de Análisis de DMAIC y en las primeras etapas de la resolución de problemas 8D para generar una lista completa de causas potenciales antes de que la investigación basada en datos reduzca la lista a causas raíz verificadas. El diagrama en sí no identifica la causa raíz; organiza hipótesis para su prueba. Después de completar el diagrama, cada rama se evalúa contra los datos disponibles para determinar qué causas potenciales están contribuyendo realmente al problema.

Análisis de árbol de fallos

El análisis de árbol de fallos (AAF) es un método analítico deductivo de arriba hacia abajo que modela las relaciones lógicas entre un evento no deseado de nivel superior (el evento cima) y los eventos de nivel inferior (eventos básicos) que pueden causarlo. El AAF fue desarrollado por Bell Telephone Laboratories en la década de 1960 para el programa de misiles Minuteman de la Fuerza Aérea de los EE. UU. y ahora se usa ampliamente en industrias aeroespaciales, nucleares, automotrices y de procesos.

Un AAF comienza definiendo el evento cima con precisión. El analista luego trabaja hacia abajo, preguntando qué combinaciones de eventos pueden causar directamente el evento cima. Estos eventos intermedios se descomponen a su vez en sus propios eventos contribuyentes, hasta que todas las ramas alcanzan eventos básicos que no pueden descomponerse más (fallos de equipos, errores humanos, eventos externos).

Las relaciones lógicas entre eventos se representan mediante puertas:

• Puerta AND: el evento de salida ocurre solo cuando todos los eventos de entrada ocurren simultáneamente. Las puertas AND representan sistemas redundantes donde se requieren múltiples fallos para producir el evento cima.
• Puerta OR: el evento de salida ocurre cuando ocurre cualquiera de los eventos de entrada. Las puertas OR representan rutas de fallo paralelas donde cualquier fallo individual es suficiente.

Cuando se asignan probabilidades de fallo a los eventos básicos, el AAF se vuelve cuantitativo. La probabilidad del evento cima se calcula usando álgebra booleana:

P(salida puerta AND) = P(A) × P(B) × P(C) [para eventos independientes]

P(salida puerta OR) = 1 − (1 − P(A)) × (1 − P(B)) × (1 − P(C))

Los conjuntos de corte mínimos del árbol de fallos son las combinaciones más pequeñas de eventos básicos cuya ocurrencia simultánea causa el evento cima. Los conjuntos de corte mínimos con solo un evento básico (fallos de punto único) son los más críticos: cualquier fallo único causa el evento cima sin protección de redundancia. Las mejoras de diseño que eliminan fallos de punto único o reducen la probabilidad de conjuntos de corte mínimos críticos tienen el mayor impacto en la confiabilidad del sistema.

Selección y combinación de herramientas de ACR

Las tres herramientas abordan diferentes tipos de problemas y diferentes etapas de investigación. Para un defecto único y bien definido con una cadena causal clara, los 5 porqués es la herramienta más rápida y práctica. Para un problema recurrente con múltiples causas sospechadas en personas, máquinas, materiales y métodos, el diagrama de espina de pescado proporciona la estructura para capturar y organizar todas las hipótesis antes de investigar. Para un fallo de sistema complejo donde múltiples componentes pueden fallar en combinación y se deben cumplir objetivos de probabilidad cuantitativos, el AAF proporciona el rigor y el marco matemático que las herramientas más simples no pueden.

En la práctica de gestión de calidad, estas herramientas a menudo se combinan. Primero se usa un diagrama de espina de pescado para mapear el espacio del problema y generar hipótesis. Las causas contribuyentes confirmadas se analizan luego con los 5 porqués para encontrar la causa raíz sistémica dentro de cada categoría. Para fallos de alta gravedad que involucran seguridad del sistema o cumplimiento regulatorio, se usa el AAF para modelar todas las rutas de fallo y verificar que las acciones correctivas reduzcan la probabilidad del evento cima a un nivel aceptable.

Errores comunes en el análisis de causa raíz

• Detenerse en la causa próxima. Una herramienta desgastada, un sensor roto, un parámetro mal configurado son causas próximas. La causa raíz es el fallo del sistema de gestión que permitió que ocurriera la causa próxima: mantenimiento preventivo inadecuado, frecuencia de calibración insuficiente, ningún proceso de control de cambios. Las acciones correctivas al nivel de la causa próxima producen soluciones temporales; las acciones correctivas al nivel de la causa raíz previenen la recurrencia.
• Confundir correlación con causalidad. En la generación de ideas del diagrama de espina de pescado, las causas potenciales son hipótesis. Confirmar una causa requiere datos: análisis estadístico, experimentos diseñados o ensayos de proceso controlados que muestren que la relación causa-efecto es real, no coincidental.
• Cadenas de 5 porqués que terminan en una persona. “El operador cometió un error” no es una causa raíz; es un síntoma de un sistema deficiente. La cadena de los 5 porqués debe continuar a través del error hasta la condición del sistema (capacitación inadecuada, procedimiento poco claro, diseño del puesto de trabajo que hace probables los errores) que permitió que ocurriera el error.
• Usar AAF para problemas simples. El AAF es una herramienta poderosa que requiere tiempo y experiencia significativos para aplicarse correctamente. Usarlo para problemas que pueden resolverse con un análisis de 5 porqués desperdicia recursos sin agregar valor analítico. Ajuste la complejidad de la herramienta a la complejidad del problema.

Preguntas frecuentes

¿Cómo se sabe cuándo se ha llegado a la causa raíz en un análisis de 5 porqués?

Se llega a una causa raíz cuando se cumplen dos condiciones. Primero, la respuesta al “porqué” actual es una condición del sistema controlable: un procedimiento faltante, un estándar inadecuado, una brecha de comunicación, un operador no capacitado, un parámetro de proceso no monitoreado. Segundo, una acción correctiva a este nivel evitaría no solo este incidente sino toda la clase de incidentes causados por la misma brecha sistémica. Una prueba práctica es la verificación del “por lo tanto”: trabajar de regreso en la cadena usando “por lo tanto” en lugar de “porqué” para verificar que la cadena lógica se mantenga desde la causa raíz hasta el síntoma. Si algún eslabón de la cadena no se mantiene, la identificación de la causa raíz es incorrecta o incompleta. Otro indicador de que no se ha llegado a la causa raíz es cuando la respuesta señala a otra persona o grupo: esto es un síntoma de un fallo del sistema, no la causa raíz misma.

¿Cuáles son las seis categorías en un diagrama de espina de pescado y cuándo se deben usar categorías adicionales?

Las seis categorías estándar en el marco de las 6M para fabricación son: Mano de obra (Personas), Máquina, Material, Método, Medición y Medio ambiente. Estas seis categorías fueron diseñadas para cubrir las principales fuentes de variación en los procesos de fabricación y son apropiadas para la mayoría de los problemas de calidad de producción. Se pueden agregar categorías adicionales cuando las seis estándar no cubren todas las fuentes relevantes de variación para un tipo de problema específico. En aplicaciones de la industria de servicios, a veces se usa el marco de las 8P en su lugar. La regla para agregar categorías es que cada fuente principal de variación relevante para el problema específico debe tener su propia rama, y cada causa potencial debe encajar claramente en exactamente una categoría. Si una causa encaja en múltiples categorías, las definiciones de categoría deben aclararse o la causa debe descomponerse en subcausas más específicas.

¿Qué es un conjunto de corte mínimo en el análisis de árbol de fallos y por qué es importante?

Un conjunto de corte mínimo es la combinación más pequeña de eventos básicos cuya ocurrencia simultánea es necesaria y suficiente para causar el evento cima. “Mínimo” significa que eliminar cualquier evento del conjunto evitaría que el evento cima ocurra a través de esa combinación. Un árbol de fallos con tres eventos básicos A, B y C y un evento cima que ocurre cuando (A AND B) OR C ocurre tiene dos conjuntos de corte mínimos: {A,B} y {C}. El conjunto de corte mínimo {C} contiene solo un evento, lo que significa que C solo puede causar el evento cima: esto es un fallo de punto único, el tipo más crítico en ingeniería de confiabilidad. Los conjuntos de corte mínimos importan porque identifican qué combinaciones de fallos son más críticas para la seguridad del sistema: los conjuntos de un solo elemento son la prioridad más alta para la mejora del diseño, los conjuntos de dos elementos son la siguiente prioridad, y así sucesivamente.

¿Cómo se utiliza el análisis de causa raíz en el proceso CAPA?

El análisis de causa raíz es el núcleo analítico del proceso de acción correctiva y preventiva (CAPA). En un flujo de trabajo CAPA, una no conformidad o queja del cliente desencadena una investigación que tiene tres resultados requeridos: una causa raíz verificada, acciones correctivas que aborden la causa raíz y evidencia de que las acciones correctivas fueron efectivas. Las herramientas de ACR se utilizan en la fase de investigación: 5 porqués para problemas sencillos de una sola causa, diagrama de espina de pescado para problemas con múltiples causas contribuyentes potenciales, y AAF para fallos de alta gravedad en sistemas complejos. La causa raíz debe verificarse, no asumirse: la investigación debe mostrar datos o evidencia de que la causa raíz identificada estaba realmente presente y contribuyó realmente al fallo. En industrias reguladas (FDA, ISO 13485, IATF 16949), el registro CAPA incluida la documentación de ACR está sujeto a auditoría.

¿Cuál es la diferencia entre una causa raíz y un factor contribuyente?

Una causa raíz es la condición sistémica fundamental que, si se corrige, evitaría que el problema vuelva a ocurrir. Un factor contribuyente es una condición que aumentó la probabilidad o gravedad del problema pero no es suficiente por sí sola para causarlo. La distinción importa para la priorización de acciones correctivas: abordar solo los factores contribuyentes sin abordar la causa raíz produce una solución incompleta que deja al problema vulnerable a la recurrencia. Por ejemplo, en una investigación de un evento de contaminación de producto: la causa raíz podría ser una validación de limpieza inadecuada que no estableció parámetros de ciclo de enjuague suficientes; los factores contribuyentes podrían incluir un operador que omitió un paso en el procedimiento de limpieza y un supervisor que no verificó el registro de limpieza. En la práctica, un CAPA exhaustivo aborda tanto la causa raíz como los factores contribuyentes significativos, siendo la corrección de la causa raíz la acción de mayor prioridad.

¿Cuándo se debe usar el análisis de árbol de fallos en lugar de herramientas de ACR más simples?

El análisis de árbol de fallos debe usarse cuando se aplican tres o más de las siguientes condiciones: el sistema tiene múltiples modos de fallo redundantes o interactivos que pueden combinarse de formas complejas para producir el evento cima; se debe demostrar un objetivo de probabilidad cuantitativa para el evento cima (como un requisito de nivel de integridad de seguridad o un límite regulatorio sobre la tasa de fallos); las consecuencias del fallo son graves (crítico para la seguridad, crítico para la vida o crítico para la regulación); el sistema es nuevo y los modos de fallo no han sido caracterizados por la experiencia operativa; o una investigación de ACR más simple anterior produjo una solución que no evitó la recurrencia. El AAF no es apropiado para problemas simples y bien entendidos donde la cadena causal es lineal. En seguridad funcional automotriz (ISO 26262 ASIL D), aeroespacial (DO-178C) y energía nuclear, el AAF a nivel de sistema es típicamente un requisito regulatorio.