Volver al blog

Cómo hacer 5 Why en investigación de incidentes paso a paso

Charly Wigstrom12 de septiembre de 2026

Respuesta directa: Cómo hacer 5 Why en investigación de incidentes consiste en reunir al equipo correcto, reconstruir el evento con evidencia, preguntar “por qué” de forma disciplinada hasta llegar a causas del sistema y validar cada hallazgo antes de cerrar. Bien aplicado, 5 Why no busca culpar a la persona, sino revelar fallas de diseño, supervisión, mantenimiento, capacitación, gestión del cambio o control operacional.

Si trabajás en HSE o en supervisión, esta herramienta puede ser la diferencia entre “cerrar” un incidente y aprender de verdad. En muchas plantas, el problema no es que falten reportes: sobra papel y faltan investigaciones que cambien el sistema. Por eso, esta guía se centra en la metodología y las herramientas para ejecutar 5 Why con consistencia, criterio técnico y trazabilidad. Si querés revisar primero los fundamentos y los errores más comunes, te recomiendo complementar esta lectura con 5 Why en incidentes: fundamentos y diagnóstico HSE.

Y si más adelante necesitás escalar el aprendizaje hacia análisis más robustos, barreras y gestión de mejora, vas a encontrar el puente natural en 5 Why avanzado: lecciones aprendidas y mejora continua.

¿Por qué importa tanto saber cómo hacer 5 Why en investigación de incidentes?

Porque una mala investigación no solo produce acciones débiles: también normaliza la desviación. En seguridad industrial, eso tiene costo operativo, reputacional y humano. API 754 recuerda que los eventos de proceso deben analizarse con criterios consistentes, y OSHA PSM 1910.119 exige investigación de incidentes que realmente identifiquen causas y recomienden acciones para prevenir recurrencia. ISO 45001, por su parte, pide investigar incidentes y no conformidades con foco en la mejora del sistema.

En la práctica, muchas organizaciones todavía hacen 5 Why como si fuera una entrevista rápida. El problema es que, cuando se usa mal, termina en frases como “error humano”, “falta de atención” o “no siguió procedimiento”, que describen el síntoma pero no explican por qué el sistema permitió que el error ocurriera. En una refinería, una planta química o una operación minera, esa superficialidad puede repetir el mismo evento con otro nombre.

La pregunta correcta no es si el operador se equivocó. La pregunta correcta es: ¿qué condiciones hicieron probable ese error y qué barreras fallaron? Ahí es donde 5 Why aporta valor real para HSE y supervisores.

¿Qué es 5 Why y cómo se usa en un entorno industrial?

5 Why es una técnica de análisis causal que encadena preguntas “por qué” para pasar de un evento observable a causas subyacentes. En investigación de incidentes industriales, su propósito no es llegar a cinco preguntas exactas, sino profundizar lo suficiente para encontrar causas controlables por la organización. El número cinco es una referencia, no una regla rígida.

La técnica funciona mejor cuando se usa sobre hechos ya reconstruidos. Primero se define el evento, luego se ordena la secuencia temporal, y recién después se preguntan las causas. Cuando se salta directamente al “por qué”, el equipo suele caer en sesgos: confirmar una hipótesis temprana, culpar al último eslabón o confundir un desvío con una causa raíz.

En investigaciones industriales serias, 5 Why debe convivir con otras herramientas: cronología, árbol de causas, análisis de tareas, revisión de procedimientos, evidencia física, entrevistas y, cuando aplica, barreras críticas o PHA. Esa integración es justamente lo que conectó el primer artículo de la serie con esta guía operativa.

¿Cuál es la secuencia correcta para conducir una sesión 5 Why?

La secuencia correcta es simple de entender, pero requiere disciplina para ejecutarla bien. No alcanza con sentarse a conversar; hace falta un método. Abajo tenés una estructura que podés usar en una sala de investigación o incluso en un cierre inicial de turno, siempre que el caso lo permita.

