Las 5M y los 5 Por Qué: guía completa para el análisis causa raíz (con casos de la industria)

Nota de edición. Esta guía reemplaza y amplía mi publicación de septiembre de 2024 sobre el mismo tema. Corregí algunos ejemplos, agregué la sexta M (Medición), un caso completo de la industria de envases y una sección sobre cómo revisa un auditor el análisis de causa.

Introducción: la causa raíz que no era

Hace algunos años revisé un plan de acciones correctivas que tenía todo en orden: el diagrama de Ishikawa estaba completo, los cinco porqués estaban escritos y la acción tenía responsable y fecha. La causa raíz decía: «falta de capacitación del operador». La acción: «capacitar al operador». Tres meses después, el mismo defecto apareció en otro turno, con otro operador ya capacitado.

El problema no era la herramienta. Era cómo se había usado. El equipo llenó las espinas del pescado con ideas, escogió la que parecía más evidente sin comprobarla y la llevó a cinco porqués hasta llegar a la respuesta que casi todos esperaban escuchar. Nadie preguntó por qué el sistema permitía que un operador sin el conocimiento necesario estuviera en esa máquina, ni por qué el control de calidad no detectó el defecto antes de que saliera de la planta.

Las 5M (o 6M, como veremos) y los 5 Por Qué son probablemente las dos herramientas de análisis causa raíz más usadas en el mundo. Son sencillas de explicar y se pueden aplicar en una sala de reuniones con un pizarrón. Esa misma sencillez es su mayor riesgo: es muy fácil obtener un análisis que parece correcto y que no resiste la primera pregunta de un auditor o, peor aún, la siguiente ocurrencia del problema.

Esta guía está pensada para implementadores, coordinadores de calidad e inocuidad, dueños de proceso, auditores internos y gerentes que tienen que investigar no conformidades y quieren que sus acciones correctivas funcionen. Al terminarla podrás:

Distinguir un síntoma de una causa directa, una causa contribuyente y una causa raíz.
Definir el problema antes de buscar culpables (o causas).
Construir un diagrama de Ishikawa útil, con preguntas guía para cada M.
Aplicar los 5 Por Qué con reglas claras para saber cuándo detenerte.
Combinar ambas herramientas en un solo flujo, con un paso que casi siempre se omite: verificar las causas con datos.
Evitar los errores que con más frecuencia hacen que un auditor rechace un análisis de causa.
Saber cuándo estas herramientas no son suficientes y conviene pasar a otra metodología.

1. Qué es el análisis causa raíz y por qué lo exigen las normas

1.1 Síntoma, causa directa, causa contribuyente y causa raíz

Antes de hablar de herramientas conviene ponernos de acuerdo en el vocabulario. Buena parte de los análisis débiles nacen de mezclar estos cuatro conceptos:

Concepto	Qué es	Ejemplo (botellas con fugas)
Síntoma o efecto	Lo que se observa; la manifestación del problema.	El cliente reporta botellas que gotean en la tapa.
Causa directa	El evento o condición física que produce el efecto de forma inmediata.	El diámetro del cuello está fuera de especificación.
Causa contribuyente	Una condición que aumenta la probabilidad o la gravedad del problema, pero que por sí sola no lo produce.	El molde tiene más ciclos de los recomendados sin revisión.
Causa raíz	La causa más profunda, bajo control de la organización, cuya eliminación evita que el problema vuelva a ocurrir.	El programa de mantenimiento de moldes no considera el conteo de ciclos como disparador de revisión.

Dos ideas importantes salen de esta tabla. La primera: casi nunca hay una sola causa. La mayoría de los problemas reales son el resultado de varias causas que coinciden, y un buen análisis lo reconoce. La segunda: la causa raíz debe estar bajo control de la organización. «El proveedor es malo» o «llovió mucho» no son causas raíz; la pregunta útil es por qué nuestro sistema no estaba preparado para esa condición.

1.2 Corrección, acción correctiva y acción preventiva

La norma ISO 9000:2015, que contiene el vocabulario de los sistemas de gestión de la calidad, distingue con claridad dos respuestas ante una no conformidad:

Corrección: acción para eliminar una no conformidad detectada. Retrabajar el lote, segregar el producto, reemplazar la pieza dañada.
Acción correctiva: acción para eliminar la causa de una no conformidad y evitar que vuelva a ocurrir.

La corrección atiende el efecto; la acción correctiva atiende la causa. Las dos son necesarias, pero solo la segunda requiere análisis causa raíz. Un error frecuente en los registros es llamar «acción correctiva» a lo que en realidad es una corrección: «se reprocesó el lote» no evita que el problema se repita.

La acción preventiva tradicional (actuar sobre causas de no conformidades potenciales) desapareció como requisito separado en las normas con estructura de alto nivel, porque se integró en el enfoque basado en riesgos. Aun así, el análisis causa raíz sigue siendo muy útil para prevenir: cuando encuentras una causa en una línea, conviene preguntar en qué otras líneas, productos o plantas existe la misma condición. A esto se le llama extensión horizontal o despliegue lateral de la acción, y es uno de los mejores indicadores de madurez de un sistema de gestión.

1.3 Qué piden ISO 9001, ISO 22000 y FSSC 22000

El análisis causa raíz no es una buena práctica opcional; es un requisito explícito en los sistemas de gestión certificables:

ISO 9001 (apartado 10.2, tanto en la edición 2015 como en la edición 2026 publicada en septiembre de 2026, que mantiene la estructura armonizada) pide que, ante una no conformidad, la organización reaccione, la controle y corrija, haga frente a sus consecuencias y evalúe la necesidad de acciones para eliminar sus causas, mediante la revisión y el análisis de la no conformidad, la determinación de sus causas y la búsqueda de no conformidades similares que existan o puedan ocurrir. Además, exige revisar la eficacia de las acciones tomadas y conservar información documentada.
ISO 22000:2018 trata las correcciones (8.9.2) y las acciones correctivas (8.9.3) cuando se pierde el control de los PPRO y los PCC, y repite el esquema general de no conformidad y acción correctiva en el apartado 10.1. Pide expresamente revisar las no conformidades, identificar sus causas e implementar acciones para que no se repitan.
FSSC 22000 se apoya en ISO 22000 y, en la práctica de auditoría, el tratamiento de las no conformidades de certificación exige al sitio presentar corrección, análisis de causa y plan de acción correctiva con evidencia dentro de plazos definidos. Los organismos de certificación revisan con detalle la calidad de ese análisis; un análisis de causa débil es una de las razones más comunes por las que se rechaza un plan de acción.

Hay un detalle que muchas organizaciones pasan por alto: la norma pide evaluar la necesidad de acciones correctivas. No toda desviación menor exige un análisis de seis espinas y cinco porqués. Un buen sistema define criterios (gravedad, recurrencia, impacto en el cliente o en la inocuidad) para decidir la profundidad del análisis. Ese criterio debe estar escrito y aplicarse de forma consistente.

Si estás empezando con estas normas, te pueden servir mis guías Introducción a ISO 9001 y FSSC 22000 v7: qué cambió, qué revisar y cómo preparar la migración.

2. Paso cero: definir el problema y contenerlo

2.1 Un problema mal definido produce un análisis mal dirigido

Si tuviera que señalar el paso que más se subestima en el análisis causa raíz, sería este. Los equipos suelen llegar a la sesión de Ishikawa con una frase como «problemas de calidad en la línea 3» o «quejas del cliente». Con esa definición, la lluvia de ideas produce de todo y no conduce a nada.

Un enunciado de problema útil es específico, medible y libre de causas o soluciones. Compara:

Enunciado débil	Enunciado útil
Hay muchos defectos en la línea 3.	Entre el 1 y el 15 de marzo, el 2.4 % de las preformas de 21.5 g de la línea 3 presentó puntos negros visibles, frente a un histórico de 0.2 %.
Los operadores no siguen el procedimiento.	En 4 de 10 verificaciones de arranque de la semana 12 no se registró la purga del husillo.
Falta capacitación en limpieza.	Tres hisopados ATP de la llenadora superaron el límite de 150 URL después de la limpieza del turno nocturno.

Observa que los enunciados débiles de la segunda y tercera fila ya contienen una causa supuesta. Cuando el problema se define así, el análisis está decidido antes de empezar.

2.2 Herramientas para definir el problema

Dos técnicas sencillas ayudan mucho en este paso:

5W2H. Responder qué, quién, dónde, cuándo, por qué (solo para el impacto, no para la causa), cómo y cuánto. Por ejemplo: qué producto y qué defecto; quién lo detectó; en qué línea, máquina o cavidad; desde cuándo y con qué frecuencia; qué impacto tiene; cómo se detectó; cuántas unidades o qué porcentaje.

