En logística, los datos están por todas partes pero rara vez en un mismo sitio. El sistema de transporte sabe cuándo salió un camión, el almacén conoce el estado del picking, la telemática registra la ruta y las horas del conductor, y las hojas de cálculo de control cuentan los costes a su manera. El director de operaciones acaba con cuatro verdades distintas y ninguna certeza. El problema no es la falta de datos, sino la ausencia de una capa única que los convierta en KPI comparables y decisiones concretas.
Por nuestra experiencia, lo difícil no es la visualización, sino ponerse de acuerdo sobre qué medimos exactamente y de dónde sale cada número. Por eso en los proyectos de analítica empezamos por las definiciones de métricas y fuentes, y solo después por los gráficos. Nuestra competencia en datos y BI se apoya en todo el RITS Group, incluidos nuestros equipos de Big Data y de IA/datos, y nuestra experiencia en transporte y travel tech se construyó en parte sobre trabajo de Data and Analytics. Aunque no hayamos ejecutado tu escenario exacto, aportamos a las personas que han diseñado y mantenido este tipo de solución.
¿Por qué están tan fragmentados los datos logísticos?
La fragmentación no es culpa de nadie; viene de la historia de los sistemas. Cada herramienta se construyó para resolver un problema operativo distinto, y cada una guarda los datos en su propio formato, con su propia definición de «entrega», «pedido» o «estado». Un TMS piensa en órdenes de transporte, un WMS en líneas de picking y la telemática en eventos GPS cada pocos segundos.
A eso se suman señales de fuera de la organización: estados de transportistas, notificaciones de reserva de clientes, ficheros EDI en varios sabores. El resultado es que el mismo envío lleva un identificador distinto en tres sitios, y su hora de entrega depende de a quién preguntes. Antes de calcular cualquier métrica tenemos que casar esos mundos y acordar un vocabulario común. Es un trabajo poco vistoso pero decisivo, porque cualquier KPI construido sobre datos mal unidos es pura ficción.
¿Cómo construir cuadros de mando de KPI operativos en logística?
Un buen cuadro de mando no lo muestra todo; muestra aquello sobre lo que quien lo lee puede actuar. Lo diseñamos en torno al rol: la pantalla de un responsable de tráfico no se parece en nada al cockpit de un director de operaciones. El conjunto de KPI de transporte que más veces funciona es:
- la puntualidad de entrega (OTD/OTIF) desglosada por transportista, región y tipo de cliente,
- el coste por envío y por kilómetro, separando las rutas propias de las subcontratadas,
- la utilización de la flota y el grado de ocupación del vehículo (carga útil, kilómetros en vacío),
- el tiempo de ciclo del pedido desde la recepción hasta la entrega,
- la calidad de los datos como KPI por derecho propio, es decir, cuántos eventos llegan a tiempo y completos.
Cada número se conecta a un camino para profundizar, desde el valor agregado hasta una ruta concreta, porque sin eso un KPI es una curiosidad y no una herramienta de decisión.
¿Cómo calcular el coste real por envío?
El coste por envío suena simple hasta que intentas calcularlo. El problema es que los costes están en sistemas distintos y con granularidades distintas: las facturas de los transportistas llegan en bloque, el combustible se liquida por vehículo y la mano de obra del almacén por turno, no por paquete. Para llegar a una cifra honesta, descomponemos el coste total en sus generadores y lo reasignamos a los envíos con claves razonables como el peso, el volumen o el número de líneas.
Eso saca a la luz cosas que una factura en bloque esconde: que una ruta pierde dinero de forma estructural, que los paquetes pequeños erosionan el margen pese a una tarificación correcta, o que el coste de los trayectos en vacío supera el ahorro de un transportista barato. En ese momento el coste deja de ser una línea en un informe y se convierte en un argumento de negociación y en una base para reencaminar.
¿Cómo informar sobre la puntualidad de entrega (OTD)?
El informe de puntualidad parece trivial y, sin embargo, todo depende de la definición de «a tiempo». ¿Contamos desde la reserva o desde la confirmación? ¿La tolerancia es una ventana horaria o un minuto exacto? ¿Una entrega parcial cuenta como cumplida? Fijar estas reglas importa más que el propio gráfico, porque deciden si un OTD del 95% es un éxito o un problema barrido bajo la alfombra.
Una vez claras las reglas, diseñamos el informe de puntualidad para que muestre no solo el resultado, sino también la causa:
- la tendencia del OTD en el tiempo, desglosada por transportista y delegación,
- los motivos de retraso, categorizados de forma consistente y no en texto libre,
- los envíos en riesgo, señalados antes de que pase el plazo y no después.
Ese último elemento mueve el reporting de un modo contable a uno operativo, porque permite al equipo reaccionar mientras todavía se puede salvar algo.
¿Cómo prever el volumen y la utilización?
Una vez ordenados los datos históricos, mirar hacia delante es el paso natural. Construimos modelos que prevén el volumen de envíos y la carga de almacén en base semanal y estacional, para que puedas planificar la dotación de turnos y la asignación de vehículos antes de que aparezca un cuello de botella. Esto no es leer los posos del café; es anclar las decisiones de capacidad en los patrones que se repiten cada año de todos modos.
Tratamos la capa de previsión como una extensión de la analítica, no como un mundo aparte. Solo cuando la base de datos limpios y métricas acordadas funciona, añadimos modelos predictivos y, cuando tiene sentido, un componente de IA. Esa competencia existe de verdad dentro del RITS Group, así que la activamos cuando aporta valor, no porque suene bien.
¿Cómo diseñar el almacén de datos y la capa de métricas?
Bajo cada cuadro de mando tiene que haber una base reproducible, o los números se separan en cuanto cambia una fuente. La construimos como un almacén de datos con una capa de métricas explícita, alimentado por pipelines que extraen regularmente de los sistemas operativos:
- pipelines desde el TMS, el WMS y la telemática, resistentes a eventos ausentes y duplicados,
- una capa de modelado que convierte tablas brutas en entidades coherentes (envío, ruta, pedido),
- una definición central de las métricas, para que el OTD o el coste por envío se calculen igual en todos los informes,
- controles de calidad de datos integrados en el pipeline, con una alerta cuando una fuente deja de entregar el conjunto completo.
Esta arquitectura hace que una métrica nueva aterrice en días en lugar de semanas, y que toda la empresa mire las mismas cifras.
¿Qué competencias aportamos a la analítica logística?
Damos forma al equipo según la etapa y el alcance concretos del trabajo, no «por si acaso». En proyectos de datos cubrimos sobre todo estos roles:
- un ingeniero de datos que construye y mantiene los pipelines y el almacén,
- un analista de BI / desarrollador de cuadros de mando que traduce las métricas en pantallas legibles,
- un arquitecto de datos responsable del modelo y de la capa de métricas,
- un especialista de ML / data scientist cuando entran las previsiones y un componente de IA.
Un equipo así puede trabajar como extensión de tu departamento de datos o como equipo dedicado que lleva el tema de extremo a extremo. Expusimos las diferencias entre estos modelos en nuestro artículo sobre modelos de colaboración en TI.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia que combina competencia en datos con experiencia en proyectos de transporte:
- nuestras competencias de Data y BI se apoyan en el RITS Group, incluidos nuestros equipos de Big Data y de IA/datos,
- en el sector de transporte y travel tech hemos entregado trabajo de Data and Analytics,
- empezamos por las definiciones de métricas y la calidad de los datos, no por un gráfico bonito,
- verificamos las competencias antes de empezar y escalamos el equipo a medida que el proyecto madura.
Lo más habitual es que lo hagamos como software de analítica a medida construido por nuestro equipo y, cuando hay huecos que cubrir rápido, como refuerzo de equipo.
¿Por dónde empezar con la analítica logística?
Empieza por una decisión que quieras tomar mejor, por ejemplo con qué transportista reducir volumen o qué ruta renegociar. Esa decisión define las métricas que necesitas, y las métricas definen las fuentes y la arquitectura. Es un punto de partida mucho más sano que intentar medirlo todo a la vez, porque entrega un resultado que se ve en la operación enseguida.
¿Quieres convertir los datos del TMS, el WMS y la telemática en KPI y decisiones? Hablemos - ajustaremos un equipo y una arquitectura a tu logística.