Aplicaciones operacionales: field service y terminales móviles

Las aplicaciones de field service industrial llevan al móvil del técnico lo que hoy viaja en papel: partes de trabajo, checklists de inspección, fotos del estado del equipo y la firma del cliente. El artículo repasa qué debe resolver una aplicación operacional de campo, por qué el funcionamiento offline es el requisito que decide el proyecto, y cómo integrarla con el ERP y el GMAO para que el dato llegue una sola vez y llegue bien.

Qué es una aplicación de field service industrial

Una aplicación de field service es el software que usan los técnicos y operarios que trabajan fuera de una oficina: en la planta, en la subestación, en la instalación del cliente o subidos a una cubierta. Su función es sencilla de enunciar: que el trabajo de campo quede registrado en el momento y en el lugar donde ocurre, con la mínima fricción posible para quien lo ejecuta.

Ese enunciado esconde una diferencia importante con el software de oficina. Una aplicación de gestión convencional asume usuario sentado, pantalla grande, red estable y tiempo para navegar por menús. El técnico de campo no tiene ninguna de las cuatro cosas: trabaja de pie, muchas veces con guantes, en una nave donde la cobertura va y viene, y cada minuto que pasa mirando el móvil es un minuto que no dedica a la avería. El diseño de una buena aplicación operacional parte de esa realidad, no de un formulario web adaptado a pantalla pequeña.

El alcance funcional habitual cubre cuatro bloques: partes de trabajo (qué hay que hacer, qué se hizo, cuánto tiempo llevó y qué materiales se consumieron), checklists e inspecciones (verificaciones pautadas con evidencia), captura de evidencias (fotos, firmas, lecturas) e integración con los sistemas de gestión, normalmente el ERP y el GMAO. Los cuatro bloques se apoyan en un requisito transversal que trataremos en su propia sección: todo tiene que funcionar sin conexión.

Los síntomas del papel: dónde duele hoy

La mayoría de las empresas industriales que se plantean una aplicación de campo no parten de cero: parten de papel, de fotos sueltas en el WhatsApp del encargado y de una persona en la oficina que transcribe partes a final de semana. Los síntomas son reconocibles:

El dato llega tarde. El parte se rellena el viernes de memoria, se entrega el lunes y se factura semanas después. Entre la intervención y su registro pueden pasar días, y la calidad del recuerdo se degrada cada hora.
El dato llega mal. Letra ilegible, horas redondeadas, materiales que no se apuntan y luego no cuadran con el almacén. Cada transcripción manual es una oportunidad de error que nadie detecta hasta que un cliente reclama.
El dato no sirve para decidir. Con partes en papel no hay historial por equipo, ni tiempos medios por tipo de intervención, ni forma razonable de saber qué máquina consume más horas de mantenimiento. La información existe, pero no es explotable.
La evidencia no existe. Ante una discrepancia con un cliente o una inspección, demostrar qué se hizo, cuándo y en qué estado quedó el equipo depende de la memoria del técnico.

Ninguno de estos problemas se resuelve comprando tablets. Se resuelven rediseñando el flujo del dato: quién lo captura, en qué momento, con qué estructura y hacia qué sistema viaja. La aplicación es el vehículo de ese rediseño.

Partes de trabajo en el móvil

El parte de trabajo digital es la pieza central. Un buen parte móvil tiene tres momentos: antes, durante y después de la intervención.

Antes: el técnico recibe la orden en su dispositivo con el contexto que necesita: ubicación, equipo afectado, historial de intervenciones anteriores sobre ese mismo equipo, materiales previstos y documentación técnica adjunta. Esto elimina las llamadas de "¿dónde era?" y los viajes en balde por no llevar el repuesto adecuado.

Durante: registro de inicio y fin (con marca de tiempo automática, no tecleada), materiales consumidos seleccionados de un catálogo en lugar de escritos a mano, y observaciones dictadas o escritas en el momento. La regla de diseño que más rendimiento da es reducir la escritura libre: cada campo que se pueda resolver con un desplegable, una lectura de código de barras o una foto es un campo que se rellenará bien.

Después: cierre del parte con firma del cliente si aplica, estado final del equipo y clasificación de la intervención (correctiva, preventiva, garantía). Ese cierre estructurado es lo que convierte una pila de partes en un historial consultable: tiempo medio de resolución por tipo de avería, equipos reincidentes, carga real de cada técnico.

Checklists e inspecciones digitales

La segunda familia de casos de uso son las verificaciones pautadas: rondas de inspección, checklists de arranque de línea, revisiones periódicas de seguridad, controles de calidad en recepción. En papel, un checklist tiene un defecto estructural: se puede rellenar entero en la sala de descanso sin haber pisado la zona. Digitalizado bien, deja de ser un trámite y pasa a ser una fuente de datos.