Es / No es. Propuesta por Kepner y Tregoe, consiste en contrastar dónde sí aparece el problema y dónde podría aparecer, pero no aparece. Esta comparación es poderosa porque las diferencias entre el «es» y el «no es» suelen apuntar directamente a la causa.

Dimensión	Es	No es (pero podría ser)	Diferencia que llama la atención
Qué	Puntos negros en preforma de 21.5 g	Preforma de 28 g en la misma línea	Distinto molde
Dónde	Cavidades 3, 7, 12, 19 y 28	Las otras 27 cavidades	Posición en el canal caliente
Cuándo	Primeras dos horas después de un paro	Producción continua	Tiempo de residencia del material
Cuánto	2.4 % del lote	—	Aumento brusco desde marzo

Con una tabla así (en la sección 6 desarrollo este mismo caso completo), la sesión de Ishikawa ya no parte de cero: el equipo sabe que debe explicar por qué el defecto aparece en ciertas cavidades y después de los paros, y por qué empezó en marzo.

2.3 Contener antes de analizar

Mientras el equipo investiga, el problema puede seguir ocurriendo. Por eso, antes del análisis, se definen acciones de contención: segregar el inventario sospechoso, aumentar la inspección, bloquear lotes en el sistema, informar al cliente cuando corresponde. En sistemas de inocuidad, si existe la posibilidad de que el producto sea potencialmente no inocuo, la contención incluye evaluar su liberación según lo que pide ISO 22000 (8.9.4) y, si el producto ya salió, activar el procedimiento de retiro.

La contención no es la solución, pero sin ella el análisis se hace bajo presión y con el riesgo de que el problema llegue al cliente mientras discutimos las espinas del pescado.

2.4 Quién debe participar

El análisis causa raíz es un trabajo de equipo. La composición recomendada incluye:

Quien conoce el proceso de primera mano: operadores y técnicos del turno donde ocurrió el problema. Son quienes saben lo que realmente pasa, que no siempre coincide con lo que dice el procedimiento.
Quien conoce el producto y sus especificaciones: calidad, aseguramiento o desarrollo.
Quien puede aportar datos: laboratorio, planeación, mantenimiento.
Un facilitador que conozca la metodología y que, idealmente, no sea el responsable directo del proceso, para evitar que el análisis se convierta en una defensa.
Quien tiene autoridad para aprobar acciones, al menos en el cierre, para que las propuestas no se queden en el papel.

Un grupo de cuatro a siete personas suele funcionar mejor que una sala llena. Y una regla que conviene decir en voz alta al inicio de cada sesión: estamos buscando causas en el sistema, no culpables.

3. El diagrama de Ishikawa y las M

3.1 Origen

El diagrama de causa y efecto fue desarrollado por el ingeniero japonés Kaoru Ishikawa, una de las figuras centrales del movimiento de calidad en Japón. Lo empezó a usar en la década de 1940 con equipos de la industria siderúrgica y lo difundió en las décadas siguientes como una de las siete herramientas básicas de la calidad, junto con la hoja de verificación, el histograma, el diagrama de Pareto, la estratificación, el diagrama de dispersión y el gráfico de control. Por su forma se le conoce también como diagrama de espina de pescado.

La estructura es simple: a la derecha, en la «cabeza» del pescado, se escribe el efecto o problema. Hacia la izquierda sale una espina central de la que nacen espinas mayores, una por cada categoría de causas. En cada espina mayor se anotan las causas posibles, y de estas pueden salir espinas menores con sus subcausas.

3.2 De 4M a 8M: ¿cuántas M hay?

Ishikawa propuso inicialmente cuatro categorías para procesos de manufactura: materiales, máquinas, mano de obra y métodos. Con el tiempo se agregaron otras, y hoy encontrarás varias versiones:

Versión	Categorías	Cuándo conviene
4M	Materiales, Maquinaria, Mano de obra, Métodos	Procesos simples o análisis rápidos.
5M	4M + Medio ambiente	Cuando las condiciones del entorno influyen (temperatura, humedad, polvo).
6M	5M + Medición	La versión recomendada para calidad e inocuidad.
8M	6M + Management (dirección/gestión) + Mantenimiento o Dinero, según la fuente	Problemas donde pesan las decisiones de gestión, los recursos o el mantenimiento.

En la versión de 2024 de esta publicación usé las 5M. Hoy recomiendo trabajar con 6M como base, por una razón práctica: una parte importante de los problemas de calidad no son problemas del producto, sino del sistema de medición. Un instrumento descalibrado, un método de ensayo mal ejecutado o un criterio de aceptación ambiguo pueden producir rechazos falsos o, peor, liberar producto no conforme. Si no existe una espina para la medición, esas causas terminan mal clasificadas en «Maquinaria» o «Métodos», o simplemente no se consideran.

El número de M no es lo importante. Las categorías son un recordatorio para no olvidar ninguna fuente de variación. Puedes usar las que tengan sentido para tu proceso, siempre que no las uses para dejar fuera algo incómodo.

3.3 Las 6M una por una, con preguntas guía

Una espina vacía no genera ideas; una buena pregunta sí. Estas son las preguntas que uso para facilitar cada categoría.

Materiales. Materias primas, insumos, componentes, material de empaque, material reciclado y, en servicios, la información de entrada.

¿Cambió el proveedor, el lote, la planta de origen o la formulación del material?
¿El material cumple la especificación? ¿La especificación está completa?
¿Cómo se almacenó y por cuánto tiempo? ¿Se respetó el sistema de primeras entradas, primeras salidas?
¿Hubo mezclas, contaminación cruzada o uso de material recuperado?
¿El problema aparece con todos los lotes o solo con algunos?

Maquinaria. Equipos, moldes, herramientas, utillajes, software de control y sistemas auxiliares (aire comprimido, agua de enfriamiento, vapor).

¿Hubo mantenimientos, reparaciones o ajustes recientes?
¿El equipo trabaja dentro de su capacidad y de sus parámetros validados?
¿Hay desgaste, vibración, fugas o temperaturas anormales?
¿El problema aparece en todos los equipos iguales o solo en uno?
¿Se cambió algún componente, programa o receta?

Mano de obra. Las personas que operan, inspeccionan, mantienen o supervisan el proceso. Aquí conviene pensar en las condiciones que el sistema les da, no en las personas como culpables.

¿La persona tiene la competencia necesaria y se evaluó?
¿Las instrucciones son claras, están disponibles y se pueden cumplir en la práctica?
¿Hay carga de trabajo, fatiga, rotación o turnos que influyan?
¿El problema aparece con todas las personas o solo con algunas? ¿Qué hacen distinto?
¿La persona sabía que lo que hacía producía el problema?

Métodos. Procedimientos, instrucciones de trabajo, parámetros de proceso, planes de control, secuencias de arranque y cambio de formato.

¿Existe un método escrito? ¿Refleja lo que realmente se hace?
¿El método cubre todas las condiciones (arranques, paros, cambios de producto, fallas de energía)?
¿Se cambió el método recientemente? ¿Se evaluó el cambio?
¿Hay métodos distintos entre turnos o plantas para la misma tarea?

Medición. Instrumentos, métodos de ensayo, planes de muestreo, criterios de aceptación y la forma de registrar datos.

¿El instrumento está calibrado y es adecuado para la tolerancia que se mide?
¿El método de ensayo es repetible y reproducible entre analistas?
¿El plan de muestreo es suficiente para detectar el defecto con la frecuencia con que aparece?
¿El criterio de aceptación es claro o depende del juicio de quien inspecciona?
¿Los datos se registran a tiempo y sin transcripciones que introduzcan errores?

Para profundizar en cómo los datos de medición se convierten en información sobre la estabilidad del proceso, puedes revisar mi publicación sobre estrategia de control de proceso con Cp y Cpk.

Medio ambiente. Las condiciones físicas del lugar donde ocurre el proceso.

¿Influyen la temperatura, la humedad, el polvo, la iluminación, el ruido o la vibración?
¿El problema varía con la época del año, la hora del día o el clima?
¿Hay fuentes de contaminación cercanas (obras, plagas, otras líneas)?
¿Cambió algo en las instalaciones?

Una aclaración respecto a la versión anterior de este artículo: allí incluí la cultura organizacional dentro de «Medio ambiente». Hoy prefiero ubicarla en una categoría propia de Dirección (la M de Management del modelo 8M) o, si se trabaja con 6M, tratarla como causa sistémica dentro de «Métodos» o «Mano de obra». Mezclar la temperatura de la nave con las prioridades que transmite la gerencia en una misma espina dificulta el análisis, porque son causas de naturaleza muy distinta y se atienden con acciones muy distintas.

