Diagnóstico de confiabilidad de activos: alcance, evidencias, datos de campo, criticidad, fallos, mantenibilidad, arquitectura, priorización y roadmap de mejora.

¡Descúbrelo!

El diagnóstico de confiabilidad de activos es una evaluación estructurada de la capacidad de equipos, sistemas y procesos para sostener funciones requeridas a lo largo del tiempo, basada en evidencias técnicas, datos de campo y condiciones reales de operación. Su objetivo no es producir una calificación genérica de madurez, sino identificar dónde se está perdiendo confiabilidad, qué mecanismos explican el desempeño observado y qué acciones tienen mayor potencial para reducir riesgo, indisponibilidad y recurrencia.

En muchas organizaciones, los síntomas aparecen antes que las causas: aumento de correctivos, backlog crítico, fallos repetidos, disponibilidad por debajo de la meta, intervenciones de emergencia, dificultad de diagnóstico, repuestos insuficientes o activos operando con soluciones provisionales. Tratar cada evento de forma aislada puede reducir el problema inmediato, pero no necesariamente corrige el sistema que produce los fallos.

Un diagnóstico robusto combina inventario y criticidad, historial de fallos, mantenimiento, condición, arquitectura, datos de indisponibilidad, modos de fallo, mantenibilidad, soporte, documentación, obsolescencia y gobernanza. El resultado esperado es una línea base técnica y un plan de mejora priorizado por riesgo, impacto y viabilidad.

Qué es un diagnóstico de confiabilidad de activos

El diagnóstico es una fotografía técnica de la situación actual, pero debe construirse de forma analítica. Compara funciones requeridas, desempeño esperado y comportamiento observado, buscando evidencias que expliquen las brechas entre los tres.

IEC 60300-1:2024 trata la dependability a lo largo del ciclo de vida y conecta confiabilidad, disponibilidad, mantenibilidad y soporte. Esto es importante porque una baja confiabilidad percibida no siempre es consecuencia únicamente de fallos físicos. Tiempos de espera, diagnóstico deficiente, falta de repuestos, configuración inadecuada, error de operación o una arquitectura frágil también pueden reducir la capacidad de entregar la función requerida.

Por ello, un diagnóstico no debe comenzar preguntando únicamente “¿cuántos fallos ocurrieron?”. Debe preguntar:

  • qué función es crítica;
  • qué nivel de desempeño se requiere;
  • qué fallos o degradaciones impiden ese desempeño;
  • con qué frecuencia y duración ocurren;
  • qué causas o condiciones se repiten;
  • cuánto tiempo se emplea en detección, diagnóstico, logística, reparación y retorno;
  • qué controles existen y si son eficaces;
  • qué riesgos permanecen sin tratamiento.

El diagnóstico de confiabilidad no es una auditoría de mantenimiento

Una auditoría de mantenimiento puede evaluar procesos, ejecución del plan, backlog, registros y disciplina operacional. Esto es relevante, pero no es suficiente para explicar la confiabilidad de un sistema.

El diagnóstico de confiabilidad atraviesa las fronteras entre mantenimiento, operación, diseño, ingeniería, suministros y gestión de activos. Un fallo recurrente puede originarse en dimensionamiento inadecuado, acceso deficiente, lógica de control, condición ambiental, procedimiento, calidad de energía o elección tecnológica.

Del mismo modo, un activo con pocos fallos registrados puede ser crítico si opera sin redundancia, está obsoleto o posee un tiempo de reposición incompatible con la continuidad requerida.

El foco debe permanecer en el desempeño de la función y en el riesgo asociado a su pérdida.

Definir el alcance antes de analizar los datos

Un diagnóstico sin alcance claro tiende a generar gran volumen de información y pocas decisiones. Antes de la recopilación, es necesario delimitar:

  • unidades, sistemas y activos incluidos;
  • período histórico analizado;
  • funciones y niveles de servicio relevantes;
  • criterios de criticidad;
  • indicadores mínimos;
  • fuentes de datos disponibles;
  • stakeholders involucrados;
  • premisas y limitaciones.

