Software de Mantenimiento Predictivo a Medida para Tu Operación

Haz la cuenta con tus números. Si una línea produce 40,000 pesos por hora y una falla en el compresor principal la detiene 6 horas, son 240,000 pesos de producción perdida en un solo evento. Súmale la cuadrilla de mantenimiento trabajando en emergencia, el flete urgente del repuesto, el personal de producción esperando y, si incumples entregas, la penalización o el cliente que no vuelve. Si ese evento ocurre cuatro veces al año, estás hablando de cerca de un millón de pesos en pérdidas evitables, sin contar el desgaste del equipo.

La respuesta tradicional es apretar el programa preventivo: cambiar piezas cada menos horas, revisar más seguido. Funciona, pero a un precio oculto. Cada componente que reemplazas antes de tiempo es vida útil tirada a la basura, y cada intervención programada innecesaria es una oportunidad más de introducir un error humano en un equipo que funcionaba bien.

El mantenimiento predictivo ataca las dos pérdidas al mismo tiempo: evita las paradas que sí iban a ocurrir y elimina las intervenciones que no hacían falta. Como referencia externa, la guía de mejores prácticas de operación y mantenimiento del Departamento de Energía de Estados Unidos (en inglés) estima que un programa predictivo bien operado ahorra entre 8% y 12% frente a uno puramente preventivo, y más cuando la operación vive en modo reactivo. La pregunta para tu planta no es si vale la pena en abstracto, es si tus datos de hoy alcanzan para predecir con precisión suficiente. Eso es exactamente lo que evaluamos primero.

Quien busca software de mantenimiento predictivo suele encontrar dos categorías que conviene separar. La primera son los GMAO y EAM comerciales con módulos predictivos: plataformas maduras que digitalizan órdenes de trabajo, inventarios de refacciones y calendarios, con analítica encima. Si todavía registras fallas en papel o en hojas de cálculo, empieza ahí. Sin un sistema de registro disciplinado no hay mantenimiento predictivo posible, con nosotros ni con nadie.

La segunda categoría es una capacidad construida a medida sobre tus datos. Tiene sentido cuando ya tienes historial registrado, tus activos críticos tienen modos de falla particulares y el módulo genérico del producto no los cubre, o cuando la alerta debe integrarse a procesos que el producto no toca: tu sistema de turnos, tu abastecimiento de refacciones o tus reglas de paro programado.

La diferencia práctica: el producto te pide adaptar tu operación a sus supuestos y cobra licencia por usuario o por activo, lo uses o no. El desarrollo a medida se adapta a tu operación, el código y los datos quedan de tu propiedad y después del despliegue pagas una suscripción por la operación, no por una licencia. Si tu caso encaja mejor en un producto comercial, te lo decimos en la primera llamada; perder un proyecto es más barato que heredar uno condenado.

Un modelo de fallas se entrena con ejemplos de fallas reales. Sin ejemplos no hay modelo, solo especulación con gráficas bonitas. Estos son los tres insumos que revisamos en la evaluación inicial:

Aquí está la parte que muchos vendedores omiten: si la evaluación muestra que no hay historial útil, la recomendación honesta es empezar por instrumentación y registro estructurado, no por un modelo. Tres a seis meses de buen registro valen más que cualquier algoritmo aplicado sobre datos malos. Ese trabajo de base es justamente el tipo de proyecto que cubre nuestra consultoría de datos.

El error clásico es querer cubrir toda la planta en el primer proyecto. Terminas con un modelo mediocre para doscientos activos que nadie usa. El piloto correcto toma una o dos familias de activos que cumplen tres condiciones: la falla es cara, la falla ocurre con suficiente frecuencia para tener ejemplos y existen datos sobre ella. Estas son las familias que suelen pasar ese filtro:

Con el piloto validado en una familia, extender a la siguiente es un trabajo de semanas, no de meses: la infraestructura de datos, el flujo de alertas y la validación ya existen. Así se construye una cobertura amplia sin apostar el presupuesto completo de entrada.

Un modelo predictivo se mide contra tu realidad, no contra una presentación. La línea base es tu programa preventivo actual: cuántas fallas no planeadas tuviste el año pasado, cuántas intervenciones programadas hiciste y qué costó cada una. Contra esa línea se comparan dos números del modelo: fallas detectadas a tiempo y falsas alarmas.

El segundo número es el que mata proyectos. Un modelo que detecta todo pero grita lobo a diario muere en una semana: la cuadrilla aprende a ignorar las alertas y el sistema entero se vuelve decorativo. Por eso el ajuste del umbral de alerta es una decisión operativa que tomamos contigo, no un parámetro escondido. Preferimos perder una detección marginal y mantener la credibilidad del sistema.

En la revisión semanal de avances ves exactamente esto: qué predijo el modelo sobre datos históricos, qué acertó, qué se le escapó y qué tan seguido se equivoca. Si los números no mejoran tu programa actual, el piloto termina ahí y te quedas con la evaluación y la documentación.

La mitad del trabajo de un proyecto de mantenimiento predictivo no es el modelo, es el flujo de la alerta. Antes de escribir el primer modelo definimos contigo tres cosas: quién recibe la alerta y por qué medio, qué acción concreta recomienda y cómo aterriza en tu sistema de mantenimiento actual. Si tu equipo vive en el GMAO, la alerta debe crear ahí una orden de trabajo con el diagnóstico y la ventana de intervención sugerida, no llegar a un correo que nadie abre.

La integración con tus sistemas existentes, incluido tu GMAO, tu ERP y tus fuentes de sensores, se evalúa durante el alcance del proyecto. Si necesitas apoyo para decidir la arquitectura completa, nuestra consultoría en inteligencia artificial cubre esa evaluación de viabilidad antes de comprometer desarrollo.

El piloto tiene alcance fijo y dura de 2 a 6 semanas según la cantidad de fuentes y el estado de tus datos. Empieza con lo que ya tienes: exportaciones de tu GMAO, archivos de historial y acceso de lectura a las señales disponibles. No necesitas comprar sensores ni detener nada.

Ese periodo en sombra es deliberado. Nadie debería reorganizar el mantenimiento de una planta por un modelo que solo ha acertado sobre el pasado. Cuando las predicciones en vivo aguantan la comparación, el paso a operación es una decisión con evidencia, y el modelo entra a producción bajo nuestra operación por suscripción de machine learning, con monitoreo y reentrenamiento continuo.

Hemos visto proyectos de este tipo fracasar por razones predecibles, y preferimos decirlas antes de cobrar. No eres candidato todavía si tu flota de activos críticos es tan pequeña que una falla al año no justifica el proyecto, si no existe historial de fallas ni registro disciplinado y no hay presupuesto para crearlo, o si las fallas que te preocupan son eventos externos, como cortes de energía o errores de operación, que ningún sensor del equipo va a anticipar.

Tampoco prometemos precisión mágica. Un modelo recién desplegado se equivoca, y lo que lo vuelve útil es el ciclo de retroalimentación con tus técnicos durante los primeros meses. Los modos de falla que nunca han ocurrido en tu planta no se pueden predecir con tu historial; para esos casos la respuesta es instrumentación y umbrales físicos, no machine learning.

Si después de leer esto tu caso sigue en pie, hablemos. Y si todavía no estás seguro de por dónde empezar, revisa nuestros servicios o escríbenos con tus datos actuales; la evaluación inicial te da un dictamen claro aunque la respuesta sea "todavía no".