Digitalizar los procesos de terreno: del papel a la aplicación móvil.

Pregunte a una dirección dónde nace su dato más importante. La respuesta rara vez es «en el ERP». Nace en el agente que visita una tienda de barrio, en la obra donde se recibe el cemento, en el almacén donde se cuentan los palés, en la agencia rural que abre una cuenta o entrega una ayuda, en el encuestador que censa hogares. Lo que el sistema registra después es una copia, tecleada más tarde, por otra persona, con un plazo y con errores. Digitalizar el terreno consiste en hacer que el dato correcto nazca una sola vez, en el lugar donde se produce.

Por qué el papel y WhatsApp persisten

Sería fácil ver en ello un retraso. Es más bien una respuesta racional a limitaciones reales. El papel nunca se queda sin cobertura. No exige cuenta, ni contraseña, ni formación. WhatsApp ya está instalado, la foto sale con un gesto y el responsable la ve enseguida. Frente a eso, muchas aplicaciones de empresa han fracasado por razones previsibles: exigían una conexión permanente, reproducían un formulario de escritorio en una pantalla pequeña, añadían trabajo al agente sin devolverle nada, y hablaban una lengua que no era la suya.

El papel y WhatsApp tienen, sin embargo, un coste que siempre se acaba pagando. El dato llega tarde, incompleto, imposible de conciliar con el cliente o con el pedido en el sistema. Las fotos se pierden en las conversaciones. Las existencias del sistema nunca corresponden a las existencias reales. Los donantes y los auditores piden pruebas que nadie encuentra. Y el conocimiento del terreno se queda en la memoria de los agentes, que se marchan con él.

Lo que una aplicación de terreno debe saber hacer

Una aplicación de terreno no es un ERP en pequeño. Es una herramienta concebida para un contexto preciso: un teléfono a menudo de gama de entrada, una mano disponible, una red incierta, un usuario con prisa. De ahí se derivan cinco exigencias.

• Funcionar sin conexión. La primera condición, y la que más a menudo se sacrifica. El agente debe poder capturar y consultar sus clientes, sus rutas, sus existencias, sin red, durante todo un día si hace falta. La aplicación es local primero, conectada después.
• Sincronizar correctamente. Cuando la red vuelve, los datos salen y regresan sin intervención, en el orden correcto, sin duplicados, con reglas claras cuando dos personas han modificado lo mismo. La sincronización es el verdadero corazón técnico del proyecto; hay que concebirla, no padecerla.
• Capturar la foto y la posición. Una foto con fecha, hora y geolocalización vale más que un formulario largo: prueba de entrega, estado de un contador, avance de una obra, presencia de un punto de venta. La posición ayuda también a organizar las rutas y a verificar, sin vigilar a las personas, que la visita ha tenido lugar.
• Seguir siendo sencilla. Pocas pantallas, botones grandes, listas ya rellenadas en lugar de campos que teclear, valores por defecto inteligentes. Cada campo añadido debe justificarse por un uso real aguas abajo. Si nadie lee el dato, no se pide.
• Hablar las lenguas del terreno. Francés, wolof u otra lengua nacional según los equipos, con pictogramas y, cuando es necesario, mensajes de audio. Una aplicación que el agente entiende sin traducir es una aplicación que utiliza.

Conectar el terreno al núcleo de gestión y al CRM

Una aplicación de terreno aislada no hace más que desplazar el problema: en lugar de teclear de nuevo desde un cuaderno, se teclea de nuevo desde una base aparte. El valor nace de la integración. Del lado del núcleo de gestión, la recepción en almacén actualiza las existencias en SAP o en Odoo; el pedido tomado en ruta se convierte en un pedido de venta; la ficha de obra alimenta el seguimiento del proyecto. Del lado de la relación con el cliente, la visita, la reclamación o la lectura de un punto de venta enriquecen la ficha en Salesforce, para que la sede y el terreno miren al mismo cliente.

Algunos principios encuadran esa integración. Los maestros permanecen en el sistema propietario: la lista de clientes, de artículos, de emplazamientos viene del ERP o del CRM, la aplicación no los recrea. Los intercambios pasan por API documentadas, con una gestión explícita de los errores y de los reintentos. Y se decide desde la definición qué sube en tiempo real y qué puede esperar a la siguiente sincronización. Es el terreno de nuestra oferta Aplicaciones a medida, de la pantalla móvil hasta la integración con SAP, Odoo y Salesforce.