Paso Objetivo Qué hacer Error frecuente
1. Definir el evento Delimitar qué ocurrió Describir el incidente con fecha, lugar, tarea, equipo y consecuencias Empezar por opiniones o culpables
2. Reunir evidencia Evitar suposiciones Recolectar fotos, registros, tendencias, entrevistas y datos de proceso Hacer 5 Why con memoria informal
3. Construir la línea de tiempo Ordenar hechos Identificar qué pasó antes, durante y después del evento Mezclar causas con consecuencias
4. Formular el problema Fijar el punto de partida Redactar una declaración breve, específica y observable Redactar frases amplias como “falla de seguridad”
5. Preguntar por qué Profundizar causas Hacer preguntas una por una, con evidencia para cada respuesta Responder con juicios, no con hechos
6. Validar la causa Confirmar controlabilidad Verificar si la causa explica el evento y si la organización puede actuar sobre ella Aceptar causas vagas o genéricas
7. Definir acciones Prevenir recurrencia Diseñar acciones sobre el sistema, no solo sobre la persona Proponer “reentrenar” como respuesta única

1) Definí el evento con precisión

La sesión arranca con una definición clara del incidente. No sirve decir “hubo un error” o “se cayó una válvula”. Hay que especificar qué tarea se hacía, quién la ejecutaba, en qué equipo, bajo qué condiciones y cuál fue la consecuencia. Eso evita que el grupo dispare hipótesis demasiado pronto.

Ejemplo: “Durante la maniobra de conexión de manguera en el área de despacho, se produjo una fuga menor de solvente por una brida con junta deteriorada, sin lesionados, con derrame contenido de 12 litros”. Esa frase ya orienta el análisis hacia integridad mecánica, inspección previa, permisos de trabajo y supervisión.

2) Reuní evidencia antes de opinar

Una buena sesión 5 Why se apoya en datos. Fotos del lugar, registros de mantenimiento, permisos, alarmas, bitácoras de turno, entrevistas breves y secuencia operativa son insumos mínimos. Si el evento involucra seguridad de proceso, sumá tendencias de presión, temperatura, nivel o integridad de barreras.

La evidencia también sirve para separar lo que se sabe de lo que se cree. Ese punto es clave porque muchas investigaciones fracasan por exceso de narrativa y poca trazabilidad. El equipo llega con una historia armada y luego busca confirmar esa historia.

3) Construí una línea de tiempo simple

Antes de preguntar por qué, necesitás entender la secuencia temporal. ¿Qué pasó dos horas antes? ¿Qué condiciones había al inicio del turno? ¿Hubo cambios de personal, desvíos de producción o trabajos simultáneos? En plantas con operación continua, una desviación pequeña puede venir de una decisión tomada mucho antes del evento.

La línea de tiempo ayuda a detectar puntos de decisión. Ahí aparecen las verdaderas oportunidades de control: un permiso que no se revisó, una alarma anulada, un repuesto no disponible, una tarea sobrecargada o una barrera que estaba degradada.

4) Redactá el problema en formato investigable

La formulación del problema debe ser concreta. Una buena práctica es usar la estructura: qué ocurrió + dónde + cuándo + qué consecuencia. Evitá incluir la causa en la pregunta inicial. Si arrancás con “¿por qué el operador no siguió el procedimiento?”, ya condicionaste la investigación.

Redacción útil: “¿Por qué se produjo la fuga de solvente durante la conexión de la línea?” Esa formulación permite explorar diseño, mantenimiento, verificación preuso, competencias, supervisión y condiciones del equipo sin contaminar la discusión desde el inicio.

Tipo de pregunta Ejemplo bueno Ejemplo malo Impacto en la investigación
Descriptiva ¿Qué condición permitió la fuga? ¿Quién cometió el error? Enfoca en el sistema
Causal ¿Por qué la junta estaba degradada? ¿Por qué fue tan descuidado? Reduce sesgo de culpa
De control ¿Qué barrera no detectó el desvío? ¿Por qué nadie se dio cuenta? Explica fallas de detección
De verificación ¿Qué evidencia confirma esta causa? ¿Ya podemos cerrar esto? Mejora la calidad del cierre

¿Qué preguntas de calidad te ayudan a profundizar más allá del error humano?

Las mejores preguntas de 5 Why no apuntan a la persona, sino al contexto que hizo posible el desvío. En seguridad industrial, el error humano rara vez es la causa final: suele ser la manifestación visible de un sistema mal diseñado, débilmente controlado o sobrecargado. CCPS insiste en que los eventos complejos requieren entender el desempeño humano dentro del sistema de trabajo.

Usá preguntas que busquen condiciones latentes, no juicios. Por ejemplo: “¿Qué información tenía el operador en ese momento?”, “¿Qué barrera esperaba detectar el desvío y no lo hizo?”, “¿Qué cambio reciente alteró la tarea?”, “¿Cómo se aseguró la competencia para esta actividad?”, “¿Qué evidencia muestra que la acción correctiva atacará la causa?”