En una planta industrial, por ejemplo, puede no ser necesario analizar todos los equipos con el mismo nivel de detalle. Los activos críticos, sistemas de utilidades y cuellos de botella de producción pueden recibir primero un análisis más profundo.

Evidencias que deben sustentar el diagnóstico

La calidad de la conclusión depende de la calidad y diversidad de las evidencias. IEC 60300-3-2:2004 proporciona orientación para recopilar datos de confiabilidad, mantenibilidad, disponibilidad y soporte en campo, destacando el retorno de la experiencia operacional como parte del proceso de dependability.

Un conjunto de evidencias puede incluir:

FuenteEjemplos de información
CMMS/EAMórdenes, fallos, tiempos, códigos, costos, backlog
operacióneventos, alarmas, indisponibilidad, bypasses, restricciones
inspeccióncondición física, anomalías, accesibilidad, ambiente
documentacióndiagramas, listas, manuales, procedimientos, historial de revisión
ingenieríaFMEA/FMECA, RAM, RBD, estudios, criterios de diseño
suministroslead time, obsolescencia, repuestos, contratos
automatizaciónlogs, tendencias, eventos y diagnósticos
personasentrevistas con operación, mantenimiento e ingeniería

Ninguna de estas fuentes debe considerarse aisladamente como verdad absoluta. Los datos del CMMS pueden estar incompletos; las entrevistas pueden reflejar percepción; la documentación puede estar desactualizada. El diagnóstico mejora cuando las fuentes se confirman entre sí o cuando las divergencias se registran explícitamente.

La calidad de los datos forma parte del resultado

Es frecuente encontrar históricos insuficientes o inconsistentes. Esto no invalida el diagnóstico, pero modifica el nivel de confianza de las conclusiones.

Algunos problemas típicos de datos son:

  • órdenes cerradas sin causa registrada;
  • códigos de fallo utilizados de forma inconsistente;
  • tiempos de indisponibilidad mezclados con horas de mano de obra;
  • eventos duplicados;
  • ausencia de identificación del activo afectado;
  • mantenimiento preventivo registrado como correctivo o viceversa;
  • pérdida de información en hojas de cálculo paralelas;
  • historial fragmentado entre sistemas.

El diagnóstico debe clasificar la calidad y completitud de los datos. Cuando sea necesario, las acciones de mejora incluyen redefinición de taxonomía, campos obligatorios, gobernanza del registro maestro y criterios de cierre de órdenes.

Un dato deficiente también es un hallazgo de confiabilidad. Sin trazabilidad de fallo, causa, duración y activo afectado, la organización pierde capacidad de priorizar y aprender de la operación.

Aplicaciones de Campo y Recopilación de Datos Técnicos →

La criticidad como filtro del diagnóstico

La criticidad orienta dónde concentrar la ingeniería. Un equipo que falla con frecuencia, pero tiene baja consecuencia y rápida recuperación, puede tener menor prioridad que un equipo que falla raramente, pero carece de redundancia y presenta una consecuencia elevada.

La clasificación puede considerar seguridad, medio ambiente, producción, calidad, conformidad, continuidad, reputación, costo, redundancia, recuperabilidad y lead time.

El análisis también debe observar dependencias. Un componente aparentemente pequeño puede soportar varias funciones críticas y convertirse en un single point of failure del sistema.

Indicadores que ayudan a construir la línea base

Los indicadores son útiles cuando poseen una definición consistente y una relación con la función analizada. Algunos de los más comunes incluyen:

  • disponibilidad;
  • indisponibilidad acumulada;
  • MTBF o tiempo entre fallos;
  • MTTR o tiempos específicos de restablecimiento;
  • número de fallos funcionales;
  • recurrencia por modo de fallo;
  • proporción de mantenimiento de emergencia;
  • backlog crítico;
  • tiempo de espera por material;
  • tiempo de diagnóstico;
  • costo de mantenimiento;
  • cumplimiento de tareas basadas en condición.

La comparación debe respetar población, período, régimen operacional y exposición. Comparar directamente dos activos que operan en condiciones diferentes puede producir conclusiones erróneas.

Pareto de fallos: útil, pero insuficiente

