Mantenimiento predictivo: qué hace falta para avisar antes de la avería

El mantenimiento predictivo es probablemente el caso de uso industrial del que más se habla y el que peor se plantea. La promesa suena impecable: en lugar de cambiar piezas cada X horas o esperar a que algo se rompa, un modelo mira los datos de la máquina y avisa con días de antelación. Lo que casi nunca se cuenta en la presentación es la parte de abajo: para que un modelo avise antes de la avería, hace falta histórico de fallos etiquetado, señales que midan lo que realmente se degrada y un equipo de mantenimiento que sepa qué hacer con el aviso.

Esta guía es para responsables de planta, de mantenimiento o de operaciones que están valorando el salto. Va de qué datos hacen falta de verdad, cuándo compensa frente al preventivo de toda la vida, cómo montar el primer caso y qué errores tumban estos proyectos antes del sexto mes.

¿Qué es el mantenimiento predictivo y en qué se diferencia del preventivo?

El mantenimiento predictivo estima cuándo va a fallar un activo concreto a partir de su comportamiento medido, y programa la intervención justo antes. No es una revisión más frecuente ni un panel con más gráficos: es cambiar la pregunta de «¿cuántas horas lleva esta bomba?» a «¿qué está haciendo esta bomba que no hacía hace tres semanas?».

| Estrategia | Cuándo se interviene | Qué exige | Coste típico | |---|---|---|---| | Correctivo | Cuando se rompe | Nada, solo repuestos y paciencia | Parada no planificada, la más cara | | Preventivo por calendario | Cada X horas o meses, según manual | Plan y disciplina | Se cambian piezas con vida útil restante | | Basado en condición | Cuando una medida cruza un umbral | Sensórica y umbrales bien puestos | Moderado; falsos avisos si el umbral es malo | | Predictivo | Cuando el modelo estima degradación creciente | Histórico de fallos, señales y modelo | Alto al montarlo, bajo al operarlo | | Prescriptivo | El sistema además propone la acción | Todo lo anterior más reglas de negocio | Solo tiene sentido con lo previo maduro |

Dos matices que ahorran dinero. Primero: el basado en condición ya resuelve una parte enorme del problema y es mucho más barato. Si nunca has puesto un acelerómetro en un motor crítico, empieza por ahí antes de hablar de modelos. Segundo: el predictivo no sustituye al preventivo, lo reordena. Los activos de bajo coste y fallo barato seguirán yendo por calendario para siempre, y está bien que sea así.

¿Qué datos hacen falta antes de pensar en modelos?

Aquí se decide si el proyecto es viable. Un modelo de mantenimiento predictivo aprende a distinguir «máquina sana» de «máquina camino de fallar», y para eso necesita haber visto fallos. Tres ingredientes, en este orden:

• Señales de la máquina con frecuencia suficiente. Vibración, temperatura, consumo de corriente, presión, caudal, horas de funcionamiento, revoluciones. La frecuencia importa: una lectura al día no detecta una degradación de rodamiento; para vibración se trabaja en el rango de kilohercios, para temperatura basta con minutos.
• Histórico de intervenciones con fecha y causa. Esto es lo que casi nunca existe en formato usable. Un GMAO relleno con «avería eléctrica» en el campo libre no sirve; hace falta saber qué componente falló, cuándo se detectó y cuándo se cambió.
• Contexto de producción. La misma vibración significa cosas distintas según el producto que se esté fabricando, el lote de materia prima o el turno. Sin esta variable, el modelo confunde cambio de referencia con degradación.

| Modo de fallo | Señal que lo anticipa | Antelación realista | |---|---|---| | Desgaste de rodamiento | Vibración (bandas de alta frecuencia), temperatura | Semanas | | Desalineación de eje | Vibración a 1x y 2x de la velocidad de giro | Semanas | | Obstrucción o cavitación en bomba | Caudal frente a presión, consumo | Días | | Degradación de aislamiento en motor | Corriente, temperatura de bobinado | Semanas o meses | | Fuga en circuito hidráulico | Presión, número de arranques de la bomba | Días | | Desgaste de herramienta de corte | Consumo del husillo, calidad de pieza | Horas o días | | Atasco de cinta o rodillo | Par motor, imagen de la zona | Minutos u horas |