Estas preguntas te llevan a causas de diseño, gestión y ejecución. Ahí es donde aparece el valor: en vez de cerrar con una charla de 15 minutos, cerrás con una mejora de trabajo real.

Preguntas guía recomendadas para cada nivel

Para que la sesión no se vuelva abstracta, conviene usar preguntas por capas. Algunas se enfocan en tarea, otras en supervisión y otras en gestión. Esa combinación evita que el análisis quede atrapado en un solo nivel.

  • Nivel tarea: ¿Qué paso del trabajo estaba ocurriendo cuando se desvió?
  • Nivel condición: ¿Qué condición del equipo, ambiente o material contribuyó al evento?
  • Nivel supervisión: ¿Qué revisión, verificación o liberación faltó o fue insuficiente?
  • Nivel competencia: ¿La persona tenía entrenamiento, práctica y autorización para esa tarea?
  • Nivel gestión: ¿Qué decisión del sistema permitió que la desviación llegara al campo?

Una buena señal de que vas bien es cuando la respuesta ya no cabe en una frase simple. Si cada “por qué” se responde con una única palabra, probablemente estás en superficie.

¿Cómo documentar hallazgos y acciones sin perder trazabilidad?

Documentar bien es parte de la metodología. Si la investigación no deja evidencia clara, no puede auditarse, aprenderse ni convertirse en mejora continua. Para HSE y supervisores, el formato debe ser lo suficientemente simple para usarse en campo y lo suficientemente riguroso para resistir revisión gerencial o regulatoria.

OSHA PSM 1910.119 y muchas auditorías ISO 45001 no miran solo si investigaste, sino si puedes demostrar el razonamiento. Eso incluye quién participó, qué evidencia se revisó, qué hipótesis se descartaron y por qué la acción elegida es proporcional al riesgo.

Campo del registro Qué debe incluir Ejemplo Validación
Descripción del evento Hecho observable, lugar, fecha, tarea, consecuencia Fuga de 12 litros durante conexión de línea ¿Lo entiende un tercero?
Datos de contexto Turno, clima, carga de trabajo, equipo, cambios recientes Relevo de turno con atraso de producción ¿Hay factores contribuyentes?
Cadena 5 Why Pregunta, respuesta, evidencia, responsable de validación Junta vencida por inspección omitida ¿Cada respuesta tiene soporte?
Causa validada Causa raíz o causalidad sistémica comprobada Programa de inspección incompleto ¿La causa explica el evento?
Acción correctiva Qué, quién, cuándo, criterio de cierre Actualizar plan de inspección y verificar cumplimiento ¿Reduce recurrencia?

Un formato útil puede tener seis bloques: evento, evidencia, secuencia, preguntas 5 Why, causas validadas y acciones. Si querés profundizar más adelante en cómo integrar estas conclusiones con sistemas de barreras y aprendizaje organizacional, el siguiente paso natural está relacionado con la evolución que abordamos en 5 Why avanzado: lecciones aprendidas y mejora continua.

Casos reales: ¿qué pasa cuando 5 Why se hace bien o mal?

Los casos reales muestran por qué la metodología importa. En investigación de incidentes, el error más caro no es equivocarse en la primera hipótesis; es cerrar la investigación con una causa pobre y una acción que no cambia nada. A continuación, dos ejemplos industriales muy representativos.

Caso 1: Incendio en BP Texas City y el costo de las causas superficiales

En la tragedia de BP Texas City en 2005 murieron 15 personas y más de 170 resultaron heridas durante el arranque de una unidad de isomerización. Aunque el evento involucró múltiples fallas, una lectura superficial habría dicho “error operativo”. Sin embargo, las investigaciones y el informe final mostraron problemas de liderazgo, mantenimiento, diseño del sistema, alarmas, entrenamiento y control de arranque.

Situación: se estaba arrancando una unidad con múltiples desviaciones acumuladas. Problema: el sistema no detectó ni contuvo condiciones peligrosas antes del sobrellenado y la liberación de hidrocarburos. Consecuencia: explosión, víctimas fatales, sanciones y pérdidas enormes. Lección: si el análisis se queda en “alguien no siguió el procedimiento”, las causas sistémicas siguen intactas.

Ver el Curso Investigación de Incidentes

Métodos probados para investigar incidentes sin buscar culpables, enfocado en aprendizaje organizacional.

Algunos enlaces pueden dirigir a productos, cursos o recursos de WFS Academy.

