Del aviso al cierre: el circuito completo

Casi todas las descripciones de un GMAO son listas de módulos. Sirven de poco, porque no explican lo único que decide si el sistema va a funcionar: qué pasa exactamente entre que alguien detecta que algo va mal y que ese trabajo queda cerrado, cobrado y demostrable.

Este es ese recorrido, paso a paso.

Paso 1: entra por un sitio

El primer punto donde se pierde información. Un aviso por mensajería a un técnico, otro por teléfono al jefe de equipo y otro por correo a administración son tres trabajos que nadie puede contar juntos.

En GMAO CLOUD una incidencia puede nacer desde el backend, desde el acceso del cliente con su descripción, el equipo afectado y una foto, o desde un buzón de correo que el sistema vacía y convierte en avisos automáticamente.

Lo que no se puede es prohibir el teléfono. Lo que sí se puede es que quien lo coja registre en el mismo sitio.

Paso 2: se prioriza

La incidencia lleva su tipo y subtipo, su prioridad, el cliente, la dirección y el activo afectado. Y los estados pueden llevar su tiempo máximo, con una entidad de SLA que define prioridad y límite.

Así lo vencido aparece en una lista en vez de descubrirse cuando alguien reclama. Y se distingue lo urgente de lo ruidoso, que no es lo mismo aunque todo llegue marcado igual.

Paso 3: o nace solo

La otra mitad del trabajo no la pide nadie: la genera el plan.

La gama de comprobaciones se asocia al activo, a su modelo o a una familia entera, se define la periodicidad, y el preventivo genera las órdenes por su cuenta, comprobando antes si el día es festivo y si el técnico está disponible.

Y si el desgaste depende del uso, el activo puede llevar un contador con un límite y un porcentaje de aviso: al registrarse una lectura que supera el umbral, la orden se genera automáticamente.

Paso 4: se reparte

El calendario muestra qué hay cada día y de quién es, y la planificación en diagrama enseña la carga de cada técnico a lo largo de las semanas. Lo más útil de esa pantalla es lo que no tiene dueño, porque es lo que se va a caer.

Cuando hay que mover algo —todos los días— se arrastra a otro día. Y el técnico puede tomar trabajo sin asignar él mismo, porque sabe si le pilla de camino.

Paso 5: se ejecuta donde ocurre

En la app el técnico abre la orden y tiene delante el histórico del equipo, su documentación y las anomalías abiertas. Arranca el cronómetro, consume material del almacén, cumplimenta el checklist —en las preventivas no puede cerrar sin hacerlo—, hace fotos y recoge la firma del cliente en pantalla.

Todo funciona sin cobertura: órdenes, activos y documentos se guardan en el dispositivo y las acciones entran en una cola que se vacía al recuperar señal. Si una falla, queda marcada con su motivo en vez de desaparecer.

Es el paso que decide el proyecto. Si aquí hay fricción, el registro se aplaza al final del día y deja de ser fiel.

Paso 6: se cierra, o se deja abierto con motivo

La orden puede marcarse como pendiente de material y como necesita volver. Son dos estados distintos y los dos necesarios: sin ellos, esos trabajos viven en una libreta.

Y el cambio de estado puede llevar su correo asociado, de modo que el interesado se entere sin que nadie escriba el aviso.

Paso 7: si hay que presupuestar

Cuando el trabajo no entra en contrato, el gestor de presupuestos cierra el circuito: el presupuesto nace de una orden y genera otra al aceptarse, con su cliente, su forma de pago y su plantilla de PDF y de correo. No hay que teclear nada dos veces.

Paso 8: el material se repone

Lo consumido baja del stock al cerrar. Cuando una referencia llega a su stock mínimo, se repone por el circuito de compras, con su proveedor, su almacén de destino y sus líneas.

Paso 9: el dato sale hacia el ERP

Un trabajo cerrado no debería teclearse dos veces para facturarlo. Las órdenes cerradas con sus horas y consumos son exactamente lo que el ERP necesita.

En integraciones está el alcance de cada conector, que no es el mismo en todos: conviene mirarlo antes de dar por hecho que el dato pasa solo.

Paso 10: queda el histórico

Y esta es la parte que no se puede recuperar después. Al cerrar, en la orden han quedado los tiempos reales, el material, las fotos, el checklist cumplimentado y la firma.

Sobre eso se apoyan los informes —coste por equipo, horas por técnico y cliente, tiempos de parada, MTBF y MTTR, plan ejecutado— y la capacidad de demostrar lo que se hizo ante una reclamación o una inspección.

Quién ve qué durante todo el recorrido

Un aspecto transversal que conviene decidir al principio, porque afecta a todos los pasos: no todo el mundo ve lo mismo.

El técnico ve sus órdenes, el histórico del equipo y la documentación que le corresponde. El jefe de equipo ve lo de su equipo, no las trescientas órdenes abiertas de la empresa. El cliente ve lo suyo: sus centros, sus activos, sus órdenes y los documentos marcados como visibles para él. Y el proveedor ve las órdenes que se le han asignado.

Cada documento lleva su visibilidad configurada una vez, lo que evita tener que decidir a mano qué se enseña cada vez que alguien pide algo.

Y un detalle que lo condiciona: si dar de alta a alguien cuesta dinero, se comparten cuentas, y en ese momento todo el circuito deja de ser trazable. En GMAO CLOUD las licencias son ilimitadas en los tres planes.

Dónde se rompe el circuito

Casi siempre en dos sitios.

En el paso 1, si los avisos siguen entrando por canales paralelos. Entonces la lista de pendientes nunca es completa.

En el paso 5, si el registro no ocurre en campo. Entonces los datos existen pero no son fieles, y todo lo que viene después describe una realidad que no pasó.

Si quieres ver el circuito entero sobre un caso tuyo, puedes solicitar una demo.