MODO CONFIABILIDADDatos›Método›Decisión

Buscar en Modo Confiabilidad

↑ ↓ para moverse · Enter para abrir · Esc para cerrar

Vista previa dentro de un visor: aquí no funcionan las descargas, la impresión ni los enlaces de correo. En el sitio publicado funcionan.

Biblioteca técnica · Metodologías

Análisis de causa raíz (RCA) en mantenimiento

Cómo investigar una falla hasta sus raíces físicas, humanas y latentes, verificar hipótesis con evidencia y medir con Crow-AMSAA si la acción correctiva funcionó.

Documento
CF-GU-03
Revisión
1 · 2026-10-15
Lectura
7 min
Normas de referencia
IEC 62740:2015 · IEC 61710:2013 · ISO 14224:2016

Fundamentos

Un análisis de causa raíz busca por qué ocurrió un evento y qué cambiar para que no vuelva a ocurrir. En mantenimiento, el objetivo práctico es eliminar fallas repetitivas: un pequeño grupo de equipos «malos actores» suele concentrar una fracción grande de las horas perdidas y del costo de correctivo.

La distinción más útil para no quedarse a mitad de camino es entre tres niveles de causa:

  • Raíz física: el mecanismo que produjo la falla (fatiga, corrosión, sobrecalentamiento, marcha en seco).
  • Raíz humana: la decisión o acción que activó ese mecanismo (un arranque sin cebado, un ajuste fuera de torque). Casi nunca es mala intención.
  • Raíz latente: la condición del sistema de gestión que hizo posible o probable esa decisión (sin procedimiento, sin capacitación, sin protección, presión de producción, diseño que facilita el error).

Las acciones sobre la raíz física corrigen un equipo; las acciones sobre la raíz latente corrigen la organización y evitan fallas en equipos que todavía no fallaron.

Idea clave

«Error del operador» no es una causa raíz: es el punto donde el análisis empieza a ser interesante.

Metodología

1. Disparar el análisis con criterios definidos

Sin criterios, todo se analiza y nada se cierra. Disparadores típicos: incidentes de seguridad o ambiente, fallas que superan un costo o una pérdida de producción, y fallas repetidas del mismo modo en un período (por ejemplo, tres en doce meses).

2. Preservar la evidencia

Partes dañadas, posición de válvulas y equipos, registros del sistema de control, órdenes de trabajo previas y testimonios. Las piezas no se tiran hasta que el análisis termina; un rodamiento lavado y guardado en una caja ya perdió la mitad de la información.

3. Construir la secuencia y el árbol lógico

Se parte del evento, se plantean los modos posibles y, para cada uno, hipótesis que se verifican o descartan con evidencia: mediciones, análisis de falla de materiales, tendencias del historiador, ensayos. Las herramientas difieren en estructura, no en lógica:

Herramienta Fortaleza Limitación
Cinco porqués Rápida, sirve para eventos simples Lleva a una sola cadena; depende de quién pregunta
Diagrama de Ishikawa Organiza hipótesis por categoría No verifica ni ordena causas
Árbol lógico Ramas verificadas con evidencia; niveles físico, humano y latente Requiere facilitación y tiempo
Árbol de fallas (FTA) Cuantifica combinaciones de eventos Más apto para diseño que para un evento ya ocurrido
Análisis de barreras Muestra qué defensas fallaron No explica por qué fallaron
Árbol lógico de causa raízDel evento a las hipótesis verificadas o descartadas con evidencia y, desde la verificada, a las raíces física, humana y latente.Evento: 6 fallas de sello mecánico en 14 meses en la bombade transferenciaMarcha en seco al arrancarVerificadaDesalineaciónDescartadaMaterial del selloincompatible con el fluidoDescartadaRaíz físicaBaja presión de succión durante el arranque: el sello opera sin película de fluidoRaíz humanaArranque sin cebado ni venteo de la carcasaRaíces latentesSin procedimiento de arranque escrito · sin disparo por baja presión de succión
Fig. 1Árbol lógico de una falla repetitiva de sello mecánico: las hipótesis se verifican o descartan antes de bajar al siguiente nivel.

4. Definir acciones con jerarquía

Las acciones más efectivas eliminan la causa o la hacen físicamente imposible (un disparo por baja presión de succión); las menos efectivas dependen de que alguien recuerde algo («reforzar la capacitación»). Cada acción tiene responsable, plazo y una forma de verificar su efecto.

5. Verificar la efectividad

Una acción se cierra cuando los datos muestran que la falla no se repite, no cuando la orden de trabajo se completa. El modelo de Crow-AMSAA es la herramienta cuantitativa para esa verificación.

Fórmulas clave

Modelo de ley de potencia (Crow-AMSAA) para un sistema reparable: el número esperado de fallas acumuladas hasta el tiempo tt y la intensidad de falla son:

E[N(t)]=λ tβρ(t)=λ β tβ−1(1)E[N(t)] = \lambda\,t^{\beta} \qquad \rho(t) = \lambda\,\beta\,t^{\beta-1} \tag{1}

Estimación por máxima verosimilitud para una observación truncada en el tiempo TT con nn fallas en los tiempos tit_i:

β^=n∑i=1nln⁡(T/ti)λ^=nTβ^MTBFinst(T)=1ρ^(T)(2)\hat\beta = \frac{n}{\sum_{i=1}^{n}\ln(T/t_i)} \qquad \hat\lambda = \frac{n}{T^{\hat\beta}} \qquad \text{MTBF}_{\text{inst}}(T) = \frac{1}{\hat\rho(T)} \tag{2}

Con β < 1 las fallas se espacian (mejora); con β ≈ 1 la tasa es constante; con β > 1 el sistema se deteriora. A diferencia del β de Weibull, que describe un componente no reparable, este β describe la evolución de un sistema reparable a lo largo del tiempo.

Costo anual de una falla repetitiva, para priorizar:

Canual=f⋅(Creparacioˊn+hparada⋅Chora)(3)C_{\text{anual}} = f\cdot\left(C_{\text{reparación}} + h_{\text{parada}}\cdot C_{\text{hora}}\right) \tag{3}

Ejemplo industrial

Ejemplo

Bomba de transferencia con fallas repetitivas de sello mecánico. Datos ilustrativos.

La bomba registró fallas de sello a los 40, 95, 160, 210, 290 y 380 días de iniciado el seguimiento. Con la ecuación 2, al día 420: β = 1,01, es decir, tasa constante y MTBF ≈ 70 días. Cada evento cuesta 9000 USD entre sello, mano de obra y producción diferida: unos 47 000 USD por año.

El árbol lógico verificó marcha en seco durante el arranque (caras del sello con marcas térmicas, registro de presión de succión cercana a cero en cada arranque) y descartó desalineación (medición láser dentro de tolerancia) e incompatibilidad del material. La raíz humana fue el arranque sin cebado ni venteo de la carcasa; las raíces latentes, la falta de procedimiento escrito y de un disparo por baja presión de succión.

Después de instalar el disparo y aprobar el procedimiento, hubo fallas a los 600 y 980 días. Con los ocho eventos y TT = 1100 días, β = 0,64 y el MTBF instantáneo pasa a 214 días: la acción funcionó, aunque las dos fallas posteriores merecen su propio análisis porque pueden ser otro modo.

Casos documentados

Refinería de Texas City, 2005. La investigación de la U.S. Chemical Safety Board identificó, además de las causas inmediatas del sobrellenado de una torre durante el arranque, raíces organizacionales: instrumentos de nivel y alarmas con fallas conocidas sin reparar, procedimientos desactualizados, recortes de presupuesto y una cultura que medía la seguridad por indicadores de lesiones personales. Ver el caso completo.

Piper Alpha, 1988. La investigación de Lord Cullen mostró cómo una falla del sistema de permisos de trabajo, es decir una raíz latente, convirtió un trabajo de mantenimiento en la peor catástrofe de la industria petrolera en alta mar. Ver el caso.

Buenas prácticas

  • Criterios de disparo escritos y un registro de análisis abiertos con su estado.
  • Facilitador entrenado e independiente del área involucrada.
  • Ninguna hipótesis se acepta sin evidencia; ninguna se descarta sin evidencia.
  • Llegar siempre al nivel latente y elegir al menos una acción de diseño o de sistema.
  • Cerrar con datos: Crow-AMSAA, MTBF del modo o costo de correctivo del equipo.
  • Compartir lecciones con plantas que tienen equipos similares.

Errores comunes

  • Terminar en «error humano» y la acción «capacitar».
  • Una única causa raíz. Los eventos industriales casi siempre combinan varias condiciones.
  • Análisis sin evidencia física: piezas descartadas, datos no consultados.
  • Acciones sin dueño ni verificación, que se cierran al emitir la orden.
  • Analizar todo: sin criterios de disparo, el backlog de análisis abiertos destruye la credibilidad del proceso.

Referencias

  1. IEC 62740:2015. Root cause analysis (RCA).
  2. IEC 61710:2013. Power law model — Goodness-of-fit tests and estimation methods.
  3. MIL-HDBK-189C (2011). Reliability Growth Management. U.S. Department of Defense.
  4. Latino, R. J., Latino, K. C. y Latino, M. A. Root Cause Analysis: Improving Performance for Bottom-Line Results. CRC Press.
  5. CCPS (2019). Guidelines for Investigating Process Safety Incidents, 3.ª ed. Wiley-AIChE.
  6. U.S. Chemical Safety and Hazard Investigation Board (2007). Investigation Report: Refinery Explosion and Fire, BP Texas City. Informe 2005-04-I-TX.
  7. U.S. Department of Energy (1992). DOE-NE-STD-1004-92, Root Cause Analysis Guidance Document.