Forecasting de demanda con IA: ejemplo aplicado

En el escenario de partida, cada mañana a las 6:30 h el equipo de planificación abre su hoja de Excel y distribuye las rutas del día. Consulta el histórico reciente y al equipo comercial antes de tomar decisiones sobre 120 rutas y más de 80 conductores. Se supone un proceso manual de entre 2 y 3 horas para poder definir un baseline medible.

El supuesto de negocio incluye picos de demanda mal anticipados, sobrestock en unos almacenes y roturas en otros. Un crecimiento anual del 8% en coste de transporte se usa como señal hipotética que habría que validar con datos reales antes de justificar una inversión.

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

Antes de proponer una solución, el discovery debería dedicar dos semanas a entender el negocio y validar estos supuestos sobre los datos:

• Se presupone un histórico de 3 años de entregas en el TMS con origen, destino, peso, volumen, hora de entrega e incidencias.
• Se presupone que el ERP aporta pedidos con 24–48 h de antelación, una condición que habría que comprobar antes de modelar.
• El escenario incluye patrones de estacionalidad por día de la semana, semana del mes y festivos que el equipo conoce de forma intuitiva pero todavía no ha cuantificado.
• También se plantea como hipótesis que clima y festivos locales aportan señal predictiva; su utilidad se validaría con un backtest.

La hipótesis no es falta de datos, sino falta de uso sistemático para decidir. El escenario presupone que la planificación depende del criterio de 2–3 personas; el discovery tendría que confirmar esa dependencia y su impacto.

La arquitectura de la solución

La solución se puede dividir en tres capas y validar 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é encajaría 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.

Objetivos que habría que medir a los 3 meses

• Hipótesis de reducción del 23% en costes de transporte mediante mayor ocupación de vehículos y menos trayectos en vacío.
• Hipótesis de mejora del 35% en entregas en plazo gracias a una planificación con más antelación.
• Hipótesis de reducción del 18% en el sobrestock de los almacenes de distribución.
• Objetivo de reducir la planificación matutina de 2–3 horas a 20–30 minutos, manteniendo revisión humana de los casos excepcionales.

Qué enseña este escenario

Tres principios que conviene aplicar a 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 con un periodo antiguo puede no capturar los patrones actuales. La cadencia debe definirse según el drift observado, no por una fecha fija universal.

En proyectos reales de datos he visto muchas veces la otra cara de esta idea: un pipeline que se ejecuta sin errores no significa que el resultado sea correcto. Antes de confiar en cualquier forecast conviene comprobar volumen, consistencia y valores del histórico con el mismo rigor con que se validaría cualquier transformación de datos, no solo mirar si el proceso terminó sin fallos.

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é haría viable este escenario 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 este escenario

Un escenario ilustrativo no demuestra que la misma solución vaya a funcionar en cualquier empresa. Su utilidad es hacer explícitas las condiciones, dependencias y decisiones que habría que validar. Lo peligroso es copiar el entregable o sus porcentajes sin revisar el baseline, los datos y la operación propios.

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.

Si te interesa profundizar, en ia en logística en 2026: casos de uso reales exploramos este tema en detalle.

Para más contexto, puedes consultar la artículo de McKinsey sobre forecasting con IA.

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.