3.4 Adaptar las categorías a servicios y procesos administrativos

En procesos de servicios, logística, compras o tecnología de la información, las M de manufactura pueden quedar forzadas. En la primera versión de este artículo, por ejemplo, en un caso de logística anoté «Materiales: no aplicable». Fue un error: en un proceso de información, el material son los datos de entrada, y muchísimos problemas nacen ahí.

Para estos procesos funcionan bien las siguientes equivalencias:

Categoría de manufactura	Equivalente en servicios o administración
Materiales	Datos de entrada, formularios, solicitudes, información del cliente
Maquinaria	Sistemas informáticos, ERP, equipos de cómputo, herramientas
Mano de obra	Personas, roles, competencias, carga de trabajo
Métodos	Políticas, procedimientos, flujos de aprobación
Medición	Indicadores, reportes, controles de conciliación
Medio ambiente	Entorno físico y organizacional, horarios, interrupciones

También existen modelos propios para servicios, como las 4P (políticas, procedimientos, personas y planta o instalaciones) o las 4S (entorno, proveedores, sistemas y habilidades). Lo importante no es el nombre, sino que las categorías cubran todas las fuentes de variación de tu proceso.

3.5 Cómo facilitar una buena sesión de Ishikawa

Escribe el problema definido en el paso cero en la cabeza del pescado, con los datos. No «defectos en línea 3», sino el enunciado completo.
Revisa con el equipo la tabla Es / No es. Cada causa que se proponga debe ser capaz de explicar por qué el problema aparece donde aparece y no donde no aparece.
Haz la lluvia de ideas por categoría, con un tiempo definido para cada una. Una técnica útil es pedir primero ideas individuales en notas adhesivas, en silencio, y después ponerlas en común. Así se evita que la persona con más jerarquía marque el rumbo.
Formula las causas como condiciones observables, no como juicios. «Temperatura del canal caliente por encima de 290 °C después de los paros» es verificable; «mal manejo del equipo» no lo es.
Desarrolla subcausas preguntando «¿qué provoca esto?» dentro de cada espina. Aquí el Ishikawa ya empieza a combinarse con los porqués.
No discutas todavía qué causa es la verdadera. El diagrama es una lista ordenada de hipótesis. La discusión viene después, con datos.
Fotografía o digitaliza el diagrama y adjúntalo al registro de la no conformidad.

3.6 Ventajas y limitaciones del Ishikawa

Ventajas:

Ofrece una estructura que obliga a mirar todas las fuentes de variación, no solo la más evidente.
Es visual y facilita el trabajo en equipo.
Deja evidencia ordenada del razonamiento del equipo.

Limitaciones:

Produce causas posibles, no causas comprobadas. Un diagrama lleno de ideas no demuestra nada por sí solo.
No muestra la relación entre causas ni su secuencia en el tiempo.
Si el problema está mal definido, el diagrama se llena de causas genéricas.
Puede convertirse en un ejercicio de forma: espinas llenas para el auditor, sin análisis real detrás.

Por eso el Ishikawa necesita complementarse con dos cosas: un paso de verificación con datos y una técnica que profundice en las causas que sí se comprueban. Ese es el papel de los 5 Por Qué.

4. El método de los 5 Por Qué

4.1 Origen

El método se atribuye a Sakichi Toyoda, fundador del grupo que daría origen a Toyota, y fue difundido por Taiichi Ohno como parte del Sistema de Producción Toyota. Ohno lo describía como la base del enfoque científico de Toyota: preguntar por qué cinco veces ante cada problema para que su naturaleza y su solución se vuelvan evidentes.

El ejemplo clásico que Ohno usaba para explicarlo es una máquina que se detiene. Se detuvo porque se fundió el fusible por una sobrecarga; hubo sobrecarga porque el cojinete no estaba bien lubricado; no estaba lubricado porque la bomba no bombeaba lo suficiente; la bomba no bombeaba porque su eje estaba desgastado; y el eje se desgastó porque no tenía un filtro y entraron virutas metálicas. Si el equipo se hubiera quedado en el primer porqué, habría cambiado el fusible y la máquina habría vuelto a detenerse. La solución real fue instalar el filtro.

Este ejemplo enseña algo que a veces se olvida: la cadena de porqués de Ohno es técnica y verificable. Cada respuesta se puede comprobar mirando la máquina. No dice «porque el operador no lubricó» ni «porque falta capacitación».

4.2 Cómo se aplica

Parte de un problema definido o de una causa ya verificada en el Ishikawa.
Pregunta por qué ocurre y responde con un hecho, no con una suposición. Si no sabes la respuesta, ve a buscarla al proceso: el gemba, el lugar donde ocurren las cosas.
Toma la respuesta como nuevo efecto y vuelve a preguntar por qué.
Repite hasta llegar a una causa que cumpla los criterios de parada (los veremos en el punto 4.4). Pueden ser tres porqués o pueden ser siete; el número cinco es una referencia, no una regla.
Verifica la cadena en sentido inverso con la prueba de «por lo tanto».
Define acciones que eliminen la causa encontrada.

4.3 Las reglas que hacen la diferencia

Estas reglas separan un análisis de porqués útil de uno decorativo:

Una causa por respuesta. Si la respuesta tiene un «y» o un «ni» («porque no hay sistema de conocimiento ni comunicación entre áreas»), en realidad hay dos causas y cada una merece su propia rama.
Cada respuesta debe ser verificable. Pregúntate: ¿cómo lo sé? ¿Qué evidencia tengo? Si la respuesta es «nos parece» o «seguramente», hay que comprobarlo antes de seguir.
No saltes pasos. Cada respuesta debe explicar directamente la anterior. Si de «el diámetro está fuera de especificación» saltas a «falta capacitación», te perdiste varios eslabones.
Habla del proceso, no de personas. «Juan no revisó» no es una causa; es una descripción. La pregunta siguiente es por qué el proceso permitió que no se revisara, o por qué revisar no era posible, práctico o claro.
No escribas soluciones disfrazadas de causas. «Falta de un sistema de alertas» suena a causa, pero en realidad es la solución que alguien ya tiene en mente. Formula la condición real: «el sistema no avisa cuando el respaldo falla».

4.4 ¿Cuándo detenerse?

Saber dónde parar es la parte más difícil del método. Si te detienes muy pronto, atiendes un síntoma; si sigues demasiado, terminas en causas tan generales («la naturaleza humana», «la economía del país») que no se pueden atender. Estos criterios ayudan:

Está bajo control de la organización. Puedes actuar sobre ella con tus propios recursos y autoridad.
Si se elimina, el problema no vuelve a ocurrir (o su probabilidad baja de forma importante).
Explica todos los hechos de la tabla Es / No es. Si tu causa raíz no explica por qué el problema solo aparece en ciertas cavidades o después de los paros, no es la causa completa.
Llegaste a un proceso del sistema de gestión que falló, no existe o está incompleto: control de cambios, mantenimiento, compras, competencia, diseño, planificación.
El siguiente porqué ya no aporta una acción distinta. Cuando la respuesta adicional no cambia lo que harías, probablemente ya llegaste.

4.5 La prueba de «por lo tanto»

Una vez escrita la cadena, léela al revés, desde la causa raíz hasta el problema, uniendo cada eslabón con «por lo tanto». Si la lectura tiene sentido lógico, la cadena es sólida. Si en algún punto suena forzada, hay un salto o una suposición.

Ejemplo: «El filtro no estaba instalado, por lo tanto entraron virutas en la bomba; por lo tanto el eje se desgastó; por lo tanto la bomba no bombeaba lo suficiente; por lo tanto el cojinete no se lubricaba; por lo tanto hubo sobrecarga y se fundió el fusible». Se lee de forma natural.

Ahora un contraejemplo tomado de la versión anterior de este artículo: «No hay respaldos actualizados, por lo tanto se pierden datos». No funciona. La falta de respaldo no causa la pérdida de datos; impide recuperarlos cuando se pierden por otra razón. Son dos problemas diferentes, con causas diferentes. Más adelante corrijo ese caso.

4.6 Más de un camino: el árbol de porqués

Una crítica muy citada al método, publicada por Alan J. Card en la revista BMJ Quality & Safety en 2017, señala que los 5 Por Qué tienden a llevar a una sola causa en una sola línea, cuando los problemas reales suelen tener varias causas que se combinan. La crítica es válida si el método se aplica como una cadena única.