El valor para HSE y supervisores es claro: un 5 Why serio debe llegar a decisiones de diseño y gestión. Si la causa se queda en el operador, la organización aprende muy poco. En eventos de proceso mayores, eso es inaceptable bajo cualquier estándar de desempeño.

Caso 2: Fuga por brida en una planta química y la falsa solución del reentrenamiento

Imaginá una planta de resinas donde, durante una intervención rutinaria, se detecta una fuga pequeña de solvente en una brida. No hubo lesión, pero hubo derrame y paro parcial de la línea. La investigación inicial concluyó que el técnico “no verificó bien” el apriete. Sin embargo, al reconstruir el caso apareció otra realidad: el plan de mantenimiento preventivo tenía atrasos, la junta reemplazada no estaba en el stock crítico, y la inspección de integridad no había priorizado ese circuito tras un cambio de servicio.

Situación: fuga menor durante operación normal. Problema: componente degradado y control preventivo incompleto. Consecuencia: pérdida de contención, exposición del personal y tiempo perdido. Lección: reentrenar al técnico no corregía la causa; sí lo hacía actualizar la estrategia de inspección, stock crítico, criterios de reemplazo y verificación prearranque.

El dato clave en casos como este es que la recurrencia suele bajar cuando la acción corrige el sistema, no cuando “recuerda” a la gente que tenga cuidado. Esa diferencia define una investigación madura de una meramente administrativa.

¿Qué enseñan estos casos sobre la calidad del 5 Why?

En ambos casos, la causa visible era solo la punta del iceberg. Un 5 Why efectivo obliga a preguntarse qué falló en la planificación, en la supervisión, en la integridad mecánica y en el control de cambios. Esa es la forma de pasar de reacción a prevención real.

Además, ambos casos muestran por qué no conviene usar 5 Why como herramienta única en eventos complejos. Cuando hay múltiples fallas simultáneas, 5 Why debe formar parte de una investigación más amplia. Ahí es donde su uso disciplinado se complementa con barreras, análisis de tareas, revisión de sistemas y, si aplica, técnicas de investigación más profundas.

¿Cómo validar causas raíz antes de cerrar la investigación?

Validar causas raíz significa demostrar que la causa propuesta es real, suficiente para explicar el evento y útil para diseñar una acción preventiva. No basta con que “suene lógico”. La lógica sin evidencia es solo una opinión bien redactada.

Una causa raíz válida cumple tres criterios: está respaldada por evidencia, está dentro de la capacidad de control de la organización y, si se elimina o controla, reduce de forma razonable la probabilidad de recurrencia. Si una supuesta causa no cumple eso, probablemente sea un síntoma o una condición contribuyente, no una raíz.

Criterios prácticos de validación

  • Relevancia causal: la causa explica cómo se produjo el evento, no solo qué estuvo presente.
  • Evidencia verificable: hay registros, observaciones o entrevistas consistentes que la sostienen.
  • Control organizacional: la empresa puede actuar sobre la causa con una medida concreta.
  • Capacidad preventiva: la acción asociada reduce la probabilidad o severidad de recurrencia.
  • Especificidad: la causa no es genérica como “falta de cultura” o “falta de atención”.

Si el equipo propone “error humano” como causa final, frená. Preguntá qué barrera no funcionó, qué información faltó, qué condición del entorno indujo el error, qué diseño de trabajo lo facilitó y qué cambio del sistema lo hace improbable. Esa secuencia es la que evita cierres débiles.

¿Qué señales de alerta te dicen que tu 5 Why está mal hecho?

Hay síntomas muy claros de que la investigación se está desviando. Si los detectás temprano, todavía podés corregir el rumbo. Si los ignorás, vas a cerrar con acciones cosméticas.

  • Se llega a una causa en menos de cinco minutos sin revisar evidencia.
  • Las respuestas usan adjetivos como “descuido”, “negligencia” o “falta de compromiso”.
  • La única acción propuesta es “reforzar entrenamiento”.
  • No aparece ningún factor de supervisión, mantenimiento o planificación.
  • La investigación termina con una explicación que no puede auditarse.
  • Las acciones no tienen responsable, fecha ni criterio de verificación.

Cuando veas esas señales, detené la sesión y pedí volver a los hechos. En investigaciones industriales, frenar a tiempo también es una forma de profesionalismo.

¿Cómo implementar esta metodología en el día a día de HSE y supervisión?

