Análisis de Causa Raíz (RCA) aplicado a la ingeniería: metodología, evidencias, 5 Porqués, Ishikawa, barreras, hipótesis, acciones correctivas y verificación de eficacia.
¡Descúbrelo!
El Análisis de Causa Raíz — RCA, de Root Cause Analysis — es un proceso estructurado para investigar por qué ocurrió una falla, incidente, no conformidad o pérdida de desempeño y qué condiciones permitieron que se manifestara. El objetivo no es encontrar una explicación conveniente ni señalar culpables, sino construir una cadena causal sustentada por evidencias e identificar acciones capaces de reducir la probabilidad de recurrencia.
En ingeniería de confiabilidad, el RCA es especialmente relevante cuando la simple restauración de la función no resuelve el problema. Sustituir un componente quemado, reiniciar un controlador o reapretar una conexión puede recuperar el sistema, pero no explica por qué ocurrió el evento ni si el mismo mecanismo seguirá presente. El RCA comienza precisamente donde termina el mantenimiento correctivo: después de restablecer el servicio, se investigan el mecanismo, las condiciones contribuyentes, las barreras que fallaron y las causas sistémicas asociadas.
RCA no es sinónimo de Ishikawa, 5 Porqués o árbol de fallas. Estas son técnicas que pueden apoyar una investigación. El RCA es el proceso completo: definir el evento, preservar evidencias, reconstruir la secuencia, formular hipótesis, probar causalidad, identificar causas físicas, humanas y organizacionales, proponer acciones y verificar si realmente reducen el riesgo de repetición.
Qué es el Análisis de Causa Raíz
La IEC 62740:2015 describe el RCA como un proceso de análisis a posteriori de eventos ocurridos, aplicable a fallas, incidentes, no conformidades y otros eventos relevantes. La norma enfatiza que las causas pueden estar relacionadas con el diseño, los procesos, factores organizacionales, aspectos humanos y eventos externos. Esto es importante porque las fallas técnicas rara vez pertenecen únicamente al componente que se detuvo.
En una instalación eléctrica, por ejemplo, la actuación repetitiva de un interruptor automático puede deberse a sobrecarga, selectividad inadecuada, ajuste incorrecto, degradación, armónicos, falla aguas abajo, condiciones ambientales, error de diseño o intervención operacional. El RCA debe separar síntoma, mecanismo y causa.
Una definición práctica es: la causa raíz es una condición causal que, cuando se trata adecuadamente, reduce de manera material la probabilidad de recurrencia del evento o de eventos equivalentes.
El RCA no busca un culpable; busca una cadena causal que pueda modificarse. Si la conclusión no cambia la recurrencia o el riesgo, probablemente la investigación se detuvo demasiado pronto.
Esto evita un error frecuente: llamar causa raíz a cualquier hecho que esté al comienzo de la narrativa. "El relé falló" puede describir solo el último eslabón visible de una cadena causal.
El evento, la falla y el problema deben definirse con precisión
Una mala investigación suele comenzar con un evento mal definido. Expresiones como "el sistema se cayó", "la bomba se detuvo" o "el tablero presentó una falla" son insuficientes.
Siempre que sea posible, el evento debe indicar:
- función perdida o degradada;
- equipo o sistema afectado;
- instante o ventana temporal;
- condición operativa;
- consecuencia observada;
- duración;
- estado anterior y posterior;
- cambios recientes relevantes.
Un ejemplo mejor: pérdida total de la función de bombeo del circuito X a las 14:32, durante operación con carga normal, tras la actuación simultánea de la protección de ambos motores, con 47 minutos de indisponibilidad del proceso.
Cuanto más precisa sea la definición, más objetiva será la búsqueda de evidencias.
El RCA comienza con la preservación de las evidencias
El impulso natural después de una falla es restablecer rápidamente la operación. Eso es correcto desde el punto de vista operativo, pero puede destruir datos necesarios para la investigación.
Antes de desmontar, resetear, sustituir o cambiar configuraciones, el equipo debe evaluar qué evidencias necesitan preservarse. Según el sistema, esto puede incluir:
- logs y alarmas;
- oscilografías y registros de protección;
- tendencias de proceso;
- fotografías y videos;
- estado de relés, contactores y protecciones;
- posición de válvulas e interruptores;
- configuraciones y versiones de software;
- muestras físicas;
- mediciones de temperatura, vibración o corriente;
- órdenes de mantenimiento anteriores;
- declaraciones de los operadores;
- registros de intervenciones recientes.
La cadena temporal es especialmente importante. En sistemas digitales, los eventos pueden ocurrir en milisegundos; en fallas mecánicas, la degradación puede desarrollarse durante meses.
Síntoma, mecanismo de falla y causa no son lo mismo
Separar estos tres niveles mejora la calidad del RCA.
| Nivel | Pregunta | Ejemplo |
| Síntoma | ¿Qué se observó? | el motor se detuvo |
| Modo/mecanismo | ¿Cómo se perdió la función? | el rodamiento se trabó después del aumento de temperatura |
| Causa | ¿Por qué se desarrolló el mecanismo? | lubricación inadecuada por procedimiento incorrecto e intervalo incompatible |
La sustitución del rodamiento trata el daño. Corregir solo el intervalo puede tratar parte del mecanismo. Si el procedimiento no define cantidad, especificación, método y evidencia, la recurrencia todavía puede mantenerse.
Causa inmediata, contribuyente y sistémica
Un RCA robusto suele encontrar múltiples niveles causales.
Causa inmediata es el mecanismo más próximo al evento: cortocircuito, pérdida de lubricación, comando indebido, rotura, sobrecalentamiento.
Condiciones contribuyentes aumentan la probabilidad o la consecuencia: ambiente severo, acceso deficiente, alarma ineficaz, documentación desactualizada, ausencia de repuestos.
Causas sistémicas están relacionadas con decisiones de diseño, proceso, gestión, competencia, gobernanza o control que permitieron que la condición existiera y permaneciera.
Esta clasificación evita la trampa de cerrar la investigación en "error humano". Un error operacional puede formar parte de la cadena, pero el RCA debe investigar por qué el sistema permitió que un único error produjera la consecuencia, si existían barreras, si la interfaz era clara y si el procedimiento era ejecutable.
Cómo estructurar un RCA paso a paso
Un proceso pragmático puede seguir nueve etapas:
1. Definir el evento y el impacto. Registrar qué ocurrió, cuándo, en qué condición y qué función se perdió. 2. Preservar y recopilar evidencias. Garantizar la trazabilidad de datos físicos, digitales y documentales. 3. Reconstruir la línea de tiempo. Ordenar los hechos y separar observación de interpretación. 4. Identificar modos y mecanismos de falla. Comprender técnicamente cómo se materializó el evento. 5. Formular hipótesis causales. Crear explicaciones plausibles sin elegir prematuramente una favorita. 6. Probar las hipótesis contra las evidencias. Buscar confirmación y también evidencias que puedan refutarlas. 7. Identificar causas y factores contribuyentes. Incluir dimensiones físicas, humanas, organizacionales y externas. 8. Definir acciones correctivas y preventivas. Priorizar acciones que modifiquen efectivamente la cadena causal. 9. Verificar la eficacia. Acompañar si las acciones redujeron recurrencia, exposición y riesgo.
El proceso debe ser proporcional a la consecuencia del evento. Un RCA de tres semanas para una falla trivial puede ser un desperdicio; una investigación superficial después de una falla crítica puede dejar expuesta a la organización.
Línea de tiempo antes de la narrativa causal
Reconstruir la secuencia factual antes de discutir las causas es una disciplina útil. La línea de tiempo puede combinar:
- condición normal anterior;
- cambios recientes;
- primer desvío detectable;
- alarmas;
- acciones automáticas;
- decisiones humanas;
- falla funcional;
- respuesta de emergencia;
- restauración.
Este método reduce el sesgo retrospectivo. Después de conocer el resultado, es fácil interpretar cada evento anterior como "obvio". La línea de tiempo preserva lo que realmente era observable en cada instante.
5 Porqués: útil para profundizar, insuficiente por sí solo
La técnica de los 5 Porqués estimula al equipo a no detenerse en la primera explicación. Su valor está en la disciplina de profundizar la causalidad.
Ejemplo simplificado:
1. ¿Por qué se detuvo la bomba? — el motor disparó por sobretemperatura. 2. ¿Por qué hubo sobretemperatura? — la ventilación estaba obstruida. 3. ¿Por qué estaba obstruida? — hubo acumulación de material particulado. 4. ¿Por qué no se identificó la acumulación? — la inspección no incluía ese punto. 5. ¿Por qué la inspección no lo incluía? — el plan fue creado a partir del manual genérico sin considerar el ambiente real.
El problema es convertir "cinco" en una regla. Algunas cadenas exigen tres niveles; otras, quince. Además, los eventos complejos tienen causas paralelas e interdependientes que una cadena lineal no representa bien.
Para la aplicación específica de la técnica, con criterios de uso, ejemplos, limitaciones e integración con la acción correctiva, vea 5 Porqués en Ingeniería: cómo investigar la causa raíz sin detenerse en el síntoma.
Diagrama de Ishikawa como herramienta de exploración
El Diagrama de Ishikawa organiza hipótesis por categorías y ayuda a evitar una investigación estrecha. Puede considerar máquina, método, mano de obra, material, medición, medio ambiente o categorías adaptadas al sistema.
Es particularmente útil al comienzo, cuando el equipo necesita ampliar el espacio de hipótesis. Sin embargo, un elemento colocado en el diagrama no se convierte en causa solo por haber sido recordado. Cada hipótesis debe confrontarse con evidencias.
En el sitio de A3A, el artículo específico sobre el Diagrama de Ishikawa debe seguir siendo el responsable de enseñar la herramienta. En esta página, Ishikawa aparece como una técnica dentro del proceso más amplio de RCA.
Árbol de causas y lógica causal
Cuando el evento resulta de la combinación de varios factores, los árboles de causas pueden representar relaciones del tipo Y/O y dependencias entre condiciones.
Considere una falla de alimentación en la que la carga solo se pierde cuando:
- la fuente principal está indisponible; y
- la transferencia automática no actúa; y
- el bypass manual no puede ejecutarse dentro del tiempo requerido.
La causa del evento no puede reducirse únicamente a la falla de la fuente principal. El sistema fue diseñado precisamente para tolerar esa condición. La investigación debe explicar por qué las barreras de defensa también fallaron.
FTA y RCA no son lo mismo
FTA — Fault Tree Analysis — es una técnica deductiva que parte de un evento superior y descompone combinaciones de fallas capaces de producirlo. Puede utilizarse de forma prospectiva o para estructurar hipótesis.
El RCA analiza un evento que realmente ocurrió. Utiliza evidencias del caso y puede incorporar FTA, Ishikawa, 5 Porqués, análisis de barreras, análisis de cambios y otras técnicas.
La elección depende de la complejidad, criticidad y naturaleza de las evidencias.
Análisis de barreras
Una manera poderosa de investigar incidentes es preguntar qué barreras deberían haber impedido el evento o reducido su consecuencia.
Las barreras pueden ser:
- físicas: protección, enclavamiento, contención;
- automáticas: lógica, alarma, shutdown;
- procedimentales: checklist, permiso, inspección;
- humanas: revisión independiente, doble verificación;
- organizacionales: gestión del cambio, competencia, aprobación técnica.
Para cada barrera, el equipo evalúa si existía, si era adecuada, si estaba disponible y si funcionó como se esperaba.
Este enfoque desplaza la investigación de "quién se equivocó" a "cómo permitió el sistema que el evento evolucionara".
Una barrera que existía en el procedimiento, pero no podía ejecutarse en campo, no es una barrera eficaz. El RCA debe evaluar existencia, adecuación, disponibilidad y desempeño real de las defensas.
Análisis de cambios
Los eventos muchas veces surgen después de algún cambio explícito o silencioso: nuevo proveedor, ajuste de proceso, actualización de software, cambio de material, modificación de carga, cambio de equipo humano, revisión de procedimiento o modificación de layout.
Comparar antes vs. después ayuda a encontrar variables relevantes. Sin embargo, la correlación temporal no demuestra causalidad. El cambio debe estar técnicamente conectado con el mecanismo observado.
Cómo probar una hipótesis causal
Una buena hipótesis debe explicar el evento y ser compatible con las evidencias.
Preguntas útiles:
- ¿la hipótesis explica la secuencia temporal?
- ¿explica el daño físico observado?
- ¿es compatible con mediciones y logs?
- ¿existe un mecanismo técnico plausible?
- ¿ya ocurrieron eventos equivalentes?
- ¿el sistema funcionaría normalmente si esta condición estuviera ausente?
- ¿hay evidencia que contradiga la hipótesis?
La última pregunta es crítica. Una investigación confiable intenta refutar su propia hipótesis, no solo acumular elementos que la confirmen.
Ejemplo técnico: falla recurrente en una fuente de alimentación
Considere una fuente industrial que falla tres veces en seis meses. La acción correctiva siempre fue sustituir el módulo.
El RCA encuentra los siguientes hechos:
- todas las fallas ocurrieron en el mismo tablero;
- los módulos presentan daños similares en la etapa de entrada;
- las mediciones muestran transitorios por encima de la condición prevista;
- el DPS instalado está al final de su vida útil y sin indicación monitorizada;
- el diseño no prevé coordinación adecuada entre dispositivos de protección;
- la inspección preventiva verifica solo presencia física, no estado funcional.
La "causa raíz" no es simplemente una "fuente defectuosa". El mecanismo está asociado con la exposición eléctrica y con barreras inadecuadas de protección/monitoreo.
Las acciones posibles incluyen revisar la coordinación de protecciones, sustituir el dispositivo degradado, mejorar el diagnóstico, actualizar los criterios de inspección y verificar otras instalaciones con la misma arquitectura.
Este último punto es importante: un buen RCA no trata solamente el activo que falló; busca riesgo sistémico replicado.
La acción correctiva debe atacar la cadena causal
Las acciones pueden clasificarse por el nivel en el que actúan.
| Tipo de acción | Ejemplo | Fuerza típica |
| restaurar | sustituir componente | baja frente a la recurrencia |
| detectar | crear alarma o inspección | media |
| reducir exposición | cambiar procedimiento o frecuencia | media |
| eliminar mecanismo | corregir diseño, proceso o material | alta |
| crear barrera independiente | enclavamiento, protección, segregación | alta |
Esto no significa que toda acción deba implicar una intervención de ingeniería pesada. En muchos casos, la mejor solución es simple. El criterio es si modifica de forma defendible la probabilidad o la consecuencia del evento.
Plan de acción con trazabilidad
Cada acción debe registrar:
- causa o factor que pretende tratar;
- responsable;
- plazo;
- evidencia de implementación;
- riesgo residual;
- criterio para verificar la eficacia.
"Capacitar al equipo" es insuficiente si no está claro qué comportamiento debe cambiar, por qué la capacitación es la barrera adecuada y cómo se verificará.
Verificación de la eficacia
Cerrar la acción administrativa no cierra el RCA. La organización debe verificar si la condición fue realmente controlada.
Los indicadores pueden incluir:
- recurrencia del modo de falla;
- tasa de falla después de la intervención;
- disponibilidad;
- reducción de alarmas/eventos precursores;
- resultado de inspecciones;
- conformidad con nuevos parámetros;
- eliminación del mecanismo en activos equivalentes.
Para eventos raros, esperar una nueva falla puede no ser aceptable. En ese caso, la eficacia puede demostrarse mediante pruebas, inspección, cálculo, revisión de diseño o verificación de barreras.
Cuándo abrir un RCA formal
No toda falla merece el mismo esfuerzo. Los criterios de activación pueden incluir:
- accidente o cuasiaccidente relevante;
- pérdida de una función crítica;
- falla con impacto ambiental o regulatorio;
- indisponibilidad por encima del límite;
- recurrencia;
- costo elevado;
- falla de una barrera crítica;
- evento inesperado en un sistema redundante;
- riesgo de repetición en activos similares.
La criticidad ayuda a calibrar la profundidad y el equipo necesario.
Quién debe participar
Un RCA multidisciplinario tiende a ser más robusto. Según el evento, pueden participar operación, mantenimiento, ingeniería, automatización, seguridad, calidad, fabricante y especialistas externos.
El equipo debe combinar conocimiento del sistema con suficiente independencia para cuestionar premisas. Cuando la investigación es conducida solo por quienes diseñaron o ejecutaron la solución, puede existir sesgo de confirmación.
Errores frecuentes en RCA
Algunos patrones reducen drásticamente la calidad de la investigación:
- elegir la causa antes de recopilar datos;
- confundir correlación con causalidad;
- detenerse en "error humano";
- usar solo entrevistas sin evidencia técnica;
- aplicar los 5 Porqués mecánicamente;
- enumerar decenas de causas sin priorización;
- proponer capacitación para cualquier problema;
- cerrar el análisis después de sustituir la pieza;
- no verificar si la misma condición existe en activos equivalentes;
- no medir la eficacia de las acciones.
RCA, FMEA y FMECA se complementan
FMEA y FMECA están estructurados principalmente para anticipar modos y efectos de falla o analizar sistemáticamente un sistema. El RCA parte de un evento ocurrido y reconstruye la causalidad.
Un RCA bien realizado puede alimentar el FMEA/FMECA con nuevos modos, causas, controles y evidencias. Del mismo modo, un FMEA existente puede acelerar la investigación al proporcionar hipótesis y relaciones funcionales previamente analizadas.
Este ciclo transforma el incidente en conocimiento de ingeniería.
RCA y FRACAS
FRACAS — Failure Reporting, Analysis and Corrective Action System — amplía el RCA a un proceso continuo de registro, análisis, acción y cierre. Mientras que el RCA puede ser una investigación específica, FRACAS organiza repetidamente los eventos a lo largo de la vida del sistema.
La madurez aparece cuando las causas y acciones dejan de quedar aisladas en informes y pasan a alimentar bases de datos, estándares de diseño, mantenimiento, capacitación y decisiones sobre activos.
Cuándo el RCA aporta más valor
El RCA es especialmente valioso cuando existe recurrencia, alto impacto, incertidumbre sobre el mecanismo, múltiples barreras involucradas o riesgo de replicación. También es útil en comisionamiento, operación asistida, mantenimiento, fallas de sistemas críticos y análisis de desempeño por debajo de lo esperado.
El entregable debe permitir la toma de decisiones: evento bien definido → evidencia → cadena causal → causas → acciones → verificación de eficacia. Sin este encadenamiento, la investigación tiende a convertirse en una narrativa retrospectiva en lugar de una herramienta de ingeniería.
Cerrar la acción no significa cerrar la causa. El RCA solo completa el ciclo cuando existe evidencia de implementación y un criterio técnico para verificar la eficacia.
Referencias técnicas
[1] IEC. IEC 62740:2015 — Root cause analysis (RCA). Geneva: IEC, 2015.
[2] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: IEC, 2018.
[3] ISO. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018.
Preguntas frecuentes
Es un proceso estructurado para investigar eventos ocurridos, identificar causas y factores contribuyentes sustentados por evidencias y definir acciones capaces de reducir la probabilidad de recurrencia.
No. 5 Porqués es una técnica que puede apoyar la investigación. RCA es el proceso completo de definición del evento, recopilación de evidencias, análisis causal, acciones y verificación de eficacia.
No. Ishikawa ayuda a organizar hipótesis de causa; el RCA exige probar esas hipótesis contra las evidencias y construir una cadena causal defendible.
Cuando el evento presenta alta consecuencia, recurrencia, falla de barrera crítica, impacto regulatorio, gran indisponibilidad, costo elevado o riesgo de repetición en activos similares.
Puede formar parte de la cadena causal, pero normalmente es insuficiente cerrar el análisis en ese nivel. La investigación debe evaluar condiciones de diseño, interfaz, procedimiento, capacitación, barreras y organización que permitieron que el error produjera la consecuencia.
La eficacia debe verificarse mediante indicadores, pruebas, inspecciones, cálculos o evidencias que demuestren reducción del mecanismo, de la recurrencia o del riesgo asociado.
Materiales técnicos complementarios
Soluciones relacionadas
- Aplicaciones de Campo, Inspección y Recopilación de Datos Técnicos
- Gestión del Conocimiento Técnico y Lecciones Aprendidas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
Servicios de ingeniería relacionados
- Ingeniería de Confiabilidad y Disponibilidad
- Ingeniería de Mantenimiento
- Recomisionamiento de Sistemas e Instalaciones
Contenidos técnicos relacionados
- Ingeniería de Confiabilidad
- FMEA en Ingeniería
- FMECA
- Diagnóstico de Confiabilidad de Activos
- Diagrama de Ishikawa
Guías, frameworks y referencias
