Cómo llevar la gestión de mantenimiento a una aplicación de campo

La orden de trabajo es la unidad básica. En la oficina interesa su planificación y su coste; en campo interesa saber qué hay que hacer, dónde y con qué. La aplicación debe mostrar primero lo necesario para actuar: activo y ubicación, descripción del trabajo, riesgos y permisos requeridos, lista de tareas y repuestos previstos.

• Tipos de orden con comportamiento distinto: preventivas con lista de comprobación fija, correctivas con diagnóstico libre, inspecciones con lecturas obligatorias.
• Estados simples y comprensibles: asignada, en camino, en curso, en pausa (con motivo), terminada, pendiente de material.
• Listas de comprobación con respuestas tipadas: sí/no, valor numérico con rango esperado, selección de una lista, texto breve. Un valor fuera de rango puede generar automáticamente un aviso o una orden correctiva.
• Creación de órdenes desde campo: si el técnico detecta una avería al pasar, debe poder abrir una solicitud con foto en segundos, sin esperar a que la oficina la cree.
• Tiempos registrados por la propia acción (inicio, pausa, fin) en lugar de pedir al técnico que los recuerde al final del día.

Una orden sobre el activo equivocado es peor que ninguna orden. Por eso la identificación en campo debe ser directa: una etiqueta con código QR o NFC en el equipo que, al leerla, abre su ficha y sus órdenes pendientes. Si no hay etiqueta, la búsqueda por ubicación jerárquica (centro, zona, línea, equipo) debe funcionar sin conexión.

La ficha del activo en el móvil debe priorizar lo que ayuda a resolver: últimas intervenciones con sus observaciones, averías recurrentes, documentación técnica (esquemas, manuales, procedimientos de bloqueo) y lecturas recientes. Un ejemplo práctico: un técnico que llega a una bomba que ha fallado tres veces en el último trimestre debería verlo nada más escanear la etiqueta, junto con lo que hicieron sus compañeros cada vez.

La evidencia es lo que permite demostrar que un trabajo se hizo y cómo. Puede ser necesaria por contrato con un cliente, por la normativa aplicable a ciertas instalaciones o simplemente para diagnosticar mejor la próxima vez. La aplicación debe capturarla en el momento y vincularla a la orden y al activo.

Una vez cerrada y sincronizada, la orden debería quedar bloqueada para edición desde campo. Las correcciones posteriores se hacen desde la oficina y quedan registradas, para que la evidencia mantenga su valor.

Sótanos, salas de máquinas, naves con estructura metálica, parques eólicos o depuradoras en zonas rurales: la falta de cobertura no es la excepción, es parte del trabajo. Una aplicación que solo funciona en línea acaba abandonada. El modo sin conexión no es una función añadida; condiciona toda la arquitectura.

1. Precarga: al inicio de la jornada, o cuando hay conexión, el dispositivo descarga las órdenes asignadas, las fichas de los activos implicados, su documentación y el catálogo de repuestos necesario.
2. Trabajo local: todo lo que el técnico registra se guarda primero en el dispositivo, con identificadores generados localmente para que no haya colisiones.
3. Cola de sincronización: los cambios se envían en orden cuando vuelve la conexión, con reintentos y un indicador visible de lo pendiente.
4. Conflictos: si la oficina reasignó o modificó una orden mientras el técnico trabajaba sin conexión, hay que definir qué prevalece. Una regla habitual es que lo registrado en campo (tiempos, evidencias, consumos) nunca se pierde, y los cambios de planificación se resuelven en la oficina.
5. Archivos pesados: las fotos pueden subirse después que los datos, para que la orden quede cerrada aunque la conexión sea débil.

Esta exigencia influye en la elección tecnológica. Una aplicación nativa o multiplataforma ofrece más control sobre almacenamiento local, cámara y lectura NFC. Una aplicación web progresiva puede trabajar sin conexión y es más sencilla de distribuir, pero conviene comprobar con los dispositivos reales que cubre todo lo necesario, especialmente la lectura NFC y el almacenamiento de muchas fotos.

Los repuestos son donde la información se pierde con más facilidad. El técnico coge una pieza del almacén o de su vehículo, la monta y se olvida de anotarla. El resultado es un stock que no cuadra y un coste de mantenimiento que no refleja la realidad.

• Repuestos previstos en la orden, que pueden reservarse en almacén antes de la intervención.
• Stock por vehículo o maletín como ubicación propia, con reposición periódica desde el almacén central.
• Consumo registrado desde la tarea leyendo el código del repuesto o eligiéndolo de la lista prevista.
• Devolución de lo no usado y registro de piezas retiradas cuando deban repararse o gestionarse como residuo.
• Si falta material, la orden pasa a «pendiente de material» con el repuesto concreto, y compras lo ve sin esperar al informe semanal.

1. ¿Dónde se pierde hoy la información: tiempos, repuestos, evidencias o lecturas? Esa respuesta marca qué debe resolver la primera versión.
2. ¿Qué porcentaje aproximado del trabajo se hace sin cobertura fiable? Si es relevante, el modo sin conexión es requisito desde el primer día.
3. ¿La GMAO o el ERP actual tiene una aplicación móvil propia? Pruébala en campo antes de descartarla; lo a medida se justifica cuando no cubre vuestras listas de comprobación, el trabajo sin conexión o la integración con otros sistemas.
4. ¿El inventario de activos es fiable? Si no lo es, presupuesta su depuración como parte del proyecto.
5. ¿Qué evidencias exigen vuestros contratos o instalaciones? Definirlas al principio evita rehacer formularios.
6. ¿Quién mantendrá las listas de comprobación? Deben poder cambiarse sin publicar una nueva versión de la aplicación.

La mejor prueba es una semana de trabajo real con un grupo reducido de técnicos y un prototipo funcional. Lo que ellos rechacen en esa semana, lo rechazará la plantilla entera. Si quieres plantear ese piloto, podemos estudiar contigo vuestro flujo de órdenes y los sistemas con los que debería hablar la aplicación.