Por qué su CMMS nunca llegó a la planta

Casi todas las plantas industriales de este país ya compraron un sistema de mantenimiento. Muchas compraron dos. Y sin embargo, si usted entra hoy a la oficina de mantenimiento de un ingenio, una cementera o una planta de alimentos, va a encontrar lo mismo: un tablero de Excel abierto en una pantalla, un cuaderno en el escritorio del jefe de área, y un grupo de WhatsApp donde de verdad se coordina el trabajo del día.

El sistema existe. Está pago. Está implementado. Y no se usa donde se hace el mantenimiento.

Lo interesante es que casi nunca es culpa del software que se compró. El SAP PM o el Maximo de esa planta suele estar bien configurado, con su jerarquía de ubicaciones técnicas, sus centros de costo y sus avisos. El problema es que ese software fue diseñado para responder preguntas de gerencia, y el mantenimiento no ocurre en la gerencia. Ocurre a treinta metros del último computador, con las manos sucias, con ruido, y muchas veces sin señal.

1. La distancia entre el sistema y el trabajo

Piense en el recorrido real de una orden de trabajo en una planta promedio:

1. El planeador la crea en el ERP, en la oficina.
2. La imprime, o la dicta por radio, o la pasa por WhatsApp.
3. El técnico va, la ejecuta, y anota lo que hizo en un papel o en la cabeza.
4. Al final del turno —o al día siguiente, o el viernes— alguien transcribe eso al sistema.
5. El sistema reporta lo que le transcribieron.

Hay dos traducciones manuales en ese recorrido, y cada una es una oportunidad de que se pierda información. Lo que llega al indicador de cumplimiento no es lo que pasó en la planta: es lo que alguien recordó y tuvo tiempo de escribir tres días después.

El indicador no mide el mantenimiento. Mide la disciplina de transcripción del planeador.

Cuando la gerencia mira ese número y decide sobre él, está decidiendo sobre una copia degradada de la realidad. Y el técnico lo sabe, que es peor: sabe que lo que él hace y lo que el sistema dice son dos cosas distintas, y deja de tomarse en serio el sistema.

2. El formulario fue diseñado por alguien que no lo iba a llenar

La segunda razón es más simple y más brutal. El formulario de cierre de una orden de trabajo suele tener entre veinte y cincuenta campos, porque cada área —costos, seguridad, confiabilidad, almacén— pidió el suyo. Cada campo, por separado, es razonable. Juntos son quince minutos de un técnico que ya terminó su trabajo y quiere irse a almorzar.

Lo que pasa entonces es predecible: el técnico llena lo mínimo que el sistema le deja pasar. Escribe "OK" en el campo de observaciones. Pone la misma causa de falla siempre, porque es la primera de la lista. Y los cuarenta campos que alguien peleó para que existieran terminan llenos de datos que nadie puede usar.

Un campo que se llena mal es peor que un campo que no existe, porque el que no existe se nota y el que está mal lleno se cree.

3. La conectividad no es un detalle de infraestructura

Una planta no es una oficina. Hay sótanos, tanques, torres, zonas con blindaje metálico y kilómetros de campo abierto. En un ingenio azucarero, buena parte del mantenimiento pasa en lugares donde no hay wifi y el dato celular es una promesa.

Un sistema que exige conexión para registrar una tarea no es un sistema que funciona mal en esos sitios: es un sistema que no existe en esos sitios. Y como el trabajo hay que hacerlo igual, el técnico vuelve al papel. Una vez que vuelve al papel para el 20% de los casos, el papel se vuelve el sistema para el 100%, porque nadie mantiene dos flujos en paralelo.

Esto no se arregla con más antenas. Se arregla asumiendo desde el diseño que el dispositivo va a estar sin señal y que tiene que funcionar igual, guardando local y sincronizando cuando vuelva la conexión.

4. Nadie devuelve nada a quien capturó el dato

Esta es la más ignorada de las cuatro y probablemente la más determinante.

El técnico que registra bien una falla —con su causa, su repuesto, su tiempo real— está haciendo un trabajo de captura de datos que no le sirve a él para nada. El dato sube. Se convierte en un indicador. El indicador se ve en un comité al que él no va. Y a la semana siguiente le vuelven a pedir lo mismo.

Los sistemas que sí se usan en campo tienen todos la misma característica: le devuelven algo a quien captura. El historial del equipo, visible ahí mismo, para que el técnico sepa qué le hicieron la última vez antes de abrirlo. Las horas que lleva trabajadas este mes, porque de eso depende su liquidación. La foto que tomó, que es su respaldo cuando alguien pregunte por qué se cambió esa pieza.

Cuando capturar el dato le sirve al que lo captura, el dato llega bien sin que nadie tenga que perseguirlo.

Entonces, ¿hay que cambiar el ERP?

No, y este es el error que se comete después de darse cuenta de todo lo anterior. La reacción natural es concluir que el sistema corporativo falló y hay que reemplazarlo. Pero SAP PM y Maximo no fallaron en lo suyo: la planeación, los costos, el almacén y la integración con compras y con finanzas funcionan, y migrar eso cuesta años y un dineral.

Lo que falta no es otro sistema de registro. Es una capa de ejecución: algo que viva en el teléfono del técnico, que funcione sin señal, que pida lo mínimo imprescindible con la cámara y dos toques, y que después sincronice hacia el sistema corporativo lo que este necesita saber.

El ERP sigue siendo la fuente de verdad para planear y costear. La capa de ejecución es la que hace que lo que ocurre en la planta llegue ahí sin pasar por la memoria de nadie ni por una transcripción del viernes.

Cómo saber si le está pasando

Tres preguntas, y las tres se responden en una tarde:

¿Cuánto tiempo pasa entre que se ejecuta una tarea y que queda registrada en el sistema? Si la respuesta se mide en días, el sistema no está midiendo la operación: está midiendo un recuerdo.

¿Qué porcentaje de los campos del formulario de cierre tiene variación real? Exporte los últimos seis meses. Si un campo tiene el mismo valor en el 90% de los registros, ese campo no está capturando información, está capturando resignación.

¿Cuántos de sus técnicos abren el sistema por voluntad propia? No para cerrar una orden porque se lo exigen: para consultar algo que necesitan. Si la respuesta es ninguno, el sistema es un requisito administrativo, no una herramienta.

Ninguna de las tres se arregla comprando más software. Se arreglan poniendo el registro donde ocurre el trabajo, y devolviéndole algo a quien lo hace.