Qué pedirle a un GMAO para predictivo
Qué tiene que traer un GMAO si quieres hacer mantenimiento predictivo: lecturas con umbral, órdenes automáticas, histórico por activo y salida de datos.
Actualizado el 6 min de lectura
- Mantenimiento predictivo
- Indicadores
- Checklists
- Activos
Si estás buscando un sistema con la intención de hacer mantenimiento predictivo, conviene saber qué preguntar. «Tenemos predictivo» aparece en casi todas las fichas y significa cosas muy distintas: desde guardar un campo de texto con la lectura hasta generar trabajo automáticamente cuando un valor se cruza.
Esta es la lista de lo que hay que exigir, con lo que hace GMAO CLOUD en cada punto.
1. Que el activo pueda tener contador
Lo básico, y no todos lo tienen bien resuelto. El equipo necesita un contador propio —horas de funcionamiento, kilómetros, ciclos, unidades producidas— y no un campo suelto donde apuntar un número.
En la gestión de activos el contador es una entidad con su unidad, y cada lectura queda registrada con quién la tomó y cuándo. Eso es lo que permite después tener una serie y no una foto.
2. Que un umbral genere trabajo, no solo un aviso
Aquí está la diferencia entre un sistema que registra y uno que actúa, y es la pregunta que más separa unos productos de otros.
En GMAO CLOUD, sobre el contador de un activo se define un límite —las unidades que se espera que aguante— y un porcentaje de aviso. Cuando se registra una lectura, el sistema suma lo acumulado, calcula el porcentaje consumido y, si supera el umbral, genera automáticamente la orden de trabajo preventiva, con su activo, su dirección y el modelo de checklist que corresponda a ese equipo.
Es decir: el plan no depende solo del calendario. Puede depender del uso real, que es lo que hace falta en una máquina que trabaja a turnos irregulares, en una flota o en un componente cuyo desgaste va por ciclos.
Pregunta esto literalmente en cualquier demo: si una lectura cruza el umbral, ¿qué pasa exactamente? Si la respuesta es «sale en un listado», no es lo mismo.
3. Que las comprobaciones admitan valores, no casillas
Un checklist de casillas dice que alguien miró. Uno con valor mínimo y máximo dice qué vio, y deja registrada como anomalía cualquier lectura fuera de rango en el momento en que se toma.
Esto es lo que convierte una ronda de inspección en una serie temporal. Y aquí está la idea más útil de todo el asunto: no hace falta sensorizar para empezar a hacer predictivo. Una persona con un termómetro y un medidor de vibración portátil, pasando cada mes por los equipos críticos y apuntando valores, ya genera la tendencia que permite anticipar.
La sensorización continua acelera eso. No lo inventa.
4. Que los checklists se definan por familia
Si hay que configurar la ronda equipo por equipo, en una instalación con cincuenta bombas iguales nadie lo hace.
Los modelos de comprobación se resuelven en cascada —activo, modelo, subfamilia, familia—, así que se define una vez para todo un tipo de equipo y solo se afina donde haga falta.
5. Que se pueda registrar sin cobertura
Las mediciones se toman en salas de máquinas, fosos y naves, que es donde no hay señal. Si el técnico tiene que apuntar en papel y pasarlo por la tarde, los valores salen redondeados y la serie pierde precisión justo donde importa.
La app de técnicos guarda órdenes, activos y documentos en el dispositivo y encola las acciones hechas sin conexión, sincronizándolas al recuperar señal. Si una falla, queda marcada con su motivo en vez de desaparecer.
6. Que la anomalía se convierta en algo
El punto donde mueren la mayoría de los proyectos predictivos, y no es técnico.
Un técnico registra una vibración que ha subido, y no pasa nada. A la tercera vez deja de registrarla, y con razón. La anomalía tiene que poder convertirse en una incidencia con su prioridad y su responsable, o en una decisión explícita de no hacer nada.
Y los avisos tienen que ser calibrables: se puede marcar qué estados no notifican. Avisar de todo convierte las notificaciones en ruido y la gente deja de leerlas, que es peor que no tenerlas.
7. Que exista el histórico contra el que comparar
Un umbral no se saca de un catálogo: sale del comportamiento de ese equipo en esa instalación.
De ahí se sigue algo poco intuitivo: el predictivo empieza midiendo equipos que funcionan bien, para tener línea base. Si solo mides cuando sospechas, nunca tendrás con qué comparar.
Por eso el requisito real, antes que cualquier función predictiva, es que las órdenes de trabajo se cierren con datos ciertos: tiempos medidos con cronómetro, material imputado y comprobaciones registradas. El predictivo sobre un histórico vacío no existe.
8. Que el coste acumulado también dispare algo
Hay una variable que no es física y que decide más dinero que la vibración: cuánto llevas gastado en reparar esa máquina.
Sobre un activo se puede registrar su coste de reposición y un porcentaje de aviso: el sistema notifica cuando el gasto acumulado en reparaciones supera ese porcentaje. No genera una orden —sustituir un equipo es una decisión de negocio, no una tarea—, pero pone la cifra delante justo cuando toca mirarla.
9. Que los datos puedan salir
Si tu plan a medio plazo incluye analítica propia —cruzar mantenimiento con producción, o aplicar tus propios modelos—, necesitas que el histórico salga del sistema.
GMAO CLOUD tiene API REST pública y conexión SQL directa, que son las dos vías que piden las herramientas de BI. Están en el catálogo de integraciones junto con SOAP, CSV y FTP.
Es la respuesta honesta a «¿tiene cuadros de mando a medida?»: dentro del producto hay un catálogo de informes con filtros y exportación, y para lo demás se conecta tu herramienta, que además te permite cruzar con datos que el GMAO no tiene.
10. Que no te vendan más de lo que hay
Una advertencia final. Un GMAO es donde vive el histórico y la decisión: la ficha del activo, las lecturas, las anomalías, la orden que sale de ellas y los indicadores para saber si sirvió.
No es una plataforma de análisis de señal en continuo, y quien te lo venda como tal probablemente esté describiendo otra cosa. Si tu caso exige muestreo a alta frecuencia sobre la señal en bruto, eso es un sistema aparte que se conecta —por API— con el GMAO para que la alerta acabe siendo trabajo.
Cómo empezar sin gastar
Tres o cuatro equipos críticos. Para cada uno: qué modo de fallo quieres anticipar, qué variable lo delata, cada cuánto se mide y quién actúa cuando se cruza el umbral. La ronda se da de alta como preventivo con su checklist de valores, y en unos meses hay línea base.
Hay más sobre el método en mantenimiento predictivo: cómo se empieza. Si quieres verlo sobre tus equipos, puedes solicitar una demo.