El Árbol de Fallas en el Análisis Causa Raíz
29 de marzo de 2026
El Árbol de Fallas conocido en la literatura técnica como FTA, del inglés Fault Tree Analysis es una técnica deductiva que descompone a un evento no deseado en las combinaciones lógicas de causas que lo hacen posible, organizando esa información en un diagrama estructurado de arriba hacia abajo. Nació en los laboratorios Bell (En Estados Unidos) a comienzos de los años sesenta impulsado por la fuerza área, cuando ingenieros del proyecto Minuteman buscaban un método sistemático para evaluar la seguridad de sistemas de lanzamiento de misiles balísticos intercontinentales, y desde entonces migró hacia la industria de procesos haciéndose lugar y calificándose como uno de los instrumentos más rigurosos para el diagnóstico y la prevención de fallas funcionales en activos críticos.
Una parte distintiva de este método de los enfoques inductivos es el punto de partida.
-1777380475527.png%3Falt%3Dmedia%26token%3Da7315b49-b7ef-43b0-9cb6-c2c6cd6ec39e&w=2048&q=75)
En lugar de preguntarse qué puede pasar si un componente falla, el análisis comienza desde el sistema ya en estado de falla y trabaja hacia atrás, nivel por nivel, hasta llegar a las causas más básicas. Ese tipo de movimientos deductivos obligan a los analistas a construir cada rama del árbol con una lógica verificable, y no con suposiciones. En esa clase de entornos industriales donde la disponibilidad y la seguridad no admiten errores repetidos, este tipo de disciplinas metodológicas marcan las diferencias entre una corrección definitiva y una reparación que vuelve a ejecutarse cierto tiempo después formando un patrón verificable.
La construcción del diagrama parte de la definición más precisa que podamos realizar del evento tope a la negación de la función deseada del activo y su parte descendente a través de las compuertas lógicas como AND y OR hasta los eventos básicos con causas verificables que la organización puede atacar de forma directa. Cada nivel de descenso transforma una hipótesis en una afirmación respaldada por evidencia de campo.
Ninguna rama se cierra sin pasar por un proceso de validación técnica de una forma documentada que confirme o descarte el camino lógico propuesto.
En los términos del valor operativo, el árbol de fallas cumple con dos funciones complementarias.
Desde el análisis reactivo, permite reconstruir la trayectoria causal de un evento ya ocurrido y establecer la causa raíz con rigor científico auditable.
Desde el análisis proactivo, posibilita calcular la probabilidad de fallas futuras en sistemas complejos y de redundancias, apoyando decisiones de diseño o modificaciones de estrategias de mantenimiento antes de que el evento se materialice en la planta.
Fundamentos metodológicos del árbol de fallas en el RCA
El FTA se fundamenta matemáticamente en el álgebra de Boole, una estructura que trata el estado de cada componente o evento como una variable binaria: opera correctamente (1) o ha fallado (0).
Las relaciones entre esos estados se modelan mediante compuertas lógicas que determinan cómo los eventos de niveles inferiores se combinan para activar el evento del nivel superior. Esa base matemática es la que convierte el árbol de un mapa visual en un modelo cuantificable.

