Su SAP no se va a reemplazar, y no hace falta

Cuando una planta reconoce que su mantenimiento no está bien registrado, aparecen dos bandos en la misma reunión.

Uno dice que el ERP no sirve para mantenimiento y hay que migrar a un CMMS especializado. El otro dice que ya se invirtieron años y varios cientos de millones en configurar SAP PM y que ni se hable de tocarlo.

Los dos tienen razón en lo que defienden y los dos están discutiendo la pregunta equivocada. La pregunta no es qué sistema debe ser el sistema. Es qué tramo del proceso está sin cubrir.

Lo que un SAP PM o un Maximo hace bien

Conviene ser justo, porque la crítica fácil al ERP suele venir de no haberlo usado en serio. Un módulo de mantenimiento corporativo bien configurado resuelve cosas que un CMMS ligero no resuelve ni de lejos:

• La jerarquía de activos. Ubicaciones técnicas, equipos, subequipos y su relación con el proceso productivo. Cambiar eso de sistema es un proyecto de año y medio, no una migración de datos.
• El costo. Cada hora hombre, cada repuesto y cada servicio contratado aterriza en un centro de costo que finanzas ya cerró y auditó. Es la razón por la que el ERP existe.
• La integración con compras y almacén. Una reserva de material que dispara una solicitud de pedido que se convierte en orden de compra. Reconstruir esa cadena en otro sistema es reconstruir la empresa.
• La trazabilidad contable y regulatoria, que en sectores auditados no es negociable.

Nada de eso está roto. Y todo eso es carísimo de mover.

Dónde deja de llegar

El ERP deja de llegar exactamente donde deja de haber un computador y empieza a haber un equipo.

Un SAP PM está diseñado para que el planeador cree el aviso y la orden, y para que después alguien confirme la operación. Ese "alguien confirme" es el hueco. En el diseño original se asume que el técnico entra a una terminal y confirma. En la planta real:

• El técnico no tiene usuario de SAP, porque cada licencia cuesta y no se le da a cincuenta operarios.
• Si lo tuviera, la pantalla de confirmación no está pensada para un teléfono con guantes puestos.
• Y donde está el equipo no hay ni terminal ni señal.

Entonces la confirmación la hace el planeador, con lo que el técnico le cuente. Y ahí es donde el dato deja de ser una medición y pasa a ser un resumen.

El ERP no falló en su trabajo. Simplemente su trabajo terminaba en la oficina, y el mantenimiento ocurre treinta metros más allá.

Qué es una capa de ejecución

Una capa de ejecución no es un CMMS de reemplazo. Es la pieza que cubre ese tramo final y nada más:

• Vive en el teléfono del técnico, no en una terminal.
• Funciona sin señal, guardando local y sincronizando después. Esto no es un extra: es la diferencia entre existir y no existir en un sótano o en una torre.
• Pide lo mínimo imprescindible: qué se hizo, con qué, cuánto tardó, y una foto. La marca de tiempo y la ubicación las pone el dispositivo, no el operario.
• Le devuelve algo a quien captura: el historial del equipo antes de abrirlo, y sus propias horas del mes.
• Y sincroniza hacia el ERP lo que el ERP necesita saber: la confirmación de la operación, el consumo de material, las horas.

El maestro de datos sigue siendo del ERP. Los activos, los centros de costo y las ubicaciones técnicas se leen de ahí, no se duplican. La capa de ejecución no inventa una segunda verdad: captura la ejecución y la devuelve al sitio donde ya vive la planeación.

Cómo se conecta sin romper nada

Esta es la parte que preocupa —con razón— a quien administra el ERP. Tres principios que hacen la integración defendible:

Uno: la capa de ejecución nunca es la fuente del maestro. Los equipos, las ubicaciones y los centros de costo se sincronizan hacia ella. Si alguien quiere crear un activo nuevo, lo crea donde siempre. Nada de dos maestros divergiendo.

Dos: la sincronización es idempotente y auditable. Cada confirmación que sube lleva un identificador propio, de modo que reintentar no duplica. Y cada intento queda registrado con su resultado, así que cuando alguien pregunte por qué una orden no se confirmó, la respuesta está en un log y no en una suposición.

Tres: si la integración se cae, la operación no se detiene. El técnico sigue registrando en campo; lo pendiente se acumula en una cola y sube cuando el enlace vuelva. Un sistema de campo que exige que el ERP esté disponible es un sistema que hereda todas las paradas del ERP, incluidos sus mantenimientos programados.

El caso en el que sí conviene migrar

No siempre la respuesta es conservar. Hay un caso claro en el que migrar el ERP sí tiene sentido: cuando el módulo de mantenimiento nunca se implementó de verdad. Sucede más de lo que parece — se compró la licencia completa, se configuró finanzas y compras, y mantenimiento quedó en una lista de equipos sin jerarquía, sin planes y sin historia.

En ese escenario no hay nada que conservar, porque no hay nada configurado, y la discusión es legítimamente otra.

Pero si su planta ya tiene la jerarquía armada, los centros de costo funcionando, y el problema es que la información de campo llega tarde y resumida, entonces migrar el ERP es resolver un problema que no tiene, con un proyecto de dos años, para terminar con el mismo hueco al final del proceso.

La pregunta que sí conviene hacerse

En vez de "¿qué sistema debería ser nuestro sistema de mantenimiento?", pruebe con esta:

¿Dónde exactamente se rompe la cadena entre lo que pasa en el equipo y lo que sabe el sistema?

Si se rompe en la planeación, tiene un problema de configuración del ERP.

Si se rompe en la ejecución —el técnico hace el trabajo y el registro llega tarde, incompleto o transcrito por otra persona— entonces no le falta un ERP distinto. Le falta el tramo que ningún ERP fue diseñado para cubrir.