Los 5 Porqués no siempre encuentran la causa: el error que puede arruinar una investigación de incidentes

Respuesta directa: Los 5 Porqués son útiles para explorar una cadena causal simple, pero no alcanzan cuando el evento involucra decisiones latentes, barreras degradadas, múltiples interacciones o sistemas complejos. En investigación de incidentes, usarlos como única herramienta suele producir una “causa raíz” aparente, pero no verificable, y eso deja intactas las condiciones que permiten que el evento se repita.

El 23 de marzo de 2005, en Texas City, murieron 15 personas y 180 resultaron heridas en una explosión durante el arranque de una unidad de isomerización. El informe de Baker Panel mostró algo incómodo: el problema no fue una sola falla, sino una combinación de diseño, mantenimiento, alarmas, cultura operativa y decisiones gerenciales. Ahí está el punto: cuando un incidente tiene múltiples capas de degradación, buscar una causa con una técnica lineal puede convertirse en una trampa. Y esa trampa no es teórica; cuesta vidas, paradas de planta, demandas, sanciones regulatorias y reputación. API 754, OSHA PSM 1910.119, IEC 61511, ISO 45001 y las guías de CCPS existen justamente porque los eventos industriales serios rara vez obedecen a una sola causa simple.

Si tu organización investiga incidentes con el ritual de “preguntar cinco veces por qué” y luego redacta una causa como si eso cerrara el caso, tenés un problema de aprendizaje. En una refinería, una planta química, una terminal de gas o una operación de mantenimiento, la pregunta no es si hubo un error humano. La pregunta correcta es: ¿qué hizo el sistema para volver probable ese error? Cuando no respondés eso, terminás corrigiendo al operador, pero no al proceso.

Este artículo te muestra por qué los 5 Porqués fallan, cuándo sirven, cuándo no, y cómo construir una investigación de incidentes verificable, defensible y útil para la operación. No para llenar un formulario. Para evitar el próximo evento.

¿Qué son los 5 Porqués y por qué suenan tan bien?

Los 5 Porqués son una técnica de análisis causal simple: se formula una pregunta repetida de “¿por qué?” para profundizar desde un evento visible hasta una explicación más profunda. Nació en el enfoque de mejora continua de Toyota y puede ser útil para problemas relativamente acotados, con relaciones causales lineales y evidencia clara. El problema aparece cuando se la usa como si fuera un método completo de root cause analysis.

En su versión más básica, la lógica es atractiva porque obliga a no quedarse en el síntoma. Pero una investigación de incidentes industrial no es un ejercicio de curiosidad; es una disciplina de verificación. Una buena investigación no busca una respuesta rápida, busca una explicación robusta. Eso implica revisar hechos, barreras, condiciones del sistema, decisiones, competencia, supervisión, mantenimiento, diseño, gestión del cambio y desempeño organizacional.

La diferencia entre una definición formal y una definición operativa importa. Formalmente, la causa raíz se define como el factor subyacente que, si se elimina, previene la recurrencia. Operativamente, en planta, eso solo vale si esa afirmación se puede demostrar con evidencia, barreras y trazabilidad. Si no podés mostrar que cambiar ese factor realmente reduce el riesgo, entonces no encontraste una causa raíz: encontraste una hipótesis cómoda.

Definiciones operativas que sí sirven

• Evento: lo que ocurrió y puede describirse con hechos observables.
• Causa inmediata: la condición o acción que produjo el evento en ese momento.
• Causa contribuyente: factor que aumentó la probabilidad o severidad del evento.
• Decisión latente: elección previa de diseño, mantenimiento, capacitación o staffing que creó vulnerabilidad.
• Barra de defensa: elemento que debía prevenir, detectar o mitigar el evento y que falló o no existía.

