La IA en el mantenimiento industrial solo puede evaluarse después de definir el problema operativo. Programar órdenes según la capacidad disponible, consultar conocimiento técnico y pronosticar la condición futura de un activo son trabajos diferentes, con datos, riesgos y criterios de validación propios. Agrupar los tres bajo la misma etiqueta de IA oculta precisamente lo que un comprador necesita comparar.
Esta guía organiza la decisión por caso de uso, muestra qué debe demostrarse antes de una compra y separa el alcance documentado de PM Run de las aplicaciones especializadas que requieren un proyecto de ingeniería independiente.
Comience por el trabajo que la IA debe mejorar
Una evaluación técnica comienza con una tarea observable y un resultado medible. “Usar IA en mantenimiento” no define ninguno de los dos. “Reducir el tiempo de programación semanal sin asignar una operación a alguien que no posee la habilidad requerida” ya identifica el trabajo, la restricción y parte de la prueba.
El AI Risk Management Framework del NIST recomienda evaluar los sistemas de IA en su contexto específico de uso, con validación, monitoreo, transparencia e intervención humana proporcionales al riesgo. En mantenimiento, ese contexto incluye la criticidad del activo, la consecuencia de una decisión incorrecta, la calidad de los datos disponibles y quién responde por la decisión final.
Tres problemas aparecen con frecuencia en las conversaciones de mantenimiento. No deben comprarse ni validarse de la misma manera.
1. Programación y asignación de órdenes
Este es un problema combinatorio. Las órdenes tienen duración, prioridad, ventanas y habilidades requeridas, mientras que el equipo tiene turnos, ausencias, capacidad y calificaciones diferentes. Una herramienta puede sugerir una distribución que respete esas restricciones y dejar la decisión final en manos del planificador.
Este es el uso documentado de IA en PM Run. En el módulo de Planificación, la función de asignación de Manu sugiere la distribución de órdenes según habilidades, capacidad y disponibilidad. El planificador define el período, revisa el resultado, realiza los ajustes necesarios y solo integra la programación con SAP después de confirmarla. El alcance es una recomendación de asignación, sin predicción de fallas ni decisiones autónomas sobre el activo.
Una demostración seria necesita un conjunto de órdenes y recursos que contenga conflictos reales. La prueba debe responder:
- ¿La recomendación respetó habilidades, turnos, ausencias y capacidad disponible?
- ¿El planificador puede entender por qué una persona recibió determinada operación?
- ¿Una restricción incumplida queda visible antes de la integración?
- ¿El usuario puede cambiar la recomendación y mantener la responsabilidad por la programación?
- ¿El resultado confirmado llega a SAP mediante el flujo documentado?
El alcance funcional de esta aplicación se detalla en la página de PM Run Planificación.
2. Asistentes para consultar conocimiento técnico
Un asistente puede reducir el tiempo dedicado a buscar procedimientos, manuales y bases internas. Su valor depende menos de la fluidez de la respuesta y más de la evidencia que puede mostrar. En mantenimiento, una respuesta plausible sin referencia puede llevar a una intervención inadecuada o a interpretar mal un requisito normativo.
La prueba debe utilizar preguntas con respuestas conocidas y documentadas. Para cada respuesta, verifique si el asistente:
- identifica el documento y el fragmento que sustentan la orientación;
- distingue un procedimiento interno, un manual del fabricante y un requisito normativo;
- declara cuándo la base no contiene información suficiente;
- respeta la versión, la unidad, la planta y el perfil de acceso;
- no convierte información general en una autorización para ejecutar una tarea crítica.
El asistente apoya la consulta. La aprobación de procedimientos, la interpretación normativa y las decisiones sobre el activo siguen a cargo de los responsables técnicos definidos por la empresa.
3. Detección de anomalías y pronóstico de condición
Este caso de uso requiere un proyecto específico. Antes de hablar de un modelo, ingeniería debe definir la función del activo, el modo de falla, la variable capaz de indicar degradación, la técnica de medición, el historial disponible y el tiempo necesario para reaccionar. Vibración, aceite, ultrasonido, temperatura y variables de proceso observan fenómenos diferentes. Un conjunto de órdenes cerradas en SAP no sustituye esas señales cuando el objetivo es detectar la condición física de un componente. La guía de mantenimiento predictivo profundiza en esta disciplina.
La guía de mantenimiento centrado en confiabilidad de la NASA aborda las pruebas e inspecciones predictivas como una selección de tareas aplicables a los modos de falla y sus consecuencias. La técnica y el intervalo dependen del equipo, la aplicación, el ambiente y la capacidad de detectar la degradación con anticipación útil.
Por eso, “mantenimiento predictivo listo para instalar” es una descripción incompleta. El proveedor debe declarar:
- qué modo de falla pretende detectar el modelo;
- qué señales utiliza y con qué frecuencia de muestreo;
- cómo se estableció la condición de referencia;
- qué tasas de falsas alarmas y fallas no detectadas aparecieron en la prueba;
- cuánto tiempo útil existe entre la alerta y la intervención;
- quién valida la alerta y qué acción operativa activa.
PM Run no ofrece IA predictiva, sensores ni un gemelo digital como módulo documentado. Cuando una planta tiene un proyecto especializado de monitoreo de condición, la orden, la programación y el registro de la intervención todavía deben ingresar al flujo de mantenimiento y a SAP PM.
El análisis histórico no se convierte en IA por usar un algoritmo
Las órdenes, los avisos, las causas, los síntomas, los tiempos y los costos permiten análisis importantes: recurrencia por clase de equipo, desviación del tiempo de reparación, concentración de retrabajo y trabajo pendiente por criticidad. Muchas de estas preguntas se responden con estadística, reglas y analítica bien diseñadas. Llamar IA a todo análisis dificulta entender qué decisión mejoró y cómo se validó el resultado.
PM Run entrega datos de mantenimiento preparados y automatizados para que cada empresa construya su propio tablero de indicadores. Esto permite analizar MTTR, MTBF, trabajo pendiente, costos, ocupación de recursos y productividad según las necesidades de la operación. Este tablero configurable no debe confundirse con un modelo que predice fallas.
La guía de gestión del mantenimiento en portugués explica cómo organizar esta base antes de elegir una capa de analítica.
Los datos necesarios cambian según el caso de uso
No existe un único tipo de “dato para IA”. La asignación necesita órdenes, duración, habilidades, capacidad, turnos y disponibilidad. Un asistente necesita documentos controlados, vigentes y autorizados. Un modelo de condición necesita señales físicas relevantes para el modo de falla, además del contexto operativo.
El registro de campo sigue siendo central porque cierra el ciclo de ejecución. Registra cuándo se realizó el trabajo, quién lo ejecutó, qué se encontró y qué acción se tomó. Mejora los indicadores y permite comparar una recomendación con el resultado. Esto no significa que todos los modelos deban entrenarse con el historial de órdenes de la planta.
Si una orden se confirma de memoria al final del turno, la causa y la duración dejan de representar el trabajo real. Antes de buscar una aplicación de IA, corrija este flujo dentro del proceso de planificación y control del mantenimiento.
Guía de validación antes de la compra
- Defina la decisión. Escriba qué tarea recibirá apoyo, quién decide y qué error sería inaceptable.
- Nombre las entradas. Enumere campos, señales, documentos, frecuencia, origen y responsable de la calidad.
- Establezca una referencia. Compare el resultado con el proceso actual y con casos cuya respuesta sea conocida.
- Pruebe excepciones. Incluya ausencias, datos faltantes, órdenes urgentes, un activo fuera del patrón y un conflicto de restricciones.
- Mida el error relevante. El tiempo ahorrado no compensa una asignación inválida, una alerta perdida o una orientación sin respaldo.
- Defina supervisión y retroalimentación. Determine quién confirma, cómo se corrige y cómo se monitoreará el desempeño después de la implementación.
El documento completo NIST AI RMF 1.0 refuerza que la validez y la confiabilidad deben verificarse en el contexto de uso y monitorearse durante todo el ciclo de vida. Una demostración genérica solo confirma que la interfaz funciona en el escenario preparado por el proveedor.
Preguntas frecuentes
¿PM Run ofrece IA predictiva?
No como módulo documentado. La aplicación de IA documentada en PM Run es Manu, que sugiere la asignación de órdenes en Planificación según habilidades, capacidad y disponibilidad. Los sensores, la predicción automática de fallas y los gemelos digitales requieren soluciones y proyectos específicos.
¿Manu programa el trabajo de forma autónoma?
No. El planificador selecciona las órdenes y el período, recibe la recomendación, revisa el resultado y puede ajustarlo. Las actividades solo siguen a SAP cuando el usuario inicia la integración.
¿El historial de órdenes basta para predecir fallas?
No en todos los casos. El historial ayuda a analizar recurrencias, tiempos, causas registradas y resultados de las intervenciones. Pronosticar la condición física de un componente puede exigir vibración, aceite, ultrasonido, temperatura u otra variable vinculada con el modo de falla.
¿Cómo se comparan dos proveedores de IA para mantenimiento?
Compare el mismo caso de uso con las mismas entradas, restricciones y criterios de error. Exija alcance documentado, procedencia de los datos, tratamiento de excepciones, supervisión humana y medición del resultado en el contexto de su planta.
¿Por dónde debe comenzar una empresa?
Elija una decisión delimitada, confirme que los datos necesarios existen y prepare una prueba con resultado conocido. Para programar órdenes, el recorte puede ser una semana real con conflictos de habilidades y capacidad. Para la condición de un activo, el recorte comienza con un modo de falla y una técnica de detección definidos por ingeniería.
Grupo de Estudios Avanzados de PM Run
El Grupo de Estudios Avanzados de PM Run, GEA, realiza encuentros exclusivos para invitados, centrados en clientes y socios. Los clientes y socios pueden solicitar la invitación a su ejecutivo de cuenta. Las empresas que todavía no son clientes pueden contactar al equipo comercial para conocer la iniciativa.
