INDUSTRIA · MANTENIMIENTO · ERP/GMAO · AUTOMATIZACIÓN CON IA
Cómo automatizar la gestión del mantenimiento preventivo alrededor del ERP o GMAO
El plan dice que una revisión toca esta semana. El técnico cree que ya la hizo. La orden sigue abierta, el repuesto utilizado no aparece registrado y nadie sabe si el siguiente vencimiento debe mantenerse o desplazarse. Al automatizar el mantenimiento preventivo, el problema no es tener un calendario: es saber qué ocurrió realmente con cada intervención.
Automatizar mantenimiento preventivo significa controlar cada intervención desde que toca hacerla hasta que queda cerrada con suficiente evidencia.
El ERP o la GMAO pueden generar fechas y órdenes, pero el proceso real incluye preparación, asignación, ejecución, evidencias, incidencias, revisión y cierre. La IA puede interpretar partes, resumir historial, clasificar hallazgos y preparar comunicaciones; no debe decidir por sí sola si una máquina es segura, cambiar frecuencias ni cerrar técnicamente una intervención sin datos verificables.
Tener un plan preventivo no significa tener el mantenimiento controlado
Una empresa puede tener un calendario completo y seguir gestionando mal el preventivo. Basta con que las órdenes se abran tarde, falten repuestos, los técnicos registren resultados de forma desigual o el cierre administrativo no refleje lo que ocurrió en planta.
El mantenimiento preventivo parte de una idea sencilla: realizar trabajos recurrentes antes de que aparezca una avería, siguiendo una frecuencia definida por tiempo, uso u otras reglas autorizadas. Sin embargo, el valor no está en que una fecha aparezca en una pantalla, sino en que la intervención pase por todas las etapas necesarias y deje una evidencia suficiente para saber qué se hizo, qué quedó pendiente y qué ocurre después.
Por eso, automatizar mantenimiento preventivo en industria no debería empezar por enviar más avisos. Debería empezar por una pregunta más útil: ¿cómo sabemos que cada preventivo previsto llegó realmente a un cierre correcto?
Este enfoque mantiene la frontera con la automatización general de procesos industriales. Allí el objetivo es identificar qué procesos administrativos y operativos alrededor del ERP conviene automatizar. Aquí nos centramos en un caso concreto: el mantenimiento preventivo y su trazabilidad de principio a fin.
ERP, GMAO, plan y orden: conceptos que conviene separar
La gestión del mantenimiento preventivo en un ERP o GMAO organiza cuándo debe realizarse cada intervención, cómo se prepara y asigna, qué se ejecuta y con qué evidencia puede darse por cerrada.
Para un decisor no técnico, parte de la confusión viene de utilizar varias palabras como si fueran intercambiables.
ERP
ERP significa Enterprise Resource Planning, o sistema de planificación de recursos empresariales. Integra áreas como compras, inventario, finanzas, producción o mantenimiento, según el software y la configuración de cada empresa.
GMAO
GMAO significa Gestión del Mantenimiento Asistido por Ordenador. Es un software especializado en activos, planes de mantenimiento, órdenes, repuestos, historial y otros procesos de mantenimiento. En inglés suele denominarse CMMS, Computerized Maintenance Management System.
Una empresa puede gestionar mantenimiento dentro de su ERP, utilizar una GMAO especializada o combinar ambos. No existe una arquitectura universal en la que un sistema “mande” sobre todo. Lo importante es definir qué información confirma cada aplicación y cómo se mantienen coherentes los datos cuando intervienen varias.
| Concepto | Qué representa | Qué no demuestra por sí solo |
|---|---|---|
| Plan preventivo | Qué mantenimiento debe repetirse y con qué lógica de frecuencia. | Que la intervención concreta ya se haya hecho. |
| Fecha o vencimiento | Cuándo corresponde generar o realizar una intervención según la configuración. | Que esté preparada, asignada o ejecutada. |
| Orden de mantenimiento | El trabajo concreto que debe gestionarse para un activo o ubicación. | Que todas las tareas estén terminadas o revisadas. |
| Tarea | Una actuación dentro de la orden. | Que la orden completa pueda cerrarse. |
| Evidencia | Dato, lectura, parte, foto, documento o registro que demuestra lo ocurrido cuando el proceso lo exige. | Que no exista un hallazgo o acción posterior. |
| Hallazgo | Una condición detectada durante el trabajo que puede requerir análisis o actuación. | Que sea automáticamente una avería crítica. |
Cómo llevar cada mantenimiento preventivo hasta un cierre verificable
En lugar de pensar en “el plan” como una lista de fechas, resulta más útil seguir la vida de cada intervención concreta. Una secuencia razonable puede ser:
La condición puede depender de una fecha, de un contador de uso o de una combinación definida en el sistema.
El sistema identifica el activo, las tareas previstas y el contexto necesario para organizar el trabajo.
Puede hacer falta un repuesto, documentación, un permiso, acceso a una zona, una ventana de parada u otra condición aplicable.
La persona o equipo responsable realiza las tareas y registra resultados relevantes.
No todas las órdenes requieren la misma documentación, pero aquello que sea condición de cierre debe quedar registrado.
Una desviación puede resolverse dentro del trabajo previsto o generar una actuación adicional, según la política de mantenimiento.
La intervención queda cerrada cuando cumple las condiciones definidas, no simplemente porque alguien haya marcado una tarea como terminada.
La lógica depende de cómo esté configurado el plan; no debe improvisarse desde una automatización externa.
Este recorrido evita que la automatización se limite a crear tareas. La orden se convierte en una unidad trazable con inicio, responsables, resultado, evidencia y excepciones.
El siguiente vencimiento no siempre se calcula igual
Los sistemas de mantenimiento pueden programar preventivos de distintas formas. IBM Maximo documenta planes basados en tiempo, en uso medido o en una combinación de ambos. SAP también contempla planes temporales y planes basados en rendimiento o contadores. Microsoft Dynamics 365 Asset Management utiliza programas de mantenimiento para generar trabajo preventivo según la configuración del activo y del plan.
Para un responsable de negocio, la conclusión importante no es aprender la interfaz de cada producto. Es entender que la frecuencia pertenece al modelo de mantenimiento y debe conservarse como una regla explícita.
Por tiempo
Por ejemplo, cada tres meses o cada año. El sistema utiliza fechas y ciclos definidos.
Por uso o contador
Por ejemplo, tras determinadas horas de funcionamiento o unidades producidas, siempre que exista una lectura autorizada y fiable.
Combinado
La intervención puede dispararse cuando se alcanza primero una condición temporal o de uso, según la configuración.
Con reglas de calendario específicas
Algunos sistemas admiten temporadas, márgenes, fechas extendidas u otras particularidades propias del plan.
Hay además una diferencia especialmente útil para evitar automatizaciones incorrectas. Maximo distingue entre una programación fija y una programación que toma como referencia el cierre del trabajo anterior. En la primera, retrasar una intervención no tiene por qué desplazar toda la secuencia futura. En la segunda, la finalización anterior sí puede influir en el siguiente vencimiento.
Ejemplo práctico
Un preventivo trimestral estaba previsto para el 1 de abril y se ejecutó el 10. Si el plan mantiene un calendario fijo, el siguiente puede seguir asociado al 1 de julio. Si está configurado para calcularse desde la finalización anterior, podría desplazarse. La automatización no debe decidir qué lógica “parece más razonable”: debe respetar la configuración real.
Una orden puede existir y todavía no estar preparada para ejecutarse
Generar la orden demasiado pronto o asignarla sin comprobar dependencias puede convertir el GMAO en una lista de trabajo que acumula bloqueos. Antes de enviar una intervención a ejecución conviene determinar qué necesita realmente.
- Activo y ubicación correctos. Evitar órdenes asociadas a referencias ambiguas o equipos ya sustituidos.
- Tareas previstas. Saber qué debe hacerse y qué instrucciones o documentación aplican.
- Repuestos o consumibles. Comprobar disponibilidad solo cuando la intervención los requiera.
- Permisos o condiciones de acceso. Puede haber trabajos que necesiten autorización, coordinación de seguridad o disponibilidad de una zona.
- Ventana operativa. Algunas tareas pueden hacerse con la instalación en funcionamiento; otras necesitan coordinación con producción.
- Responsable adecuado. Competencia, equipo, proveedor o turno deben corresponder con el trabajo.
Compras y aprovisionamiento aparecen aquí como dependencia, pero no deben absorber el artículo. Si falta un repuesto, el proceso puede generar una solicitud o relacionar la orden con una compra. El detalle de necesidad, aprobación, proveedor, pedido y recepción pertenece a la guía de automatización de compras y aprovisionamiento en industria.
La automatización aporta especialmente cuando puede detectar que una orden está a punto de vencer y todavía tiene una dependencia abierta. Eso permite actuar antes de que el mantenimiento llegue tarde, en lugar de limitarse a alertar cuando el retraso ya existe.
También permite ordenar el trabajo con más contexto. No es lo mismo una intervención que vence mañana y está completamente preparada que otra prevista para la semana siguiente pero bloqueada por un repuesto con plazo de entrega largo. La prioridad operativa puede incorporar fecha, impacto, preparación y excepciones, siempre según reglas definidas por mantenimiento. Así se evita que el equipo trabaje únicamente por orden cronológico cuando existen dependencias que requieren anticipación.
“Preventivo ejecutado” no significa necesariamente “orden cerrada”
Conviene definir este término con precisión. En este artículo, preventivo ejecutado significa que las tareas previstas para esa intervención se han realizado y su resultado ha quedado registrado con el nivel de detalle exigido. No significa automáticamente que la orden pueda cerrarse.
Puede faltar, por ejemplo, adjuntar una evidencia requerida, validar una lectura, registrar materiales utilizados, revisar un hallazgo o confirmar que una condición posterior se ha cumplido.
Marcar “hecho”
Indica que alguien da por realizada una tarea. Si el sistema no exige más, puede perderse información necesaria para reconstruir el trabajo.
Cerrar con condiciones verificables
La orden solo cambia a cerrada cuando se cumplen las condiciones definidas para ese tipo de intervención.
Esto no implica que todas las órdenes deban pasar por una aprobación humana. Una intervención sencilla puede cerrarse automáticamente si todas las tareas, datos y evidencias exigidas están presentes y no existe ninguna excepción. Otra puede requerir revisión por el responsable de mantenimiento.
Un hallazgo durante el preventivo no debería alargar la misma orden indefinidamente
Durante una revisión preventiva puede aparecer desgaste, una fuga, una lectura fuera de rango, una pieza que conviene sustituir o cualquier otra condición no prevista. Ese hallazgo debe registrarse, pero no siempre debe resolverse dentro de la misma orden.
Separar ambas cosas permite responder preguntas que de otro modo se mezclan:
- ¿El preventivo programado se realizó?
- ¿Se detectó una incidencia?
- ¿La incidencia requiere una orden correctiva?
- ¿Puede seguir funcionando el activo según los criterios autorizados?
- ¿Quién debe revisar o priorizar la actuación posterior?
Una política puede permitir resolver en el momento una pequeña anomalía prevista dentro del alcance. Otra situación puede necesitar abrir una orden correctiva independiente. El sistema debe conservar la relación entre ambas sin convertir el preventivo en un contenedor infinito de trabajo futuro.
Esta frontera también evita confundir la entrada con el mantenimiento correctivo hotelero desarrollado en automatización del mantenimiento de un hotel. Allí el centro es un aviso o incidencia que afecta a la operación y debe resolverse. Aquí partimos de una intervención preventiva planificada en entorno industrial.
Dónde puede aportar la IA sin decidir lo que corresponde al sistema de mantenimiento
Buena parte de la información de mantenimiento no llega como un dato limpio. Los técnicos escriben observaciones, adjuntan partes, describen síntomas con vocabulario distinto, envían fotos o reciben documentación de proveedores. Ahí la IA puede reducir trabajo manual y mejorar la calidad del registro.
Interpretar observaciones
Convertir texto libre de técnicos en información estructurada: síntoma descrito, pieza mencionada, ubicación, acción realizada o pendiente.
Clasificar hallazgos
Agrupar observaciones por tipos operativos para facilitar revisión y priorización, sin declarar por sí sola su criticidad técnica.
Resumir historial
Preparar un resumen de intervenciones anteriores, incidencias relacionadas y trabajos abiertos para que el responsable llegue al caso con contexto.
Extraer datos de partes
Recuperar referencias, fechas, materiales, lecturas o comentarios desde documentos cuando el formato lo permita y exista validación suficiente.
Detectar contradicciones
Señalar casos en los que un parte dice “realizado” pero faltan tareas, evidencias o estados necesarios para cerrar.
Preparar comunicaciones
Redactar borradores para avisar de una orden bloqueada, solicitar información o explicar una excepción al equipo correspondiente.
La IA no debería decidir que una máquina es segura, modificar una frecuencia de mantenimiento desde conocimiento general, omitir tareas, inventar lecturas de contador, afirmar que un trabajo se realizó sin evidencia ni cerrar técnicamente una orden cuando faltan condiciones.
En Yarvia diseñamos esta separación de forma explícita: la IA ayuda a entender información ambigua y a reducir trabajo manual; las reglas, el ERP/GMAO, las integraciones y las personas autorizadas conservan el control sobre fechas, estados, activos, evidencias y decisiones técnicas.
La frontera IT/OT: automatizar la gestión no es controlar la maquinaria
En industria es importante separar dos ámbitos. IT, de Information Technology, se refiere a los sistemas de información y gestión: ERP, GMAO, correo, bases de datos, aplicaciones administrativas o integraciones. OT, de Operational Technology, agrupa tecnologías que monitorizan o actúan sobre procesos y equipos físicos.
NIST SP 800-82 Rev. 3 utiliza OT como marco para sistemas que interactúan con el entorno físico y trata sus requisitos particulares de rendimiento, fiabilidad y seguridad. En ese ámbito pueden aparecer PLC, sistemas SCADA, DCS, controladores y otras tecnologías de operación industrial.
Esta entrada se mantiene deliberadamente en el lado de la gestión. Podemos automatizar, por ejemplo:
- La creación de una orden cuando un dato autorizado cumple una condición.
- La consulta de una lectura que ya publica un sistema intermedio autorizado.
- La asignación de trabajo en la GMAO.
- La recopilación de evidencias y el registro de resultados.
- La sincronización de estados con el ERP.
Queda fuera diseñar lógicas de PLC, cambiar consignas, controlar motores, actuar directamente sobre equipos, alterar sistemas SCADA/DCS o tomar decisiones de seguridad funcional. Consumir un dato procedente de OT no convierte automáticamente una automatización administrativa en un sistema de control industrial.
Qué dato debe confirmar cada sistema antes de automatizar
Cuando ERP, GMAO, almacén, compras y otras aplicaciones participan en el mismo mantenimiento, duplicar toda la información entre todas ellas suele crear más problemas que soluciones. Conviene definir quién confirma cada dato.
| Dato o decisión | Sistema que podría confirmarlo | Riesgo si se duplica sin criterio |
|---|---|---|
| Plan y frecuencia preventiva | ERP o GMAO, según arquitectura. | Dos calendarios calculando vencimientos distintos. |
| Activo y ubicación | Maestro de activos del ERP/GMAO o sistema definido. | Órdenes sobre equipos duplicados o retirados. |
| Repuesto disponible | Inventario/ERP o almacén. | Reservas ficticias o cantidades desactualizadas. |
| Asignación y estado de la orden | GMAO o módulo de mantenimiento correspondiente. | Trabajo “cerrado” en un sistema y abierto en otro. |
| Lectura de uso | Fuente autorizada que la registra o expone. | Disparar preventivos desde una lectura antigua o no validada. |
| Evidencia y parte técnico | Orden/GMAO, gestor documental o repositorio definido. | No poder reconstruir qué justificó el cierre. |
Esta lógica enlaza con la guía sobre integración CRM–ERP y autoridad del dato: una integración fiable no consiste en copiar campos de un sitio a otro, sino en definir quién puede crear, actualizar y confirmar cada información.
Lo mismo ocurre cuando las órdenes generan movimientos de materiales, compras o costes. El mantenimiento puede iniciar el proceso, pero cada dominio conserva su propia lógica.
Las excepciones útiles son las que explican por qué una orden no puede avanzar
Una bandeja de “órdenes atrasadas” sirve de poco si no distingue causas. Para automatizar de forma útil conviene registrar el motivo que impide avanzar y qué decisión hace falta.
Falta un repuesto
La orden puede quedar bloqueada hasta que exista disponibilidad o una alternativa autorizada.
Activo no disponible
Producción no puede liberar el equipo en la ventana prevista y hace falta reprogramar.
Lectura incoherente
El contador muestra un salto o un valor que necesita comprobación antes de recalcular nada.
Evidencia incompleta
El técnico terminó las tareas, pero falta un dato necesario para cerrar.
Hallazgo abierto
La intervención preventiva acabó, pero apareció una condición que debe convertirse en otra actuación.
Integración fallida
El trabajo se registró en un sistema pero no sabemos si se actualizó correctamente en el otro.
El último caso conecta con la monitorización de automatizaciones en producción. Si una escritura tiene un resultado incierto, conviene verificar el sistema destino antes de reintentar; repetir a ciegas puede crear órdenes o movimientos duplicados.
Qué medir para saber si la automatización mejora el mantenimiento
La primera métrica no debería ser “número de automatizaciones”. Interesa saber si el flujo preventivo se vuelve más controlable.
Cumplimiento
Intervenciones previstas frente a cerradas dentro de la ventana definida por la empresa.
Preparación
Órdenes que llegan al vencimiento con dependencias pendientes: repuestos, documentación, acceso o recursos.
Calidad del cierre
Órdenes reabiertas, evidencias ausentes, datos corregidos después del cierre o estados inconsistentes.
Excepciones
Motivos de bloqueo y tiempo hasta resolverlos, diferenciando causas operativas de fallos de integración.
Hallazgos
Preventivos que generan actuaciones posteriores y trazabilidad entre la orden original y el correctivo.
Trabajo administrativo
Tiempo dedicado a buscar información, copiar datos, perseguir cierres o reconciliar sistemas.
La guía de KPIs para automatización de procesos desarrolla cómo construir una línea base y evitar confundir actividad técnica con resultado de negocio.
Cómo empezaría un piloto sin intentar conectar toda la planta
Un proyecto de este tipo puede empezar con un alcance muy contenido. No hace falta integrar PLC, sensores, almacenes, proveedores y todo el parque de activos desde el primer día.
- Elegir pocos planes preventivos. Mejor un conjunto representativo y bien entendido que cientos de órdenes con reglas desconocidas.
- Identificar el sistema que genera el vencimiento. ERP, GMAO u otra aplicación definida.
- Documentar las condiciones de preparación. Qué debe existir antes de asignar y ejecutar.
- Definir qué significa “ejecutado”. Qué tareas y datos mínimos demuestran que el trabajo previsto se realizó.
- Definir qué significa “cerrado”. Cuándo puede cambiar el estado de la orden y cuándo hace falta revisión.
- Clasificar excepciones frecuentes. Repuestos, indisponibilidad del activo, evidencia, hallazgos, permisos o fallos de integración.
- Decidir qué puede hacer la IA. Empezar por interpretar texto, resumir y estructurar información antes de ampliar autonomía.
- Registrar relaciones. Vincular preventivo, orden, evidencia, hallazgo y correctivo cuando proceda.
- Medir unas semanas. Observar retrasos, reaperturas, bloqueos y trabajo administrativo antes de ampliar alcance.
Las integraciones OT complejas, el mantenimiento predictivo y cualquier actuación directa sobre maquinaria pueden evaluarse después si existe una necesidad real y un marco técnico adecuado. No deberían añadirse simplemente porque el proyecto incluya IA.
La primera versión útil puede ser mucho menos espectacular: órdenes bien creadas, dependencias visibles, evidencia suficiente, excepciones claras y cierres que reflejan la realidad.
Preguntas frecuentes sobre automatización del mantenimiento preventivo
¿Qué diferencia hay entre un ERP y una GMAO?
Un ERP integra distintas áreas de gestión empresarial, mientras que una GMAO está especializada en mantenimiento, activos, órdenes, planes e historial. Algunas empresas gestionan el mantenimiento dentro del ERP; otras usan una GMAO independiente; y otras combinan ambos. La arquitectura correcta depende de los sistemas y procesos reales.
¿Automatizar mantenimiento preventivo significa usar mantenimiento predictivo?
No. El preventivo puede automatizarse gestionando fechas, contadores, órdenes, asignaciones, evidencias y excepciones sin utilizar modelos predictivos. El mantenimiento predictivo es otro enfoque y requiere datos, señales y criterios específicos.
¿Puede la IA decidir cuándo hay que hacer un mantenimiento?
Puede ayudar a interpretar información o detectar señales para revisión, pero la frecuencia autorizada debe proceder del plan de mantenimiento, de datos fiables y de la lógica definida por la empresa o el fabricante cuando corresponda. No debería modificarla desde conocimiento general.
¿Qué significa que un preventivo está ejecutado?
En este artículo significa que las tareas previstas para esa intervención se han realizado y su resultado se ha registrado. Puede seguir faltando evidencia, revisión o tratamiento de un hallazgo antes de cerrar la orden.
¿La orden debe cerrarse automáticamente cuando el técnico termina?
No necesariamente. Si todas las condiciones son verificables y no hay excepciones, puede ser razonable automatizar el cierre. Si existe una revisión obligatoria, un hallazgo, evidencia pendiente o una decisión técnica, la orden debe permanecer abierta o pasar al estado correspondiente.
¿Se pueden generar órdenes desde horas de funcionamiento de una máquina?
Sí, cuando el sistema de mantenimiento admite frecuencias por contador y dispone de una lectura autorizada y suficientemente fiable. La integración que obtiene esa lectura debe respetar la arquitectura y la frontera con los sistemas OT.
¿Qué ocurre si el ERP y la GMAO muestran estados diferentes?
Hay que determinar qué sistema confirma el dato concreto y reconciliar la discrepancia. Una automatización no debería elegir arbitrariamente el valor más reciente ni sobrescribir un sistema sin saber cuál tiene autoridad sobre ese estado.
DIAGNÓSTICO DE AUTOMATIZACIÓN
Revisar cómo se gestiona el mantenimiento preventivo
Si los planes existen pero las órdenes, evidencias, repuestos, excepciones y cierres siguen dependiendo de hojas, correos o comprobaciones manuales, podemos revisar qué parte puede automatizarse alrededor del ERP o GMAO y dónde aporta realmente la IA.
Revisar cómo se gestiona el mantenimiento preventivoFuentes
- IBM Maximo — Preventive Maintenance.
Documentación oficial sobre mantenimiento preventivo, generación de órdenes, planes basados en tiempo, uso medido o combinación y diferencias entre programación fija y basada en cierre.
Consultar fuente - IBM Maximo — Preventive maintenance frequency schedules.
Referencia específica para frecuencias por tiempo/contador y para la diferencia entre planificación fija y planificación dependiente del cierre anterior.
Consultar fuente - SAP Help — Maintenance Plan / Scheduling of Maintenance Plans.
Documentación oficial sobre planes de mantenimiento, ciclos temporales, estrategias, contadores y generación de objetos de mantenimiento.
Consultar fuente - Microsoft Learn — Dynamics 365 Asset Management.
Referencia sobre programas de mantenimiento y creación de órdenes a partir del calendario de mantenimiento.
Consultar fuente - NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security.
Referencia para delimitar sistemas de información y gestión frente a tecnologías que monitorizan o actúan sobre procesos físicos y requieren consideraciones específicas de OT.
Consultar fuente
Las capacidades concretas de ERP, GMAO e integraciones dependen del producto, versión, configuración, permisos y arquitectura de cada empresa. Antes de implementar debe verificarse la documentación vigente del sistema real.