Cuando investigás solo con 5 Porqués, casi siempre terminás muy arriba en la jerarquía causal. Por ejemplo: “se derramó producto porque la válvula estaba abierta; la válvula estaba abierta porque el operador se equivocó; se equivocó porque estaba cansado”. ¿Y después qué? ¿Capacitás al operador y listo? Si no revisaste alarmas, procedimientos, ergonomía, permisos de trabajo, supervisión, fatiga, MOC, entrenamiento y diseño de interfaz, tu investigación quedó corta.

¿Por qué los 5 Porqués no siempre encuentran la causa?

Porque los eventos industriales no suelen tener una sola línea causal. La realidad de una refinería, una planta de amoníaco o una operación de mantenimiento es sistémica: múltiples barreras interactúan, el contexto cambia, y el error humano emerge de condiciones normales de trabajo, no de defectos morales. Ahí, la técnica lineal se rompe.

OSHA PSM 1910.119 exige administrar procesos con sustancias altamente peligrosas mediante elementos como Process Hazard Analysis, capacitación, procedimientos operativos, integridad mecánica, gestión del cambio y auditorías. No pide una explicación rápida; pide un sistema capaz de controlar riesgo. API 754, por su parte, promueve indicadores de seguridad de procesos que permiten ver la degradación antes del accidente. IEC 61511 exige ciclo de vida de seguridad funcional, no intuición. Y ISO 45001 insiste en identificación de peligros, evaluación de riesgos y mejora continua con participación de trabajadores. Todo eso va en dirección opuesta a una investigación superficial.

Hay cuatro razones técnicas por las que los 5 Porqués fallan con frecuencia:

1. Linealizan sistemas no lineales. Un incidente suele emerger de la coincidencia de varias condiciones.
2. Favorecen sesgo de confirmación. El equipo elige la explicación que “suena bien”.
3. Premian la narrativa, no la evidencia. Se arma una historia, no un análisis.
4. Confunden evento con causa. La última acción humana visible absorbe toda la culpa.

El resultado es predecible: se implementa una acción que ataca el síntoma, baja el ruido interno, pero no cambia el riesgo. En el mejor de los casos, la organización aprende poco. En el peor, repite el evento con otro nombre.

Comparación técnica: 5 Porqués vs métodos robustos de investigación

Conclusión técnica: los 5 Porqués no son “malos”. Son insuficientes como método único. Sirven como herramienta de exploración, no como cierre de investigación.

¿Qué dice la industria sobre esto?

La evolución de la seguridad industrial lo dejó bastante claro. En los 70 y 80, muchas organizaciones se concentraban en la energía peligrosa y la conducta individual. Después de Bhopal 1984, Piper Alpha 1988, Texas City 2005 y Macondo 2010, la conversación cambió: el problema no era solo el error del operador, sino la forma en que el sistema producía condiciones para ese error.

CCPS ha insistido durante años en que los incidentes mayores nacen de la interacción entre hardware, software, humanos y organización. No alcanza con preguntar “qué pasó”; hay que preguntar “qué barreras fallaron, por qué fallaron y cómo sabemos que siguen funcionando”. Esa es la diferencia entre investigar para cerrar un caso e investigar para reducir el riesgo.

OSHA PSM 1910.119(j) sobre integridad mecánica, (e) sobre procesos, (f) sobre procedimientos operativos, (g) sobre capacitación, (l) sobre gestión del cambio y (m) sobre revisión previa al arranque, muestran que la prevención depende de controles múltiples. IEC 61511, en su lógica de seguridad funcional, exige especificar, validar y mantener las funciones instrumentadas de seguridad. ISO 45001, en su cláusula 10.2, pide investigar incidentes y acciones correctivas con enfoque en causas y no solo en consecuencias. Ninguno de estos marcos fue diseñado para que el investigador “adivine” la causa con cinco preguntas.

“Si tu investigación termina donde empieza la culpa, no aprendiste nada. Solo decoraste el mismo problema con lenguaje técnico.”

Y eso importa mucho más en operaciones de alto riesgo. Un error pequeño en mantenimiento de una bomba de carga, una derivación en permisos de trabajo en caliente, o una desviación en un procedimiento de aislamiento puede ser la diferencia entre un desvío operativo y una fatalidad. No es retórica; es física aplicada a sistemas sociotécnicos.

