Fichar en el campo cuando no hay cobertura

En el campo no hay wifi, y muchas veces tampoco hay cobertura. Pero el trabajo se hace igual, y alguien tiene que registrar quién ha venido, quién falta y qué ha hecho cada equipo. Este es el caso de una empresa agroalimentaria que necesitaba que ese registro se hiciera donde ocurre —en la finca— y llegara solo a los sistemas que ya tenía. La parte difícil no era la pantalla. Era el rato en el que no hay red.

Este caso es para quien tiene gente trabajando fuera de la oficina. Si buscas quién te construya una aplicación para el móvil, la página es desarrollo de aplicaciones móviles; si lo que necesitas es que un sistema nuevo conviva con los que ya tienes, integración de software. Y si quieres que lo miremos contigo, cuéntanos el caso.

El punto de partida

El cliente es Primaflor, empresa del sector agroalimentario con operaciones de campo repartidas en fincas. El trabajo lo organizan jefes de equipo: cada uno se responsabiliza de un grupo de personas y, cada día, de dejar constancia de quién está y qué se ha hecho.

No partíamos de una hoja en blanco. La empresa ya tenía su ERP de campo, con su directorio de usuarios corporativo y una base de datos SQL Server en sus propias instalaciones donde vive la información de siempre. Lo que faltaba era el eslabón de la presencia: que el registro se hiciera en el sitio donde se trabaja y acabara, sin pasos intermedios, en el sistema que ya usaba todo el mundo.

Y ahí aparece la condición que lo cambia todo. El enunciado del proyecto lo decía sin rodeos: la aplicación la usarían los jefes de equipo en condiciones de baja conectividad. No «con mala cobertura de vez en cuando». Con conectividad esporádica: hay red un rato, luego no la hay durante horas, y vuelve cuando vuelve.

Si has trabajado en operaciones fuera de la ciudad, sabes lo que significa. Una aplicación que pide conexión para guardar no se usa: se usa el papel, y el papel llega dos días después, con letra de otro y con los errores de haberlo copiado dos veces. La aplicación no compite con otra aplicación. Compite con el papel, y el papel siempre funciona.

Por qué la respuesta no era «una app más»

La tentación, en un proyecto así, es tratar el modo sin conexión como una funcionalidad más de la lista. Se construye la aplicación normal, se deja para el final una tarea que ponga «offline» y se ve qué se puede hacer con el tiempo que quede.

Eso no funciona, por una razón sencilla: sin conexión, el dato de verdad está en el teléfono. Durante horas, la única copia de lo que ha pasado en esa finca está en el bolsillo de una persona. Todo lo demás del diseño se deriva de ahí:

• Si el dato está en el móvil, hay que escribirlo en almacenamiento persistente en el momento, no al enviar. Un cierre de navegador o una batería agotada no pueden costar una jornada.
• Si el envío se hace más tarde, hay que decidir en qué orden se reproduce lo pendiente, porque un parte se abre antes de tener líneas y las líneas no existen sin su cabecera.
• Si algo falla al enviarse, alguien tiene que enterarse. Un fallo silencioso es peor que no tener aplicación: la gente confía, y el dato no está.
• Y hay información que sí se puede guardar en caché para trabajar sin red —la lista del equipo, las tablas de configuración— y otra que no puede cachearse nunca, porque cachear un fichaje es arriesgarse a darlo por enviado dos veces o a servir uno viejo como si fuera el de hoy.

Esa última distinción es la que decide si el proyecto sale bien. No es una decisión de pantalla: es una decisión de arquitectura, y se toma al principio.

Qué hace la aplicación, fichaje a fichaje

El jefe de equipo abre la aplicación en el navegador de su propio teléfono. No hay tienda de aplicaciones ni instalación: es una PWA, una aplicación web que el navegador guarda como si fuera nativa y que arranca aunque no haya red.

Las credenciales se recuerdan durante días, precisamente porque no se puede depender de tener conexión para validar una contraseña en mitad de una finca. En la sincronización posterior sí puede pedirse la autenticación de nuevo: es el punto donde tiene sentido comprobar quién eres, porque ahí hay red.

A partir de ahí, el flujo es el que espera alguien que tiene diez personas delante y prisa:

1. Ve a su equipo. Los datos que necesita para trabajar están cacheados, así que la lista aparece con o sin cobertura.
2. Registra presencias y ausencias. El parte del día se abre y se van añadiendo las líneas de fichaje de cada miembro del equipo.
3. Identifica al trabajador por QR cuando hace falta. Cada persona tiene su código, generado desde el backoffice, y la aplicación lo lee con la cámara del propio teléfono.
4. Anota el trabajo hecho, no solo la presencia: las líneas de trabajo van al mismo parte.
5. Sigue trabajando, con o sin red. Todo lo que introduce queda escrito en el almacenamiento local del teléfono en cuanto lo introduce.
6. Cuando vuelve la cobertura, lo pendiente se envía solo, en segundo plano, en el orden correcto. La aplicación avisa cuando la sincronización ha terminado y avisa —esto es lo importante— cuando un elemento concreto no ha podido enviarse.