La solución es permitir que la cadena se ramifique. Cuando una respuesta tiene dos causas posibles y ambas se verifican, se abren dos ramas, y cada una se sigue hasta su propia causa raíz. El resultado ya no es una línea, sino un árbol de porqués. En la práctica, la mayoría de los análisis serios terminan con dos o tres causas raíz y no con una sola.

4.7 Las tres pistas: ocurrencia, no detección y sistema

En la industria automotriz y en las exigencias de muchos clientes del sector de alimentos se popularizó una variante muy útil: aplicar los porqués en tres pistas paralelas.

Ocurrencia: ¿por qué ocurrió el problema?
No detección: ¿por qué no lo detectamos antes de que llegara al cliente (o a la siguiente etapa)?
Sistema: ¿por qué nuestro sistema de gestión permitió que existieran las dos condiciones anteriores?

Esta variante tiene un gran valor práctico. Muchas veces la causa de ocurrencia es técnica y difícil de eliminar por completo, mientras que la causa de no detección revela que el plan de control o de muestreo no estaba diseñado para ese riesgo. Y la pista del sistema suele llevar a los procesos de gestión que fallaron: control de cambios, análisis de riesgos, mantenimiento, competencia. Es ahí donde las acciones tienen efecto en más de un producto o línea.

Cuando un cliente o un organismo de certificación revisa un análisis de causa, una de las primeras cosas que mira es si el sitio explicó por qué el problema no se detectó. Si solo explicas la ocurrencia, el análisis queda incompleto.

4.8 Ventajas y limitaciones de los 5 Por Qué

Ventajas:

Es fácil de entender y no requiere software ni estadística.
Obliga a pasar del síntoma a las causas más profundas.
Bien aplicado, lleva a acciones sobre el sistema y no solo sobre el evento.

Limitaciones:

Es fácil de entender, pero difícil de hacer bien. Sin entrenamiento y sin un facilitador con criterio, tiende a producir cadenas con saltos lógicos o que terminan en la persona.
Depende del conocimiento del equipo: no puede encontrar una causa que nadie en la sala conoce o se atreve a mencionar.
Si se aplica como una sola cadena, ignora las causas múltiples.
Si las respuestas no se verifican, se convierte en una conversación de opiniones bien ordenadas.

En la versión anterior de este artículo afirmé que los 5 Por Qué se pueden aplicar «sin necesidad de formación especializada», y al final recomendaba capacitar al personal en ambos métodos. Las dos cosas no encajaban. La versión correcta es esta: el método se entiende en cinco minutos, pero aplicarlo bien requiere práctica, acompañamiento y retroalimentación.

5. El método combinado: amplitud con el Ishikawa, profundidad con los porqués

5.1 Por qué combinarlos

Cada herramienta compensa una debilidad de la otra. El Ishikawa da amplitud: obliga a mirar todas las fuentes de variación, pero se queda en el nivel de causas posibles. Los 5 Por Qué dan profundidad: llevan una causa hasta su origen en el sistema, pero por sí solos tienden a seguir el primer camino que se le ocurre al equipo.

Combinadas, y con un paso de verificación entre ambas, cubren las dos dimensiones. Conviene ser claros en algo: ninguna combinación de herramientas garantiza que se encuentren todas las causas. Lo que hace el método combinado es reducir mucho la probabilidad de quedarse con una causa superficial o equivocada.

5.2 El flujo completo en nueve pasos

En la versión anterior de esta publicación presenté dos listas de pasos que se repetían y no coincidían entre sí. Este es el flujo único que recomiendo:

Paso	Qué se hace	Herramientas	Resultado
1. Formar el equipo	Reunir a quienes conocen el proceso, el producto y los datos, con un facilitador.	—	Equipo de 4 a 7 personas.
2. Definir el problema	Describir el problema con datos, sin causas ni soluciones.	5W2H, Es / No es	Enunciado del problema.
3. Contener	Proteger al cliente mientras se investiga.	Segregación, inspección 100 %, bloqueo	Producto y proceso bajo control temporal.
4. Identificar causas posibles	Lluvia de ideas por categoría.	Ishikawa 6M	Lista ordenada de hipótesis.
5. Priorizar	Escoger qué hipótesis verificar primero.	Matriz de priorización, votación ponderada	Hipótesis a verificar.
6. Verificar	Comprobar con datos qué causas son reales.	Estratificación, Pareto, pruebas, revisión de registros	Causas verificadas (y descartadas).
7. Profundizar	Llevar cada causa verificada hasta su raíz, en tres pistas.	Árbol de porqués	Causas raíz.
8. Actuar	Definir acciones sobre cada causa raíz y extenderlas a procesos similares.	Plan de acción	Acciones con responsable, fecha y criterio de eficacia.
9. Verificar eficacia y estandarizar	Comprobar que el problema no volvió y actualizar documentos.	Indicadores, auditoría, control de cambios	Cierre con evidencia y lección aprendida.

Los pasos 5 y 6 son los que más se omiten y los que más valor agregan. Vale la pena detenernos en ellos.

5.3 Priorizar sin adivinar

Un diagrama de Ishikawa bien hecho puede tener 20 o 30 causas posibles. No todas se pueden verificar al mismo tiempo, y no tiene sentido verificar primero las más improbables. Para priorizar, el equipo puede calificar cada hipótesis con tres criterios simples, en una escala de 1 a 5:

Coherencia con los hechos: ¿explica lo que muestra la tabla Es / No es?
Evidencia disponible: ¿hay datos o señales que la apoyen?
Facilidad de verificación: ¿se puede comprobar rápido y con pocos recursos?

Las hipótesis con mayor puntaje se verifican primero. Este paso no reemplaza la verificación; solo ordena el trabajo.

Un detalle importante: la votación por mayoría (cada persona marca las causas que cree más probables) es útil para ordenar, pero no demuestra nada. He visto muchos registros donde la causa raíz es simplemente la más votada. Eso es una opinión colectiva, no una causa comprobada.

5.4 Verificar con datos

Verificar una causa significa obtener evidencia de que existe y de que produce el efecto. Las formas más comunes son:

Revisión de registros: bitácoras de producción, registros de mantenimiento, certificados de análisis de materias primas, historial de cambios.
Estratificación: separar los datos por turno, máquina, cavidad, lote, proveedor, operador o fecha para ver dónde se concentra el problema. Es una de las siete herramientas básicas y probablemente la más subestimada.
Diagrama de Pareto: ordenar las causas o tipos de defecto por frecuencia o impacto para identificar las pocas que explican la mayor parte del problema. Si te interesa el principio detrás de esta herramienta, lo comento en mi publicación sobre el principio 80/20.
Observación directa: ir al proceso y ver cómo se hace realmente la tarea, en el turno y las condiciones en que ocurre el problema.
Pruebas controladas: reproducir el problema activando la causa sospechosa, o hacerlo desaparecer eliminándola. Es la evidencia más fuerte.
Correlación: un diagrama de dispersión entre una variable de proceso y el defecto. Ojo: la correlación sugiere, pero no demuestra causalidad.

Cada causa del Ishikawa debe quedar marcada al final como verificada, descartada (con la evidencia que la descarta) o pendiente. Ese registro es muy valioso: si el problema regresa, el equipo sabe qué ya se descartó y por qué.

5.5 Un formato simple para documentar el análisis

No necesitas un software especial. Una hoja con estas secciones es suficiente para la mayoría de las no conformidades:

Enunciado del problema (5W2H) y tabla Es / No es.
Contención: qué se hizo, cuándo y con qué resultado.
Diagrama de Ishikawa (foto o archivo).
Tabla de verificación de hipótesis: causa, método de verificación, resultado, estado.
Árbol de porqués para cada causa verificada, con las tres pistas.
Plan de acción: acción, causa que atiende, responsable, fecha, criterio de eficacia.
Extensión horizontal: otros productos, líneas o plantas donde se aplica la acción.
Verificación de eficacia: indicador, periodo de seguimiento, resultado.
Documentos actualizados y lección aprendida.

6. Caso completo: puntos negros en preformas PET

Este caso es ilustrativo. Está construido a partir de situaciones típicas de la fabricación de envases plásticos para alimentos y bebidas, y los datos son ficticios. Lo desarrollo paso a paso porque la mejor forma de entender el método combinado es verlo aplicado de principio a fin.

6.1 El problema

Una planta fabrica preformas PET por inyección para un embotellador de agua purificada. A mediados de marzo, el cliente reporta, en su inspección de recepción, preformas de 21.5 g con puntos negros incrustados en la pared. Los puntos son partículas de material degradado (carbonizado) de entre 0.2 y 0.8 mm.

