Cómo interpretar el MTBF con horas, fallos y periodo

MTBF suele presentarse como una sola cifra: 800 horas, 1.200 horas o cualquier resultado que salga de un cálculo. La cifra aislada, sin embargo, no dice qué activos se contaron, qué periodo se observó ni qué se consideró un fallo. Para interpretarla, hay que leer junto al resultado la población, la exposición y la regla de recuento.

En el marco de la guía de mantenimiento centrado en fiabilidad de NASA, la relación se expresa mediante las horas de operación y los fallos observados para equipos reparables. La guía ilustra el cálculo con 3.805 horas y cinco fallos: 761 horas por fallo, bajo el supuesto de una tasa de fallos constante y el modelo exponencial que acompaña al ejemplo.

Es un ejemplo de la guía de 2008, no un valor de referencia para una planta española ni una promesa sobre un equipo concreto. NASA, §5.5.5.2, PDF pp. 65–66 / pp. impresas 5-19–5-20

La cifra contesta una pregunta acotada

El cálculo básico divide una exposición acumulada por el número de fallos incluidos:

MTBF observado = horas efectivas de operación ÷ fallos cualificados

La unidad importa. Si el numerador son horas de operación, el resultado se interpreta como horas de operación por fallo observado, no como días de calendario hasta el siguiente fallo. El cociente resume lo ocurrido en un grupo durante una ventana; no marca una fecha de caducidad ni un temporizador individual.

La propia expresión “observado” ayuda a mantener el alcance visible. Habla de registros que entraron en una cuenta concreta. No convierte a todos los equipos de una fábrica en una población homogénea, ni demuestra que cada unidad vaya a comportarse como el promedio. Tampoco permite explicar por qué ocurrió cada evento. Para esas preguntas harían falta datos y análisis distintos.

NASA presenta el ejemplo como una estimación de la tasa de fallos de equipo reparable. En la sección citada, la guía relaciona las horas de operación con los fallos y muestra cómo invertir la tasa para obtener el MTBF. El resultado depende del supuesto estadístico que acompaña al ejemplo.

Si se cita el número 761, conviene mantener juntas las 3.805 horas, los cinco fallos y ese supuesto; sin ellos, el número pierde contexto. NASA, §5.5.5.2, PDF pp. 65–66 / pp. impresas 5-19–5-20

Tres datos que dan sentido al resultado

Un valor interpretable necesita, como mínimo, tres piezas de contexto. No son campos que NASA imponga en una plantilla universal; son datos editoriales y de análisis que permiten entender qué división se hizo y valorar si dos resultados se pueden comparar.

La población puede ser una unidad, una familia de equipos o un conjunto definido por otra característica común. El nombre “línea 2” quizá no baste si durante el periodo cambió qué máquinas se incluyeron. Un registro de cálculo debería permitir reconstruir qué identificadores formaron el grupo y qué exclusiones se aplicaron.

La ventana tampoco se reduce siempre a escribir dos fechas. Si hubo periodos en los que los equipos estaban parados, la cifra de horas de exposición debe explicar qué significa “operación” en ese conjunto de datos. Puede tratarse de horas efectivas registradas, de un contador de funcionamiento o de otra medida local. Lo importante es no sustituir silenciosamente el tiempo de operación por las horas transcurridas en el calendario.

Por último, “fallo” requiere una regla de recuento. Una incidencia, una parada, una alarma y una orden correctiva pueden estar relacionadas, pero un sistema de registro puede tratarlas como objetos diferentes. No existe en esta página una taxonomía universal que resuelva cada caso. El criterio aplicable debe salir de la definición de datos que use la organización y quedar visible en el informe.

Horas calendario y horas de operación no son lo mismo

Imagina dos activos hipotéticos observados durante el mismo mes de 30 días. El activo A funciona en dos turnos y acumula 360 horas efectivas; el activo B funciona en un turno y acumula 180 horas. Si cada uno registra un fallo y se divide el tiempo de funcionamiento, los resultados serían 360 y 180 horas de operación por fallo.

Si alguien usa 720 horas de calendario para los dos, obtiene 720 en ambos casos, pero habrá respondido a otra pregunta: horas transcurridas en el periodo por evento, no horas efectivas de operación por fallo.

Este contraste no demuestra que un activo tenga el doble de fiabilidad. Los números son inventados para mostrar la consecuencia del denominador. Para evaluar el sentido de la diferencia aún se necesitaría confirmar que los equipos, eventos, periodos y criterios de registro son comparables. Una cifra basada en contador de funcionamiento tampoco es automáticamente mejor; debe describir la exposición que se quiso medir y usar el mismo criterio cuando se comparan grupos.

Una ficha útil puede indicar tanto la ventana del calendario como las horas efectivas acumuladas. Así quien lee sabe dónde buscar el periodo y qué exposición se usó. Si el sistema solo proporciona fechas de alta y cierre, no se debe llamar “horas de operación” a la resta entre ambas sin demostrar que el equipo estuvo operando durante todo ese tiempo.

Cálculo didáctico: 4.800 horas y seis fallos