En la oficina, el backoffice hace el resto: correcciones de lo registrado, gestión de las tablas maestras, tratamiento de incidencias, generación de los códigos QR de los trabajadores y las configuraciones que necesita la aplicación de campo para comportarse como debe.

Las decisiones que importaban (y por qué)

Aplicación web instalable, no aplicación de tienda. Los usuarios son personal de la empresa, no público general. Con una PWA no hay proceso de publicación, ni aprobación de nadie, ni la situación clásica de tener a la mitad de la plantilla con una versión de hace ocho meses porque no ha actualizado. Se publica una vez y todos entran a lo mismo. Y funciona en los teléfonos que ya tienen, con el navegador que ya llevan.

Las lecturas se cachean; las escrituras, jamás. Lo que la aplicación consulta se sirve primero de la red y, si no hay, de una copia local con vigencia limitada. Lo que la aplicación escribe —cabecera del parte, líneas de fichaje, líneas de trabajo— se excluye explícitamente de la caché y se encola para reenviarse en segundo plano. Es la diferencia entre una aplicación que va rápida y una que duplica jornadas.

El aviso de fallo forma parte del producto. Cuando la reproducción de la cola termina, la aplicación se lo dice al usuario; cuando un elemento falla, también. Un sistema que solo comunica los éxitos entrena a la gente para confiar en él justo cuando no debe.

La autenticación es la que ya existía. La aplicación valida contra el directorio corporativo del cliente por LDAP, el mismo mecanismo que usaba su ERP de campo. Ninguna lista de usuarios nueva, ninguna baja que se olvide en un sitio y siga viva en otro.

Los datos aterrizan donde ya estaban. Los servicios escriben en la base de datos SQL Server que la empresa tenía en sus instalaciones. No hubo migración, ni esquema nuevo, ni «ya que estamos». El resto de la organización siguió leyendo los datos donde siempre los había leído, y el proyecto no arrastró consigo un segundo proyecto encubierto.

Las pantallas se validaron antes de programarlas. El diseño se prototipó a partir de los materiales del propio cliente y se revisó con él antes de escribir el código de la interfaz. En una aplicación que se usa de pie, con guantes y con prisa, mover un botón en un prototipo cuesta unos minutos; moverlo cuando ya está programado cuesta un día.

Cómo se hizo

El proyecto se planteó por actividades, cada una con su entregable, y con reuniones de seguimiento cada quince días:

• Diseño gráfico de pantallas. Prototipos de la aplicación de campo y del backoffice, a partir de los diseños originales del cliente, revisados y validados antes de programar.
• Módulo de fichaje y ausencias. La parte de negocio dentro de la API, la que permite a los jefes de equipo registrar y auditar a su gente. La consumen tanto la aplicación de campo como el backoffice, así que la regla vive en un solo sitio.
• Sincronización sin conexión. Programación a dos bandas: en la aplicación, la cola y el almacenamiento local; en la API, el comportamiento que hace que reproducir lo encolado sea seguro.
• Backoffice de gestión. Mantenimiento de la información y generación de los códigos QR que se asignan a los trabajadores.
• Autenticación y seguridad, con el mismo modelo que el ERP de campo ya existente.

El equipo se compuso por perfiles: desarrollo backend, desarrollo frontend, jefatura de proyecto a tiempo parcial, diseño gráfico a tiempo parcial y perfil de despliegue, este último para dejar la entrega automatizada sobre la infraestructura de integración continua que el cliente ya tenía montada. Las fases cubrieron desde el análisis y el diseño hasta las pruebas y la formación.

Qué se incluyó sin estar en el título

Un proyecto llamado «registro de presencias» acaba conteniendo unas cuantas cosas que no suenan a registro de presencias y sin las cuales no habría entrega:

• Generación y lectura de códigos QR, en la API y en la aplicación, para identificar a los trabajadores sin teclear nada.
• Backoffice completo de tablas maestras e incidencias, que es donde se arregla lo que en el campo salió mal.
• Servicios documentados con OpenAPI, de modo que la propia documentación de la API sea la que genera el cliente que consume el frontend, y no una página que envejece en un cajón.
• Despliegue continuo sobre Kubernetes, para que publicar una corrección sea rutina y no un acontecimiento.
• Formación al equipo del cliente, porque una aplicación de campo la usan personas que no van a leerse un manual.

El resultado