Pareto es una buena herramienta de clasificación inicial. Puede revelar qué activos, sistemas o categorías concentran eventos u horas de indisponibilidad.

El riesgo está en tratar la frecuencia como único criterio. Un modo de fallo de baja frecuencia puede ser prioritario si su consecuencia es severa. Por ello, Pareto debe combinarse con criticidad y análisis de consecuencias.

También es útil elaborar más de un Pareto:

  • cantidad de eventos;
  • horas de indisponibilidad;
  • costo;
  • recurrencia;
  • impacto en producción;
  • fallos de seguridad o conformidad.

Las prioridades pueden cambiar completamente según la variable observada.

Separar la frecuencia de la duración del fallo

Dos sistemas pueden producir la misma indisponibilidad anual mediante mecanismos diferentes.

El sistema A puede presentar 20 fallos de una hora. El sistema B puede presentar dos fallos de diez horas. Aunque la indisponibilidad total sea la misma, las estrategias de mejora son diferentes.

En el primer caso, el foco puede estar en eliminar la recurrencia y reducir la tasa de fallo. En el segundo, el problema puede encontrarse en diagnóstico, logística, reparación, acceso o repuestos.

Esta descomposición evita recomendaciones genéricas como “aumentar el mantenimiento preventivo” sin saber qué componente de la indisponibilidad debe reducirse.

Descomponer el tiempo de restablecimiento

La confiabilidad operacional se ve afectada por el tiempo necesario para recuperar la función. Un evento de ocho horas puede descomponerse en:

EtapaTiempo
detección y triaje0,5 h
liberación operacional1,0 h
diagnóstico1,0 h
espera por repuesto3,0 h
reparación efectiva1,5 h
prueba y retorno1,0 h

En este escenario, actuar únicamente sobre la velocidad de reparación tendría un efecto limitado. La principal ganancia se encuentra en logística y preparación.

NBR 5462, utilizada como base terminológica interna, diferencia tiempos de mantenimiento, retrasos logísticos, diagnóstico, localización, reparación y restablecimiento. Esta descomposición es especialmente útil en el diagnóstico.

Analizar modos de fallo y recurrencia

Después de la clasificación cuantitativa, los eventos relevantes deben tratarse a nivel de modo de fallo.

IEC 60812:2018 proporciona la base para FMEA y FMECA. Un diagnóstico puede utilizar esta lógica para organizar:

  • función;
  • fallo funcional;
  • modo de fallo;
  • efecto;
  • causa o mecanismo;
  • control existente;
  • consecuencia;
  • evidencia;
  • acción recomendada.

La recurrencia es una señal importante. Cuando el mismo modo se repite después de sucesivos correctivos, es probable que la acción esté restaurando la función sin eliminar la causa.

RCA: cuándo profundizar en la causa raíz

No todo evento exige un Análisis de Causa Raíz (RCA) extenso. La RCA debe aplicarse cuando la consecuencia, recurrencia, incertidumbre o potencial de aprendizaje justifiquen el esfuerzo.

Un criterio puede considerar:

  • severidad del evento;
  • recurrencia;
  • fallo de control crítico;
  • exposición futura;
  • potencial de repetición en otros activos;
  • costo de la investigación.

El diagnóstico debe evitar RCA basada únicamente en narrativa. Evidencias físicas, secuencia temporal, datos de proceso, configuración, historial de intervenciones y modificaciones deben sustentar la conclusión.

Arquitectura y puntos únicos de fallo

Parte de la baja confiabilidad puede ser estructural. RBD, FTA y el análisis funcional ayudan a identificar dependencias que no aparecen en el historial de órdenes.

IEC 60300-3-1:2003 presenta una visión general de técnicas de análisis de dependability y criterios para seleccionar métodos apropiados. En sistemas críticos, un análisis de arquitectura puede identificar:

  • single points of failure;
  • redundancias no independientes;
  • fallos de causa común;
  • propagación de fallo;
  • interfaces frágiles;
  • capacidad degradada insuficiente;
  • ausencia de bypass o contingencia.

Un sistema puede no haber sufrido nunca la combinación crítica de eventos y aun así presentar riesgo alto. El diagnóstico debe considerar tanto evidencia histórica como exposición estructural.