Los elementos que marcan la diferencia frente al papel son cuatro:

Capacidad	Qué aporta frente al papel
Lógica condicional	Si una respuesta es "no conforme", el formulario despliega campos adicionales: foto obligatoria, gravedad, acción inmediata. El papel no puede ramificar.
Validación en captura	Una lectura fuera de rango se marca al instante, no semanas después en una revisión de archivo. Los campos obligatorios no se pueden saltar.
Evidencia asociada	Cada punto del checklist puede exigir foto o lectura, y queda registrado quién lo completó y cuándo, punto por punto.
Acciones derivadas	Un ítem no conforme puede generar automáticamente una orden de trabajo correctiva, sin depender de que alguien lea el checklist y la abra a mano.

Un detalle de implantación que se suele pasar por alto: los checklists cambian. Las pautas de inspección se revisan, se añaden puntos, se retiran otros. La aplicación debe permitir que calidad o mantenimiento editen las plantillas sin pasar por un desarrollador, y debe versionarlas: saber con qué versión de la pauta se hizo cada inspección es relevante si hay que reconstruir un histórico.

Funcionamiento offline: la cobertura no se negocia

Este es el requisito que separa una aplicación de campo seria de un formulario web con buena pinta. Las naves industriales son entornos hostiles para la conectividad: estructuras metálicas que apantallan la señal, sótanos y salas técnicas sin cobertura, wifi corporativo que no llega a todas las zonas o que directamente no admite dispositivos móviles por política de seguridad. Y el trabajo en casa del cliente añade otra variable: la red de la que se dispone no es la propia.

La consecuencia de diseño es tajante: la aplicación tiene que asumir que no hay red y tratar la conectividad como una oportunidad, no como un requisito. En la práctica eso significa una arquitectura offline-first:

Los datos de trabajo (órdenes asignadas, catálogos de materiales, plantillas de checklist, historial del equipo) se sincronizan al dispositivo por adelantado, de forma que la jornada completa es operable sin conexión.
Todo lo que el técnico captura se guarda primero en el almacenamiento local del dispositivo. La escritura nunca depende de la red: no hay ruleta de carga delante de un formulario relleno.
Cuando vuelve la cobertura, la sincronización se hace en segundo plano, con reintentos, y sin exigir intervención del usuario. Las fotos, que pesan, se suben las últimas o solo con wifi si así se configura.
Los conflictos se resuelven con reglas explícitas. El caso típico: la oficina reasigna una orden mientras el técnico, sin cobertura, ya la ha empezado. Qué gana y qué se notifica a quién debe estar decidido en el diseño, no descubierto en producción.

Merece la pena insistir porque es el error más caro de esta categoría de proyectos: añadir modo offline a una aplicación pensada online es, en la práctica, reescribirla. La decisión se toma el primer día o se paga después.

Fotos, firmas y evidencias

La evidencia gráfica es probablemente la funcionalidad con mejor relación esfuerzo-valor de toda la aplicación. Una foto del estado del equipo antes y después de la intervención resuelve conversaciones enteras: reclamaciones de clientes, discusiones sobre si un daño era previo, dudas sobre si un trabajo se terminó. La clave no es hacer la foto, que cualquier móvil hace, sino asociarla: la imagen queda vinculada al parte, al equipo y al punto concreto del checklist, con fecha y autor, en lugar de perderse en la galería del teléfono o en un grupo de mensajería.

La firma en pantalla cierra el ciclo con el cliente. Firmar sobre el resumen de la intervención (trabajos realizados, tiempo, materiales) en el momento reduce drásticamente las disputas de facturación posteriores: lo que se factura es lo que se firmó. Para trabajos internos, el equivalente es la validación del supervisor, que puede hacerse en remoto sobre el parte cerrado.

Dos consideraciones prácticas. Primera: las fotos deben comprimirse en el dispositivo antes de subir; enviar originales de doce megapíxeles por la red móvil multiplica costes y tiempos de sincronización sin aportar nada. Segunda: si los técnicos trabajan en instalaciones de terceros, conviene pautar qué se puede fotografiar y revisarlo con el cliente, porque hay plantas con restricciones de confidencialidad estrictas sobre imágenes.

Integración con el ERP y el GMAO

Una aplicación de campo aislada crea el mismo problema que venía a resolver: una isla de datos más. El valor aparece cuando el flujo es de extremo a extremo: la orden nace en el GMAO o en el ERP, viaja al móvil, se ejecuta, y el resultado vuelve al sistema de origen sin retranscripción.

Los puntos de integración habituales son cuatro:

Órdenes de trabajo: el GMAO (o el módulo de mantenimiento del ERP) sigue siendo el dueño de la planificación. La aplicación recibe las órdenes asignadas y devuelve estados, tiempos y cierres. No conviene duplicar la planificación en la app: un solo sistema manda.
Materiales y almacén: el catálogo de artículos viene del ERP, y los consumos registrados en campo descuentan stock o generan la necesidad de reaprovisionamiento. Es la integración que más errores administrativos elimina.
Clientes y facturación: en empresas de servicios, el parte firmado alimenta directamente el borrador de factura o el albarán de servicio. El ciclo intervención-cobro se acorta de semanas a días.
Maestro de equipos: el historial por equipo solo es posible si la app y el GMAO comparten la misma identificación de activos. Etiquetar los equipos con códigos QR o placas con matrícula legible cierra el círculo: el técnico escanea y la app sabe exactamente sobre qué activo está trabajando.

En proyectos con Odoo como ERP este flujo es especialmente natural, porque mantenimiento, inventario y facturación viven en la misma plataforma; lo tratamos en detalle en la guía de Odoo para entornos industriales. Con otros ERP el patrón es el mismo: definir qué sistema es dueño de cada dato y sincronizar por API con colas y reintentos, nunca con exportaciones manuales.

Dispositivos: del móvil personal al terminal rugerizado

La elección de dispositivo condiciona coste, adopción y mantenimiento del parque. Las tres opciones habituales:

Opción	A favor	En contra
Móvil personal (BYOD)	Coste cero en hardware, cero curva de aprendizaje del dispositivo	Fronteras difusas entre lo personal y lo laboral, soporte sobre un parque heterogéneo, reticencias legítimas de los técnicos
Móvil corporativo estándar	Parque homogéneo, gestionable de forma centralizada, coste moderado	Fragilidad en entornos duros: polvo, golpes, grasa, lluvia
Terminal rugerizado	Sobrevive al entorno industrial, lector de códigos integrado, batería para turnos completos, usable con guantes	Coste unitario claramente superior y catálogo más limitado

La decisión sensata suele ser mixta: terminales rugerizados para los puestos de planta con uso intensivo y móvil corporativo para técnicos de servicio exterior. En cualquier caso, la aplicación debe ser multiplataforma para no quedar atada a una gama concreta de dispositivos; es uno de los motivos por los que en Captia construimos este tipo de herramientas como aplicaciones multiplataforma con una única base de código para Android, iOS y escritorio.

Ejemplo trabajado: mantenimiento con subcontratas

Veámoslo sobre un caso tipo, deliberadamente genérico pero realista. Una empresa de mantenimiento industrial atiende instalaciones de clientes con un equipo propio de técnicos y varias subcontratas. Hoy: las órdenes se comunican por teléfono y correo, los partes vuelven en papel o en fotos de papel, y una persona dedica buena parte de su jornada a transcribir y perseguir partes que faltan.

El flujo rediseñado con una aplicación de campo queda así:

La orden se crea en el GMAO y se asigna a un técnico propio o a una subcontrata. El técnico la ve en su móvil con el historial del equipo y la documentación adjunta. Las subcontratas acceden con perfiles limitados: ven sus órdenes, no las del resto.
Al llegar, el técnico escanea el QR del equipo, la app abre la orden correcta y registra la hora de inicio. Si la sala no tiene cobertura, todo sigue funcionando sobre los datos sincronizados por la mañana.
Ejecuta el checklist de la intervención con fotos en los puntos que la pauta exige. Un ítem no conforme genera una orden correctiva propuesta que el planificador verá al sincronizar.
Cierra el parte: materiales del catálogo, observaciones, firma del responsable de la instalación en pantalla.
Al recuperar cobertura, el parte sube solo. El GMAO actualiza el historial del equipo, el ERP descuenta materiales y el administrativo ve el parte firmado listo para facturar, el mismo día de la intervención.

La transcripción desaparece, la facturación se adelanta y, con unos meses de datos, aparece algo que antes no existía: historial real por equipo y por cliente sobre el que tomar decisiones de mantenimiento preventivo y de precio de contrato.

Comprar, adaptar o construir a medida

Existen productos de field service management maduros en el mercado, módulos de campo de los grandes ERP y plataformas genéricas de formularios móviles. La decisión no es ideológica, es de encaje:

Producto estándar cuando el proceso de campo es convencional y la empresa puede adaptarse al flujo que el producto propone. Es la vía más rápida si el encaje existe de verdad y la integración con los sistemas propios está resuelta.
Módulo del ERP existente cuando ya se opera sobre una plataforma que lo ofrece con solvencia: la integración viene de serie, que es justo la parte cara.
Desarrollo a medida cuando el proceso de campo es diferencial (flujos propios, checklists complejos, integraciones con sistemas heredados poco estándar) o cuando las licencias por usuario de un producto comercial, multiplicadas por decenas de técnicos y subcontratas, superan con los años el coste de construir exactamente lo que se necesita.