La compuerta OR (O) indica que el evento de salida se activa si cualquiera de sus entradas se cumple, representando rutas independientes hacia la falla.
La compuerta AND (Y), en cambio, requiere que todas sus entradas sean verdaderas simultáneamente, modelando sistemas con redundancias donde la coexistencia de varios fallos es condición necesaria para comprometer la función.
Además, existen compuertas XOR, NOT, AND y K/N que permiten modelar relaciones más complejas entre eventos, por ejemplo, XOR indica exclusividad entre causas, NOT representa la negación de una condición, AND exige la concurrencia de factores y K/N requiere que al menos K de N condiciones ocurran; su uso se justifica cuando la lógica de falla no se reduce a combinaciones simples y se necesita representar dependencias, exclusiones o umbrales de ocurrencia para mantener la trazabilidad del árbol.
Estas compuertas hacen parte de las diferencias que tienen consecuencias directas no solo en la representación gráfica sino en el cálculo probabilístico y en la priorización de las acciones correctivas.
Definición del evento tope y recolección de evidencia inicial
La construcción del árbol comienza a partir de la definición del evento tope o suceso superior, que debe describir de forma medible y acotada la negación observable de la función del activo; ya que, una definición que sea vaga o insuficiente, por ejemplo “falla general del equipo”, dificulta y prácticamente nos impide la ramificación lógica posterior porque no delimita qué causas son relevantes para el análisis, y esta precisión inicial condiciona y determina la calidad de todo lo que sigue después.
Una vez definido el evento tope, el Equipo Natural de Trabajo (ENT) recolecta evidencias siguiendo las cinco P´s de ProACT:
Empezando por la Posición que describe el contexto y la ubicación del equipo en el momento del evento, Personas que aporta testimonios y registros del personal involucrado, Partes que incluye los componentes disponibles para inspección física, Papel que reúne documentación técnica y bitácoras e historial de mantenimiento en el sistema CMMS, y Proceso que documenta las operaciones y procedimientos vigentes.
Esta recolección debe realizarse antes de que la reparación altere el entorno porque las evidencias físicas son la única fuente de datos que no puede reconstruirse una vez intervenido el equipo. Cuando los datos no estén disponibles, se puede complementar con el juicio de expertos, pero siempre conviene priorizar la evidencia directa para sostener las conclusiones del análisis.
Ramificación deductiva hacia los eventos intermedios y básicos
El anexo A de la normativa contiene la simbología completa que es utilizada en el Árbol de Fallas, mediante una división de 4 tablas; la primera contiene los más frecuentes, la segunda los más comunes para eventos y su descripción, la tercera a las compuertas estaticas, y por último las compuertas dinamicas
A partir del evento tope el análisis desciende por niveles jerárquicos y en cada nivel se responde qué condiciones previas fueron necesarias y suficientes para que ocurriera el suceso del nivel superior.
Los eventos intermedios se representan con rectángulos y describen fallas que resultan de la combinación de sucesos de nivel inferior mediante una compuerta lógica por lo que requieren desarrollo adicional.
En el nivel más bajo aparecen los eventos básicos representados con círculos que corresponden a causas sobre las que existe información de confiabilidad o sobre las que la organización puede actuar directamente sin seguir descendiendo.
El símbolo de diamante señala un evento no desarrollado ya sea porque la información es insuficiente o porque el suceso tiene bajo impacto para el objetivo del análisis.
Cuando el árbol supera el espacio de una hoja, los triángulos de transferencia permiten continuar el desarrollo en otra sección del informe sin perder la trazabilidad lógica del modelo. El analista debe avanzar en pasos pequeños y documentados evitando saltos directos desde el evento tope hasta una causa básica sin registrar la cadena de eventos intermedios que los conecta.
Construcción paso a paso del diagrama causal en la industria
La elaboración del árbol en un entorno industrial sigue la secuencia estructurada que la norma BS EN 62740 formaliza en cinco fases: iniciación, establecimiento de hechos, análisis, validación y presentación de resultados. En la fase de iniciación se evalúa si el evento justifica el análisis atendiendo impacto económico, riesgo de seguridad o recurrencia; a partir de esa evaluación se definen el propósito, el alcance y los límites del sistema bajo estudio y se establece la regla de parada, es decir el nivel de profundidad hasta el que se investigará en función de que las causas identificadas sean accionables por la organización.
En la fase de establecimiento de hechos se organiza la información en una línea de tiempo que muestra la evolución del incidente desde las primeras señales de degradación hasta el colapso funcional. A continuación se identifican los modos de falla observables y las señales registradas por los sistemas de control como SCADA, tendencias de temperatura o vibración sin interpretarlas inicialmente para evitar que juicios previos condicionen la ramificación del árbol; de este modo se preserva la evidencia y se garantiza que el análisis descienda por niveles lógicos y verificables.
Identificación de los modos de falla y condiciones latentes
"Un modo de falla es un evento único que causa una falla funcional." — Norma SAE JA1011, Sección 3.14 (Evaluation Criteria for Reliability-Centered Maintenance Processes)
Un modo de falla es un evento físico o proceso lógico único, razonablemente probable dentro de un contexto operacional específico, que conforma la causa directa de un estado de falla funcional (en una pérdida total o parcial de una función)
Por lo tanto, los modos de falla describen la forma observable en que un activo pierde su función. Puesto que, estos son prácticamente los hechos que observa y determina el custodio, lo que conforma el segundo nivel del árbol; por ejemplo: un eje que giró en reversa, un sello que perdió contención o una válvula que no cerró en el tiempo requerido.
Desde la visión de los fenómenos de fallas, identificarlos correctamente evita confundir síntoma con causa raíz porque una pieza fracturada puede deberse a fatiga, corrosión, sobrecarga o a la combinación de varios mecanismos y cada mecanismo conduce a una causa básica distinta. Así que, su forma de escribirlos correctamente depende del nivel de causalidad que se quiera llegar en el análisis; de su redacción la más recomendable es la combinación estructurada por el ítem mantenible y su mecanismo de daño (este último es el proceso físico, químico, estructural o termodinámico de deterioro).
Para profundizar un poco más en la interpretación de esta definición que es base muy importante para el análisis del RCM, es recomendable destacar lo siguiente:
Naturaleza del Evento: No debe confundirse con el estado de falla (la incapacidad de cumplir la función). El modo de falla es el suceso que provoca dicha transición de estado.
Profundidad Causal (Efecto del Binomio Ítem + Mecanismo): La descripción debe bajar hasta el mecanismo de daño (ej. fatiga, cavitación, corrosión). Si el análisis se detiene en un nivel muy superficial (ej. "bomba no arranca"), no se podrá identificar la tarea de mantenimiento óptima; si baja a un nivel atómico innecesario, el análisis se vuelve inmanejable y demasiado análisis se convierte en muchas horas de trabajo a su vez equivalentes a más dinero y a un derroche o malgasto de los recursos.
Contexto Operacional y Probabilidad: Solo deben incluirse aquellos eventos que son "razonablemente probables", lo cual abarca fallas históricas, fallas actualmente prevenidas por el plan vigente y fallas potenciales técnicamente creíbles en las condiciones reales de operación.
Inclusión Multicausal: El concepto integra tanto el deterioro físico natural del activo como los errores de diseño, de fabricación y los errores humanos cometidos por operadores o mantenedores, siempre que afecten la función del sistema
A medida que avanza el análisis, y se va descendiendo en el árbol se transita desde la causa física del daño hacia la intervención humana que la permitió o aceleró y luego hacia las condiciones latentes, es decir las debilidades del sistema de gestión que hicieron posible el error y que explican la recurrencia del evento independientemente de quién intervenga. Entre esas causas organizacionales se encuentran procedimientos desactualizados, falta de entrenamiento específico, políticas de compras que priorizan el costo sobre la especificación técnica y ausencia de revisión documental tras cambios de activo; por tanto, el análisis no debe detenerse en la pieza rota sino buscar las fallas sistémicas que la hicieron posible.
Cursos recomendados
Validación cruzada de las ramas mediante pruebas técnicas
Cada rama del árbol es inicialmente una hipótesis. Para cerrarla como causa confirmada o descartarla como camino sin sustento, el equipo aplica pruebas técnicas documentadas en una matriz de verificación que registra el método utilizado, el responsable y el resultado obtenido. Sin esa confirmación basada en datos duros, las conclusiones del análisis carecen de validez científica y el riesgo de recurrencia permanece latente detrás de una falsa sensación de cierre.
Para los equipos dinámicos, las herramientas de uso habitual incluyen análisis de vibraciones, termografía, análisis de ultrasonido y análisis tribológico de aceites.
Para equipos estáticos como tuberías y recipientes, se recurre a ensayos no destructivos: medición de espesores por ultrasonido, radiografía industrial, líquidos penetrantes o partículas magnéticas.
El resultado de cada prueba no solo confirma o descarta una hipótesis; también orienta la investigación hacia las ramas con evidencia de soporte, reduciendo progresivamente el número de caminos activos hasta aislar la causa raíz.
Integración del modelo visual con los reportes de mantenimiento
Un árbol de fallas produce conclusiones, pero sino retroalimenta a los sistemas de gestión pierde gran parte de su utilidad estratégica.
Los hallazgos del análisis se incorporan a los sistemas CMMS o EAM para actualizar los historiales del activo, modificar los planes de mantenimiento y registrar las lecciones aprendidas con trazabilidad. De este modo el conocimiento generado pase más alla del evento puntual y sirva como una base de decisiones futuras en equipos de la misma clase de familia.
El estándar ISO 14224 proporciona el marco de codificación uniforme necesario para que la información sea comparable entre activos, instalaciones y organizaciones. Al codificar modos de falla, mecanismos de deterioro y causas raíz bajo esa taxonomía se facilitan la identificación de patrones de recurrencia en familias de equipos y el ajuste de las estrategias de mantenimiento con datos reales de la planta en lugar de supuestos estadísticos genéricos.
Diferencias entre otros árboles que indica la EN 62740 y el árbol lógico de fallas
La Interacción de herramientas de análisis ramificado con el estándar BS EN 62740 y el árbol lógico:
El árbol de sucesos (ETA) parte de un evento iniciador y muestra las secuencias posibles de respuesta del sistema ante ese evento, evaluando la efectividad de las barreras de mitigación; pues se orienta hacia consecuencias, y no hacia causas. De este modo, también es posible intentar la combinación del FTA y ETA para generar un análisis causa‑consecuencia, que incorpora demoras temporales y permite estudiar fallos secuenciales con mayor profundidad dinámica que cada método por separado.
El método del árbol de causas (CTM) es una técnica reactiva que parte de un accidente ya ocurrido para remontar hacia las causas comprobadas sin desarrollar relaciones lógicas formales mediante compuertas booleanas. A diferencia del FTA que puede emplearse de forma proactiva en la fase de diseño, el CTM se limita a los factores causales reales del evento analizado.
En los diferentes modelos de las metodologías de RCA como PROACT el árbol lógico de fallas se diferencia del FTA probabilístico porque exige que cada nodo sea un hecho verificado, y no una suposición; en un RCA industrial post‑evento cada nodo debe estar anclado en evidencia antes de fundamentar una acción correctiva que modifique el sistema de gestión.
Ejemplo práctico de construcción en un activo crítico
Para demostrar la secuencia de construcción del Árbol de Fallas (FTA) en un contexto operativo, se analiza el caso de la Bomba Centrífuga TB-3 en una estación de rebombeo industrial, clasificada según la ISO 14224 como equipo rotatorio en la categoría de transferencia de fluidos de proceso.