Supongamos un conjunto hipotético de equipos reparables con una ventana declarada y 4.800 horas efectivas acumuladas. En ese intervalo se registraron seis fallos que cumplen la regla de inclusión definida para el ejercicio. La operación es:

4.800 horas de operación ÷ 6 fallos = 800 horas de operación por fallo

Los valores son inventados para mostrar la aritmética. El resultado no representa una instalación, un fabricante ni una expectativa de rendimiento. Si en las mismas 4.800 horas se contaran cinco fallos bajo otra regla, el cociente sería 960 horas por fallo. El cambio no revela por sí mismo cuál regla es correcta; muestra cuánto puede moverse una media cuando el número de eventos es pequeño.

La división produce un cociente exacto en este ejemplo, pero eso no vuelve exacta la interpretación. Debe poder leerse como “en este conjunto, durante esta ventana y con esta regla, se observaron 800 horas de operación por fallo cualificado”. Decir “el equipo fallará dentro de 800 horas” transforma el promedio de una observación en una predicción individual que el cálculo no sustenta.

También conviene dejar la unidad en el resultado. “800 horas” puede confundirse con tiempo calendario, tiempo de reparación o una vida útil especificada. “800 horas de operación por fallo observado, para el conjunto descrito” reduce esa ambigüedad sin añadir una precisión que los datos no ofrecen.

Qué entra en el recuento de fallos

El denominador parece sencillo hasta que se revisan los registros. Una orden de trabajo puede reunir varios avisos; una parada puede originarse en una condición que no se registró como fallo; una alarma puede repetirse sin representar eventos independientes. En vez de decidir desde fuera qué debe contar, el análisis debe declarar cómo convierte los datos locales en fallos cualificados.

Una regla de recuento puede responder preguntas concretas: ¿se cuenta cada evento o cada activo afectado? ¿Qué se hace con un aviso duplicado? ¿Cuándo se considera que dos registros describen la misma incidencia? ¿Cómo se tratan los eventos todavía abiertos cuando termina la ventana? ¿Qué pasa si el criterio de registro cambió durante el periodo? Las respuestas dependen del sistema de datos y del objetivo del indicador.

Por eso no basta con extraer el total de órdenes correctivas si ese total no corresponde a fallos. Tampoco debe suponerse que cada parada es un fallo o que toda alarma es independiente. Esas equivalencias quizá funcionen en una base concreta, pero necesitan confirmación y documentación. La recomendación de conservar la regla es una práctica de trazabilidad de este artículo; no se atribuye como instrucción textual a NASA.

Si la definición cambia, lo correcto es anotar el cambio y revisar la comparabilidad. Una serie antes y después de una migración de GMAO, por ejemplo, puede reflejar tanto el comportamiento del equipo como una nueva forma de registrar eventos. El indicador no explica cuál de esas causas produjo la diferencia.

Cuándo tiene sentido comparar dos MTBF

Una comparación necesita denominadores compatibles. Antes de poner dos cifras en una tabla, comprueba si se refieren a la misma población o a grupos con una relación clara; si las horas se calcularon con la misma base; si las ventanas son comparables; y si el criterio de fallo tuvo el mismo significado. Es un control metodológico propuesto para leer los datos, no una recomendación textual de NASA.

Una comparación hipotética muestra el problema. En el periodo A, un conjunto acumula 2.400 horas de operación y cuatro fallos: 600 horas por fallo. En el periodo B, otro conjunto acumula 3.600 horas y seis fallos: también 600 horas por fallo. Los cocientes coinciden, pero no sabemos si la composición de los grupos, las cargas, las condiciones de funcionamiento o los métodos de captura fueron los mismos. La coincidencia del cociente no prueba equivalencia de condiciones ni causa común.

También puede cambiar la exposición sin que cambie el número de equipos. Si un activo opera más turnos, acumula más horas y puede registrar más eventos simplemente porque estuvo expuesto durante más tiempo. El cociente intenta incorporar la exposición en el denominador, pero sigue dependiendo de que ese denominador esté bien medido y corresponda a los eventos contados.

Al leer una tendencia temporal, no conviene atribuir una subida o bajada a una mejora o deterioro sin examinar primero esos elementos. El cambio puede coincidir con una intervención, una variación de carga, una modificación del criterio de registro o una diferente selección de activos. El MTBF resume el conteo y la exposición; no separa esas explicaciones.

MTBF no es MTBM ni disponibilidad

En §14.3, NASA distingue el MTBF, asociado a fallos, del MTBM, que incluye acciones de mantenimiento correctivas y preventivas. Allí expresa la disponibilidad operacional como Ao = MTBM / (MTBM + MDT). La tabla 14-1, en la página siguiente, enumera medidas de tiempos de mantenimiento como MTTR; no presenta esa fórmula ni define MTBF o MTBM.

Esto importa porque cambiar de “fallos” a “acciones de mantenimiento” modifica el denominador conceptual. NASA, §14.3: ecuación Ao en p. impresa 14-5 / PDF p. 217; tabla 14-1: p. impresa 14-6 / PDF p. 218