La clave está en volver el método repetible. No necesitás una ceremonia compleja para cada incidente menor, pero sí necesitás una estructura mínima común. Eso permite que distintos supervisores e inspectores investiguen con el mismo estándar.

Una forma práctica es usar una plantilla de una página para incidentes de baja y media complejidad, y escalar a un equipo multidisciplinario cuando el evento involucra pérdida de contención, lesión grave, potencial de fatalidad o barreras críticas. En ese esquema, HSE facilita el método y supervisión aporta conocimiento del trabajo real.

Etapa Herramienta Responsable Quick win Cambio estructural
Inicio Plantilla de evento + línea de tiempo HSE / supervisor Usar un formato estándar único Integrar la plantilla al sistema de reporte
Análisis Sesión 5 Why guiada Investigador líder Preguntas por capas y evidencia obligatoria Capacitación formal de facilitadores
Validación Checklist de causa raíz Equipo investigador Revisar criterios de causalidad y control Comité de revisión de investigaciones
Acción Plan correctivo con seguimiento Operaciones / mantenimiento / HSE Asignar responsables y fechas Vincular acciones a KPI de cierre

Si querés acelerar resultados, empezá por dos mejoras: una plantilla única y un checklist de validación. Después, incorporá revisión cruzada entre HSE, operaciones y mantenimiento. Esa combinación eleva la calidad del análisis sin volverlo burocrático.

¿Qué herramientas concretas deberías usar como HSE o supervisor?

Te conviene trabajar con cinco herramientas base. No hacen magia, pero ordenan el razonamiento y reducen sesgo.

  1. Plantilla de investigación: evento, cronología, evidencias, 5 Why, acciones.
  2. Checklist de calidad: para verificar si la causa es válida antes de cerrar.
  3. Matriz de acción: prioridad, responsable, fecha, seguimiento y verificación.
  4. Guía de preguntas: para no quedarse en la culpa del operador.
  5. Registro fotográfico y documental: para sostener el análisis con trazabilidad.

Estas herramientas son especialmente útiles en turnos, cuando la presión por volver a producir empuja a cerrar rápido. Una guía visible y simple ayuda a mantener el estándar incluso bajo presión operativa.

¿Cómo saber si una causa raíz vale la pena?

Una causa raíz vale la pena si cambia decisiones. Si la causa no te obliga a modificar un procedimiento, una barrera, un criterio de mantenimiento, una competencia o una supervisión, entonces probablemente no sea raíz. Puede ser una descripción elegante del síntoma, pero no una palanca de mejora.

Una conclusión robusta tiene que sobrevivir tres preguntas: ¿qué evidencia la sostiene?, ¿qué riesgo reduce?, ¿qué control nuevo o mejorado deja instalado? Si no podés responder eso, la investigación todavía no está lista para cerrarse.

FAQ rápida para aplicar 5 Why en investigación de incidentes

Abajo respondemos las preguntas que más aparecen en campo cuando HSE y supervisión quieren implementar el método con consistencia.

¿Cuántos “why” hay que hacer?

No hay un número fijo. Hacés tantos como sean necesarios para llegar a una causa controlable por la organización. En algunos casos, tres preguntas alcanzan; en otros, necesitás más de cinco. La clave no es la cantidad, sino si la respuesta final explica el evento con evidencia y permite una acción preventiva efectiva.

¿Se puede usar 5 Why para incidentes graves?

Sí, pero no como herramienta única. En eventos complejos o de alto potencial, 5 Why debe formar parte de una investigación más amplia con cronología, evidencia física, análisis de barreras y revisión de sistema. Para incidentes graves, usar solo 5 Why suele ser insuficiente y puede simplificar demasiado la causalidad.

¿Qué hago si el equipo insiste en culpar al operador?

Redirigí la discusión hacia condiciones del trabajo. Preguntá qué información tenía, qué barrera falló, qué entrenamiento recibió, qué presión operacional existía y qué controles estaban disponibles. El objetivo no es exonerar a nadie; es entender por qué una persona razonable pudo equivocarse en ese contexto.

¿Cómo evito que la sesión se vuelva subjetiva?

Exigí evidencia para cada respuesta. Cada “por qué” debe poder vincularse con un dato, un registro, una observación o una entrevista consistente. Si una respuesta no puede ser verificada, no la tomes como causa validada. Eso convierte la sesión en un análisis técnico y no en una discusión de opiniones.

¿Qué pasa si no encuentro una causa raíz clara?