Una aplicación de terreno lograda se reconoce por una señal: los agentes la abren porque les presta un servicio, no porque se lo hayan pedido.

La gestión del cambio con los equipos de terreno

Ahí se juega la mayoría de los fracasos, y casi nunca son técnicos. Los equipos de terreno han visto pasar herramientas impuestas por la sede y luego abandonadas. Saben que la aplicación puede servir para controlarlos tanto como para ayudarlos. No se les convence con una circular interna.

Lo que funciona, según nuestra experiencia: asociar a algunos agentes desde el diseño, no solo en las pruebas de aceptación; devolverles algo desde la primera versión, una ruta ya preparada, un histórico de cliente a mano, el fin de un informe que rehacer por la noche; designar enlaces sobre el terreno, compañeros que forman a sus compañeros en su lengua; aceptar un periodo en el que el papel y la aplicación coexisten; y corregir rápido a partir de los comentarios de cada semana. Los mandos intermedios cuentan tanto como los agentes: si el director de agencia o el jefe de obra sigue pidiendo la ficha en papel, la aplicación está muerta.

Seguridad y datos personales

Un teléfono que circula por el terreno lleva datos sensibles: identidades de clientes o de beneficiarios, datos de contacto, posiciones, fotos y, a veces, importes. Puede perderse, ser robado o prestarse. La aplicación debe, por tanto, cifrar lo que almacena localmente, abrirse con una autenticación adaptada a los usos, guardar en el dispositivo únicamente lo que sirve para la jornada, y poder borrarse a distancia. Los derechos siguen al rol y al perímetro: un agente ve su zona, no el país.

En cuanto la aplicación recoge datos sobre personas, entra en el ámbito de la ley n.º 2008-12. El tratamiento se declara ante la CDP, se informa a las personas de la finalidad, la recogida se limita a lo que sirve a esa finalidad y el plazo de conservación queda definido. Para una recogida de datos de beneficiarios, esas reglas cuentan tanto más cuanto que las personas afectadas suelen ser vulnerables. Todo eso se concibe en la definición, no después de la puesta en producción. Nuestra oferta Seguridad y riesgos IT interviene desde esa etapa.

Un método por iteraciones, con un piloto

No creemos en el gran despliegue de una aplicación concebida en un despacho. Se elige un proceso y una zona: un equipo de ruta, un almacén, una agencia. Se observa el trabajo real, sobre el terreno, antes de dibujar la menor de las pantallas. Se construye una primera versión limitada a lo estrictamente necesario, sin conexión desde el principio, conectada al sistema al menos por un flujo. Se pone en manos de los agentes piloto en unas semanas, y se corrige a su ritmo. Se mide lo que cuenta para el negocio: plazo entre la visita y el dato en el sistema, proporción de capturas completas, existencias concordantes, tiempo devuelto a los agentes. Después se extiende, zona por zona, llevando consigo a los enlaces formados durante el piloto.

Esta manera de trabajar es coherente con lo que somos: una firma de Dakar, cuyos equipos pueden ir al terreno, probar con los agentes en su lengua y volver la semana siguiente. Concebir una aplicación de terreno para la subregión desde la subregión es la condición para que tenga en cuenta las redes, los teléfonos, las lenguas y las costumbres reales. El dato que de ella sale alimenta después el reporting, tema de nuestra oferta Data & Analytics, y a veces los primeros casos de uso de IA y automatización, con la lectura de los documentos fotografiados a la cabeza.

Nuestras recomendaciones

1. Partir de un proceso, no de una aplicación. ¿Qué gesto de terreno produce el dato que la empresa más necesita? Por ahí se empieza.
2. Exigir el funcionamiento sin conexión y la sincronización desde la definición. Son los dos puntos que no se recuperan después.
3. Decidir pronto la integración. Qué maestros vienen de SAP, de Odoo o de Salesforce, qué flujos suben y a qué ritmo.
4. Concebir con los agentes y con los mandos de terreno. Devolverles tiempo desde la primera versión.
5. Tratar la seguridad y la ley n.º 2008-12 como exigencias del producto. Cifrado, derechos, declaración ante la CDP, información a las personas.
6. Pilotar, medir, extender. Una zona, unas semanas, indicadores de negocio y luego el despliegue por oleadas.

Del papel a la aplicación móvil, el camino no es en primer lugar tecnológico. Consiste en respetar el trabajo de terreno tal como es, en darle una herramienta que lo sirva, y en conectar por fin lo que la empresa hace con lo que registra.