La ausencia de historial de fallos no demuestra baja exposición. Los sistemas críticos también deben evaluarse por arquitectura, dependencias y consecuencias potenciales.

Ingeniería de Confiabilidad y Disponibilidad →

Evaluación de confiabilidad cuando los datos son limitados

IEC 62308:2006 trata métodos de evaluación de confiabilidad a partir de datos de campo y ensayo, incluso para elementos críticos y complejos. En activos con historial limitado, puede ser necesario combinar distintas fuentes y explicitar la incertidumbre.

Algunos enfoques posibles incluyen:

  • historial de activos similares;
  • datos del fabricante con verificación de contexto;
  • bases de datos reconocidas;
  • pruebas e inspecciones;
  • modelado de arquitectura;
  • juicio experto documentado;
  • análisis por escenarios.

El diagnóstico debe separar dato observado, estimación y premisa. Mezclar estas categorías transmite una precisión que no existe.

Condición física y degradación

Los datos históricos no sustituyen la inspección. Los equipos pueden estar operando con una degradación relevante que todavía no se ha transformado en fallo funcional.

Según la disciplina, las inspecciones pueden observar:

  • calentamiento;
  • corrosión;
  • desgaste;
  • holguras;
  • contaminación;
  • vibración;
  • aislamiento;
  • fugas;
  • calidad de conexiones;
  • alarmas deshabilitadas;
  • protecciones en bypass;
  • modificaciones no documentadas.

La condición debe relacionarse con el mecanismo de fallo y la criticidad. Un indicador de condición deficiente no implica automáticamente sustitución; debe interpretarse en el contexto del riesgo y de la estrategia de ciclo de vida.

Mantenibilidad y capacidad de recuperación

El diagnóstico también debe evaluar si la organización puede recuperar el sistema dentro del plazo necesario.

Preguntas útiles incluyen:

  • existe acceso seguro para intervenir;
  • el nivel de intervención está definido;
  • hay documentación actualizada;
  • los puntos de prueba son adecuados;
  • es posible aislar el equipo sin paradas excesivas;
  • las herramientas están disponibles;
  • existe la competencia necesaria;
  • el procedimiento es ejecutable;
  • el sistema puede probarse después de la reparación.

Una mantenibilidad deficiente suele aparecer en los datos como MTTR elevado, pero su causa puede estar en el diseño y no en el equipo humano.

Repuestos, logística y soporte

Lead time, disponibilidad de piezas y obsolescencia pueden dominar la indisponibilidad. El diagnóstico debe cruzar la criticidad con la estrategia de repuestos.

Para cada elemento relevante, pueden evaluarse:

  • tiempo de reposición;
  • consumo histórico;
  • costo de stock;
  • posibilidad de reparación;
  • equivalentes aprobados;
  • vida de almacenamiento;
  • obsolescencia;
  • dependencia de proveedor único;
  • capacidad de contingencia durante la espera.

El objetivo no es maximizar el stock, sino reducir la exposición de forma económicamente justificable.

Obsolescencia como riesgo de confiabilidad

Obsolescencia no significa únicamente fin de fabricación. Puede implicar pérdida de soporte, indisponibilidad de firmware, incompatibilidad con sistemas actuales, ausencia de competencia interna, componentes sin equivalencia o imposibilidad de actualización segura.

Un activo obsoleto puede continuar funcionando durante años. El riesgo aparece cuando el próximo fallo no puede restaurarse dentro del plazo aceptable.

Por ello, el diagnóstico de confiabilidad debe alimentar decisiones de retrofit, modernización y renovación.

Evaluar la eficacia del plan de mantenimiento

No basta con verificar si el plan se está cumpliendo. Es necesario evaluar si las tareas controlan los modos de fallo relevantes.

Las preguntas de diagnóstico incluyen:

  • la tarea está vinculada a un mecanismo de fallo conocido;
  • la frecuencia es coherente con el comportamiento de degradación;
  • el criterio de aceptación está definido;
  • la evidencia registrada es suficiente;
  • la tarea detecta anomalías con tiempo para actuar;
  • los fallos siguen ocurriendo a pesar de la tarea;
  • existen modos críticos sin ninguna política de tratamiento.