Tabla técnica: cuándo sirven y cuándo no los 5 Porqués

Casos reales y operativos: dónde se rompe la lógica lineal

Caso 1: refinería, arranque de unidad y una causa “demasiado cómoda”

En una refinería del Golfo de México, durante un arranque después de parada de mantenimiento, una sobrepresión en una línea auxiliar produjo una fuga de hidrocarburo liviano. El hallazgo inicial fue inmediato: la válvula de drenaje estaba en una posición incorrecta. El equipo aplicó 5 Porqués y llegó rápido a una respuesta familiar: “el operador no verificó la alineación”. Parecía suficiente. Era simple, barato y cerraba la conversación.

Pero el análisis posterior mostró otra cosa. El procedimiento tenía 18 pasos, 6 de ellos con cambios de estado críticos, y el diagrama no coincidía con la configuración física del sistema. Además, el permiso de trabajo había sido aprobado con una verificación parcial, la supervisión de turno estaba cubriendo dos unidades por reducción de dotación y el indicador de integridad de barreras de esa línea mostraba tres desviaciones previas en seis meses. Había además una alarma de alto nivel inhabilitada temporalmente por mantenimiento y no revalidada antes del arranque.

Consecuencia: 4 horas de pérdida operativa, 60 toneladas de producto fuera de especificación, 1 notificación regulatoria interna y una recomendación de paro parcial para inspección. Lección: la “causa” no era la mano del operador. El sistema había acumulado condiciones para que el error fuera probable.

La pregunta correcta no era “¿por qué se equivocó el operador?”, sino “¿qué permitió que un único desvío humano se convirtiera en liberación de energía peligrosa?”

Caso 2: mantenimiento en planta química, fatiga, bypass y datos que no perdonan

En una planta de amoníaco, un equipo de mantenimiento debía intervenir una bomba de recirculación durante un paro corto. La ventana era de 90 minutos. El procedimiento exigía bloqueo y etiquetado, prueba de cero energía y verificación cruzada. Sin embargo, hubo presión por devolver el equipo a servicio antes del cambio de turno. El técnico omitió documentar una prueba, y al reconectar, el equipo quedó con una condición insegura que derivó en fuga menor y exposición de dos personas a una nube de vapor.

Si la investigación se hubiera quedado en 5 Porqués, probablemente habría terminado en “falta de atención” o “apuro”. Pero el detalle operativo cambió el diagnóstico: el equipo llevaba 11 días con horas extra, la dotación de mantenimiento estaba 14% por debajo del plan, la lista de trabajos críticos tenía 23% de tareas vencidas y el supervisor llevaba dos turnos consecutivos sin descanso suficiente. Además, el permiso de bloqueo tenía un campo ambiguo sobre verificación secundaria y el LOTO no estaba físicamente aislado con candados por persona, sino con un arreglo de grupo débilmente supervisado.

Dato relevante: investigaciones de seguridad industrial muestran reiteradamente que la fatiga y la presión de tiempo elevan el riesgo de error. No porque la persona “quiera equivocarse”, sino porque el sistema reduce márgenes. En mantenimiento, eso se traduce en verificación incompleta, atajos y normalización de desviaciones.

Consecuencia: no hubo lesión registrable, pero sí 2 horas de parada, evacuación parcial y revisión de 41 permisos de trabajo similares. Lección: el incidente no fue solo “un error humano”; fue un fallo de control de trabajo.

Caso 3: organización que lo hizo bien y bajó el riesgo de repetición

Una planta petroquímica en Sudamérica tenía un patrón repetitivo de derrames pequeños en maniobras de transferencia. Durante un año registró 17 eventos menores y 4 desviaciones de alto potencial. En lugar de quedarse en la narrativa de “falta de cuidado”, la organización integró una metodología de investigación con barreras, verificación de competencia y seguimiento de acciones. Cada evento fue clasificado por severidad real y potencial usando criterios cercanos a API 754. Luego se identificaron las barreras degradadas: procedimientos largos, válvulas sin identificación visible, entrenamiento no práctico y supervisión centrada en producción.