Para el cliente es un defecto crítico de apariencia y, además, lo trata como materia extraña, por lo que exige un análisis formal de causa y un plan de acciones correctivas. Para la planta, el evento se registra como no conformidad externa y, por la posible implicación de inocuidad, se escala al equipo de inocuidad.

Enunciado del problema (5W2H): del 1 al 15 de marzo, el 2.4 % de las preformas de 21.5 g producidas en la inyectora 3 con el molde de 32 cavidades presentó puntos negros visibles, frente a un histórico de 0.2 %. El defecto fue detectado por el cliente en su recepción; la inspección de la planta no lo detectó.

Tabla Es / No es:

Dimensión	Es	No es	Diferencia
Producto	Preforma 21.5 g	Preforma 28 g (misma máquina, otro molde)	El molde de 21.5 g es nuevo; se instaló en febrero.
Ubicación	Cavidades 3, 7, 12, 19 y 28	Las otras 27 cavidades	Cavidades alejadas de la entrada del canal caliente.
Momento	Primeras dos horas después de un paro de más de 30 minutos	Producción continua sin paros	Material retenido a alta temperatura durante el paro.
Tiempo	Desde el 1 de marzo	Antes de marzo	Coincide con el aumento de paros por falta de programa.
Detección	Inspección del cliente (100 % con visión artificial)	Inspección de la planta (muestreo cada 2 h, visual)	Diferente capacidad de detección.

6.2 Contención

Bloqueo en el sistema de todo el inventario de preformas de 21.5 g producido desde el 1 de marzo.
Inspección del 100 % del inventario bloqueado con mesa de luz y reinspección por muestreo ampliado.
Purga obligatoria y descarte de las primeras dos horas de producción después de cualquier paro, como medida temporal.
Comunicación al cliente con el plan de contención y las cantidades involucradas.
Evaluación del equipo de inocuidad sobre el tratamiento del producto, conforme al procedimiento de producto potencialmente no inocuo.

6.3 Ishikawa 6M

El equipo (supervisor de inyección, técnico de moldes, analista de calidad, técnico de mantenimiento, planificador y el coordinador del sistema de gestión como facilitador) construyó el siguiente diagrama:

Diagrama de Ishikawa 6M del caso de puntos negros en preformas PET

Categoría	Causas posibles
Materiales	Resina con contaminación de origen. Exceso de material reciclado molido. Humedad de la resina por secado insuficiente.
Maquinaria	Zonas muertas en el canal caliente del molde nuevo. Resistencias del canal caliente con sobretemperatura. Desgaste del husillo o de la válvula antirretorno.
Mano de obra	Personal nuevo en el turno nocturno. Diferente forma de hacer los arranques entre turnos.
Métodos	Instrucción de arranque sin purga después de paros largos. Parámetros del molde nuevo copiados del molde anterior. Paros frecuentes por cambios en el programa de producción.
Medición	Muestreo visual cada 2 h insuficiente para detectar defectos de baja frecuencia. Iluminación inadecuada en el punto de inspección. Criterio de aceptación sin tamaño mínimo de partícula.
Medio ambiente	Polvo en el área de alimentación de resina. Humedad ambiental alta en marzo.

6.4 Priorización y verificación

Con la tabla Es / No es a la vista, el equipo descartó rápidamente varias hipótesis: si la causa fuera la resina, el defecto aparecería en todas las cavidades y también en la preforma de 28 g, que usa el mismo lote de resina. Lo mismo para el polvo y la humedad ambiental. La tabla también muestra un matiz importante: dos de las causas verificadas (los paros frecuentes y el diseño del canal caliente con recorridos largos) son contribuyentes. Existen y hacen más probable el defecto, pero no lo producen si la temperatura y la purga son correctas.

Hipótesis	Cómo se verificó	Resultado	Estado
Contaminación de la resina	Análisis del lote; comparación con preforma de 28 g del mismo lote	Sin defectos en 28 g; resina conforme	Descartada
Exceso de reciclado molido	Revisión de registros de dosificación	Proporción dentro de lo establecido	Descartada
Secado insuficiente	Registro de punto de rocío del secador	Dentro de parámetros	Descartada
Zonas muertas en el canal caliente	Revisión del diseño del molde con el proveedor; inspección de las boquillas de las cavidades afectadas	Las cavidades afectadas tienen recorridos más largos; se encontró material degradado acumulado	Verificada (contribuyente)
Desgaste del husillo o de la válvula antirretorno	Medición en el mantenimiento programado	Dentro de tolerancia; además, el desgaste afectaría a ambos moldes	Descartada
Sobretemperatura en resistencias	Registro de temperaturas por zona	Dos zonas 15 °C por encima del valor recomendado por el fabricante del molde	Verificada
Arranque sin purga después de paros largos	Prueba controlada: paro de 45 min con y sin purga	Sin purga: 3.1 % de defecto; con purga: 0.3 %	Verificada
Parámetros copiados del molde anterior	Comparación de hoja de parámetros con la ficha del fabricante del molde	Se copiaron del molde anterior; no se consultó la ficha del nuevo	Verificada
Paros frecuentes por cambios de programa	Revisión del registro de paros	Los paros de más de 30 minutos se duplicaron desde marzo; por sí solos no producen el defecto si se purga y la temperatura es correcta	Verificada (contribuyente)
Personal nuevo y arranques distintos entre turnos	Estratificación de defectos por turno y observación de arranques	Sin diferencia significativa entre turnos	Descartada
Iluminación del punto de inspección	Medición de iluminancia	Dentro del nivel definido para inspección visual	Descartada
Polvo y humedad ambiental	Comparación con la preforma de 28 g, producida en el mismo entorno	Sin defecto en 28 g	Descartada
Muestreo insuficiente	Cálculo de probabilidad de detección con el plan vigente	Con 2.4 % concentrado después de paros, el muestreo cada 2 h tenía baja probabilidad de detectarlo	Verificada
Criterio de aceptación ambiguo	Revisión de la especificación	No define tamaño mínimo de partícula	Verificada

Observa lo que pasó con «Personal nuevo en el turno nocturno». Era la hipótesis que varios miembros del equipo daban por segura al inicio. La estratificación mostró que el defecto se repartía igual entre turnos. Sin el paso de verificación, este análisis habría terminado en «capacitar al personal del turno nocturno», y el problema habría continuado.

6.5 Árbol de porqués en tres pistas

Pista 1 — Ocurrencia: ¿por qué aparecen puntos negros?

¿Por qué aparecen puntos negros en las preformas? Porque se desprenden partículas de PET degradado del canal caliente y pasan a la cavidad.
¿Por qué se degrada el PET en el canal caliente? Porque el material queda expuesto a temperatura excesiva durante más tiempo del que tolera, en las zonas de recorrido más largo.
¿Por qué queda expuesto a temperatura excesiva? Aquí el árbol se abre en dos ramas, porque la verificación confirmó dos causas:
- Rama A: porque dos zonas del canal caliente trabajan 15 °C por encima de la temperatura recomendada por el fabricante del molde.
- Rama B: porque después de los paros de más de 30 minutos no se purga el material retenido antes de reanudar la producción.
¿Por qué ocurren las dos condiciones? Las dos ramas convergen: la hoja de parámetros (rama A) y la instrucción de arranque (rama B) se copiaron del molde anterior, que tenía otro diseño de canal caliente y no requería purga.
¿Por qué se copiaron del molde anterior? Porque la instalación del molde nuevo se trató como un cambio de herramienta de rutina y no como un cambio que requería validar parámetros.
¿Por qué se trató como rutina? Porque el procedimiento de control de cambios no incluye la sustitución de moldes por diseños distintos entre los cambios que requieren evaluación técnica y actualización de instrucciones.

Observa que esta pista necesitó seis porqués, no cinco: el número lo decide el criterio de parada, no la costumbre. Las causas contribuyentes (paros frecuentes y diseño del canal caliente) no forman parte de la cadena principal, pero no se ignoran: el diseño del canal caliente tiene su propia acción con el proveedor del molde, y los paros frecuentes se trasladaron a planificación como oportunidad de mejora.

Causa raíz de ocurrencia: el procedimiento de control de cambios no considera la introducción de moldes de diseño diferente como un cambio que requiere validación de parámetros y revisión de instrucciones de operación.

Pista 2 — No detección: ¿por qué la planta no detectó el defecto?

¿Por qué no se detectó el defecto en la planta? Porque el muestreo visual cada dos horas rara vez coincidía con las dos horas posteriores a un paro, que es cuando se concentra el defecto.
¿Por qué el muestreo no considera los arranques? Porque el plan de muestreo es de frecuencia fija y no define muestreos adicionales después de paros, arranques o cambios.
¿Por qué no los define? Porque el plan de control se elaboró a partir de la experiencia con defectos de distribución uniforme y no a partir de un análisis de los modos de falla del proceso de inyección.
¿Por qué no se hizo ese análisis? Porque el procedimiento para elaborar planes de control no exige considerar los momentos de mayor riesgo del proceso.