La pregunta útil no es «¿tenemos datos?», sino «¿cuántos fallos de este tipo hemos tenido en los últimos dos años y están bien registrados?». Con menos de diez o quince eventos por modo de fallo, olvídate de entrenar un modelo supervisado decente: toca empezar por detección de anomalías —que solo necesita saber cómo se ve lo normal— y por registrar bien a partir de hoy. Es la misma lógica de datos primero que explicamos en análisis predictivo aplicado.

Un proyecto de mantenimiento predictivo sin histórico de fallos etiquetado no es un proyecto de IA: es un proyecto de instrumentación y registro, y conviene llamarlo por su nombre para presupuestarlo bien.

¿Cuándo conviene el mantenimiento predictivo y cuándo no?

La decisión es económica, no tecnológica. Un activo merece modelo si se cumplen tres condiciones a la vez:

1. El fallo cuesta caro. Parada de línea, lote perdido, penalización por incumplimiento, riesgo de seguridad. Si la máquina se para y no pasa nada durante dos horas, el negocio no está ahí. 2. El fallo es progresivo. La degradación deja rastro medible antes del final. Un fallo súbito de electrónica no se anticipa con vibración; no hay modelo que lo arregle. 3. Hay margen de acción. Si el repuesto tarda seis semanas en llegar, un aviso con cuatro días de antelación sirve de poco. La antelación útil la define la logística, no el algoritmo.

Casos donde normalmente no conviene: flotas de activos baratos y redundantes, máquinas que se sustituyen antes de degradarse, plantas con menos de un año de datos y sin sensórica, y cualquier activo cuyo plan preventivo actual esté funcionando sin incidencias. En esos escenarios el dinero rinde más en mejorar la calidad del dato de mantenimiento o en un cuadro de mando de disponibilidad decente.

Un cuarto criterio que se olvida: quién recibe el aviso. Si el técnico no tiene hueco en el plan de la semana para adelantar una intervención, el modelo genera alertas que nadie atiende. Ese es el punto donde muere la mitad de estos proyectos, y no tiene nada que ver con la precisión del modelo.

¿Cómo se monta el primer caso paso a paso?

Un primer caso bien acotado son entre tres y cinco meses, un solo modo de fallo y una familia de activos. No «la planta».

| Fase | Duración | Qué se produce | Señal de que va bien | |---|---|---|---| | 1. Selección del activo y del fallo | 1-2 semanas | Un activo crítico, un modo de fallo, coste del fallo cuantificado | Mantenimiento y producción están de acuerdo en el caso | | 2. Inventario de datos | 2-3 semanas | Qué señales existen, a qué frecuencia, qué fallos hay registrados | Sabes cuántos eventos reales tienes | | 3. Instrumentación si falta | 3-8 semanas | Sensores añadidos y datos aterrizando en un sitio único | Series continuas, sin huecos de días | | 4. Línea base sin modelo | 2 semanas | Reglas y umbrales simples, con su tasa de acierto | Ya detectas algo; tienes con qué comparar | | 5. Modelo y validación histórica | 3-5 semanas | Detección de anomalía o predicción, probada sobre fallos pasados | Habría avisado en la mayoría de fallos reales | | 6. Piloto en sombra | 6-8 semanas | Avisos que se registran pero no disparan intervención | Falsos positivos por semana en un número tolerable | | 7. Operación | Continua | Aviso integrado en el GMAO con responsable y plazo | Se adelantan intervenciones de verdad |

Las fases 4 y 6 son las que todo el mundo quiere saltarse y las que más valen. La línea base con umbrales te dice si el modelo aporta algo: si una regla de «temperatura media de 24 h por encima de X» detecta el 70 % de los fallos, el modelo tiene que superar eso para justificarse. Y el piloto en sombra evita el desastre clásico: empezar a mandar avisos a producción con un modelo que grita dos veces por turno.

¿Cómo se mide si funciona?

Con métricas de mantenimiento, no de ciencia de datos. La precisión del modelo es un dato interno; lo que se lleva al comité es otra cosa:

• Avisos verdaderos frente a falsos por semana. El número que determina si el equipo confía. Un falso positivo semanal suele ser tolerable; tres al día mata la credibilidad en un mes.
• Antelación media del aviso. Y sobre todo cuántos avisos llegan con antelación útil, la que permite planificar el repuesto y la parada.
• Fallos no detectados. Los que se escaparon. Cada uno se revisa: ¿faltaba señal, faltaba etiqueta o el modo de fallo no es predecible?
• Paradas no planificadas del activo piloto frente al periodo anterior comparable.
• Intervenciones evitadas o adelantadas. Si el preventivo por calendario se espacia con respaldo de datos, ahí hay ahorro directo en piezas y horas.
• Coste total del caso, incluido lo que cuesta mantener los sensores, la conectividad y el modelo. Es el apartado que más se subestima, como pasa con casi cualquier proyecto de IA bien presupuestado.