El activo presentó tres paros no programados por la falla del sello mecánico doble en un período de 18 meses, lo que superó el umbral de recurrencia establecido y justificó el análisis mediante FTA.

El diagrama interactivo completo, incluirá en las proximas etapas a las compuertas en cada nivel, la tabla de validación y las acciones correctivas por tipo de causa, está disponible en la herramienta visual adjunta a este artículo.
Planteamiento de la falla funcional y formulación de teorías
El evento tope se definió con la mayor precisión técnica posible: paro no programado de la TB-3 por falla del sello mecánico doble bajo condiciones de operación nominal. Ese enunciado evita ambigüedades y acota el análisis a las condiciones reales del activo, descartando desde el inicio factores externos fuera de los límites del sistema definido bajo ISO 14224.
Bajo ese evento tope, la primera capa del árbol conecta tres ramas mediante una compuerta OR: alta temperatura en la zona del sello, vibración excesiva en el eje y contaminación del fluido de sello.
Los dos primeros se clasificaron como eventos intermedios que requieren desarrollo y verificación adicionales; el tercero quedó señalado con diamante por ausencia de evidencia analítica en el momento del análisis.
Con la ponderación inicial, basada en el historial del activo y el criterio del Equipo Natural de Trabajo (ENT), se concentró la atención en las ramas de temperatura y vibración como los caminos más probables de validación, priorizando pruebas y muestreos que permitan confirmar o descartar esas hipótesis antes de avanzar hacia causas básicas y acciones correctivas.
Descarte de ramas falsas y confirmación de la raíz física
El análisis espectral de vibración mostró una señal característica de desalineación angular que aumentaba con la temperatura de operación del equipo, por lo que se priorizó investigar la interacción entre calor y geometría del acoplamiento; al revisar el procedimiento de alineación vigente, versión 3 con cuatro años sin actualizar, se constató que no incluía el coeficiente de corrección térmica aplicable a las bombas TB-3, de modo que los técnicos actuaron conforme al documento y no hubo error en la ejecución, y esto demuestra que la brecha técnica está en la documentación y no en la práctica operativa.