Causa raíz de no detección: el plan de control no se basa en el análisis de riesgos del proceso y no prevé inspección reforzada en arranques y después de paros. Como causa contribuyente, el criterio de aceptación no define el tamaño mínimo de partícula, lo que deja la decisión al juicio de cada inspector.

Pista 3 — Sistema: ¿por qué el sistema permitió ambas condiciones?

¿Por qué el sistema permitió instalar un molde nuevo sin validar parámetros ni actualizar el plan de control? Porque la evaluación del cambio la hizo solo el área de producción, sin participación de calidad ni del equipo de inocuidad.
¿Por qué solo participó producción? Porque el formato de control de cambios no define qué áreas deben evaluar cada tipo de cambio.
¿Por qué no lo define? Porque el formato se diseñó para cambios documentales y se extendió a cambios de proceso sin revisarlo.

Causa raíz sistémica: el proceso de gestión del cambio no define, por tipo de cambio, las áreas que deben evaluarlo ni los documentos que deben revisarse (parámetros, instrucciones, plan de control, análisis de peligros).

Prueba de «por lo tanto» (pista 1): el control de cambios no considera los moldes nuevos como cambio de proceso, por lo tanto el molde se instaló como rutina; por lo tanto se copiaron los parámetros del molde anterior; por lo tanto dos zonas trabajan con sobretemperatura (rama A) y no se purga después de los paros (rama B); por lo tanto el material queda expuesto a temperatura excesiva; por lo tanto el PET se degrada en el canal caliente; por lo tanto aparecen puntos negros en las preformas. La lectura se sostiene.

Si te interesa profundizar en cómo diseñar un buen proceso de gestión del cambio, lo desarrollo en mi publicación sobre control de cambios en sistemas de calidad e inocuidad alimentaria.

6.6 Plan de acción

Tipo	Acción	Causa que atiende	Criterio de eficacia
Corrección	Inspección 100 % y segregación del inventario afectado.	Efecto	Cero preformas defectuosas despachadas.
Acción correctiva técnica	Ajustar temperaturas por zona según la ficha del fabricante del molde y validar parámetros con una corrida de prueba.	Ocurrencia	Defecto ≤ 0.2 % en tres semanas de producción.
Acción correctiva técnica	Actualizar la instrucción de arranque con purga obligatoria después de paros de más de 30 minutos.	Ocurrencia	100 % de arranques con purga registrada en las verificaciones.
Acción correctiva técnica	Limpieza del canal caliente y revisión con el proveedor del molde sobre la modificación de las zonas de recorrido largo.	Ocurrencia	Sin acumulación de material degradado en la siguiente inspección.
Acción correctiva de detección	Incluir en el plan de control muestreo reforzado en arranques y después de paros; definir tamaño mínimo de partícula en el criterio de aceptación.	No detección	Plan aprobado y aplicado; concordancia entre inspectores verificada.
Acción correctiva sistémica	Modificar el procedimiento y el formato de control de cambios: incluir moldes nuevos o de diseño distinto como cambio de proceso y definir áreas evaluadoras y documentos a revisar por tipo de cambio.	Sistema	Siguiente cambio de molde evaluado con el formato nuevo y con participación de calidad e inocuidad.
Extensión horizontal	Revisar los moldes instalados en el último año en todas las inyectoras para confirmar que sus parámetros provienen de la ficha del fabricante.	Sistema	Revisión completa con evidencia.

Observa que el plan no incluye «capacitar al personal» como acción principal. La capacitación aparece, desde luego, cuando se actualiza la instrucción de arranque, pero como consecuencia de un cambio en el método, no como la respuesta a la causa raíz.

6.7 Verificación de eficacia y cierre

El equipo definió un periodo de seguimiento de tres semanas de producción después de implementar las acciones técnicas, con estratificación de los defectos por cavidad y por momento (continuo o arranque). Además, programó una verificación en la siguiente auditoría interna del proceso de control de cambios.

El cierre se documentó con: los datos de defecto antes y después, las instrucciones y el plan de control actualizados, el formato de control de cambios en su nueva versión y la evidencia de la revisión de los demás moldes. La lección aprendida se compartió con las otras plantas del grupo.

7. Revisando cuatro ejemplos clásicos: dónde falla el razonamiento

La versión anterior de esta publicación tenía varios ejemplos que, revisados con más cuidado, contenían justo los errores que esta guía busca evitar. En lugar de borrarlos, me pareció más útil mostrar dónde estaba el problema y cómo se corrige. Es un buen ejercicio para entrenar el ojo.

7.1 Retrasos en proyectos de software: la causa raíz que no salía de la cadena

Cadena original (resumida): hay retrasos porque los desarrollos no se terminan a tiempo; porque hay cambios frecuentes en los requisitos; porque no se define el alcance al inicio; porque no se hace una recopilación exhaustiva de requisitos; porque el equipo de ventas no involucra al equipo técnico en las reuniones iniciales.

Causa raíz original: «falta de comunicación y colaboración entre ventas y el equipo técnico».

Qué falla: la causa raíz enunciada no es la respuesta del último porqué, sino una generalización de ella. Además, «falta de comunicación» es tan amplia que no orienta una acción concreta. La cadena se detuvo en la conducta de un área («ventas no involucra») sin preguntar por qué el proceso lo permite.

Cadena corregida (último tramo):

¿Por qué ventas no involucra al equipo técnico en las reuniones iniciales? Porque el proceso comercial no define la participación técnica como requisito para aceptar un proyecto.
¿Por qué no lo define? Porque el procedimiento de revisión de requisitos del cliente solo pide la aprobación de precio y plazo, no la validación de la factibilidad técnica.

Causa raíz corregida: el procedimiento de revisión de requisitos no exige validación técnica del alcance antes de comprometer plazos con el cliente. Una causa así lleva a una acción concreta: modificar el procedimiento y el formato de aceptación de proyectos. Este caso, por cierto, encaja con lo que ISO 9001 pide sobre la revisión de los requisitos para los productos y servicios (apartado 8.2.3 en la edición 2015).

7.2 Pureza en productos farmacéuticos: el atajo de la capacitación

Cadena original (resumida): no se siguen los protocolos de limpieza porque el personal no los considera críticos; porque no fue capacitado; porque el programa de formación no incluye el tema; porque no se actualiza; porque no hay un responsable designado.

Qué falla:

El primer porqué da por hecho lo que hay que demostrar. Antes de preguntar por qué no se siguen los protocolos, hay que verificar que efectivamente no se siguen y que esa es la causa del problema de pureza. En el Ishikawa había al menos otras nueve causas posibles (materias primas, calibración, contaminación cruzada, control ambiental) que nunca se verificaron.
La cadena termina en la formación, que es la causa raíz más frecuente y, a la vez, la que más cuestionan los auditores. La capacitación casi nunca es la causa raíz por sí sola: si una persona capacitada puede cometer el mismo error, el problema está en otro lugar.
La calibración de instrumentos estaba clasificada en «Maquinaria», cuando corresponde a «Medición».

Cómo se corrige:

Verificar primero, con registros de limpieza, resultados de análisis y estratificación por equipo, sala y lote, qué causas explican el aumento de lotes fuera de especificación.
Si se confirma que la limpieza es una causa, ir al lugar y observar cómo se hace realmente. Preguntar: ¿el procedimiento es claro? ¿Se puede cumplir en el tiempo disponible? ¿Existe una verificación de la limpieza antes de liberar el equipo?
Llevar la cadena al proceso que falló. Por ejemplo: «la limpieza se libera sin verificación objetiva (hisopado o inspección) porque el procedimiento no define criterios de aceptación de limpieza para el cambio de producto».

La causa raíz corregida apunta al diseño del proceso de limpieza y a su verificación, no solo al programa de formación. En un sector regulado como el farmacéutico, además, este análisis se enmarca en el sistema de desviaciones y CAPA, con exigencias propias de documentación.

Si quieres profundizar en por qué la capacitación rara vez resuelve un problema por sí sola, te recomiendo mi guía sobre detección de necesidades de capacitación (DNC).

7.3 Fallas en la gestión de datos de una empresa de logística: dos problemas en uno

Cadena original (resumida): se pierden datos porque no hay respaldos actualizados; porque el respaldo automático no funciona; porque el software está desactualizado; porque no hay un plan de mantenimiento; porque no se asignaron recursos en el presupuesto.