Define cada métrica con dueño y frecuencia antes de arrancar; si no, a los tres meses la discusión será sobre si el proyecto «va bien» sin nadie capaz de responder con un número. El criterio que usamos para eso está en elegir KPIs que se usan.

¿Qué errores tumban estos proyectos?

Los que se repiten en planta tras planta:

• Empezar por la plataforma. Comprar una solución de monitorización para 300 activos antes de haber demostrado valor en uno. Se acaba pagando licencia por datos que nadie mira.
• Sensorizar todo «por si acaso». Cada sensor es cableado, calibración, mantenimiento y una serie más que vigilar. Se instrumenta el modo de fallo que se quiere predecir, no la máquina entera.
• Confiar en el campo libre del GMAO. Sin un catálogo cerrado de modos de fallo, el histórico no se puede usar para entrenar. Cerrar ese catálogo es trabajo de un mes y desbloquea todo lo demás.
• Ignorar el contexto de producción. Modelos que se disparan cada vez que se cambia de referencia porque nadie les dijo que ese cambio existe.
• No cerrar el bucle. El técnico interviene, encuentra la causa y no la registra. Sin ese retorno el modelo no mejora nunca y el proyecto se estanca en la precisión del primer día.
• Confundir tablero con predicción. Ver la vibración en tiempo real en una pantalla es útil y es otra cosa. Está bien tenerlo, pero no llames predictivo a un visor.
• Dejar fuera al jefe de mantenimiento. Es quien sabe qué falla, cómo suena antes de fallar y qué avisos son creíbles. Sin él, el proyecto es un ejercicio estadístico. Es el mismo patrón que analizamos en por qué fracasan los pilotos de IA.

Cuando el modo de fallo se ve —desgaste visible, fugas, atascos, estado de una pieza en línea—, a veces la vía corta no es la sensórica sino la cámara; ese terreno lo cubrimos en visión artificial en industria. Y en ambos casos, la capa que sostiene todo esto es la de siempre: recoger, almacenar y servir series temporales sin huecos, que es puro trabajo de ingeniería de datos.

Preguntas frecuentes

¿Cuántos datos históricos hacen falta para el mantenimiento predictivo?

Como regla práctica, uno o dos años de señales continuas y entre diez y quince fallos bien registrados del mismo modo. Con menos, el camino razonable es detección de anomalías —que solo necesita aprender cómo se ve el funcionamiento normal— y empezar a etiquetar intervenciones con rigor desde hoy para tener base en doce meses.

¿Se puede hacer mantenimiento predictivo sin instalar sensores nuevos?

A veces sí. Muchos variadores, PLC y máquinas de control numérico ya registran corriente, par, temperatura o alarmas, y esos datos suelen estar accesibles pero sin recoger. Antes de presupuestar sensórica, merece la pena una revisión de lo que la planta ya genera y se está tirando.

¿Qué antelación se consigue en la práctica?

Depende del modo de fallo: días en hidráulica y bombas, semanas en rodamientos y desalineaciones, horas en desgaste de herramienta. Lo importante no es maximizar la antelación, sino que sea mayor que el plazo de repuesto más la ventana de parada disponible; si no, el aviso no cambia ninguna decisión.

¿Cuánto cuesta un primer proyecto de mantenimiento predictivo?

Varía sobre todo según haga falta instrumentar o no. Si las señales ya existen y están accesibles, el coste es de análisis e integración; si hay que sensorizar, se suma hardware, instalación y conectividad, que a menudo pesan más que el modelo. Pide siempre presupuestos que separen esas partidas y que incluyan el mantenimiento anual.

Si tienes un activo que te está dando disgustos y no sabes si tu histórico aguanta un modelo, lo más útil no es una demo de plataforma: es mirar dos años de intervenciones y las señales que ya registra la máquina y decirte con números si el caso es viable o si primero toca instrumentar. Eso es la auditoría, y si prefieres contárnoslo antes en voz alta, hablemos media hora y te diremos sin adornos por dónde empezaríamos.