Análisis de fallos aplicado a la ingeniería: metodología, evidencias, mecanismos, causas, ensayos, RCA, FMEA, FTA, gobernanza y acciones correctivas.
¡Descúbrelo!
El análisis de fallos es el proceso técnico utilizado para comprender por qué un elemento, sistema o proceso dejó de cumplir la función requerida, qué mecanismos contribuyeron al evento, qué evidencias respaldan la conclusión y qué acciones son necesarias para reducir la probabilidad de recurrencia. El objetivo no es simplemente identificar un componente que falló, sino reconstruir la secuencia del evento de forma técnicamente defendible.
Un análisis consistente distingue ocurrencia, síntoma, modo de fallo, mecanismo físico o lógico, causa, factores contribuyentes y consecuencia. Esta separación es esencial porque sustituir el componente que quedó en estado de fallo puede restablecer la función sin eliminar la condición que originó el evento. En sistemas complejos, la causa puede estar en el diseño, la instalación, el entorno, la operación, el mantenimiento, la configuración, los suministros, el software, la interfaz entre disciplinas o el proceso de decisión.
Por ello, el análisis de fallos no es sinónimo de RCA, FMEA o FTA. El análisis de fallos es un proceso de investigación más amplio. La RCA puede formar parte de ese proceso cuando es necesario identificar las causas raíz de un evento ocurrido; la FMEA es predominantemente preventiva y parte de los modos de fallo posibles; la FTA parte de un evento superior e investiga combinaciones causales. Cada técnica responde a una pregunta diferente.
En organizaciones intensivas en activos, el análisis de fallos también es una herramienta de gobernanza. Transforma eventos de campo en evidencias para revisar diseño, mantenimiento, criterios de operación, repuestos, contratos, normas técnicas, datos de activos y decisiones de ciclo de vida. Cuando se formaliza, deja de ser una actividad reactiva aislada y pasa a alimentar un sistema continuo de confiabilidad y mejora.
Fallo, estado de fallo, defecto, causa y mecanismo: por qué importa la terminología
La ABNT NBR 5462 establece una distinción importante entre conceptos que con frecuencia se utilizan como sinónimos. Un fallo es el evento que termina la capacidad de un elemento para desempeñar una función requerida. El estado de fallo es la condición resultante de incapacidad para desempeñar dicha función. Un defecto es una desviación de una característica respecto de un requisito y puede existir sin provocar un fallo inmediato.
La norma también diferencia causa de fallo y mecanismo de fallo. La causa está asociada a las circunstancias de diseño, fabricación o uso que conducen al evento. El mecanismo es el proceso físico, químico, eléctrico, lógico o de otra naturaleza que efectivamente conduce a la pérdida de la función. Esta distinción es decisiva para evitar conclusiones superficiales.
| Concepto | Pregunta de ingeniería |
| Defecto | ¿Qué requisito o característica está fuera de lo esperado? |
| Fallo | ¿Qué función dejó de cumplirse y en qué momento? |
| Estado de fallo | ¿En qué condición de incapacidad quedó el elemento después del fallo? |
| Modo de fallo | ¿Cómo se manifestó la pérdida de la función? |
| Mecanismo de fallo | ¿Qué proceso produjo la degradación o rotura? |
| Causa | ¿Qué circunstancias permitieron o provocaron el mecanismo? |
| Consecuencia | ¿Qué efecto operativo, económico, de seguridad o conformidad resultó? |
Esta disciplina terminológica conecta el análisis con la Ingeniería de Confiabilidad y Disponibilidad y con el contenido sobre Ingeniería de Mantenimiento, porque permite relacionar eventos reales con modos de fallo, estrategias de mantenimiento y requisitos de desempeño.
Cuándo un fallo requiere una investigación estructurada
No todo estado de fallo exige una investigación completa. El nivel de profundidad debe ser proporcional a la criticidad, recurrencia, incertidumbre y consecuencia. Una sustitución simple puede ser suficiente para un elemento no crítico cuya causa es conocida y cuyo riesgo residual es bajo. En cambio, los eventos que implican seguridad, indisponibilidad relevante, fallos repetitivos, impacto contractual o causa desconocida requieren un tratamiento diferente.
Los criterios típicos para abrir un análisis estructurado incluyen:
- fallo en un activo o función crítica;
- recurrencia del mismo modo de fallo;
- consecuencia de seguridad, medio ambiente o conformidad;
- indisponibilidad o pérdida de producción relevante;
- ocurrencia en equipos nuevos, recién comisionados o en garantía;
- divergencia entre el comportamiento observado y las premisas de diseño;
- fallo simultáneo o aparentemente común en sistemas redundantes;
- evento cuya causa continúa siendo incierta después del diagnóstico de mantenimiento;
- necesidad de sustentar una decisión contractual, técnica o de inversión.
El Análisis de Criticidad de Activos ayuda a definir cuándo movilizar recursos de investigación. En organizaciones de mayor tamaño, el disparador puede formalizarse mediante la Gestión de Procesos, Workflows y Aprobaciones Técnicas, evitando que eventos relevantes se cierren únicamente como órdenes correctivas.
Preservación de evidencias: el primer paso del análisis
Uno de los fallos más comunes del propio proceso de investigación ocurre antes de que empiece el análisis: el equipo se desmonta, limpia, reconfigura, reinicia o descarta sin un registro adecuado de la condición encontrada. Esto puede destruir evidencias críticas y hacer imposible distinguir la causa de la consecuencia.
La condición as found debe preservarse en la medida compatible con la seguridad y la continuidad operativa. El registro puede incluir fotografías, posición de interruptores, alarmas, logs, temperatura, estado de las protecciones, configuración, firmware, historial reciente de intervenciones, diagramas, tendencias de proceso, calidad de energía, piezas retiradas, rastros físicos y testimonios de los equipos implicados.
En entornos digitales o automatizados, la preservación puede incluir logs de servidores, switches, VMS, PLC, relés, BMS, SCADA, sistemas de monitorización y plataformas de gestión. En equipos electromecánicos, puede incluir mediciones, muestras de aceite, superficies de fractura, residuos, holguras, desgaste, aislamiento, par de apriete, vibración o termografía.
Cuando el análisis tiene implicaciones contractuales, de garantía o de seguridad, la gobernanza de la evidencia debe ser aún más rigurosa. La Gestión de Requisitos, Evidencias y Criterios de Aceptación y la Gobernanza Documental permiten controlar origen, versión, autoría, integridad y trazabilidad de los registros utilizados en la conclusión.
Cómo estructurar un análisis de fallos paso a paso
Una investigación técnicamente consistente puede organizarse en la siguiente secuencia de trabajo:
1. Definir la función perdida y el evento analizado. Evitar descripciones vagas como “el equipo se quemó”. 2. Establecer la frontera del sistema. Definir equipos, interfaces, utilidades, software, personas y condiciones incluidas. 3. Preservar y registrar la condición encontrada. Documentar evidencias antes de modificar el sistema. 4. Construir la cronología. Relacionar operación, alarmas, intervenciones, cambios y eventos antecedentes. 5. Caracterizar el modo de fallo. Describir cómo se manifestó la pérdida de la función. 6. Formular hipótesis. Enumerar mecanismos y causas técnicamente plausibles. 7. Seleccionar ensayos y verificaciones. Buscar evidencias capaces de confirmar o refutar cada hipótesis. 8. Reconstruir la cadena causal. Separar causa inmediata, mecanismo, factores contribuyentes y causas sistémicas. 9. Evaluar la extensión de la condición. Verificar si el problema puede existir en activos similares, redundantes o instalados bajo la misma premisa. 10. Definir acciones. Tratar contención, corrección, prevención, rediseño, revisión de planes, datos o procesos. 11. Validar la eficacia. Confirmar si las acciones realmente redujeron el riesgo o eliminaron la condición. 12. Registrar el aprendizaje. Actualizar documentación, normas, planes, registros, requisitos y lecciones aprendidas.
Esta secuencia puede adaptarse al tipo de activo. Su valor está en mantener la trazabilidad entre evidencia → hipótesis → ensayo → conclusión → acción.
Una hipótesis plausible no es una causa demostrada. Las investigaciones críticas deben preservar evidencias, probar explicaciones alternativas y mantener trazabilidad entre hipótesis, ensayo y conclusión.
Hipótesis y verificación: evitar conclusiones por plausibilidad
Una hipótesis técnicamente plausible no es una causa demostrada. En la investigación de fallos es común que un equipo reconozca un patrón familiar y cierre el análisis antes de probar explicaciones alternativas. Este sesgo puede reforzarse cuando la primera hipótesis es presentada por alguien con gran autoridad técnica o cuando la solución propuesta resulta operativamente conveniente.
El método debe buscar evidencias que confirmen y también puedan refutar cada hipótesis. Si la causa propuesta es sobretemperatura, deben verificarse señales térmicas, condiciones de ventilación, carga, protección, entorno e historial. Si la hipótesis es un error de configuración, deben compararse copias de seguridad, logs, revisiones, permisos, cambios y comportamiento del sistema. Si la hipótesis es un fallo de alimentación, el análisis debe considerar calidad de energía, protección, coordinación, conexiones y eventos aguas arriba.
La lógica es similar a la utilizada en Root Cause Analysis — RCA, pero el análisis de fallos puede finalizar antes de una RCA completa cuando el objetivo es caracterizar técnicamente el modo y el mecanismo. Cuando el evento posee causas organizativas, humanas o de proceso relevantes, la RCA amplía la investigación.
Ensayos y datos que pueden sustentar la investigación
No existe un paquete universal de ensayos. Los métodos dependen de la tecnología, del mecanismo sospechado y de la evidencia disponible. En distintas disciplinas, un análisis puede recurrir a:
| Dominio | Ejemplos de evidencias y técnicas |
| Eléctrica | oscilografía, calidad de energía, resistencia de aislamiento, termografía, coordinación de protecciones, registros de relés |
| Mecánica | vibración, alineación, análisis de aceite, metalografía, fractura, desgaste, holguras, ensayos no destructivos |
| Automatización | logs de PLC/SCADA, secuencia de eventos, estados de I/O, firmware, lógica e historial de cambios |
| Redes y telecomunicaciones | syslog, SNMP, NetFlow, errores de interfaz, pérdida óptica, OTDR, topología, redundancia, configuraciones |
| Data Center | BMS/DCIM, eventos UPS/STS/PDU, temperatura, carga, baterías, generadores, alarmas y transferencias |
| Seguridad electrónica | logs de VMS, almacenamiento, cámaras, controladoras, red, sincronización, grabación y eventos de integración |
A3A Engenharia actúa transversalmente en infraestructura crítica, lo que permite conectar el análisis con la arquitectura del sistema. Proyectos como el monitoreo operativo para soporte a teleasistencia en subestación, el FEED de telecomunicaciones en una central hidroeléctrica y la implantación turnkey de videomonitorización en un complejo gubernamental ejemplifican entornos en los que la función depende de interfaces entre energía, redes, software, infraestructura y operación.
Análisis de fallos, RCA, FMEA, FTA y RAM
Las técnicas son complementarias, pero no deben utilizarse como nombres diferentes para el mismo análisis.
| Técnica | Punto de partida | Pregunta central |
| Análisis de Fallos | evento, componente o función perdida | ¿qué falló, cómo ocurrió y qué evidencias explican el mecanismo? |
| RCA | evento ocurrido | ¿por qué ocurrió el evento y qué causas deben eliminarse? |
| FMEA/FMECA | elemento, función o proceso | ¿cómo puede fallar y qué efectos y criticidades resultan? |
| FTA | evento superior | ¿qué combinaciones pueden producir ese evento? |
| RAM | arquitectura y datos de fallo/reparación | ¿qué confiabilidad, disponibilidad y mantenibilidad entrega el sistema? |
La FMEA ayuda a verificar si el modo observado ya estaba previsto y qué barreras deberían existir. La FTA es útil cuando el evento depende de combinaciones o redundancias. El Análisis RAM permite evaluar el efecto de fallos y reparaciones sobre el desempeño sistémico. El Análisis de Weibull ayuda cuando el comportamiento estadístico a lo largo del tiempo es relevante.
Del fallo técnico a la causa sistémica
Una investigación madura no se detiene en la pieza dañada. Un contactor puede haber fallado por calentamiento, pero el calentamiento puede estar relacionado con un apriete inadecuado, especificación incorrecta, sobrecarga, ventilación insuficiente, calidad de instalación o mantenimiento inadecuado. Una placa electrónica puede presentar daños, pero la causa dominante puede estar en una sobretensión, la puesta a tierra, el entorno, el firmware o la alimentación auxiliar.
Por ello, resulta útil distinguir al menos cuatro niveles:
- efecto observado: lo que percibió la operación;
- modo/mecanismo: cómo el elemento perdió la función;
- causa técnica: condición que originó o permitió el mecanismo;
- causa sistémica: proceso, requisito, decisión o gobernanza que permitió que la condición permaneciera.
Esta última capa aproxima el análisis a Technical Authority en Ingeniería, Project Assurance y Gestión de Ingeniería. La recurrencia muchas veces no deriva de falta de conocimiento técnico, sino de la ausencia de un proceso que transforme conocimiento en decisiones controladas.
Un fallo relevante debe generar evidencia de ingeniería, no solo una orden correctiva. Criterios, responsables, versiones, conclusiones y acciones deben permanecer trazables para sustentar decisiones y auditorías futuras.
Conozca Gestión de Requisitos, Evidencias y Criterios de Aceptación →
Gobernanza del análisis: roles, independencia y trazabilidad
Los análisis con impacto relevante necesitan una gobernanza proporcional. Debe existir un responsable de la investigación, criterios para la participación de operación, mantenimiento, ingeniería, proveedores y seguridad, además de reglas para revisar y aprobar las conclusiones.
En determinados casos, el equipo que diseñó, instaló u operó el sistema no debe ser el único responsable de validar la causa. Una revisión independiente reduce sesgos y aumenta la confianza en la conclusión, especialmente cuando el análisis sustenta aceptación, garantía, responsabilidad técnica o una decisión de inversión.
La Auditoría Técnica de Ingeniería y el Design Review pueden formar parte de esta capa de assurance. En contratos o proyectos de mayor complejidad, la Owner’s Engineering mantiene la perspectiva del owner sobre requisitos, evidencias, aceptación y riesgo residual.
Acciones correctivas: corregir, prevenir y verificar la eficacia
Un buen análisis separa las acciones de contención de las acciones que tratan la causa. Sustituir un componente, reiniciar un servicio, aplicar un parche de emergencia u operar en contingencia puede ser necesario para restablecer la función, pero eso no significa que se haya reducido el riesgo de recurrencia.
Las acciones pueden incluir:
- corrección o sustitución del elemento;
- revisión del diseño o de la arquitectura;
- cambio de especificación o proveedor;
- cambio de protección, redundancia o segregación;
- actualización del procedimiento operativo;
- revisión del Plan de Mantenimiento;
- cambio de frecuencia, condición o técnica de inspección;
- actualización de repuestos y estrategia de soporte;
- mejora de registros, instrumentación o monitorización;
- revisión de formación, competencia o autorización;
- cambio de workflow, aprobación o control de cambios.
La acción solo debe considerarse cerrada cuando existe evidencia de implementación y un criterio para evaluar su eficacia. Esta disciplina evita que la organización acumule informes técnicamente correctos sin reducir efectivamente la recurrencia.
Cómo integrar el análisis de fallos con el PCM y la gestión de activos
El PCM — Planificación y Control del Mantenimiento debe funcionar como uno de los mecanismos de captura de eventos que requieren investigación. Órdenes correctivas, recurrencias, retrabajos, fallos en activos críticos y anomalías sin causa definida pueden generar disparadores formales para el análisis.
Los resultados vuelven al sistema de mantenimiento mediante la revisión de planes, criticidad, registros, repuestos, procedimientos y criterios de aceptación. Al mismo tiempo, los Indicadores de Mantenimiento permiten verificar si las acciones redujeron recurrencia, indisponibilidad, retrabajo o trabajo de emergencia.
En el nivel de Gestión de Activos, el análisis puede modificar decisiones de rehabilitación, recomisionamiento, modernización o sustitución. Cuando el fallo revela una limitación estructural del activo, seguir optimizando el mantenimiento puede ser económicamente inferior a una intervención de ciclo de vida.
Cuando el fallo afecta disponibilidad, seguridad, garantía o una decisión de inversión, la investigación debe ir más allá del diagnóstico de mantenimiento. La ingeniería de confiabilidad integra evidencias, mecanismos, riesgo y acciones en una conclusión técnicamente defendible.
Análisis de fallos como servicio de ingeniería consultiva
Cuando un evento presenta complejidad, criticidad o impacto contractual relevante, el análisis puede estructurarse como un servicio de ingeniería con alcance, evidencias, premisas, métodos y entregables claramente definidos. El trabajo puede incluir levantamiento de campo, entrevistas técnicas, revisión de historiales, ensayos, análisis documental, modelado, workshops multidisciplinares, revisión independiente y plan de acciones.
Una estructura de entrega puede incluir informe de la condición encontrada, cronología, definición funcional, matriz de hipótesis y evidencias, resultados de ensayos, mecanismo de fallo, causa técnica y sistémica, extensión de la condición, riesgo residual y plan de acciones priorizado. Según el caso, el trabajo puede evolucionar hacia Ingeniería de Confiabilidad y Disponibilidad, Ingeniería de Mantenimiento, Gestión de Riesgos de Ingeniería o Servicios Continuados de Ingeniería Consultiva.
El valor del análisis está en transformar un evento aislado en conocimiento reutilizable. Cuando las evidencias, decisiones y acciones permanecen trazables, cada fallo puede mejorar el diseño, la operación y el mantenimiento futuros en lugar de limitarse a generar una nueva orden correctiva.
Referencias técnicas
[1] ABNT. NBR 5462:1994 — Confiabilidad y mantenibilidad — Terminología. Rio de Janeiro: ABNT, 1994.
[2] IEC. IEC 62740:2015 — Root cause analysis (RCA). Geneva: IEC, 2015.
[3] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: IEC, 2018.
[4] IEC. IEC 61025:2006 — Fault tree analysis (FTA). Geneva: IEC, 2006.
[5] IEC. IEC 60300-3-1:2003 — Dependability management — Analysis techniques for dependability. Geneva: IEC, 2003.
[6] ISO. ISO 55001:2024 — Asset management — Asset management system — Requirements. Geneva: ISO, 2024.
Preguntas frecuentes
Es el proceso técnico de investigar un evento para identificar la función perdida, el modo y mecanismo de fallo, las evidencias, las causas y las acciones necesarias para reducir la probabilidad de recurrencia.
En la terminología de la NBR 5462, fallo es el evento que termina la capacidad de desempeñar una función requerida; el estado de fallo es la condición de incapacidad resultante.
No. El análisis de fallos es más amplio y puede incluir la caracterización del modo, el mecanismo y las evidencias. RCA es una técnica específica para investigar las causas raíz de eventos ocurridos.
Cuando existe criticidad, recurrencia, impacto relevante, causa desconocida, riesgo de seguridad o conformidad, fallo de redundancia, implicación contractual o necesidad de una decisión de ingeniería.
Según el caso, pueden utilizarse inspección visual, ensayos eléctricos y mecánicos, termografía, vibración, análisis de aceite, logs, FMEA, FTA, RCA, RAM, Weibull y otras técnicas especializadas.
La acción necesita un criterio de verificación y debe acompañarse de evidencias e indicadores capaces de demostrar una reducción de la recurrencia, el riesgo o la indisponibilidad asociada.
Materiales técnicos relacionados
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Gobernanza Documental y Sistema de Gestión de Documentos
- Indicadores, Dashboards e Informes Ejecutivos de Ingeniería
- Gestión del Conocimiento Técnico y Lecciones Aprendidas
Servicios de ingeniería relacionados
- Ingeniería de Confiabilidad y Disponibilidad
- Ingeniería de Mantenimiento
- Auditoría Técnica de Ingeniería
- Gestión de Riesgos de Ingeniería
- Design Review en Proyectos de Ingeniería
- Owner’s Engineering
- Servicios Continuados de Ingeniería Consultiva
Contenidos técnicos relacionados
- Análisis de Causa Raíz — RCA
- FMEA en Ingeniería
- FTA — Análisis de Árbol de Fallos
- Análisis RAM
- Análisis de Weibull
- Análisis de Criticidad de Activos
- PCM — Planificación y Control del Mantenimiento
- Indicadores de Mantenimiento
Gobernanza y profundización
