El análisis de causa raíz (ACR, root cause analysis) es el proceso estructurado de identificar la falla de sistema fundamental que originó un incidente, una no conformidad o una desviación, para eliminar esa causa e impedir que el problema vuelva a ocurrir, en lugar de corregir solo el síntoma visible.
El análisis de causa raíz, conocido muchas veces por la sigla inglesa RCA (root cause analysis) o como análisis de causa raíz (ACR), es un conjunto de métodos que sirve para descubrir la razón de fondo por la que ocurrió un problema. En lugar de reaccionar a lo que se ve en la superficie, el ACR busca la falla de sistema que, si no se corrige, dejará que el mismo problema vuelva a ocurrir.
La definición de referencia proviene de la OSHA, la agencia de seguridad y salud ocupacional de los Estados Unidos: "una causa raíz es una razón fundamental, subyacente y ligada al sistema por la que ocurrió un incidente, que identifica una o más fallas de sistema corregibles." La American Society for Quality (ASQ) complementa esa visión desde la calidad, y describe el ACR como "un término colectivo que describe una amplia gama de enfoques, herramientas y técnicas usados para descubrir las causas de los problemas."
En el marco normativo, el ACR es el motor de la mejora. La norma ISO 45001:2018, en la cláusula 10.2, exige que, ante un incidente o una no conformidad, la organización evalúe la necesidad de acción para eliminar la causa raíz, de modo que el evento no se repita. En América Latina, la NOM-030-STPS-2009 de México pide investigar las causas de los accidentes, y en Colombia la Resolución 1401 de 2007 obliga a investigar los incidentes y accidentes dentro de los quince días siguientes a su ocurrencia. En todos los casos, el requisito legal no se cumple con un arreglo puntual: exige llegar al origen.
Un problema tratado solo en la superficie vuelve. El análisis de causa raíz es lo que separa a una organización que apaga incendios de una que aprende de cada evento. Su valor, sin embargo, se lee de forma distinta según quién esté mirando.
Cada incidente que se repite es una investigación que no llegó al final. El ACR transforma reportes dispersos en conclusiones accionables: identifica la barrera que falló, genera una acción correctiva con responsable y plazo, y produce la evidencia estructurada que un auditor de ISO 45001 va a pedir. Sin causa raíz documentada, la acción correctiva es una opinión; con ella, es un control verificable.
El costo de un incidente rara vez aparece en el reporte del turno. Según el National Safety Council, en su Injury Facts, el costo promedio de una lesión laboral que requiere atención médica se estimó en 48.000 dólares y el de una muerte relacionada con el trabajo en 1,54 millones de dólares (datos de 2024). El costo total de las lesiones laborales en los Estados Unidos se estimó en 181,4 mil millones de dólares ese año. Un ACR que elimina el origen de un evento evita repetir el costo, y la repetición es donde el dinero se acumula.
Una cultura que busca la causa raíz correcta es una cultura que no busca culpables. Cuando la organización demuestra que investiga sistemas y no personas, los equipos de campo reportan más y ocultan menos. Eso alimenta el círculo virtuoso: más datos de calidad, mejores análisis, menos eventos. Lo contrario, culpar al operador, seca la propia fuente de información de la que depende el análisis.
Investigar bien empieza por separar niveles de causa. Confundir la causa inmediata con la causa raíz es el error más común y el más caro, porque lleva a acciones que tratan el síntoma y dejan el origen intacto.
Corregir solo la causa inmediata reemplaza el sello y reinicia la bomba. La misma falla vuelve en unos meses. Actuar sobre la causa raíz crea el plan de mantenimiento preventivo que impide la próxima fuga en toda la flota de bombas similares. Es la diferencia entre remendar y resolver.
Cuando una investigación termina en "error del operador", casi siempre se detuvo demasiado pronto. El enfoque moderno, muy ligado al trabajo del psicólogo James Reason, distingue dos tipos de falla. Las fallas activas son los actos inseguros de quien está en la punta operativa, con efecto inmediato. Las condiciones latentes son debilidades dormidas creadas aguas arriba, por decisiones de diseño, procedimientos, asignación de recursos o cultura, que quedan ocultas hasta que se alinean con una falla activa.
El modelo del queso suizo ilustra la idea: cada capa de defensa es una rebanada de queso, y cada rebanada tiene agujeros, que son sus debilidades. Un accidente ocurre cuando los agujeros de varias capas se alinean y dejan pasar la trayectoria del daño. La lección para el ACR es directa: el error humano suele ser el último agujero, no el origen. La causa raíz está, la mayoría de las veces, en las condiciones latentes del sistema, y por eso la propia OSHA prefiere hablar de fallas de sistema corregibles, y no de culpa individual.
No existe un único método de análisis de causa raíz. Existe una caja de herramientas, y la competencia está en elegir la correcta para cada problema. Estos son los métodos más usados en el mundo EHSQ.
Preguntar "¿por qué?" de forma sucesiva, encadenando cada respuesta en la siguiente pregunta, hasta llegar a la falla de sistema. Nació en el Sistema de Producción Toyota, con Sakichi Toyoda y Taiichi Ohno. Es rápido, no exige estadística y funciona bien en problemas de causa probablemente única. El riesgo es detenerse en un síntoma o seguir una sola línea de razonamiento cuando el evento tiene varias causas.
Un diagrama de causa y efecto que organiza las causas posibles en categorías, típicamente las 6M: método, máquina, material, mano de obra, medición y medio ambiente. Creado por Kaoru Ishikawa, es ideal para la lluvia de ideas estructurada en equipo, porque impide la fijación en una sola causa y obliga a mirar todas las dimensiones. No jerarquiza ni cuantifica: lista hipótesis que todavía deben verificarse con datos.
Método deductivo, de arriba hacia abajo: parte de un evento indeseado en la cima y desciende por compuertas lógicas (Y / O) hasta las fallas elementales que, combinadas, lo provocan. Desarrollado en Bell Labs en 1962, es la herramienta correcta para sistemas complejos y para eventos que solo ocurren cuando varias fallas coinciden, y permite incluso el análisis cuantitativo. A cambio, es laborioso y exige datos de probabilidad.
Método inductivo, de abajo hacia arriba, que recorre cada modo de falla posible y lo prioriza con un número de prioridad de riesgo (RPN), resultado de multiplicar severidad, ocurrencia y detección. Es proactivo por naturaleza: se usa para anticipar fallas en diseños (DFMEA) y procesos (PFMEA) antes de que ocurran. Hay que tener cuidado con el RPN, porque la multiplicación puede enmascarar riesgos de severidad alta y frecuencia baja.
Un gráfico de barras ordenado por frecuencia o costo que evidencia los "pocos vitales": los pocos tipos de problema responsables de la mayor parte de los efectos. Se basa en el principio 80/20 de Vilfredo Pareto, popularizado por Joseph Juran. No explica el porqué de nada, pero responde a una pregunta esencial antes del ACR: por dónde empezar cuando hay muchos problemas compitiendo por atención.
El análisis de barreras pregunta qué controles debieron prevenir o detectar el evento y cuáles fallaron. El diagrama bowtie lleva la idea más lejos: coloca el evento de cima al centro, las amenazas y las barreras preventivas a la izquierda, y las consecuencias y las barreras de mitigación a la derecha. Es particularmente fuerte en seguridad de procesos y se alinea bien con la lógica de controles de la ISO 45001.
El mayor error no es aplicar mal un método, es aplicar el método equivocado al problema. Esta tabla cruza las variables que realmente deciden la elección: complejidad del evento, tiempo disponible, necesidad de datos y tipo de razonamiento.
En la práctica, los métodos se combinan. Un análisis de Pareto elige el problema, un diagrama de Ishikawa levanta las hipótesis, los 5 porqués profundizan la línea más prometedora y el análisis de barreras confirma qué control falló. La herramienta sirve a la investigación, no al revés.
Sea cual sea el método, un ACR bien conducido sigue una secuencia. Saltar etapas es la vía más rápida hacia una conclusión equivocada.
1. Definir el problema con precisión: qué, dónde, cuándo y cuál es la desviación frente a lo esperado.
2. Recoger datos y evidencias: reconstruir la cronología antes de que la memoria y la escena se pierdan.
3. Identificar las causas posibles: usar Ishikawa o lluvia de ideas estructurada para no fijarse en una sola hipótesis.
4. Determinar la causa raíz: probar cada hipótesis contra las evidencias, con 5 porqués, FTA o análisis de barreras.
5. Implementar acciones correctivas: definir acciones que eliminan la causa, con responsable y plazo, no solo el arreglo.
6. Verificar la eficacia: confirmar, semanas o meses después, que la acción funcionó y el problema no volvió.
La última etapa es la que casi todos olvidan y la que más importa. Una acción correctiva sin verificación de eficacia es una hipótesis, no una solución.
El análisis de causa raíz no vive solo. Es el corazón del ciclo CAPA (acciones correctivas y preventivas), el proceso que transforma el resultado de la investigación en un cambio real. La acción correctiva actúa sobre un problema que ya ocurrió, eliminando la causa para impedir la recurrencia. La acción preventiva actúa sobre un riesgo identificado antes de que se materialice. Ambas dependen de una causa raíz bien identificada: sin ella, el CAPA cierra acciones que no resuelven nada.
Vale la pena distinguir corregir de acción correctiva. Corregir es remediar el síntoma, como limpiar un derrame. La acción correctiva elimina la razón por la que ocurrió el derrame. Un ciclo CAPA maduro exige siempre el paso final de verificación de eficacia, el mismo principio que, en el FMEA, lleva a recalcular el RPN después de la acción. Ese cierre de ciclo es lo que distingue a un sistema de gestión que aprende de un archivo de reportes.
En una línea de fundición a presión, las piezas empiezan a salir con porosidad por encima del límite. La causa inmediata es la temperatura del metal fuera de rango; la causa raíz, identificada con Ishikawa y 5 porqués, es la ausencia de un plan de calibración periódica de los termopares. La acción correctiva crea el plan de calibración y una alerta automática para desviaciones, y el resultado alimenta los indicadores de calidad que exigen los auditores OEM.
El apagón de 2003 en el noreste de los Estados Unidos y Canadá es un caso real y emblemático de análisis de causa raíz en sistemas complejos. La investigación combinó vegetación en contacto con líneas y una falla de software en el sistema de monitoreo (SCADA) que impidió a los operadores ver el problema a tiempo. La conclusión llevó a normas de confiabilidad obligatorias, mostrando cómo un buen ACR sistémico cambia a todo un sector.
El accidente en T2 Laboratories en 2007, investigado por la Chemical Safety Board de los Estados Unidos, resultó de una reacción descontrolada cuyo sistema de enfriamiento y de alivio de presión era insuficiente para el escenario de falla. El análisis por árbol de fallas y la lógica de barreras evidenciaron condiciones latentes de diseño, no un error del operador de turno, un ejemplo claro de por qué la investigación no puede detenerse en la acción humana visible.
En una caldera de recuperación, el riesgo crítico de contacto entre smelt y agua exige un ACR de barreras siempre que una protección falla. Una rotura de hoja en la máquina de papel, a su vez, combina 5 porqués con análisis de cambio: qué cambió en el proceso, en el material o en la regulación de la máquina inmediatamente antes de la rotura. La causa raíz suele estar en un cambio de setup no documentado, no en el operador.
Un resultado fuera de especificación (OOS) en una prueba de disolución activa una investigación por etapas, como exigen las buenas prácticas de manufactura. La tentación es atribuir la desviación a un error de laboratorio; un ACR riguroso sigue los 5 porqués hasta una causa de proceso, por ejemplo una variación en la fuerza de compresión del comprimido, y alimenta un CAPA rastreable exigido por la FDA y por la ICH Q10.
La explosión de polvo de azúcar en Imperial Sugar en 2008, también investigada por la Chemical Safety Board, mostró cómo la acumulación de polvo combustible y las fallas de limpieza y contención fueron las condiciones latentes detrás del evento. En un contexto de HACCP, la misma disciplina de causa raíz se aplica a una desviación en un punto crítico de control: encontrar el origen sistémico, no el turno donde se detectó.
Detenerse en la causa inmediata es el primero. Apenas aparece una explicación plausible, la investigación se cierra, y el problema regresa. Culpar a la persona es el segundo y el más tóxico: además de rara vez ser la causa raíz real, seca el reporte futuro. El sesgo de confirmación es el tercero, cuando el equipo persigue la hipótesis que ya traía en mente e ignora las evidencias que la contradicen.
Está además el error de elegir la solución antes de comprender el problema, y el de no verificar la eficacia de la acción, dejando sin saber si la causa fue realmente eliminada. El antídoto es siempre el mismo: disciplina de método, evidencias antes de conclusiones y un ciclo que solo se cierra cuando la verificación confirma que el evento no vuelve.
La calidad del análisis de causa raíz aparece en los números de la organización. Cuando el ACR llega de verdad al origen, la tasa de recurrencia de incidentes baja y los indicadores de resultado mejoran. Uno de los más usados para medir la gravedad de los eventos es la tasa de frecuencia de incidentes registrables, que se calcula así:
TRIR = (número de casos registrables × 200.000) ÷ total de horas trabajadas
El factor 200.000 representa 100 trabajadores a tiempo completo a lo largo de un año. El ACR actúa sobre la causa de los eventos que componen ese indicador; para entender el cálculo completo y cómo interpretarlo, consulte la página completa: [TRIR — Tasa de Frecuencia de Incidentes Registrables].
Durante décadas, el análisis de causa raíz vivió en formularios de papel y hojas de cálculo. El reporte de investigación quedaba en un cajón, la acción correctiva en un Excel sin responsable ni plazo, y la conexión entre un cuasi-accidente de hoy y el incidente grave de mañana se perdía. El conocimiento existía, pero no circulaba.
Un software EHSQ cambia esa realidad al llevar la investigación al lugar donde ocurre el evento. El operador reporta desde el celular, incluso sin conexión, la investigación se conduce con método, la acción correctiva nace con responsable, plazo y rastro de verificación, y todo queda conectado en un solo flujo. Glartek es el software EHSQ que conecta a los equipos de EHS con los operadores de campo, garantizando que la causa raíz identificada se transforme en una acción verificable, y no en un reporte más archivado.
El mayor salto es predictivo. Cuando cada cuasi-accidente y cada no conformidad alimentan la misma base, los patrones se vuelven visibles antes de que ocurra el incidente grave. Es la diferencia entre reaccionar a los eventos y anticipar precursores, y ahí es donde el análisis de causa raíz deja de ser un ejercicio retrospectivo para convertirse en un motor de prevención.
.webp)
La causa inmediata es el acto o la condición directamente ligado al evento, lo que se ve primero. La causa raíz es la falla de sistema fundamental que permitió que la causa inmediata existiera. Corregir solo la causa inmediata resuelve el síntoma; actuar sobre la causa raíz impide la recurrencia.
Cinco es una referencia, no una regla. El número correcto de porqués es el que llega a una falla de sistema corregible: a veces bastan tres, otras veces se necesitan seis o siete. Detenerse demasiado pronto deja la causa raíz sin descubrir.
Use el diagrama de Ishikawa cuando el problema puede tener varias causas en dimensiones diferentes y se beneficia de una lluvia de ideas estructurada en equipo. Use los 5 porqués cuando la causa es probablemente única y quiere profundizar rápido en una línea de razonamiento. Muchas veces se combinan: Ishikawa levanta las hipótesis, los 5 porqués profundizan la más fuerte.
De forma indirecta, sí, en muchos regímenes. La ISO 45001:2018 exige evaluar la necesidad de eliminar la causa raíz de incidentes y no conformidades. En México, la NOM-030-STPS pide investigar las causas de los accidentes, y en Colombia la Resolución 1401 de 2007 obliga a investigar incidentes y accidentes. La investigación de causa es la forma de cumplir esos requisitos.
Rara vez. El error humano suele ser una causa inmediata; la causa raíz está en las condiciones latentes que hicieron probable el error, como procedimientos confusos, capacitación insuficiente o falta de barreras. Detenerse en el error humano es detenerse demasiado pronto y perder la oportunidad de prevención real.
CAPA significa acciones correctivas y preventivas. El ACR identifica la causa; el CAPA transforma esa causa en acción, con responsable, plazo y verificación de eficacia. La acción correctiva elimina la causa de un problema ocurrido; la acción preventiva actúa sobre un riesgo antes de que se materialice.
Después de cualquier incidente, cuasi-accidente o no conformidad con potencial de repetición o de gravedad. Investigar los cuasi-accidentes es particularmente valioso: son avisos gratuitos que revelan causas antes de que provoquen una lesión grave.
Es una debilidad dormida en el sistema, creada aguas arriba por decisiones de diseño, procedimientos o gestión, que queda oculta hasta que se alinea con otras fallas y permite el evento. En el modelo del queso suizo, son los agujeros en las capas de defensa que rara vez aparecen solos en el reporte de turno.
Depende de la complejidad. Un análisis con 5 porqués puede cerrarse en una hora; un árbol de fallas para un sistema crítico puede tomar semanas e involucrar a varios especialistas. Lo importante no es la velocidad, sino llegar a la causa correcta y verificar después la eficacia de la acción.
Un software EHSQ lleva la investigación al punto donde ocurre el evento, garantiza que la acción correctiva nazca con responsable y plazo, y conecta cada cuasi-accidente y no conformidad a una base común que revela patrones. Glartek automatiza ese flujo, desde el reporte en campo hasta la verificación de eficacia, transformando la causa raíz en prevención medible.
Solicite su demostración
Comience su viaje de trabajador conectado EHSQ con Glartek y conviértase en un líder en su industria.
Solicite una demostración.webp)
Descubra el poder del único Solución EHSQ nativa de IA diseñado para la primera línea
.webp){kind=small}