Eso también es un resultado. Puede indicar que faltó evidencia, que el evento es multifactorial o que necesitás otra herramienta además de 5 Why. No cierres con una respuesta débil solo para cumplir plazo. En gestión de incidentes, un cierre rápido pero pobre suele costar más que una investigación un poco más larga pero sólida.

¿Quién debería facilitar la sesión?

Idealmente un facilitador con formación en investigación de incidentes, pero sin sesgo directo sobre el evento. Puede ser HSE, un supervisor entrenado o un líder de operaciones según la complejidad. Lo importante es que tenga criterio para cortar respuestas superficiales, pedir evidencia y mantener el foco en el sistema.

Conclusión: el valor de hacer 5 Why con método

Hacer 5 Why en investigación de incidentes no es repetir una plantilla. Es conducir una conversación técnica para descubrir por qué el sistema permitió que ocurriera un desvío. Cuando la metodología está bien aplicada, la organización deja de perseguir síntomas y empieza a corregir causas que importan.

Para profesionales HSE y supervisores, la verdadera ganancia está en la consistencia: mismos criterios, mismas preguntas, misma exigencia de evidencia y mismas reglas para validar causas antes de cerrar. Eso mejora la calidad de las acciones y también la credibilidad del proceso ante operaciones y liderazgo.

Si ya entendiste los fundamentos y ahora querés llevar la técnica a un estándar más maduro, el siguiente paso natural es conectar esta práctica con lecciones aprendidas, indicadores y mejora continua. Ahí es donde el método deja de ser una herramienta de investigación y se vuelve parte del sistema de gestión.

Si todavía no leíste la base conceptual, te conviene volver al artículo de fundamentos y diagnóstico HSE. Y si querés ver cómo esta técnica madura hacia aprendizaje organizacional, seguí con 5 Why avanzado: lecciones aprendidas y mejora continua.

Esto te ayudara

Acompañamiento personalizado de Charly Wigstrom para líderes de seguridad y operaciones.

Algunos enlaces pueden dirigir a productos, cursos o recursos de WFS Academy.

Nota de transparencia: Algunos enlaces en este artículo pueden dirigir a productos, cursos o recursos de WFS Academy. Solo recomendamos recursos directamente relacionados con el tema técnico tratado.

Preguntas Frecuentes

¿Cuántos “why” hay que hacer en una investigación?

No existe un número fijo. Tenés que seguir preguntando hasta llegar a una causa que sea verificable, controlable por la organización y capaz de explicar el evento. A veces tres preguntas alcanzan; en otras, necesitás más de cinco. El criterio no es la cantidad, sino la calidad de la causa final.

¿Puedo usar 5 Why sin otras herramientas?

Solo en incidentes simples y de bajo potencial, y aun así conviene apoyarlo con una línea de tiempo y evidencia básica. En eventos complejos, con potencial de fatalidad o pérdida de contención, 5 Why por sí solo suele quedarse corto. Ahí conviene combinarlo con análisis de barreras, revisión de tareas y documentación del sistema.

¿Cómo evito que la sesión se convierta en una búsqueda de culpables?

Redirigí siempre hacia condiciones del sistema: información disponible, estado del equipo, presión operacional, supervisión, entrenamiento y barreras. Si una respuesta apunta a una persona, reformulala para preguntar qué permitió que esa persona actuara de esa forma en ese contexto. La disciplina del facilitador es clave.

¿Qué evidencias mínimas debería reunir antes de hacer 5 Why?

Al menos una descripción exacta del evento, fotos del lugar, registros de turno o mantenimiento, entrevistas breves y cualquier dato de proceso relevante. Si el incidente involucra seguridad de proceso, sumá tendencias operativas, alarmas, bypasses o información de integridad mecánica. Sin evidencia, el análisis se vuelve opinático.

¿Cómo sé si una causa raíz está bien validada?

Una causa raíz válida está sostenida por evidencia, explica la secuencia del incidente, está dentro del control de la organización y permite diseñar una acción preventiva concreta. Si la causa no cumple esos criterios, probablemente sea un síntoma, una condición contribuyente o una hipótesis todavía no confirmada.

¿Quién debe participar en la sesión 5 Why?

Idealmente, un facilitador HSE o un supervisor entrenado, más las personas que conozcan el trabajo real: operación, mantenimiento, ingeniería o procesos según el caso. La mezcla correcta ayuda a evitar conclusiones sesgadas y a identificar tanto fallas técnicas como organizacionales.

¿Te resultó útil este análisis?

Recibe contenido técnico exclusivo directamente