La trampa habitual está en el medio: comprar un producto estándar y personalizarlo tanto que se pierde la ventaja de comprar (las actualizaciones se vuelven un problema) sin ganar la ventaja de construir (el flujo sigue sin ser exactamente el propio). Si la personalización prevista es profunda, suele salir mejor plantear la aplicación como una herramienta interna a medida, diseñada sobre el proceso real y propiedad de la empresa.

Cómo implantar sin que la app muera en un cajón

La causa de muerte más frecuente de una aplicación de campo no es técnica: es que los técnicos no la usen, o la usen a regañadientes rellenando lo mínimo. Algunas reglas que se pagan solas:

Diseñar con los técnicos, no para ellos. Dos o tres usuarios de referencia implicados desde el prototipo detectan en una semana fricciones que un despacho no vería nunca: campos innecesarios, pasos que sobran, terminología que no es la de planta.
La app debe ahorrar tiempo al que la usa, no solo a la oficina. Si el parte digital tarda más que el de papel, la batalla está perdida. El historial del equipo a un toque, la orden con toda la información y no volver a rellenar nada dos veces son los argumentos que convencen a un técnico.
Piloto acotado antes que despliegue general. Un equipo, un tipo de intervención, entre cuatro y ocho semanas, con capacidad real de cambiar la aplicación con lo aprendido. Luego se extiende.
Retirar el papel de verdad. Mientras convivan los dos canales, el papel gana por costumbre. Tras el piloto, el parte digital debe ser el único válido, con el respaldo explícito de dirección.
Medir la adopción como un KPI del proyecto: porcentaje de partes cerrados en la app el mismo día, checklists completados en la zona (la marca de tiempo y la evidencia lo delatan), tiempo medio de cierre administrativo.

Preguntas frecuentes

¿Qué diferencia hay entre una app de field service y un GMAO?

El GMAO es el sistema de gestión: planifica el mantenimiento, guarda el maestro de equipos y el historial, y gestiona preventivos y correctivos. La aplicación de campo es la interfaz de ejecución: lo que el técnico usa en el móvil para recibir órdenes y registrar el trabajo. Muchos GMAO incluyen su propia app móvil; cuando esa app resuelve bien el trabajo offline y el flujo propio de la empresa, es una opción razonable. Cuando no, se integra una aplicación de campo a medida con el GMAO como sistema maestro.

¿De verdad hace falta funcionamiento offline si la planta tiene wifi?

Casi siempre sí. El wifi industrial rara vez cubre el cien por cien de la superficie útil (sótanos, salas técnicas, interiores de máquinas grandes), y los técnicos que salen a instalaciones de clientes dependen de redes ajenas. Además, el modo offline protege frente a caídas puntuales de la propia red: el técnico sigue trabajando y la sincronización se recupera sola. El coste de añadirlo a posteriori es tan alto que conviene decidirlo antes de escribir la primera línea.

¿Tienen validez las firmas capturadas en pantalla?

Para el uso habitual de un parte de trabajo (conformidad del cliente con la intervención realizada) la firma en pantalla acompañada de los metadatos del registro (fecha, hora, autor, contenido firmado) es práctica extendida y aporta una evidencia muy superior al papel. Para actos con requisitos formales específicos puede ser necesaria una firma electrónica cualificada; en ese caso conviene revisar el supuesto concreto con asesoramiento legal antes de definir el flujo.

¿Cuánto se tarda en poner en marcha una aplicación de campo a medida?

Depende del alcance y de las integraciones, pero el patrón sano es incremental: un primer producto usable con partes de trabajo y sincronización offline para un equipo piloto en pocos meses, y a partir de ahí iteraciones con checklists, firmas, integraciones adicionales y despliegue al resto de equipos. Los proyectos que intentan salir con todo el alcance a la vez tardan más en dar valor y llegan al piloto con decisiones de diseño sin contrastar con usuarios reales.

¿Cómo se gestiona el acceso de subcontratas sin exponer datos internos?

Con perfiles y ámbitos de datos definidos desde el diseño: la subcontrata ve exclusivamente sus órdenes asignadas, sin acceso al historial completo del cliente ni a información de otros proveedores. Las cuentas se dan de alta y de baja por proyecto o contrato, y toda actividad queda trazada por usuario. Es un requisito que conviene poner en la lista desde el primer día, porque condiciona el modelo de permisos de toda la aplicación.

Si tus partes de trabajo siguen viajando en papel y quieres llevarlos a una aplicación que funcione en planta, con o sin cobertura, e integrada con tu ERP o tu GMAO, en Captia Technology diseñamos y construimos este tipo de herramientas sobre el proceso real de cada empresa. Cuéntanos tu caso.