Se aplicaron cambios concretos: rediseño de etiquetas, simplificación de pasos críticos, simulaciones de turno, revisión de competencia por observación en campo y un tablero semanal de barreras críticas. En 9 meses, los eventos repetitivos bajaron 62%, los hallazgos de desviación en rondas de supervisión aumentaron 38% al principio —lo cual fue positivo porque mostraba más detección— y después se estabilizaron con mejor calidad operativa. Lo importante no fue “investigar más”. Fue investigar mejor y cerrar el ciclo con cambios verificables.

Una organización madura no busca culpables rápidos; busca patrones que expliquen por qué el sistema toleró el desvío.

¿Cómo saber si tu organización está cayendo en el mismo error?

Hay señales muy claras. Si aparecen varias de estas, tu investigación de incidentes probablemente está demasiado apoyada en 5 Porqués o en variantes superficiales de análisis causal.

• Las causas raíz terminan casi siempre en “error humano”, “falta de atención” o “no siguió el procedimiento”.
• Las acciones correctivas son capacitaciones, charlas o recordatorios, pero no cambios en barreras o diseño.
• No se revisan condiciones latentes como staffing, fatiga, MOC, integridad mecánica o disponibilidad de alarmas.
• El mismo tipo de evento se repite cada 6-12 meses con distinto protagonista.
• Las investigaciones cierran rápido, pero el aprendizaje no se refleja en los indicadores de proceso.
• No hay trazabilidad entre hallazgo, acción y reducción del riesgo.

Preguntas de autoevaluación

1. ¿Podés demostrar con evidencia que tu “causa raíz” explica el evento y no solo lo describe?
2. ¿Tus acciones correctivas cambian una barrera crítica o solo intentan reforzar conducta?
3. ¿Los hallazgos se vinculan con riesgos mayores, no solo con el evento inmediato?
4. ¿Medís desempeño de barreras, no solo cantidad de incidentes?
5. ¿Las investigaciones incluyen operación, mantenimiento, ingeniería y supervisión?

Tabla de madurez de investigación de incidentes

Metodología verificable: cómo investigar sin caer en la trampa

Si querés evitar que los 5 Porqués arruinen una investigación, no los elimines por reflejo. Ubicalos en el lugar correcto y rodealos de un método más fuerte. Te propongo un enfoque en seis pasos, pensado para operaciones industriales de alto riesgo.

Paso 1: reconstruí hechos, no interpretaciones

Qué hacer: armá una línea de tiempo con hora, lugar, condición de equipo, actores, alarmas, permisos, clima operativo y secuencia de acciones. Separá hechos observables de opiniones.

Cómo verificar: cada afirmación debe tener fuente: registros de DCS, rondas, CCTV, bitácora, entrevistas, permisos, mantenimiento o instrumentación.

Error común: meter conclusiones desde el primer minuto. Si hacés eso, la investigación se contamina.

Paso 2: identificá barreras y su desempeño

Qué hacer: definí barreras preventivas, detectivas y mitigadoras. Preguntate cuál debía actuar, cuál falló y cuál estaba degradada.

Cómo verificar: usá evidencia de prueba, inspección, calibración, competencia o supervisión en campo.

Error común: listar barreras “teóricas” que en la práctica no existían o estaban fuera de servicio.

Paso 3: buscá causas contribuyentes y decisiones latentes

Qué hacer: explorá staffing, fatiga, MOC, calidad del procedimiento, interfaz hombre-máquina, diseño, presión de producción y cultura de escalamiento.

Cómo verificar: revisá tendencias, no un caso aislado. Mirá repeticiones, desvíos de turno y backlog de mantenimiento.

Error común: confundir comportamiento individual con diseño organizacional.

Paso 4: usá 5 Porqués solo como subherramienta