La aplicación está en producción y los partes se registran donde se trabaja, con cobertura o sin ella, y llegan al sistema de la empresa sin que nadie los vuelva a teclear.

Las cifras del proyecto, tal y como están imputadas en nuestro sistema de gestión:

• Más de 940 horas de desarrollo imputadas al proyecto.
• Diecisiete meses con dedicación registrada.
• Siete personas distintas han trabajado en él.

Y aquí va lo que no vas a encontrar en esta página: un porcentaje de ahorro, una reducción de tiempos o una mejora de productividad. No los publicamos porque no los hemos medido nosotros y el cliente no nos ha facilitado esas cifras por escrito. Un caso sin porcentaje es creíble; uno con un porcentaje inventado se cae en la primera pregunta, y normalmente delante de la persona a la que se le quería contar.

Lo que más nos gusta del proyecto

No es la aplicación. Es que la parte frágil está identificada y escrita.

En una aplicación así hay tres piezas que están acopladas aunque no lo parezcan: qué peticiones se excluyen de la caché, cómo se reencola lo que falló y con qué claves se guarda el estado en el teléfono. Quien toque una de las tres sin mirar las otras dos rompe el modo sin conexión, y lo romperá de la peor manera posible: sin error visible, con el usuario convencido de que ha fichado.

Eso está documentado como lo que es —un punto sensible del sistema, con nombre y apellidos— para quien lo mantenga dentro de dos años, sea quien sea. Software que resiste el paso del tiempo no es software que no se toca: es software en el que se puede entrar sin miedo.

¿Te suena? Señales de que este caso va contigo

• Tienes gente trabajando fuera de la oficina y su parte llega al sistema con horas o días de retraso.
• Alguien teclea dos veces lo que ya se escribió en papel, y las diferencias entre las dos copias se descubren a final de mes.
• Probaste una aplicación y no se usa porque «en el campo no va».
• Tienes un ERP o una base de datos que manda, y cualquier cosa nueva tiene que hablar con ella sin obligarte a migrar nada.
• El registro de jornada es una obligación legal y hoy depende de que nadie pierda una hoja.
• Te preocupa quién mantendrá esto dentro de tres años, y con razón.

Si te reconoces en tres, la conversación merece la pena. Si te reconoces en una, quizá todavía no; y te lo diremos igual.

Preguntas frecuentes

¿Una aplicación web puede funcionar de verdad sin cobertura? Sí, si se construye para eso desde el principio. La aplicación se guarda en el propio teléfono y trabaja contra un almacén local; lo que no se puede enviar se encola y sale solo cuando vuelve la red. Lo que no funciona es coger una aplicación web normal y añadirle el modo sin conexión al final. Ahí es donde se pierden datos.

¿Qué pasa con un fichaje hecho sin conexión si el móvil se queda sin batería? El dato no vive en memoria: se escribe en el almacenamiento local en cuanto se introduce, y la cola de envío también. Al volver a abrir la aplicación, lo pendiente sigue ahí y se reenvía en cuanto hay red. Y el usuario recibe aviso tanto cuando la sincronización termina como cuando un elemento concreto falla.

¿Hace falta publicar una app en Google Play o App Store? Aquí no. La aplicación se ejecuta en el navegador del propio teléfono: sin tienda, sin aprobación y sin versiones antiguas conviviendo con las nuevas. Encaja cuando el usuario es personal de la empresa y no público general.

¿Se puede usar el directorio de usuarios que ya tenemos? Sí, y es lo que recomendamos. En este caso la aplicación autentica contra el directorio corporativo por LDAP, el mismo que ya usaba el ERP de campo. Así no aparece una segunda lista de usuarios que alguien tenga que mantener.

¿Y si nuestros datos tienen que acabar en una base de datos antigua? Es exactamente este caso. Los servicios escriben en la base de datos SQL Server que la empresa ya tenía en sus instalaciones: sin migración y sin cambiar el esquema. La aplicación nueva se adapta al sistema que manda, no al revés.

¿Cuánto trabajo lleva un proyecto así? Este acumula más de 940 horas imputadas, en diecisiete meses con dedicación y con siete personas distintas. No es todo la primera entrega: una aplicación que se usa cada día en operación real sigue creciendo después, y eso es una buena señal, no una mala.

¿Quién lo mantiene después? Lo hablamos siempre antes de entregar. Una aplicación que sostiene una obligación diaria necesita que alguien esté cuando falla, y el momento de decidirlo es antes de que falle.

Si quieres que lo miremos

Llevamos desde 2012 construyendo software a medida para empresas que tienen procesos fuera de la oficina y sistemas que no se pueden tocar. Cuéntanos dónde se registra hoy el trabajo de tu gente y cuánto tarda en llegar a tu sistema, y te decimos si esto te encaja o si todavía no te hace falta.

Escríbenos y lo vemos.