Qué falla:

El problema contenía dos síntomas (pérdida de datos y errores en el seguimiento de envíos) y solo se analizó uno.
Error lógico en el primer porqué: la falta de respaldo no causa la pérdida de datos; impide recuperarlos. Es una causa de la consecuencia, no de la ocurrencia.
«Materiales: no aplicable». En un proceso de información, los datos de entrada son el material. Errores de captura, formatos inconsistentes o integraciones entre sistemas son causas muy probables de errores de seguimiento.
Terminar en «no hubo presupuesto» es aceptable solo si se pregunta por qué no se presupuestó. Casi siempre hay detrás un proceso de planificación que no consideró el riesgo.

Cómo se corrige: separar los dos problemas y analizar cada uno con sus tres pistas.

Pérdida de datos — ocurrencia: ¿por qué se pierden datos? Por ejemplo, porque el servidor se apaga sin protección ante cortes de energía y se corrompe la base de datos.
Pérdida de datos — no recuperación: ¿por qué no se pudieron recuperar? Porque el respaldo automático falló sin que nadie se enterara, ya que no existe una alerta ni una verificación periódica de restauración.
Sistema: ¿por qué el sistema lo permitió? Porque la gestión de riesgos de tecnología no incluyó los sistemas de seguimiento de envíos como críticos, y por eso no tenían plan de continuidad ni presupuesto de mantenimiento.

El resultado son varias causas raíz, cada una con su acción, en lugar de una sola cadena que mezclaba consecuencias con causas. Para quien quiera abordar el tema de los sistemas críticos y la continuidad, desarrollé una guía para implementar un sistema de gestión de continuidad del negocio.

7.4 Plazos incumplidos en construcción: la causa doble

Cadena original (último tramo): no se consultan experiencias pasadas ni a expertos porque «no hay un sistema de gestión del conocimiento ni comunicación efectiva entre departamentos».

Qué falla: la respuesta contiene dos causas unidas por «ni». Cada una lleva a acciones diferentes y merece su propia rama. Además, en el Ishikawa, «problemas con permisos y regulaciones» estaba clasificado como «Medio ambiente», cuando en realidad es un tema de métodos (planificación de trámites) o de factores externos que el plan debe considerar como riesgo.

Cómo se corrige: abrir dos ramas.

Rama A: ¿por qué no se usan datos de proyectos anteriores para estimar tiempos? Porque los tiempos reales de los proyectos cerrados no se registran de forma comparable. ¿Por qué? Porque el cierre de proyecto no incluye una revisión de lecciones aprendidas con datos de duración por actividad.
Rama B: ¿por qué la planificación no se coordina con las áreas que ejecutan? Porque el procedimiento de planificación lo elabora una sola área y no exige validación del cronograma con compras, ingeniería y obra.

Dos causas raíz, dos acciones concretas, y ninguna de ellas es «mejorar la comunicación».

7.5 Lo que tienen en común estos errores

Si miras los cuatro casos juntos, aparecen los mismos patrones: causas supuestas en lugar de verificadas, saltos lógicos, respuestas con dos causas, generalizaciones que no orientan acciones y cadenas que terminan en personas o áreas en lugar de procesos. Son los mismos patrones que veo con más frecuencia en las auditorías, y por eso les dedico la siguiente sección.

8. Errores frecuentes y cómo los ve un auditor

Durante años revisé análisis de causa desde los dos lados: como responsable de responderlos y como auditor que debía evaluarlos. Estos son los errores que más se repiten y la pregunta que suele hacer el auditor cuando los encuentra.

Error	Cómo se ve en el registro	Lo que pregunta el auditor	Cómo evitarlo
Error humano como causa raíz	«El operador olvidó…», «descuido del personal».	¿Por qué el proceso permite que un olvido llegue al cliente?	Preguntar por qué la tarea depende solo de la memoria o la atención. Buscar barreras: listas de verificación, dispositivos a prueba de error (poka-yoke), verificaciones independientes.
Falta de capacitación	«Se capacitará al personal».	Si otra persona capacitada comete el mismo error, ¿qué cambia?	Verificar si la persona sabía hacerlo. Si sabía, la causa está en otro lado. Si no sabía, preguntar por qué el sistema permitió que estuviera en el puesto.
Causa no verificada	La causa raíz coincide con la primera idea del Ishikawa.	¿Qué evidencia tiene de que esta es la causa?	Registrar la verificación de cada hipótesis.
Saltos lógicos	De un efecto técnico se pasa a una causa organizacional sin pasos intermedios.	¿Cómo se relaciona esto con lo anterior?	Aplicar la prueba de «por lo tanto».
Dos causas en una respuesta	«Por falta de X y de Y».	¿Cuál de las dos produce el problema?	Abrir una rama por cada causa.
Solución disfrazada de causa	«Falta de un sistema de…».	¿Cuál es la condición real que falla?	Formular la condición observable, no la ausencia de la solución.
Solo pista de ocurrencia	No se explica por qué no se detectó.	¿Por qué el control no lo detectó?	Analizar las tres pistas.
Corrección en lugar de acción correctiva	«Se reprocesó el lote» como acción correctiva.	¿Qué evita que vuelva a pasar?	Separar corrección, contención y acción correctiva.
Causas fuera de control	«El proveedor», «el clima», «el cliente cambió el pedido».	¿Por qué su sistema no estaba preparado para esa condición?	Llevar la cadena hasta un proceso propio: evaluación de proveedores, planificación, gestión de riesgos.
Acción sin criterio de eficacia	«Se revisará el procedimiento», sin fecha ni indicador.	¿Cómo sabrá que funcionó?	Definir un indicador, un periodo y una meta.
Sin extensión horizontal	La acción se aplica solo a la línea afectada.	¿Existe la misma condición en otros procesos?	Revisar productos, líneas o plantas similares.
Cierre prematuro	La acción se cierra el mismo día en que se implementa.	¿Cómo verificó que fue eficaz?	Separar la fecha de implementación de la fecha de verificación de eficacia.

Un comentario adicional sobre el «error humano». Las personas se equivocan, y eso no va a cambiar. Un sistema de gestión maduro no busca personas que no se equivoquen; diseña procesos donde un error no se convierta en un defecto, o donde se detecte antes de llegar al cliente. Cuando un análisis termina en «el operador no siguió el procedimiento», todavía faltan al menos dos porqués: por qué no lo siguió (¿era claro?, ¿era posible?, ¿era la práctica habitual?) y por qué el sistema no lo detectó.

Esto se conecta con algo que he venido trabajando en mis publicaciones sobre cultura de calidad e inocuidad: si cada análisis de causa termina señalando a una persona, el mensaje que recibe la organización es que reportar problemas trae consecuencias. Y entonces los problemas se dejan de reportar.

9. Del análisis a la acción: plan, eficacia y estandarización

9.1 Acciones que atacan la causa, no el síntoma

Las acciones tienen distinta fuerza. De mayor a menor efecto, una jerarquía útil es:

Eliminar la causa mediante un cambio de diseño del producto, del equipo o del proceso.
Hacer imposible el error con dispositivos a prueba de error, bloqueos o automatización.
Detectar el error antes de que se convierta en defecto o llegue al cliente: sensores, verificaciones, inspección reforzada en los momentos de riesgo.
Estandarizar mediante instrucciones, listas de verificación y ayudas visuales.
Capacitar y sensibilizar.

No significa que las acciones de los niveles 4 y 5 no sirvan: casi siempre acompañan a las demás. Pero un plan compuesto solo por «actualizar el procedimiento» y «capacitar al personal» difícilmente evitará que el problema se repita.

9.2 Cómo escribir una buena acción

Cada acción debe responder: qué se hará, qué causa raíz atiende, quién es responsable, cuándo se implementará y cómo se verificará su eficacia. Una acción como «mejorar el control de cambios» no cumple ninguna de esas condiciones. «Modificar el procedimiento de control de cambios para incluir los moldes de diseño distinto como cambio de proceso, con evaluación obligatoria de calidad e inocuidad; responsable: coordinador del sistema de gestión; fecha: 30 de abril; eficacia: el siguiente cambio de molde se evalúa con el nuevo formato» sí las cumple.

9.3 Verificar la eficacia

Implementar una acción no es lo mismo que comprobar que funcionó. ISO 9001 exige revisar la eficacia de las acciones correctivas, y esa revisión requiere:

Un indicador relacionado con el problema original (porcentaje de defecto, número de quejas, resultados de verificación).
Un periodo de seguimiento suficiente para que el problema, si sigue presente, tenga oportunidad de aparecer. Si el defecto ocurría una vez al mes, revisar una semana no demuestra nada.
Una meta definida desde el inicio.
Una decisión documentada: eficaz, no eficaz (y se reabre el análisis) o eficaz parcialmente.

Si la acción no fue eficaz, la conclusión no es «hay que insistir». Es que la causa raíz identificada era incorrecta o incompleta, y hay que volver al análisis con lo aprendido.

9.4 Estandarizar y aprender

El cierre del análisis incluye actualizar los documentos afectados (instrucciones, planes de control, especificaciones, análisis de peligros, matrices de riesgo) mediante el proceso de control de cambios, y registrar la lección aprendida de forma que otras áreas la puedan consultar. También conviene revisar si los riesgos y oportunidades del sistema deben actualizarse; ISO 9001 lo pide expresamente en el apartado 10.2.

Una buena práctica es revisar periódicamente, en la revisión por la dirección o en los comités de calidad e inocuidad, las no conformidades recurrentes. Si un mismo problema vuelve, la pregunta no es solo técnica: es por qué el análisis anterior no llegó a la causa.

10. Cuándo el método se queda corto

El método combinado funciona muy bien para la mayoría de las no conformidades de un sistema de gestión. Hay situaciones, sin embargo, en las que conviene usar metodologías más estructuradas:

Problemas complejos o recurrentes con impacto en el cliente: la metodología 8D (ocho disciplinas), muy usada en la industria automotriz y cada vez más exigida por clientes de otros sectores, integra el trabajo en equipo, la contención, el análisis de causas (con Ishikawa y porqués), la verificación de acciones y el reconocimiento al equipo.
Problemas de mejora con enfoque de gestión: el informe A3 de Toyota resume en una sola hoja el contexto, la situación actual, el análisis, las contramedidas y el seguimiento. Es excelente para comunicar el análisis a la dirección.
Fallas de equipos o sistemas con múltiples causas combinadas: el análisis de árbol de fallas representa con lógica «y / o» cómo distintas fallas se combinan para producir un evento.
Accidentes e incidentes graves: el análisis de barreras y otros métodos de investigación de incidentes ayudan a entender qué barreras fallaron y por qué, algo que los porqués lineales no capturan bien.
Problemas con alta variabilidad o muchas variables de proceso: las herramientas estadísticas (diseño de experimentos, análisis de regresión, estudios de capacidad) son necesarias cuando la causa no se puede encontrar con observación y lógica.

El Ishikawa y los 5 Por Qué no compiten con estas metodologías; suelen estar dentro de ellas. Una 8D, por ejemplo, casi siempre usa ambos en su disciplina de análisis de causa.

11. Lista de verificación para revisar un análisis de causa

Antes de dar por cerrado un análisis, o al revisarlo como auditor interno, estas preguntas ayudan a detectar debilidades:

¿El problema está definido con datos, sin causas ni soluciones en el enunciado?
¿Se hizo una tabla Es / No es o una comparación equivalente?
¿Se aplicaron acciones de contención y se verificó su resultado?
¿El Ishikawa cubre todas las categorías relevantes, incluida la medición?
¿Cada causa posible quedó marcada como verificada, descartada o pendiente, con evidencia?
¿Los porqués parten de causas verificadas?
¿Cada respuesta contiene una sola causa y es verificable?
¿La cadena pasa la prueba de «por lo tanto»?
¿Se analizaron las pistas de ocurrencia, no detección y sistema?
¿Las causas raíz están bajo control de la organización y explican todos los hechos?
¿Alguna causa raíz es «error humano» o «falta de capacitación» sin más análisis?
¿Cada acción atiende una causa raíz identificada?
¿Hay acciones de los niveles superiores de la jerarquía (eliminar, hacer imposible, detectar)?
¿Cada acción tiene responsable, fecha y criterio de eficacia?
¿Se evaluó la extensión horizontal a otros productos, líneas o plantas?
¿Se actualizaron los documentos mediante el control de cambios?
¿Se verificó la eficacia después de un periodo suficiente?
¿Se registró y compartió la lección aprendida?

Si la respuesta a la mayoría de estas preguntas es «sí», el análisis probablemente resistirá una auditoría y, lo más importante, el problema no volverá.

12. Preguntas frecuentes

¿Siempre tienen que ser cinco porqués? No. El cinco es una referencia para no detenerse demasiado pronto. Algunos problemas llegan a su causa raíz con tres porqués y otros necesitan siete. Lo que importa son los criterios de parada, no el número.

¿Son 5M o 6M? Las dos versiones existen. Para calidad e inocuidad recomiendo las 6M, porque incluyen la medición, que es una fuente frecuente de problemas. Lo importante es que las categorías cubran todas las fuentes de variación del proceso.

¿Puedo usar solo los 5 Por Qué, sin Ishikawa? Para problemas sencillos, con una causa evidente y verificable, sí. Para problemas con varias causas posibles, usar solo los porqués aumenta el riesgo de seguir el primer camino que se le ocurra al equipo.

¿Cuántas causas raíz debe tener un análisis? Las que existan. Es frecuente encontrar una causa raíz por cada pista (ocurrencia, no detección y sistema), y a veces más de una en cada pista. Un análisis con una sola causa raíz no es necesariamente incorrecto, pero conviene preguntarse si se exploraron todas las ramas.

¿La capacitación nunca puede ser causa raíz? Puede serlo, pero es poco frecuente y hay que demostrarlo. Si la persona no sabía hacer la tarea, la siguiente pregunta es por qué el sistema le permitió hacerla sin la competencia necesaria. Esa respuesta suele llevar al proceso de gestión de competencias, de inducción o de asignación de puestos, que es donde está la causa raíz real.

¿Cuánto tiempo debe tomar un análisis de causa? Depende de la complejidad. Una no conformidad menor puede analizarse en una sesión de una hora. Un problema con impacto en el cliente puede requerir varias semanas, sobre todo por el tiempo que toma verificar causas con datos. Lo que no debe pasar es que la urgencia por cerrar lleve a saltarse la verificación.

¿Qué hago si el equipo no se pone de acuerdo sobre la causa? Eso indica que faltan datos. En lugar de resolver por votación o por jerarquía, define qué evidencia permitiría distinguir entre las hipótesis en discusión y ve a buscarla.

¿Cómo registro el análisis para la auditoría? Con evidencia de cada paso: enunciado, contención, diagrama, verificación de hipótesis, porqués, acciones, eficacia. El auditor no busca un formato específico; busca poder seguir el razonamiento desde el problema hasta la acción y comprobar que se sostiene.

Conclusión

Las 5M (o 6M) y los 5 Por Qué siguen siendo, después de décadas, dos de las herramientas más poderosas para resolver problemas en cualquier organización. Su fuerza no está en el diagrama ni en el número de preguntas, sino en la disciplina con que se aplican: definir bien el problema, mirar todas las fuentes de variación, verificar con datos antes de concluir, profundizar en las tres pistas, llegar a los procesos del sistema que fallaron y comprobar que las acciones funcionaron.

Si me pidieran resumir esta guía en una sola idea, sería esta: una causa raíz no se elige, se demuestra. Cuando un equipo adopta esa idea, los análisis dejan de ser un trámite para la auditoría y se convierten en lo que siempre debieron ser: la forma en que una organización aprende de sus problemas.

Referencias

Ishikawa, K. (1986). Guide to Quality Control (2.ª ed.). Asian Productivity Organization.
Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
Card, A. J. (2017). The problem with «5 whys». BMJ Quality & Safety, 26(8), 671–677.
Kepner, C. H. y Tregoe, B. B. (1981). The New Rational Manager. Princeton Research Press.
ISO 9000:2015. Sistemas de gestión de la calidad — Fundamentos y vocabulario.
ISO 9001:2015 e ISO 9001:2026. Sistemas de gestión de la calidad — Requisitos, apartado 10.2.
ISO 22000:2018. Sistemas de gestión de la inocuidad de los alimentos — Requisitos para cualquier organización en la cadena alimentaria, apartados 8.9 y 10.1.
FSSC 22000. Esquema de certificación, versión 7.

Sobre el autor

Llevo más de 23 años trabajando en sistemas integrados de gestión, pero con el tiempo descubrí que los sistemas más importantes están en las personas, no en los manuales. Soy Ing. Industrial y Máster en Sistemas Integrados de Gestión. Autor y podcast host de Microaprendizajes, donde exploro gestión, liderazgo y filosofía aplicada desde la práctica. Creador del Triángulo del Éxito Integral. Padre comprometido. Creo que la excelencia operativa y el desarrollo humano son el mismo camino visto desde ángulos distintos.