Cualquier jefe de planta conoce las dos formas en que suele fallar el mantenimiento. Se espera a que una máquina se rompa y luego se corre a apagar el incendio, o se reemplazan piezas según un calendario fijo, las necesiten o no. Lo primero cuesta paradas no planificadas. Lo segundo cuesta piezas y mano de obra en equipos que todavía estaban bien. El mantenimiento predictivo busca intervenir solo cuando el equipo avisa que está a punto de fallar, y el IoT es la forma en que el equipo lo avisa.
Esto no es magia y hacerlo mal sale caro. Bien hecho, empieza en pequeño, se valida sobre una clase de activos y crece desde ahí. Así es como las empresas lo aplican de verdad.
Reactivo, preventivo y predictivo son tres apuestas distintas
El mantenimiento reactivo es trabajar hasta el fallo. Se arregla la máquina cuando se detiene. Es el enfoque más barato de montar y el más caro cuando un activo crítico cae a mitad de turno y se lleva la línea por delante.
El mantenimiento preventivo cambia ese riesgo por un calendario. Reemplazar el rodamiento cada seis meses, cambiar el aceite cada tantas horas, sin importar el estado real. Reduce los fallos imprevistos, pero se paga por un servicio que el activo aún no necesitaba, y de todos modos aparecen fallos entre intervalos porque el desgaste no sigue un calendario.
El mantenimiento predictivo observa el estado real de la máquina y actúa según lo que ve. Un rodamiento que empieza a fallar aparece en los datos de vibración semanas antes de gripar. Un motor que consume más corriente de lo normal está avisando de que algo se está agarrotando. Se interviene el activo cuando los datos dicen que lo necesita, ni antes ni después de que ya haya fallado. A cambio, el predictivo exige instrumentación, un flujo de datos y alguien que confíe lo suficiente en las alertas como para actuar sobre ellas.
Los sensores que de verdad dicen algo
No hace falta medirlo todo. Un puñado de señales concentra la mayor parte del aviso temprano en equipos rotativos y eléctricos.
Vibración. El caballo de batalla para motores, bombas, ventiladores, reductores y todo lo que gira. El desgaste de rodamientos, el desequilibrio, la desalineación y la holgura aparecen como cambios en la firma de vibración mucho antes de manifestarse como una avería.
Temperatura. El calor es síntoma de fricción, resistencia eléctrica y sobrecarga. Un rodamiento más caliente que sus vecinos, una carcasa de motor que sube con el tiempo o un reductor que se calienta bajo carga normal son señales que vale la pena revisar.
Corriente del motor. La corriente que consume un motor refleja contra qué está luchando. Firmas de corriente crecientes o erráticas apuntan a problemas de carga mecánica, fallos eléctricos e ineficiencias en desarrollo, sin meter un sensor dentro de la máquina.
Acústica. El monitoreo ultrasónico y audible detecta cosas que las demás señales pasan por alto, como fugas de aire comprimido, defectos incipientes en rodamientos y arcos eléctricos. Resulta útil donde no se puede colocar un sensor de contacto sobre el activo.
Elija las señales que coincidan con sus modos de fallo. Una planta llena de bombas y motores se apoya en vibración y corriente. Una instalación con mucho aire comprimido se apoya en la acústica. Medir una señal que no tiene nada que ver con cómo fallan sus equipos solo suma costo.
El flujo desde el sensor hasta la acción
Una lectura de sensor guardada en una base de datos no ha salvado a nadie. El valor está en el camino que recorren los datos después de recogerse.
Empieza en el activo, donde el sensor genera una lectura. Esa lectura viaja por la conectividad, ya sea celular, LoRaWAN, cableada o un gateway local, hacia una plataforma que la ingiere y la almacena. En la plataforma, los datos se encuentran con la lógica. Al principio esa lógica es un umbral: una alarma de vibración alta, un techo de temperatura, un límite de corriente. A medida que se acumula histórico, la lógica puede convertirse en un modelo que aprende la firma normal de cada activo y marca las desviaciones, lo que detecta problemas que un umbral fijo dejaría pasar.
Cuando la lógica salta, levanta una alerta. La alerta llega a una persona o a un sistema que puede actuar, y la acción queda registrada. Ese último paso es donde fracasan en silencio la mayoría de los despliegues. Los datos estaban bien, la alerta saltó y no pasó nada porque responder a ella no era tarea de nadie. El ahorro vive en la orden de trabajo, no en el dashboard.
Empiece por una clase de activos, no por la planta entera
El instinto es instrumentarlo todo de golpe. Resístalo. Un despliegue a nivel de planta multiplica el costo, el esfuerzo de integración y el número de alertas antes de que se haya aprendido a confiar en ninguna, y una avalancha de alertas en las que nadie confía es peor que no tener alertas.
Elija una clase de activos donde el fallo duela y el modo de fallo se entienda bien. Bombas críticas, los motores principales, una línea concreta de reductores. Instrumente esa clase, lleve las alertas a un punto en que el equipo de mantenimiento les crea y demuestre el ahorro sobre algo que pueda medir. Una vez que el equipo confíe en el sistema y se pueda señalar la parada que se evitó, ampliar a la siguiente clase de activos es un argumento fácil de defender. Querer abarcar toda la planta el primer día es como se estancan los pilotos.
Qué impulsa realmente el ROI
El retorno del mantenimiento predictivo viene de unos pocos lugares concretos, y debería poder señalar cada uno.
Las paradas evitadas suelen ser lo más grande. Si el fallo no planificado de un activo crítico cuesta una cantidad conocida por hora de producción perdida, anticiparse a ese fallo es dinero que puede defender. La mayor vida útil del activo también cuenta, porque dar servicio según el estado en lugar de trabajar hasta el fallo mantiene los equipos más sanos durante más tiempo y estira el capital. Menos salidas de emergencia se reflejan directamente en el presupuesto de mantenimiento, ya que el trabajo planificado durante un turno es más barato que una carrera fuera de horario por una pieza que no tenía en el almacén.
Sea honesto con la línea base. El ROI es la diferencia entre lo que los fallos solían costarle y lo que le cuestan ahora, y una línea base recordada de memoria favorece a cualquier proyecto. Si no conoce su costo actual de paradas, ese es el primer número que debe fijar, antes de comprar un solo sensor.
Dashboards que la gente lee y alertas en las que la gente confía
Dos cosas hacen que la adopción en planta funcione o se hunda. La primera es un dashboard que muestre la salud de los activos de un vistazo, para que el equipo vea qué máquinas van por mal camino sin leer números en bruto. La segunda son alertas en las que el equipo confíe.
La confianza es frágil. Una alerta que salta por ruido, o que salta diez veces por un solo evento, enseña a la gente a ignorarla, y una alerta ignorada equivale a no tener alerta. Ajuste los umbrales a cada activo, suprima las alarmas duplicadas y dirija cada alerta a la persona responsable de la respuesta. Una alerta que aterriza en la bandeja correcta con suficiente contexto para actuar vale más que un dashboard lleno de gráficos que nadie abre.
Dónde encaja TagoIO
TagoIO es la capa de plataforma dentro de ese flujo. Ingiere los datos de sensores que llegan por su conectividad, los almacena, ejecuta la lógica que decide qué es normal, visualiza la salud de los activos en dashboards y levanta las alertas cuando algo se desvía.
Algunas cosas importan para un despliegue de mantenimiento. La lógica puede empezar como un umbral simple y crecer hasta un modelo de condición a medida que se acumula histórico, sin tocar el resto del stack. Las alertas se dirigen a email, SMS o a otro sistema, para que lleguen a quien sea responsable de la respuesta. Y TagoIO se integra con un CMMS o un ERP a través de sus APIs, de modo que una alerta que salta puede abrir una orden de trabajo automáticamente en lugar de esperar a que alguien la transcriba. Para entornos regulados, la plataforma cuenta con certificación ISO 27001 y se alinea con el GDPR. Si revende a clientes, TagoRUN ofrece una versión de marca blanca, y TagoCore es un runtime de borde open source para procesar más cerca del activo.
La plataforma se encarga de la ingesta, el almacenamiento, la lógica, los dashboards y las alertas. El ahorro sigue viniendo de sus propias operaciones y de que alguien actúe sobre lo que muestran los datos. Empiece por una clase de activos, demuestre el número y crezca desde ahí.