Qué hacer: aplicá la técnica para una hipótesis acotada, no para todo el incidente. Si la cadena deja de ser lineal o surgen bifurcaciones, frená y cambiate de método.

Cómo verificar: cada “por qué” debe estar respaldado por evidencia, no por consenso del equipo.

Error común: forzar cinco preguntas aunque la explicación ya quedó incompleta o haya múltiples causas.

Paso 5: convertí hallazgos en acciones que cambien riesgo

Qué hacer: priorizá acciones sobre diseño, barreras, competencia, mantenimiento y control operacional. Las capacitaciones solas no alcanzan.

Cómo verificar: cada acción debe tener responsable, plazo, criterio de cierre y métrica de eficacia.

Error común: cerrar acciones por “ejecución” sin probar si realmente redujeron el riesgo.

Paso 6: validá aprendizaje y eficacia

Qué hacer: revisá a 30, 90 y 180 días si el patrón cambió. Compará eventos, desviaciones y desempeño de barreras.

Cómo verificar: mirá indicadores leading, no solo lagging.

Error común: dar por resuelto algo porque no hubo lesión este mes.

Tabla de implementación

Quick wins en 30 días: ordenar plantillas de investigación, separar hechos de opiniones, incorporar revisión de barreras, exigir evidencia para cada causa y eliminar acciones cosméticas. Cambios estructurales en 6-12 meses: integrar API 754, tablero de barreras, mejora de competencia, control de MOC y validación sistemática de eficacia.

Aplicación práctica en turno, planta y organización

En el turno, la herramienta más útil no es una presentación; es una guía de campo corta y útil. Una tarjeta de investigación debería obligar al supervisor a registrar hora, condición de equipo, permiso, personal presente, alarmas activas, cambios recientes y barreras comprometidas. Si no existe ese mínimo, la investigación nace débil.

En planta, necesitás una matriz de barreras críticas. Esa matriz debe mostrar qué barrera protege qué escenario, cómo se verifica, quién la mantiene y cada cuánto se prueba. Sin eso, nadie sabe si el sistema está realmente protegido o solo está documentado.

En la organización, el cambio exige tres cosas: roles claros, indicadores de proceso y resistencia gestionada. Los roles no se mezclan: operación aporta contexto, mantenimiento aporta condición de activos, ingeniería aporta diseño, HSE facilita método y gerencia remueve obstáculos. Si todo cae en HSE, el aprendizaje se vuelve burocracia.

Indicadores recomendados

• Porcentaje de investigaciones con evidencia completa en 72 horas.
• Porcentaje de acciones que modifican barreras o diseño.
• Tasa de repetición del mismo tipo de evento en 6 meses.
• Tiempo promedio de cierre de acciones con verificación de eficacia.
• Número de barreras críticas con desempeño validado al día.

La resistencia al cambio aparece cuando la organización descubre que investigar bien obliga a mirar decisiones incómodas. Es normal. La clave no es pelear por narrativas; es mostrar datos. Cuando una planta ve que sus repetición de eventos baja después de cambiar barreras y no solo conductas, la conversación se ordena sola.

Preguntas frecuentes sobre Los 5 Porqués no siempre encuentran la causa

Las siguientes preguntas reflejan búsquedas reales y dudas comunes de profesionales que investigan incidentes en planta, mantenimiento y operaciones.

¿Los 5 Porqués sirven para investigar incidentes industriales?

Sí, pero solo como herramienta parcial. Funcionan mejor en problemas simples, con una relación causa-efecto clara y poca ambigüedad. En incidentes industriales complejos, donde intervienen barreras, decisiones latentes y múltiples áreas, usarlos como método único suele producir una explicación incompleta. Lo correcto es combinarlos con análisis de barreras, verificación de hechos y revisión sistémica.

¿Cuál es el error más común al usar los 5 Porqués en seguridad?

El error más común es detenerse en el comportamiento del operador y tratarlo como causa raíz. Eso suele esconder problemas de diseño, procedimiento, mantenimiento, supervisión o gestión del cambio. Cuando la investigación termina en “falta de atención”, casi siempre significa que no se profundizó en el sistema. El error humano es muchas veces una consecuencia del contexto organizacional.