La rama de alta temperatura se reposicionó como efecto secundario de la vibración, mientras que la rama de contaminación se eliminó tras el análisis del fluido en el depósito colector; en consecuencia la causa raíz física confirmada fue la desalineación dinámica producida por la expansión térmica del eje sin compensación y la causa latente fue el procedimiento desactualizado que no contemplaba esa corrección. Esto demuestra la distinción entre el mecanismo físico del fallo y la condición organizacional que lo perpetúa, y por tanto ilustra cómo el árbol de fallas permite identificar con claridad el origen para que las acciones correctivas ataquen la raíz y no el síntoma.

Conclusión
El árbol de fallas sin duda alguna es más que un diagrama de causas porque obliga a cada hipótesis a enfrentarse con la evidencia; por tanto la validación convierte la investigación en una actividad científica y replicable, de modo que dos analistas que trabajen con los mismos datos deben llegar a las mismas conclusiones. Esta rigurosidad es la que diferencia un análisis que reduce la recurrencia de uno que solo documenta lo conocido sin cambiar nada de fondo.
Desde la gestión de activos el valor del FTA surge con el tiempo porque al codificar los hallazgos bajo ISO 14224 e integrarlos en el CMMS se construye una base de datos reales. Así se identifican causas comunes en familias de equipos y se ajustan las estrategias de mantenimiento con información operativa en lugar de supuestos estadísticos; en consecuencia cada árbol bien construido deja a la planta un conocimiento que antes no existía.
Para quien avanza en ingeniería de confiabilidad dominar la técnica permite cuantificar el riesgo en términos probabilísticos, calcular conjuntos de corte mínimos y justificar inversiones en redundancias con fundamento matemático.
Dinos qué te ha parecido el artículo
El Árbol de Fallas en el Análisis Causa Raíz
29 de marzo de 2026El Árbol de Fallas conocido en la literatura técnica como FTA, del inglés Fault Tree Analysis es una técnica deductiva que descompone a un evento no deseado en las combinaciones lógicas de causas que lo hacen posible, organizando esa información en un diagrama estructurado de arriba hacia abajo. Nació en los laboratorios Bell (En Estados Unidos) a comienzos de los años sesenta impulsado por la fuerza área, cuando ingenieros del proyecto Minuteman buscaban un método sistemático para evaluar la seguridad de sistemas de lanzamiento de misiles balísticos intercontinentales, y desde entonces migró hacia la industria de procesos haciéndose lugar y calificándose como uno de los instrumentos más rigurosos para el diagnóstico y la prevención de fallas funcionales en activos críticos.
Una parte distintiva de este método de los enfoques inductivos es el punto de partida.
-1777380475527.png%3Falt%3Dmedia%26token%3Da7315b49-b7ef-43b0-9cb6-c2c6cd6ec39e&w=2048&q=75)
En lugar de preguntarse qué puede pasar si un componente falla, el análisis comienza desde el sistema ya en estado de falla y trabaja hacia atrás, nivel por nivel, hasta llegar a las causas más básicas. Ese tipo de movimientos deductivos obligan a los analistas a construir cada rama del árbol con una lógica verificable, y no con suposiciones. En esa clase de entornos industriales donde la disponibilidad y la seguridad no admiten errores repetidos, este tipo de disciplinas metodológicas marcan las diferencias entre una corrección definitiva y una reparación que vuelve a ejecutarse cierto tiempo después formando un patrón verificable.
La construcción del diagrama parte de la definición más precisa que podamos realizar del evento tope a la negación de la función deseada del activo y su parte descendente a través de las compuertas lógicas como AND y OR hasta los eventos básicos con causas verificables que la organización puede atacar de forma directa. Cada nivel de descenso transforma una hipótesis en una afirmación respaldada por evidencia de campo.
Ninguna rama se cierra sin pasar por un proceso de validación técnica de una forma documentada que confirme o descarte el camino lógico propuesto.
En los términos del valor operativo, el árbol de fallas cumple con dos funciones complementarias.
Desde el análisis reactivo, permite reconstruir la trayectoria causal de un evento ya ocurrido y establecer la causa raíz con rigor científico auditable.
Desde el análisis proactivo, posibilita calcular la probabilidad de fallas futuras en sistemas complejos y de redundancias, apoyando decisiones de diseño o modificaciones de estrategias de mantenimiento antes de que el evento se materialice en la planta.
Fundamentos metodológicos del árbol de fallas en el RCA
El FTA se fundamenta matemáticamente en el álgebra de Boole, una estructura que trata el estado de cada componente o evento como una variable binaria: opera correctamente (1) o ha fallado (0).
Las relaciones entre esos estados se modelan mediante compuertas lógicas que determinan cómo los eventos de niveles inferiores se combinan para activar el evento del nivel superior. Esa base matemática es la que convierte el árbol de un mapa visual en un modelo cuantificable.

