Las primeras cuatro semanas con un GMAO

La mayoría de las implantaciones que se tuercen lo hacen en el primer mes, y casi siempre por abarcar demasiado: se decide cargar el inventario completo, se tarda medio año y el equipo se cansa antes de ver ningún resultado.

Esto es un plan alternativo de cuatro semanas. No deja el sistema terminado —eso lleva meses— pero deja algo funcionando de verdad, que es lo que hace que el proyecto sobreviva.

Antes de empezar: dos decisiones

Hasta dónde quieres llegar. ¿Solo registrar el trabajo técnico y sacar informes, o que el sistema atraviese hasta compras y administración? Lo primero se implanta en semanas; lo segundo exige acuerdos previos que tardan más que la configuración.

Quién es el dueño del proyecto. Alguien de casa que conozca la operación y pueda decidir sin convocar una reunión por cada duda. No hace falta que sea informático.

Semana 1: los activos críticos

No el inventario completo. Los equipos que paran la producción o el servicio si fallan, y los que tienen obligación normativa. Suelen ser menos de cincuenta.

De cada uno, lo mínimo: dónde está, modelo, número de serie, fecha de instalación y fin de garantía. Ese último dato es el que antes se rentabiliza, porque evita pagar reparaciones de equipos que seguían cubiertos.

Y lo más importante de esta semana, aunque parezca secundario: agruparlos por sistema, familia y modelo. De esa clasificación depende que todo lo demás se pueda configurar una vez para muchos equipos, en lugar de uno a uno. Está desarrollado en gestión de activos.

Semana 2: las gamas y las periodicidades

Para cada familia —no para cada equipo— qué hay que comprobar y cada cuánto.

Los checklists se resuelven en cascada —activo, modelo, subfamilia, familia—, así que se define una vez por tipo de equipo. Pocos campos y bien elegidos: es mejor un modelo de ocho puntos que se cumplimenta bien que uno de cuarenta que se rellena a medias.

Y los que registran una medida, con su valor mínimo y máximo, porque es lo que convierte la comprobación en un dato aprovechable.

De dónde sale el contenido: del manual del fabricante, de la norma cuando la hay y —sobre todo— de la gente que lleva años atendiendo esos equipos. Esa tercera fuente es la más valiosa y la única que desaparece.

Con esto configurado, el preventivo ya genera órdenes de trabajo solo, comprobando antes si el día es festivo y si el técnico está disponible.

Semana 3: el equipo en campo

La semana que decide el proyecto.

Un grupo pequeño de técnicos, con las órdenes que ya se están generando, usando la app de verdad: cronómetro dentro de la orden, checklist cumplimentado, fotos y firma. Y funcionando sin cobertura, que es como va a ser la mayoría de las veces.

De esa prueba salen siempre dos cosas: ajustes de configuración que nadie había previsto —un campo que estorba, un aviso que molesta— y los argumentos para convencer al resto. Un técnico contándole a otro que ya no llama a la oficina convence más que cualquier formación.

El criterio para saber si va bien no es que no haya quejas: es que las quejas sean concretas. Eso significa que lo están usando.

Semana 4: la entrada del trabajo no planificado

El preventivo es la mitad. La otra es lo que aparece sin avisar.

Hay que decidir por dónde entran las incidencias —backend, acceso del cliente con foto, o un buzón de correo que el sistema convierte en avisos— y unificarlo. Mientras haya tres vías paralelas, no hay lista de pendientes fiable.

Y definir los estados: cinco, con su significado acordado, su tiempo máximo y su correo asociado cuando toque. Es una conversación de una hora que evita meses de ambigüedad sobre qué significa «en curso».

Qué debería funcionar al final del mes

Si el plan ha ido bien, esto:

• Órdenes preventivas generándose solas con responsable y fecha.
• Técnicos cerrándolas en campo, con tiempos medidos.
• Checklists de los equipos críticos escritos, con sus valores.
• Incidencias entrando por un sitio, con prioridad y plazo.
• Y el primer informe con datos reales.

Ese último punto es el que justifica el proyecto ante quien lo paga: enseñar una cifra que la empresa no tenía.

Lo que viene después, y no hay prisa

Almacén y compras, cuando las órdenes ya se cierren con soltura. El almacén empieza a tener sentido cuando el consumo se registra al cerrar la orden.

Documentación, empezando por lo que caduca: certificados, contratos y seguros con su fecha en el gestor documental, que avisa antes de vencer.

Portal de clientes, cuando haya contenido que enseñar. Un portal vacío genera más llamadas de las que evita.

Integración con el ERP, cuando el resto lleve meses funcionando solo.

Qué hacer con el histórico antiguo

La pregunta que frena a mucha gente al arrancar, y la respuesta corta es: casi nada.

Migrar años de partes en papel es caro y rinde poco, porque lo que se consulta de verdad es lo reciente. Lo que sí merece la pena traer es el inventario de activos con sus fechas de instalación, sus garantías vigentes y la documentación que sigue en vigor, porque es lo que da contexto desde el primer día.

El histórico se construye hacia delante. En doce meses hay suficiente para empezar a decidir con datos —qué equipos concentran las averías, qué periodicidades sobran— y en tres años, para no querer volver atrás.

Merece la pena decirlo al equipo al arrancar, porque la sensación de «estamos metiendo datos para nada» es real durante las primeras semanas y desaparece en cuanto sale el primer informe que contesta algo.

Los cuatro errores que hay que evitar

Empezar por el inventario completo. Es el más común y el que más proyectos deja a medias.

Configurarlo sin quien lo va a usar. Lo diseñado en una sala de reuniones choca con la realidad el primer día.

Activar todos los módulos el primer día. Nada de lo que no se use aporta, y todo lo que se ve sin usar resta claridad.

Esperar que el sistema arregle el proceso. Si nadie decide quién atiende qué y con qué prioridad, registrará el mismo desorden con más precisión.

Si quieres que veamos cómo sería el arranque en vuestro caso, puedes solicitar una demo o escribirnos.