Este tipo de revisión acerca el diagnóstico a la ingeniería de mantenimiento y a RCM.

Estructurar los hallazgos por evidencia y consecuencia

Un diagnóstico útil no debe producir únicamente una larga lista de observaciones. Cada hallazgo puede estructurarse en cinco campos:

  1. Condición observada. Qué se identificó.
  2. Evidencia. Qué dato, inspección, documento o registro sustenta el hallazgo.
  3. Consecuencia. Qué función, riesgo o desempeño puede verse afectado.
  4. Causa probable o brecha. Qué explica la condición o impide una decisión segura.
  5. Recomendación. Qué acción debe evaluarse o implementarse.

Esta estructura evita recomendaciones desconectadas de la evidencia.

Ejemplo de hallazgo técnico

Condición: dos bombas críticas operan en redundancia 1+1.

Evidencia: el historial muestra cinco eventos durante el año; la inspección confirma que ambas comparten el mismo tablero de alimentación y el mismo tramo de succión.

Consecuencia: un fallo en el tablero o una obstrucción común puede retirar simultáneamente ambos equipos e interrumpir la función.

Brecha: la redundancia de equipos no elimina los puntos comunes de arquitectura.

Recomendación: evaluar segregación eléctrica, vulnerabilidad hidráulica, contingencia operacional y eventual modificación de diseño según riesgo y viabilidad.

El valor del diagnóstico está en conectar la observación con el mecanismo de pérdida de la función.

Priorización de las acciones

No toda recomendación debe convertirse en un proyecto inmediato. El plan de mejora debe considerar riesgo, beneficio, urgencia, dependencias, costo y capacidad de ejecución.

Una matriz práctica puede utilizar:

PrioridadCaracterística
inmediatariesgo intolerable, seguridad, conformidad o exposición crítica
altarecurrencia relevante, indisponibilidad o riesgo elevado
mediaganancia consistente con planificación de corto/medio plazo
estructurantedatos, proceso, documentación o gobernanza necesarios para mejoras futuras
oportunidadoptimización con beneficio, pero sin urgencia operacional

La priorización debe ser transparente para que las decisiones puedan revisarse cuando cambien el contexto o los recursos.

Roadmap de mejora de confiabilidad

Un diagnóstico normalmente produce acciones en horizontes diferentes.

0–90 días: controlar riesgos inmediatos, corregir bypasses críticos, revisar repuestos urgentes, cerrar causas de fallos recurrentes y mejorar registros esenciales.

3–12 meses: revisar planes, ejecutar FMEA/FMECA o RCM en sistemas prioritarios, actualizar documentación, corregir arquitectura vulnerable y estructurar indicadores.

12–36 meses: implementar modernizaciones, renovación de activos, proyectos de redundancia, automatización del diagnóstico y cambios estructurales de proceso.

El roadmap debe indicar responsable, dependencias, entregable, criterio de finalización e indicador de resultado.

Indicadores para medir si el plan funcionó

Después de la implementación, la organización debe verificar el resultado. Según el caso, los indicadores pueden incluir:

  • reducción de fallos funcionales;
  • reducción de recurrencia;
  • aumento de disponibilidad;
  • reducción del tiempo de diagnóstico;
  • reducción de indisponibilidad logística;
  • reducción del backlog crítico;
  • aumento de la cobertura de modos críticos mediante controles;
  • reducción de activos con riesgo de obsolescencia sin plan;
  • reducción de correctivos de emergencia.

La acción solo debe considerarse eficaz cuando la evidencia de desempeño sustente la conclusión.

Diagnóstico e ISO 55001:2024

ISO 55001:2024 refuerza la toma de decisiones, riesgos y oportunidades, criticidad de los activos, datos, información, planificación y ciclo de vida. Un diagnóstico de confiabilidad puede alimentar directamente este sistema de gestión.