La compuerta OR (O) indica que el evento de salida se activa si cualquiera de sus entradas se cumple, representando rutas independientes hacia la falla.
La compuerta AND (Y), en cambio, requiere que todas sus entradas sean verdaderas simultáneamente, modelando sistemas con redundancias donde la coexistencia de varios fallos es condición necesaria para comprometer la función.
Además, existen compuertas XOR, NOT, AND y K/N que permiten modelar relaciones más complejas entre eventos, por ejemplo, XOR indica exclusividad entre causas, NOT representa la negación de una condición, AND exige la concurrencia de factores y K/N requiere que al menos K de N condiciones ocurran; su uso se justifica cuando la lógica de falla no se reduce a combinaciones simples y se necesita representar dependencias, exclusiones o umbrales de ocurrencia para mantener la trazabilidad del árbol.
Estas compuertas hacen parte de las diferencias que tienen consecuencias directas no solo en la representación gráfica sino en el cálculo probabilístico y en la priorización de las acciones correctivas.
Definición del evento tope y recolección de evidencia inicial
La construcción del árbol comienza a partir de la definición del evento tope o suceso superior, que debe describir de forma medible y acotada la negación observable de la función del activo; ya que, una definición que sea vaga o insuficiente, por ejemplo “falla general del equipo”, dificulta y prácticamente nos impide la ramificación lógica posterior porque no delimita qué causas son relevantes para el análisis, y esta precisión inicial condiciona y determina la calidad de todo lo que sigue después.
Una vez definido el evento tope, el Equipo Natural de Trabajo (ENT) recolecta evidencias siguiendo las cinco P´s de ProACT:
Empezando por la Posición que describe el contexto y la ubicación del equipo en el momento del evento, Personas que aporta testimonios y registros del personal involucrado, Partes que incluye los componentes disponibles para inspección física, Papel que reúne documentación técnica y bitácoras e historial de mantenimiento en el sistema CMMS, y Proceso que documenta las operaciones y procedimientos vigentes.
Esta recolección debe realizarse antes de que la reparación altere el entorno porque las evidencias físicas son la única fuente de datos que no puede reconstruirse una vez intervenido el equipo. Cuando los datos no estén disponibles, se puede complementar con el juicio de expertos, pero siempre conviene priorizar la evidencia directa para sostener las conclusiones del análisis.
Ramificación deductiva hacia los eventos intermedios y básicos
El anexo A de la normativa contiene la simbología completa que es utilizada en el Árbol de Fallas, mediante una división de 4 tablas; la primera contiene los más frecuentes, la segunda los más comunes para eventos y su descripción, la tercera a las compuertas estaticas, y por último las compuertas dinamicas
A partir del evento tope el análisis desciende por niveles jerárquicos y en cada nivel se responde qué condiciones previas fueron necesarias y suficientes para que ocurriera el suceso del nivel superior.
Los eventos intermedios se representan con rectángulos y describen fallas que resultan de la combinación de sucesos de nivel inferior mediante una compuerta lógica por lo que requieren desarrollo adicional.
En el nivel más bajo aparecen los eventos básicos representados con círculos que corresponden a causas sobre las que existe información de confiabilidad o sobre las que la organización puede actuar directamente sin seguir descendiendo.
El símbolo de diamante señala un evento no desarrollado ya sea porque la información es insuficiente o porque el suceso tiene bajo impacto para el objetivo del análisis.
Cuando el árbol supera el espacio de una hoja, los triángulos de transferencia permiten continuar el desarrollo en otra sección del informe sin perder la trazabilidad lógica del modelo. El analista debe avanzar en pasos pequeños y documentados evitando saltos directos desde el evento tope hasta una causa básica sin registrar la cadena de eventos intermedios que los conecta.
Construcción paso a paso del diagrama causal en la industria
La elaboración del árbol en un entorno industrial sigue la secuencia estructurada que la norma BS EN 62740 formaliza en cinco fases: iniciación, establecimiento de hechos, análisis, validación y presentación de resultados. En la fase de iniciación se evalúa si el evento justifica el análisis atendiendo impacto económico, riesgo de seguridad o recurrencia; a partir de esa evaluación se definen el propósito, el alcance y los límites del sistema bajo estudio y se establece la regla de parada, es decir el nivel de profundidad hasta el que se investigará en función de que las causas identificadas sean accionables por la organización.
En la fase de establecimiento de hechos se organiza la información en una línea de tiempo que muestra la evolución del incidente desde las primeras señales de degradación hasta el colapso funcional. A continuación se identifican los modos de falla observables y las señales registradas por los sistemas de control como SCADA, tendencias de temperatura o vibración sin interpretarlas inicialmente para evitar que juicios previos condicionen la ramificación del árbol; de este modo se preserva la evidencia y se garantiza que el análisis descienda por niveles lógicos y verificables.
Identificación de los modos de falla y condiciones latentes
"Un modo de falla es un evento único que causa una falla funcional." — Norma SAE JA1011, Sección 3.14 (Evaluation Criteria for Reliability-Centered Maintenance Processes)
Un modo de falla es un evento físico o proceso lógico único, razonablemente probable dentro de un contexto operacional específico, que conforma la causa directa de un estado de falla funcional (en una pérdida total o parcial de una función)
Por lo tanto, los modos de falla describen la forma observable en que un activo pierde su función. Puesto que, estos son prácticamente los hechos que observa y determina el custodio, lo que conforma el segundo nivel del árbol; por ejemplo: un eje que giró en reversa, un sello que perdió contención o una válvula que no cerró en el tiempo requerido.
Desde la visión de los fenómenos de fallas, identificarlos correctamente evita confundir síntoma con causa raíz porque una pieza fracturada puede deberse a fatiga, corrosión, sobrecarga o a la combinación de varios mecanismos y cada mecanismo conduce a una causa básica distinta. Así que, su forma de escribirlos correctamente depende del nivel de causalidad que se quiera llegar en el análisis; de su redacción la más recomendable es la combinación estructurada por el ítem mantenible y su mecanismo de daño (este último es el proceso físico, químico, estructural o termodinámico de deterioro).
Para profundizar un poco más en la interpretación de esta definición que es base muy importante para el análisis del RCM, es recomendable destacar lo siguiente:
Naturaleza del Evento: No debe confundirse con el estado de falla (la incapacidad de cumplir la función). El modo de falla es el suceso que provoca dicha transición de estado.
Profundidad Causal (Efecto del Binomio Ítem + Mecanismo): La descripción debe bajar hasta el mecanismo de daño (ej. fatiga, cavitación, corrosión). Si el análisis se detiene en un nivel muy superficial (ej. "bomba no arranca"), no se podrá identificar la tarea de mantenimiento óptima; si baja a un nivel atómico innecesario, el análisis se vuelve inmanejable y demasiado análisis se convierte en muchas horas de trabajo a su vez equivalentes a más dinero y a un derroche o malgasto de los recursos.
Contexto Operacional y Probabilidad: Solo deben incluirse aquellos eventos que son "razonablemente probables", lo cual abarca fallas históricas, fallas actualmente prevenidas por el plan vigente y fallas potenciales técnicamente creíbles en las condiciones reales de operación.
Inclusión Multicausal: El concepto integra tanto el deterioro físico natural del activo como los errores de diseño, de fabricación y los errores humanos cometidos por operadores o mantenedores, siempre que afecten la función del sistema
A medida que avanza el análisis, y se va descendiendo en el árbol se transita desde la causa física del daño hacia la intervención humana que la permitió o aceleró y luego hacia las condiciones latentes, es decir las debilidades del sistema de gestión que hicieron posible el error y que explican la recurrencia del evento independientemente de quién intervenga. Entre esas causas organizacionales se encuentran procedimientos desactualizados, falta de entrenamiento específico, políticas de compras que priorizan el costo sobre la especificación técnica y ausencia de revisión documental tras cambios de activo; por tanto, el análisis no debe detenerse en la pieza rota sino buscar las fallas sistémicas que la hicieron posible.
Cursos recomendados
Validación cruzada de las ramas mediante pruebas técnicas
Cada rama del árbol es inicialmente una hipótesis. Para cerrarla como causa confirmada o descartarla como camino sin sustento, el equipo aplica pruebas técnicas documentadas en una matriz de verificación que registra el método utilizado, el responsable y el resultado obtenido. Sin esa confirmación basada en datos duros, las conclusiones del análisis carecen de validez científica y el riesgo de recurrencia permanece latente detrás de una falsa sensación de cierre.
Para los equipos dinámicos, las herramientas de uso habitual incluyen análisis de vibraciones, termografía, análisis de ultrasonido y análisis tribológico de aceites.
Para equipos estáticos como tuberías y recipientes, se recurre a ensayos no destructivos: medición de espesores por ultrasonido, radiografía industrial, líquidos penetrantes o partículas magnéticas.
El resultado de cada prueba no solo confirma o descarta una hipótesis; también orienta la investigación hacia las ramas con evidencia de soporte, reduciendo progresivamente el número de caminos activos hasta aislar la causa raíz.
Integración del modelo visual con los reportes de mantenimiento
Un árbol de fallas produce conclusiones, pero sino retroalimenta a los sistemas de gestión pierde gran parte de su utilidad estratégica.
Los hallazgos del análisis se incorporan a los sistemas CMMS o EAM para actualizar los historiales del activo, modificar los planes de mantenimiento y registrar las lecciones aprendidas con trazabilidad. De este modo el conocimiento generado pase más alla del evento puntual y sirva como una base de decisiones futuras en equipos de la misma clase de familia.
El estándar ISO 14224 proporciona el marco de codificación uniforme necesario para que la información sea comparable entre activos, instalaciones y organizaciones. Al codificar modos de falla, mecanismos de deterioro y causas raíz bajo esa taxonomía se facilitan la identificación de patrones de recurrencia en familias de equipos y el ajuste de las estrategias de mantenimiento con datos reales de la planta en lugar de supuestos estadísticos genéricos.
Diferencias entre otros árboles que indica la EN 62740 y el árbol lógico de fallas
La Interacción de herramientas de análisis ramificado con el estándar BS EN 62740 y el árbol lógico:
El árbol de sucesos (ETA) parte de un evento iniciador y muestra las secuencias posibles de respuesta del sistema ante ese evento, evaluando la efectividad de las barreras de mitigación; pues se orienta hacia consecuencias, y no hacia causas. De este modo, también es posible intentar la combinación del FTA y ETA para generar un análisis causa‑consecuencia, que incorpora demoras temporales y permite estudiar fallos secuenciales con mayor profundidad dinámica que cada método por separado.
El método del árbol de causas (CTM) es una técnica reactiva que parte de un accidente ya ocurrido para remontar hacia las causas comprobadas sin desarrollar relaciones lógicas formales mediante compuertas booleanas. A diferencia del FTA que puede emplearse de forma proactiva en la fase de diseño, el CTM se limita a los factores causales reales del evento analizado.
En los diferentes modelos de las metodologías de RCA como PROACT el árbol lógico de fallas se diferencia del FTA probabilístico porque exige que cada nodo sea un hecho verificado, y no una suposición; en un RCA industrial post‑evento cada nodo debe estar anclado en evidencia antes de fundamentar una acción correctiva que modifique el sistema de gestión.
Ejemplo práctico de construcción en un activo crítico
Para demostrar la secuencia de construcción del Árbol de Fallas (FTA) en un contexto operativo, se analiza el caso de la Bomba Centrífuga TB-3 en una estación de rebombeo industrial, clasificada según la ISO 14224 como equipo rotatorio en la categoría de transferencia de fluidos de proceso.

