Cómo ayudamos a GLS Spain a reducir incidencias logísticas con datos en tiempo real
El problema no era falta de datos
Cuando empezamos a trabajar con GLS Spain, el equipo de operaciones no tenía escasez de datos. El sistema de gestión de rutas capturaba eventos continuamente: intentos de entrega, incidencias por destinatario ausente, desvíos de ruta, tiempos de carga en depósito, confirmaciones de entrega, escaneos en puntos de consolidación. Cada día se generaban millones de eventos distribuidos por toda la red nacional.
El problema era temporal. Esos datos llegaban al equipo operativo en forma de reportes consolidados con entre 18 y 24 horas de retraso. Para la logística de última milla, 24 horas es un ciclo completo de operaciones. Cuando el equipo de coordinación recibía el informe del día anterior, los repartidores ya estaban en ruta repitiendo el mismo problema: una dirección sistemáticamente fallida, un código postal con tasa de ausencias anormalmente alta, un tipo de paquete con incidencia de daños elevada. La respuesta llegaba un ciclo después de cuando podría haber servido.
Las herramientas BI existentes no ayudaban. Estaban diseñadas para análisis de tendencias a medio plazo —semanas, meses—, no para la ventana de minutos a horas en la que una decisión operativa es útil. Un dashboard que refresca cada noche es excelente para un director comercial. Es inútil para un coordinador de depósito que tiene que decidir si reasignar rutas en las próximas dos horas.
El objetivo del proyecto no era construir otro data warehouse analítico. Era comprimir el tiempo entre el evento operativo y la decisión correctiva, de 24 horas a menos de una hora, sin comprometer la profundidad de análisis que los equipos de planificación también necesitaban.
Arquitectura event-driven: Pub/Sub + BigQuery
El sistema de gestión de rutas de GLS generaba eventos en un formato propietario con variaciones según el tipo de evento. El primer trabajo de ingeniería fue mapear esos eventos a un esquema normalizado que pudiera alimentar el sistema analítico sin transformaciones costosas en tiempo de consulta. Eso implicó semanas de discovery técnico con el equipo de sistemas de GLS: entender qué eventos existían, qué campos eran fiables en cada tipo, qué significaban los códigos heredados, y cuáles eran las dependencias de orden entre eventos.
La arquitectura resultante se construyó sobre tres componentes de GCP. Pub/Sub como bus de eventos: cada evento del sistema origen se publica en un topic con particionado por tipo de evento y zona. Cloud Functions (y en algunos casos Cloud Run para pipelines más pesados) como suscriptores: aplican validación, enriquecimiento con datos de referencia (códigos postales, perfiles de ruta, histórico de destinatario) y normalización. BigQuery como almacén analítico de destino, con tablas particionadas por día y clusterizadas por zona operativa.
La latencia extremo a extremo del pipeline —desde que el evento ocurre en el sistema origen hasta que es consultable en BigQuery— era inferior a dos minutos en el percentil 95. Para los casos de uso operativos eso era suficientemente bajo: muy por debajo de la ventana de decisión del coordinador.
La elección de BigQuery no fue casual. Los equipos de operaciones necesitan poder hacer consultas ad hoc sobre millones de eventos sin planificar con antelación qué preguntas van a hacer. Un data warehouse columnar con separación de almacenamiento y cómputo permitía eso sin coste prohibitivo. Consultas que en un PostgreSQL operacional habrían tardado minutos bajaban a segundos.
Tres iteraciones de dashboard hasta acertar con UX
El error más frecuente en proyectos de datos es diseñar dashboards para quienes los piden, no para quienes los usan. Los directores de operaciones piden dashboards. Los que necesitan actuar sobre los datos son los coordinadores de depósito y los supervisores de zona. Esos perfiles tienen necesidades radicalmente distintas.
La primera iteración del dashboard —lo reconocemos sin problema— falló. La diseñamos como un analista habría diseñado algo para sí mismo: densa, con filtros flexibles, con múltiples vistas. Cuando la presentamos en un depósito real, los coordinadores nos miraron con amabilidad y siguieron usando Excel.
La segunda iteración corrigió parte del problema. Bajamos la densidad, destacamos incidencias, pero seguíamos asumiendo que el usuario se sentaba a "consultar" el dashboard. La realidad era otra: los coordinadores están de pie, moviéndose, gestionando cuatro incidencias a la vez. Un dashboard que se consulta no encaja en ese flujo.
La tercera iteración, la que funcionó, partió de una semana de observación directa. Vimos qué hacían los coordinadores minuto a minuto, con qué sistemas cambiaban de contexto, qué interrupciones recibían. Diseñamos un tablero con tres zonas claras: estado en tiempo real de rutas activas con mapa e indicadores de desviación, incidencias activas clasificadas por severidad y tiempo sin resolución, y tendencias de las últimas cuatro horas para detección temprana de patrones. Nada más. Los filtros desaparecieron; el dashboard muestra automáticamente la zona relevante para el usuario conectado.
La carga objetivo fue menos de un segundo. Cuando una herramienta tarda tres segundos, un analista espera. Un coordinador la cierra. Esa diferencia de percepción determinó muchas decisiones técnicas —materialización agresiva de vistas, pre-agregados actualizados por triggers, caché de consultas frecuentes— que no eran glamurosas pero eran las únicas que permitían que el dashboard fuera usable en la realidad operativa.
Alertas: el problema del falso positivo
El dashboard resuelve la visibilidad. Pero pedir a un coordinador que mire el dashboard cada cinco minutos no es escalable. La detección proactiva de desviaciones requería un sistema de alertas.
La primera versión de las alertas usó umbrales estáticos. Si las incidencias en una zona superaban X en una hora, alerta. Funcionó mal: los umbrales razonables en un jueves por la tarde eran absurdos un lunes por la mañana, y viceversa. En pocos días, los coordinadores recibían entre 30 y 50 alertas diarias, la mayoría irrelevantes. La consecuencia predecible: dejaron de mirarlas.
La segunda versión introdujo una lógica de anomalía estadística relativamente simple. Para cada combinación de zona geográfica y tipo de incidencia, calculamos la media y desviación estándar histórica en ventanas comparables —mismo día de la semana, misma franja horaria, últimas cuatro semanas—. Cuando la tasa en tiempo real supera la media más dos desviaciones estándar de forma sostenida durante 15 minutos, se genera una alerta. El "sostenido" es clave: evita el falso positivo por picos puntuales que no requieren acción.
Con ese cambio, el volumen de alertas diarias bajó de decenas a tres o cuatro, casi todas accionables. La tasa de atención a las alertas pasó de alrededor del 20% al 85%.
El canal también importaba. Las alertas se enviaban inicialmente por email. El equipo no las leía —los correos de sistemas compiten con muchos otros en la bandeja—. La integración con el sistema de mensajería interno de operaciones, que ya usaban para coordinación diaria, fue lo que cerró el bucle. El canal importa tanto como el contenido.
Resultados con números reales
Seis meses después del despliegue, la tasa de incidencias escaladas —las que superaban la ventana de resolución de cuatro horas sin intervención— había bajado un 34%. El tiempo medio de respuesta a una incidencia detectada proactivamente pasó de más de 24 horas a 40 minutos. Las zonas problemáticas emergentes se identificaban durante el mismo turno en el que aparecían, no al día siguiente.
No todo funcionó como se había planeado. El módulo más ambicioso del alcance inicial fue el que más lecciones dejó, precisamente porque falló.
Lo que no funcionó: el módulo predictivo
La idea era predecir, basándose en histórico y condiciones del día (clima, día de la semana, volumen de paquetes, perfil del conductor), qué zonas tendrían incidencias elevadas antes de que las rutas salieran del depósito. Sobre el papel era el componente más vistoso del proyecto.
El modelo funcionaba razonablemente en backtesting. En producción generó demasiados falsos positivos. La distribución de datos de entrenamiento no capturaba bien situaciones reales como reparto en festivos locales, campañas promocionales o rutas sustitutivas por cambios de conductor. Los coordinadores recibían avisos predictivos que en una proporción significativa no se materializaban. En dos semanas dejaron de confiar en el módulo.
El postmortem honesto fue doble. Técnicamente, el modelo necesitaba más features contextuales y un proceso de evaluación continua que no habíamos presupuestado. Pero sobre todo, operativamente, la detección reactiva de alta calidad tiene más valor que la predicción de baja precisión. Mejor identificar el problema dos minutos después de que ocurra con certeza que intentar predecirlo con tasa de error del 30%.
Simplificamos el módulo predictivo a un ranking de zonas de atención prioritaria basado únicamente en histórico reciente, sin ML complejo. Ese sí se usa. La complejidad técnica no es un proxy de valor.
Operativos vs analistas: dos productos, un mismo dato
La gran lección del proyecto fue que construir para usuarios operativos requiere criterios de diseño distintos a los que aplican para analistas. El mismo dato alimenta ambos productos, pero la presentación, la cadencia, el volumen de información, las alertas y los flujos de acción son completamente diferentes.
La pregunta que importa en un proyecto de datos operativos no es "qué visualización es más informativa" sino "cambia el sistema las decisiones que toma el equipo". En GLS, lo hizo. Y lo hizo porque resistimos la tentación de añadir más métricas, y porque aceptamos, a tiempo, que la predicción ambiciosa era menos valiosa que la reacción robusta.
¿Quieres llevar esto a tu empresa?
Cuéntanos tu proyecto y te ayudamos a encontrar la solución tecnológica adecuada.
Hablar con nuestro equipo