Los hallazgos pueden apoyar:

  • actualización de criticidad;
  • revisión de objetivos de gestión de activos;
  • AMPs y roadmaps;
  • decisiones de CAPEX;
  • gestión de riesgos;
  • requisitos de datos;
  • revisión de estrategias de mantenimiento;
  • decisiones de renovación y obsolescencia.

Así, la confiabilidad deja de ser únicamente un indicador operacional y pasa a ser un insumo para decisiones de ciclo de vida.

Cuándo contratar un diagnóstico de confiabilidad

El diagnóstico tiende a generar mayor valor cuando existen fallos recurrentes, disponibilidad por debajo de la meta, gran volumen de correctivos, dificultad para explicar el downtime, activos críticos antiguos, expansión de planta, integración de sistemas, baja calidad de datos o necesidad de justificar inversiones de modernización.

También es útil antes de estructurar programas RCM, grandes revisiones de mantenimiento o planes de gestión de activos. El diagnóstico ayuda a identificar dónde realmente son necesarios métodos más profundos.

El entregable debe permitir una decisión. Más que señalar problemas, un buen diagnóstico establece evidencia, criticidad, mecanismo, prioridad y plan de mejora, creando una línea base para seguir si la confiabilidad evoluciona efectivamente.

Un diagnóstico sin roadmap es solo una fotografía. El valor aparece cuando las evidencias se convierten en prioridades, responsables, acciones y criterios para medir la reducción efectiva del riesgo.

Gestión de Activos de Ingeniería →

Referencias técnicas

[1] IEC. IEC 60300-1:2024 — Dependability management — Part 1: Managing dependability. Geneva: IEC, 2024.

[2] IEC. IEC 60300-3-2:2004 — Dependability management — Part 3-2: Application guide — Collection of dependability data from the field. Geneva: IEC, 2004.

[3] IEC. IEC 60300-3-1:2003 — Dependability management — Part 3-1: Application guide — Analysis techniques for dependability — Guide on methodology. Geneva: IEC, 2003.

[4] IEC. IEC 62308:2006 — Equipment reliability — Reliability assessment methods. Geneva: IEC, 2006.

[5] ISO. ISO 55001:2024 — Asset management — Asset management system — Requirements. Geneva: ISO, 2024.

[6] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: IEC, 2018.

[7] ABNT. NBR 5462:1994 — Confiabilidade e mantenabilidade — Terminologia. Rio de Janeiro: ABNT, 1994.

Preguntas frecuentes
¿Qué es un diagnóstico de confiabilidad de activos?

Es una evaluación estructurada del desempeño de confiabilidad, disponibilidad, mantenibilidad y soporte de los activos, basada en datos de campo, condición, arquitectura, historial de fallos y evidencias técnicas.

¿Cuál es la diferencia entre diagnóstico de confiabilidad y auditoría de mantenimiento?

La auditoría de mantenimiento suele evaluar procesos y ejecución de la función mantenimiento. El diagnóstico de confiabilidad también investiga arquitectura, diseño, operación, datos, repuestos, obsolescencia, condición y causas de pérdida de la función.

¿Es posible hacer un diagnóstico con datos deficientes?

Sí, siempre que la baja calidad de los datos se explicite como limitación. El diagnóstico puede combinar historial, inspección, entrevistas, documentación, modelado y otras evidencias, distinguiendo siempre el dato observado de la premisa.

¿Qué indicadores deben analizarse?

Disponibilidad, fallos funcionales, MTBF, tiempos de restablecimiento, recurrencia, backlog crítico, emergencias, indisponibilidad logística, costo y otros indicadores pertinentes al sistema y a la función analizada.

¿El diagnóstico debe incluir FMEA o RCM?

No obligatoriamente. FMEA, FMECA, RCM, RBD y otras técnicas deben aplicarse donde la criticidad, incertidumbre o complejidad justifiquen mayor profundidad.

¿Cuál debe ser el principal entregable?

Una línea base de confiabilidad, hallazgos sustentados por evidencias, priorización por riesgo e impacto y un roadmap de mejora con responsables, plazos y criterios de resultado.

Materiales técnicos complementarios

Soluciones relacionadas

Servicios de ingeniería relacionados

Contenidos técnicos relacionados

Guías, frameworks y referencias