Forecasting de demanda con IA: caso real en empresa logística

Cada mañana, a las 6:30h, el equipo de planificación de un operador logístico nacional abría su hoja de Excel de siempre y empezaba a distribuir las rutas del día. Miraban el histórico de los últimos días, consultaban al equipo comercial por si había clientes especiales y tomaban decisiones que afectaban a 120 rutas y más de 80 conductores. El proceso duraba entre 2 y 3 horas.

Los picos de demanda los pillaban por sorpresa con frecuencia: sobre-stock en unos almacenes, roturas en otros, y coste de transporte creciendo un 8% cada año sin que el volumen lo justificase.

¿Por qué el problema era de datos y no de personas?

Antes de proponer cualquier solución, pasamos dos semanas entendiendo el negocio y los datos. Lo que encontramos fue interesante:

• Tenían 3 años de histórico de entregas en su TMS con un nivel de detalle excelente: origen, destino, peso, volumen, hora de entrega, incidencias.
• El ERP tenía datos de pedidos con 24–48h de antelación, suficiente para alimentar un modelo predictivo.
• Había patrones de estacionalidad muy claros (día de la semana, semana del mes, festivos) que el equipo de planificación conocía de forma intuitiva pero no podía cuantificar.
• Las variables externas (clima, festivos locales de las zonas de destino) impactaban la demanda de forma predecible.

El problema no era la falta de datos: era que esos datos no se usaban de forma sistemática para tomar decisiones. Todo dependía del criterio y la experiencia de 2–3 personas del equipo de planificación.

La arquitectura de la solución

El proyecto se dividió en tres capas que construimos de forma secuencial:

1. 1Pipeline de datos: integración automática del TMS, ERP y datos de tráfico/clima en una base de datos centralizada. Actualización cada noche con datos del día.
2. 2Modelo de forecasting: un ensemble de series temporales (Prophet para capturar estacionalidad) y gradient boosting (XGBoost para capturar patrones de pedidos recientes). El modelo predice la demanda por zona geográfica con 72h de antelación.
3. 3Interfaz de planificación: un dashboard en Power BI donde el equipo de planificación ve las predicciones del día y los dos siguientes, puede ajustarlas manualmente si tienen información que el modelo no tiene, y registra los ajustes para mejorar el modelo en el siguiente ciclo.

Por qué elegimos este stack técnico

Python con Prophet y XGBoost para el modelo, Apache Airflow para orquestar los pipelines, PostgreSQL como almacén central y Power BI para la visualización. No es el stack más moderno del mercado, pero es robusto, el equipo interno puede entenderlo y mantenerlo, y resuelve el problema sin over-engineering.

Resultados a los 3 meses de uso

• Reducción del 23% en costes de transporte, principalmente por optimización de la ocupación de vehículos y reducción de trayectos en vacío.
• Mejora del 35% en el cumplimiento de entregas en plazo, gracias a una planificación con más antelación.
• Reducción del 18% en el sobre-stock de los almacenes de distribución.
• El proceso de planificación matutina pasó de 2–3 horas a 20–30 minutos: el modelo hace la propuesta y el equipo revisa y ajusta los casos excepcionales.

“Antes tardábamos 3 horas cada mañana en planificar rutas. Ahora el sistema nos da un plan optimizado antes de que lleguemos a la oficina.”

— Director de Operaciones, Operador logístico nacional

Qué aprendimos de este proyecto

Tres aprendizajes que aplicamos ahora a todos los proyectos de forecasting con IA:

1. 1El modelo no reemplaza al planificador: lo amplifica. El equipo de planificación tiene información que el modelo no tiene (un cliente importante tiene una urgencia, hay una huelga de transporte prevista). La interfaz de ajuste manual es tan importante como el modelo.
2. 2La calidad del histórico es más importante que la sofisticación del algoritmo. Con datos limpios y bien estructurados, un modelo relativamente sencillo supera a uno complejo entrenado con datos sucios.
3. 3El reentrenamiento continuo es imprescindible. Un modelo entrenado en enero de 2024 no captura bien los patrones de 2026. Diseñamos ciclos de reentrenamiento automático mensual desde el primer día.

Cuándo tiene sentido un proyecto de forecasting con IA

Este tipo de proyecto tiene ROI claro cuando:

• El coste de una mala previsión es alto: sobre-stock inmovilizado, roturas que generan urgencias caras, capacidad mal dimensionada.
• Tienes al menos 18–24 meses de histórico de datos con buena granularidad.
• El proceso de planificación actual depende del criterio de pocas personas, generando un riesgo de continuidad.
• El volumen de decisiones es suficientemente alto: si solo planificas 5 entregas al día, Excel es suficiente.

Qué hacía viable este caso y no solo atractivo sobre el papel

Los casos de forecasting que acaban en producción no suelen empezar por un modelo muy sofisticado. Empiezan por una pregunta concreta, un histórico usable y una decisión operativa que alguien está dispuesto a cambiar si la previsión mejora. Cuando esas tres piezas no existen, el proyecto se parece más a una demo que a una herramienta de negocio.

Qué no conviene extrapolar de un caso real

Que un caso haya funcionado no significa que cualquier empresa deba pedir exactamente lo mismo. Lo útil de un caso real es entender el patrón: qué condiciones estaban presentes, qué dependencias aparecieron y qué decisiones se desbloquearon con la previsión. Lo peligroso es copiar el entregable sin revisar si tus datos y tu operación están al mismo nivel de preparación.

Por eso conviene leer este artículo junto con los requisitos para un proyecto de predicción de demanda y con una revisión honesta de tu plataforma de datos. Si además necesitas aterrizar tiempos, este contenido sobre cuánto tarda un proyecto de datos o IA ayuda a poner expectativas realistas desde el principio.

Preguntas útiles antes de pedir algo parecido

¿Qué decisión va a mejorar si el forecast es mejor?

Si no puedes responder esto en una frase, probablemente todavía no estás pidiendo un proyecto de forecasting, sino una exploración previa.

¿Qué parte del proceso seguirá siendo humana?

Un buen forecast no elimina criterio. Lo normal es que mejore compras, reposición o planificación, pero con revisión de negocio y excepciones controladas.

¿Qué parte del trabajo estará en los datos y no en el modelo?

En la mayoría de empresas la mayor parte del esfuerzo inicial está en calidad de datos, unificación de fuentes y validación de reglas, no en elegir un algoritmo exótico.

Señales de que antes necesitas ordenar datos y proceso

Si la previsión no tiene un owner claro, si el histórico cambia según quién exporte el dato o si nadie sabe qué acción tomar cuando el forecast se desvía, todavía no estás pidiendo solo un modelo. Estás pidiendo, además, una mínima disciplina de datos y de planificación. Detectarlo antes ahorra muchas expectativas mal calibradas.

Preguntas frecuentes sobre un caso de forecasting de demanda

¿Qué parte del valor vino del modelo y cuál del dato?

En este tipo de proyectos, el valor suele repartirse. El modelo mejora la previsión, pero la base de datos, la integración y la validación con negocio son las que permiten que esa previsión se use de verdad.

¿Cuándo conviene empezar por discovery y no por build?

Cuando todavía no está clara la unidad de decisión, el histórico no es fiable o el equipo no ha acordado qué acción tomar con la predicción. Ahí conviene ordenar primero y construir después.

¿Qué siguiente paso tiene más sentido si quiero algo parecido?

Lo normal es revisar primero los requisitos para predicción de demanda, el estado de la plataforma de datos y, si ya quieres bajar a alcance, cómo encajaría dentro de un proyecto de análisis de datos.