El activo presentó tres paros no programados por la falla del sello mecánico doble en un período de 18 meses, lo que superó el umbral de recurrencia establecido y justificó el análisis mediante FTA.

El diagrama interactivo completo, incluirá en las proximas etapas a las compuertas en cada nivel, la tabla de validación y las acciones correctivas por tipo de causa, está disponible en la herramienta visual adjunta a este artículo.
Planteamiento de la falla funcional y formulación de teorías
El evento tope se definió con la mayor precisión técnica posible: paro no programado de la TB-3 por falla del sello mecánico doble bajo condiciones de operación nominal. Ese enunciado evita ambigüedades y acota el análisis a las condiciones reales del activo, descartando desde el inicio factores externos fuera de los límites del sistema definido bajo ISO 14224.
Bajo ese evento tope, la primera capa del árbol conecta tres ramas mediante una compuerta OR: alta temperatura en la zona del sello, vibración excesiva en el eje y contaminación del fluido de sello.
Los dos primeros se clasificaron como eventos intermedios que requieren desarrollo y verificación adicionales; el tercero quedó señalado con diamante por ausencia de evidencia analítica en el momento del análisis.
Con la ponderación inicial, basada en el historial del activo y el criterio del Equipo Natural de Trabajo (ENT), se concentró la atención en las ramas de temperatura y vibración como los caminos más probables de validación, priorizando pruebas y muestreos que permitan confirmar o descartar esas hipótesis antes de avanzar hacia causas básicas y acciones correctivas.
Descarte de ramas falsas y confirmación de la raíz física
El análisis espectral de vibración mostró una señal característica de desalineación angular que aumentaba con la temperatura de operación del equipo, por lo que se priorizó investigar la interacción entre calor y geometría del acoplamiento; al revisar el procedimiento de alineación vigente, versión 3 con cuatro años sin actualizar, se constató que no incluía el coeficiente de corrección térmica aplicable a las bombas TB-3, de modo que los técnicos actuaron conforme al documento y no hubo error en la ejecución, y esto demuestra que la brecha técnica está en la documentación y no en la práctica operativa.



