Redacción de 8D.wiki — Redactado con asistencia de IA y después revisado, editado y maquetado por el fundador; hechos, cifras, tablas y terminología se comprueban antes de publicar.
Revisado y editado por: Alvin Jin — Experto en IATF 16949 · Coach certificado de Product Engineering (PE) · Experto en DRBFM
Published 2024-02-13 · Last reviewed 2026-10-25
Pase de los Cinco Porqués lineales al análisis de causa raíz sistémico con Ishikawa y Análisis de Árbol de Fallos (FTA) para detectar fallos multicondición e...
Una vez vi a siete ingenieros perseguir una causa raíz fantasma durante tres semanas porque estaban aferrados a un Análisis de los Cinco Porqués lineal. El problema era una falla de comunicación intermitente entre un PLC y un sistema de visión en una línea de empaque de alta velocidad. La cadena de los Cinco Porqués se veía impecable sobre el papel: la comunicación se caía porque el blindaje del cable estaba dañado porque se había tendido demasiado cerca de un variador de frecuencia. El equipo reemplazó el cable con confianza, lo reencaminó por otra bandeja portacables, actualizó el SOP de cableado y cerró el 8D. El problema regresó cuatro días después y la línea se detuvo durante una corrida de producción crítica, lo que le costó a la planta más de cincuenta mil dólares en tiempo de inactividad.
La falla real requería tres condiciones simultáneas que ninguna cadena lineal de Cinco Porqués podría capturar. La primera condición era la interferencia electromagnética del VFD, que siempre estaba presente pero normalmente era benigna porque el blindaje del cable estaba intacto. La segunda condición era un lazo de tierra que se desarrolló cuando el equipo de mantenimiento reemplazó una puerta de tablero oxidada tres semanas antes sin poner a tierra la nueva puerta al bus de tierra. La tercera condición era un error de temporización del firmware en el sistema de visión que solo se activaba cuando la carga de procesamiento de imágenes superaba el 80 por ciento, lo que provocaba una colisión de temporización de 3 milisegundos con el ciclo de lectura Modbus. Cada condición por sí sola era completamente inofensiva. La interferencia del VFD estaba muy dentro de la especificación del cable. El lazo de tierra estaba dentro de la tolerancia de la fuente de alimentación aislada. El error de temporización del firmware nunca había causado un problema durante las pruebas porque el entorno de prueba nunca alcanzaba el 80 por ciento de carga de procesamiento. Juntas, estas tres condiciones inofensivas crearon una falla intermitente que parecía completamente aleatoria.
Esa experiencia me convirtió en un firme creyente del análisis de causa raíz por capas. Ahora inicio cada investigación de D4 con un diagrama de Ishikawa como andamiaje de lluvia de ideas. Obligo al equipo a llenar las seis categorías con al menos dos hipótesis por categoría antes de que alguien tenga permitido perseguir una sola teoría. Para el caso de la línea de empaque, el Ishikawa habría señalado Medición: nunca se había realizado monitoreo de EMI en esta línea; Entorno: el lazo de tierra introducido por el reemplazo de la puerta del tablero; y Método: el parámetro de temporización del firmware que ningún desarrollador había probado bajo estrés a escala, junto con la obvia categoría de Máquina del ruteo del cable. De repente, el equipo tenía seis familias de causas potenciales en lugar de un solo rastro lineal que conducía a un callejón sin salida.
Solo entonces, y únicamente entonces, despliego el Análisis de Árbol de Fallos, que es el inverso de los Cinco Porqués. En lugar de preguntar por qué hacia atrás desde la falla, usted construye un árbol lógico de qué combinaciones de eventos podrían causar la falla usando compuertas AND y compuertas OR. Para la falla del PLC, un FTA habría revelado de inmediato que la falla requería ruido del VFD Y lazo de tierra Y temporización del firmware ocurriendo simultáneamente. Esa compuerta AND de tres entradas era completamente invisible para los Cinco Porqués lineales porque cada factor era inofensivo de forma aislada. He visto este patrón repetirse en docenas de industrias. Un defecto de pintura automotriz requería balance de solvente Y humedad ambiental superior al 65 por ciento Y presión de aplicación superior a 3.2 bar para converger. Una falla de sello en un dispositivo médico requería desgaste de herramienta superior a 0.15 mm Y variación de lote de material en la dureza Y tiempo de permanencia inferior a 1.8 segundos. Un levantamiento de hilo de unión en semiconductores necesitaba contaminación por un cambio de solvente de limpieza Y deriva del generador ultrasónico Y antigüedad de la herramienta de unión superior a 200,000 ciclos. En todos los casos, el equipo que comenzaba solo con los Cinco Porqués quemaba semanas persiguiendo callejones sin salida, mientras que el equipo que iniciaba con Ishikawa y validaba de forma cruzada con FTA encontraba la causa verdadera en días. Los Cinco Porqués no están equivocados, simplemente son incompletos. Piense en ellos como su herramienta de precisión para la última milla del análisis de causa raíz, después de haber mapeado todo el panorama causal con Ishikawa y modelado las interacciones con FTA. Si su investigación de D4 está tomando más de dos semanas, pregúntese con honestidad si está buscando una sola cadena en un sistema que en realidad es una red de variables que interactúan.
La aplicación práctica de Ishikawa más FTA requiere disciplina y paciencia. Imprimo un Ishikawa en blanco en papel A3 y lo coloco en la pared con notas adhesivas. El equipo llena cada categoría usando un protocolo de lluvia de ideas en el que cada miembro aporta al menos una hipótesis antes de que alguien pueda descartar una idea. Esto evita que la voz más fuerte domine. Después del Ishikawa, dibujo el árbol lógico del FTA en un pizarrón, comenzando desde el evento superior y avanzando hacia abajo a través de compuertas AND y OR. Estas dos herramientas visuales juntas involucran al equipo de una manera que una lista lineal de cinco preguntas nunca podrá. He visto equipos atascados en D4 durante semanas lograr un avance en una sola tarde después de este enfoque combinado. La clave es resistir la tentación de saltar a una hipótesis demasiado pronto. Dedique las primeras dos horas de D4 a ampliar el espacio de búsqueda antes de confirmar o refutar cualquier hipótesis individual.
Suponga que la falla de la línea de empaque se reabre y el equipo ejecuta el método por capas correctamente. El Ishikawa arroja una lista corta y el FTA la reduce a una sola compuerta AND con tres entradas. Luego, el equipo diseña un plan de verificación que prueba cada entrada de forma independiente y en combinación, porque una falla multicondición no se puede demostrar corrigiendo una sola rama.
| Entrada | Método de prueba | Criterio de aprobación | Resultado observado |
|---|---|---|---|
| Ruido del VFD | Operar la línea con el variador a plena carga, blindaje intacto | Sin pérdida de comunicación durante 8 horas | 0 caídas |
| Lazo de tierra | Medir el potencial entre la puerta del tablero y el bus de tierra | Por debajo de 0.1 V | 0.42 V antes de la puesta a tierra, 0.03 V después |
| Temporización del firmware | Llevar la carga de visión por encima del 80 por ciento durante 2 horas | Sin colisión de Modbus | 3 colisiones en 90 minutos |
Los datos muestran que cada entrada es individualmente tolerable, pero la combinación no lo es. Por lo tanto, la acción correctiva es triple: poner a tierra la puerta al bus de tierra, agregar una ferrita y reencaminar el cable de señal, y aplicar un parche al firmware para ampliar la ventana de lectura de Modbus. Solo después de que las tres estén implementadas, el equipo ejecuta una corrida de confirmación de 72 horas a plena carga de producción con cero caídas. Esa es la evidencia que cierra D4.
Un D4 completado solo es creíble cuando los datos de verificación coinciden con el árbol lógico. Verifique que cada entrada de la compuerta AND tenga una acción correctiva correspondiente, que cada acción tenga un valor medido antes y después, y que la corrida de confirmación refleje condiciones reales de producción en lugar de un montaje de laboratorio. Si la falla es intermitente, la ventana de confirmación debe ser lo suficientemente larga como para haber detectado al menos una recurrencia bajo las condiciones anteriores. Cuando sea posible, reproduzca la falla deliberadamente reinstaurando una entrada y luego retírela de nuevo; esto demuestra el vínculo causal en lugar de suponerlo.
El enfoque por capas no está aislado. Se alimenta directamente de D2 (descripción del problema), porque un evento superior vago produce un FTA inútil. Alimenta a D5 (acciones correctivas), porque cada entrada de la compuerta AND se convierte en una acción correctiva permanente con un responsable y una fecha de vencimiento. Informa a D6 (implementación y validación), donde la corrida de confirmación proporciona la evidencia de eficacia. Y protege a D7 (prevención de recurrencia), porque el SOP de cableado actualizado, el procedimiento de puesta a tierra y el protocolo de prueba del firmware son los cambios sistémicos que impiden que la red de condiciones se vuelva a formar. Cuando D4 se realiza de esta manera, los pasos posteriores se vuelven sencillos: el pensamiento difícil ya ocurrió.
Turn this method into a submittable 8D report
Generate a D0–D8 report skeleton with a 5-Why chain and containment actions.
8D.wiki — Quality Engineering Knowledge Base