¿Qué método es mejor que los 5 Porqués para incidentes graves?

No hay un único método universal, pero para incidentes graves conviene combinar reconstrucción factual, análisis de barreras, SCAT/TASC, Bowtie y revisión de decisiones latentes. En eventos de alto potencial, también ayuda un enfoque tipo AcciMap o un análisis de factores sistémicos. Lo importante no es el nombre de la herramienta, sino que permita verificar hechos, validar barreras y conectar el evento con el sistema.

¿Cómo sé si una causa raíz es realmente válida?

Una causa raíz válida debe cumplir tres condiciones: explicar el evento sin contradicciones, estar respaldada por evidencia y apuntar a un cambio que reduzca el riesgo. Si solo describe el evento o culpa a una persona, no es una causa raíz sólida. Además, debería poder sostenerse ante una revisión técnica independiente. Si no puede, probablemente sea una hipótesis débil.

¿Qué dice ISO 45001 sobre investigación de incidentes?

ISO 45001, especialmente en la cláusula 10.2, exige reaccionar ante incidentes y no conformidades, investigar, determinar causas y tomar acciones correctivas. La norma no promueve investigaciones superficiales; busca aprendizaje organizacional y mejora continua. En la práctica, eso implica revisar causas inmediatas y subyacentes, y verificar que las acciones implementadas realmente cambien el desempeño.

¿Por qué se repiten los mismos incidentes aunque se investiguen?

Porque muchas investigaciones terminan en acciones débiles, como capacitaciones o recordatorios, sin cambiar barreras, diseño o condiciones operativas. Si el sistema sigue generando la misma vulnerabilidad, el incidente se repetirá con otra persona o en otro momento. La repetición es una señal de que el aprendizaje fue formal, pero no operativo.

Cierre con perspectiva

La seguridad industrial está dejando atrás la era de la explicación rápida. Hoy el estándar real no es “cerrar investigaciones”, sino aprender más rápido que la energía del sistema. Eso exige pensar en barreras, decisiones latentes, desempeño de activos, competencia y disciplina operativa. Y exige aceptar algo incómodo: a veces el problema no está en la última persona que tocó el equipo, sino en todo lo que hizo posible que ese error fuera esperable.

Resumen ejecutivo:

• Los 5 Porqués no siempre encuentran la causa porque los incidentes industriales son sistémicos, no lineales.
• Su uso exclusivo favorece sesgo, culpa individual y acciones correctivas débiles.
• Las investigaciones robustas deben integrar hechos, barreras, decisiones latentes y verificación de eficacia.
• La madurez se nota cuando la organización cambia el riesgo, no solo el formulario.

La pregunta que debería incomodar a cualquier líder de operaciones es esta: si mañana ocurre el mismo incidente con otro nombre y otra persona, tu investigación actual lo habría prevenido? Si la respuesta es no, entonces no te faltan más “porqués”; te falta sistema. Este análisis forma parte del trabajo de WFS Academy sobre investigación de incidentes, disciplina operativa y seguridad de procesos. Si todavía medís aprendizaje por cierre administrativo y no por verificación en campo, es momento de revisar cómo estás investigando.

Contenido relacionado sugerido: investigación de incidentes, análisis causal, causas raíz, barreras críticas, seguridad de procesos, disciplina operativa, error humano, gestión del cambio.

Nota de contexto para la estrategia de contenidos: este tema se conecta naturalmente con programas de análisis causal, revisión de barreras y aprendizaje organizacional. Si tu organización ya invierte en seguridad, pero no ve descenso en la repetición de eventos, el problema puede estar en la calidad de la investigación, no en la cantidad de reportes.

CTA contextual: Si querés evaluar si tus investigaciones están encontrando causas reales o solo cerrando casos, un diagnóstico de madurez puede ayudarte a verlo con claridad. La diferencia entre cumplir y aprender suele estar en esos detalles.