La rama de alta temperatura se reposicionó como efecto secundario de la vibración, mientras que la rama de contaminación se eliminó tras el análisis del fluido en el depósito colector; en consecuencia la causa raíz física confirmada fue la desalineación dinámica producida por la expansión térmica del eje sin compensación y la causa latente fue el procedimiento desactualizado que no contemplaba esa corrección. Esto demuestra la distinción entre el mecanismo físico del fallo y la condición organizacional que lo perpetúa, y por tanto ilustra cómo el árbol de fallas permite identificar con claridad el origen para que las acciones correctivas ataquen la raíz y no el síntoma.

Conclusión
El árbol de fallas sin duda alguna es más que un diagrama de causas porque obliga a cada hipótesis a enfrentarse con la evidencia; por tanto la validación convierte la investigación en una actividad científica y replicable, de modo que dos analistas que trabajen con los mismos datos deben llegar a las mismas conclusiones. Esta rigurosidad es la que diferencia un análisis que reduce la recurrencia de uno que solo documenta lo conocido sin cambiar nada de fondo.
Desde la gestión de activos el valor del FTA surge con el tiempo porque al codificar los hallazgos bajo ISO 14224 e integrarlos en el CMMS se construye una base de datos reales. Así se identifican causas comunes en familias de equipos y se ajustan las estrategias de mantenimiento con información operativa en lugar de supuestos estadísticos; en consecuencia cada árbol bien construido deja a la planta un conocimiento que antes no existía.
Para quien avanza en ingeniería de confiabilidad dominar la técnica permite cuantificar el riesgo en términos probabilísticos, calcular conjuntos de corte mínimos y justificar inversiones en redundancias con fundamento matemático.
Dinos qué te ha parecido el artículo



%252FRAMPREDYC.webp%3Falt%3Dmedia%26token%3D0ef608dc-cd45-4601-a211-997dda9326df&w=3840&q=75)