Si una persona quiere conocer la frecuencia de fallos observados, un MTBF puede ayudar dentro de la definición adoptada. Si quiere relacionar acciones correctivas y preventivas con tiempos caídos, necesita otra medida y los datos correspondientes. No se debe sustituir una fórmula por otra y conservar la misma etiqueta.

Un ejemplo hipotético: durante una ventana inventada se registran seis fallos correctivos y dos intervenciones preventivas. Una cuenta de MTBF que use los seis fallos tendrá una base distinta de una cuenta de MTBM que incluya las ocho acciones, siempre que el marco utilizado defina esas categorías así. No son dos respuestas alternativas a una sola pregunta: responden a recuentos distintos.

La guía NASA es una referencia técnica estadounidense fechada en 2008. Sirve aquí para explicar el marco y las diferencias que establece en ese documento. No es legislación española o europea, no establece por sí sola cómo debe registrar una empresa española sus activos y no sustituye el criterio de un fabricante ni el procedimiento aplicable a un equipo.

Lo que la media no demuestra

Un MTBF calculado a partir de una población y una ventana no permite conocer la vida restante de una unidad. Tampoco identifica la causa de un evento, demuestra que una medida preventiva funcionó ni acredita que un activo sea seguro. Esas conclusiones no están contenidas en el cociente; requieren evidencia adicional y, en contextos reales, el análisis apropiado para la decisión.

El supuesto de tasa constante y distribución exponencial que NASA asocia a su ejemplo debe leerse junto a ese ejemplo. Si la tasa cambia con la edad, la carga, el entorno, el mantenimiento o la forma de capturar eventos, no debe presentarse el cálculo ilustrativo como pronóstico de fallos futuros.

Esta cautela es una limitación de interpretación del modelo citado, no una afirmación de que todos los equipos sigan o incumplan ese modelo. NASA, §5.5.5.2, PDF pp. 65–66 / pp. impresas 5-19–5-20

El promedio tampoco revela por sí solo la dispersión. Dos grupos pueden arrojar la misma media y tener distribuciones de intervalos muy diferentes. Si se necesita conocer valores extremos, agrupación de fallos o comportamiento por subgrupo, el resumen único no basta. Haría falta examinar los registros subyacentes y elegir un análisis que corresponda a esa pregunta; no se propone aquí un método de diagnóstico.

Por la misma razón, no se puede convertir una cifra promedio en una instrucción para mantener, sustituir, reactivar o dejar fuera de servicio un activo concreto. Este texto explica lectura de un indicador; las decisiones reales dependen del fabricante, la evaluación de riesgos, la competencia y los procedimientos del centro.

Una ficha mínima para conservar el contexto

Al publicar un número, una ficha puede acompañarlo con la siguiente información. Es una lista práctica para que el cálculo se pueda reconstruir, no un formulario legal ni una norma obligatoria:

• población, identificadores o criterio de selección de equipos;
• fechas de la ventana y fuente de las horas acumuladas;
• tipo de horas usado y unidad de medida;
• número de fallos cualificados y regla de inclusión;
• tratamiento de duplicados, eventos abiertos y exclusiones;
• fórmula aplicada y redondeo del resultado;
• sistema o registro de procedencia, fecha de extracción y responsable de validar la calidad del dato.

Si la ficha no contiene alguno de estos campos, no significa automáticamente que el resultado sea falso. Significa que otra persona quizá no pueda reconstruir qué observación resume. Conviene señalar lo que falta antes que completar con una suposición el denominador o el criterio de evento.

Una tabla de comparación también debería conservar esa información. Si solo muestra “equipo A: 800 h; equipo B: 950 h”, el lector no puede comprobar si las cifras describen la misma población, ventana y regla. El formato más breve puede ser: “800 h de operación/fallo; 6 fallos cualificados; 4.800 h observadas; ventana y población indicadas en la nota”. La frase es más larga, pero lleva consigo la base de lectura.

Cómo elegir el siguiente paso de análisis

Primero decide qué pregunta tienes. Si necesitas interpretar cuántas horas de operación se observaron por cada fallo de una población, aclara la exposición y el recuento. Si la pregunta trata de acciones preventivas y correctivas, la distinción MTBM de la guía NASA puede ser pertinente. Si quieres examinar cuánto tiempo permanece el equipo caído, la conversación pasa a las medidas de mantenimiento y downtime, no a renombrar el MTBF.

Cuando faltan registros consistentes, el resultado útil puede ser una nota de limitación: “cálculo basado en los eventos que el sistema clasifica como fallo; la exposición se tomó del contador de horas; la comparación entre periodos requiere confirmar si la regla de registro fue constante”. Esto hace explícita la frontera del análisis y evita presentar una conclusión más firme que los datos.

Si el objetivo es relacionar MTBF con MTTR y disponibilidad, la página complementaria sobre MTBF, MTTR y disponibilidad cubre las bases de esas métricas en conjunto. Para entender cómo cada fuente define el MTTR y qué acciones incluye, consulta la página de MTTR. Aquí el foco se mantiene en qué significan las horas, los fallos y el periodo que forman el MTBF.