Cómo una major europea de la energía ahorró 500K€/año con forecasting IA
De Excel basado en reglas a un Random Forest en producción · 400 variables · 92 % precisión · 12 semanas
TL;DR
- Forecast en Excel + reglas, equipo de 4 analistas dedicando 60 % de la semana a hojas de cálculo.
- Random Forest sobre 400 variables (clima, histórico, tipos de contrato, geo, festivos) → 92 % precisión vs 78 % baseline.
- Producción en 12 semanas: Python + scikit-learn, pipeline batch diario, monitoring + detección de drift.
- Resultado: −35 % de costes logísticos en piloto, 500K€ ahorros anuales extrapolados.
El contexto
Una major europea de la energía — 2M+ clientes residenciales y B2B en Francia, ~1.500 camiones, distribución de propano a granel. Mercado ultra-estacional (picos invierno × 3 vs verano), regulado, donde la supply chain es el primer driver de coste. Combustible, conductores, stocks de depósito: todo depende de un forecast fiable.
El problema
El forecast existente corría sobre Excel + 4-5 scripts Python basados en reglas. Los analistas (equipo de 4) dedicaban el 60 % del tiempo a reconstruir archivos cada semana — poco tiempo real para análisis. Tres consecuencias directas:
- Sobre-stock en zonas de baja demanda (capital inmovilizado).
- Roturas en zonas de alta demanda → entregas urgentes a 2-3× el coste estándar.
- Camiones "deadheading" (retorno vacío) por rutas construidas sobre forecasts malos.
El error de forecast costaba ~5-8 % del presupuesto logístico total. Sobre cientos de millones de euros anuales, el cálculo es rápido.
Por qué las soluciones del mercado fracasaron
Antes de mí, dos vías se habían explorado y abandonado:
- BI "forecast en un click": las herramientas SaaS ofrecen forecast time-series univariado. Sobre un producto estacional multi-zona con 400 variables exógenas, los resultados eran peores que la baseline humana.
- Deep learning: un POC interno con LSTM corrió 4 meses, llegó al 87 % de precisión, pero ningún equipo de negocio entendía las salidas. Cero adopción, proyecto archivado.
La lección: la precisión no es la métrica. Es adopción × precisión. Un modelo al 87 % que nadie usa vale menos que uno al 85 % que todo el equipo ops adopta.
El enfoque
Cuatro decisiones de arquitectura, cada una motivada por el contexto de negocio:
1.Random Forest en lugar de XGBoost o Deep Learning
RF es interpretable (feature importance directa + SHAP), robusto frente a datos faltantes (huge en el mundo real), rápido de re-entrenar (1h semanal) y rinde casi tan bien como XGBoost en datos estructurados como estos. El equipo de negocio podía debuggear un forecast en 2 minutos.
2.Forecast por zona × día, no global
El negocio razona en "depósito × día de entrega". Alinear la granularidad del modelo con la unidad de decisión operativa duplicó la adopción.
3.Pipeline batch diario, no tiempo real
La planificación logística se decide el día antes. No hace falta streaming. Cron a las 4 AM, salida al data warehouse, lectura por la herramienta de planning a las 6 AM. Simple y robusto.
4.Monitoring + drift detection desde el día 1 de prod
Distribución de features trackeada vs baseline de entrenamiento, alerta Slack si drift > 2σ. El clima cambia, los precios cambian, una pandemia rompe patrones: sin monitoring, el modelo deriva en silencio.
Implementación · 12 semanas
Semanas 1-2 · Diagnóstico & auditoría de datos
12 sistemas fuente analizados, 400+ variables identificadas (ventas, clima, contratos, geo, festivos, económico). 60 entrevistas en 2 semanas con ops, IT, finanzas, comercial. Output: 1 esquema end-to-end, 1 baseline medida en 78 %.
Semanas 3-6 · Modelo baseline & validación
Random Forest + cross-validation deslizante 12 meses. Iteración sobre 8 versiones de feature engineering. Selección final: 400 features, ensemble RF + correcciones post-hoc para festivos y picos climáticos.
Semanas 7-9 · Pipeline producción
Python + scikit-learn en AWS. Cron diario, escritura en data warehouse, retraining semanal. Tests de integración con la herramienta de planning. Documentación handoff (50 páginas) para el equipo data interno.
Semanas 10-12 · Rollout progresivo & training
10 % del volumen (3 depósitos piloto) semana 10, 50 % semana 11, 100 % semana 12. Comparación vs grupo control en cada paso. 2 bugs críticos detectados y corregidos en piloto — invisibles en synthetic tests.
Resultados medidos
Medidos sobre los primeros 6 meses en producción (vs 6 meses anteriores, misma estacionalidad):
- Precisión forecast: 78 % → 92 % (+14 pts)
- Costes logísticos: −35 % en piloto, −22 % rollout completo (efecto diluido en zonas menos forecasteables)
- Ahorros anuales: 500K€ extrapolados en pleno run
- Tiempo analista: 60 % spreadsheets → 15 % (el resto a análisis de escenarios de alto valor)
- Time-to-value: 12 semanas kickoff → primera entrega en producción
Lecciones
La interpretabilidad no es un nice-to-have
Sin ella, el equipo de negocio no confía y el modelo acaba en el cajón. RF + SHAP hicieron cada forecast "debugueable" en 2 minutos — eso llevó la adopción del 30 % al 95 %.
Los datos reales son 20 % más sucios que tu dev set
Durante el rollout encontramos: timezones inconsistentes entre 3 sistemas, contratos antiguos con campos vacíos, festivos regionales no documentados. Si testeas sólo con synthetic, descubres estos bugs en cliente.
El rollout progresivo salvó el proyecto
Los 2 bugs críticos detectados en el piloto del 10 % habrían bloqueado operaciones al 100 %. Lección: nunca lanzar al 100 % el día 1, sin importar la presión del sponsor.
El doc de handoff vale más que el modelo
6 meses después de mi marcha, el equipo data interno re-entrenó el modelo, añadió 30 features, lo extendió a 2 países nuevos. Sin las 50 páginas de handoff, el proyecto se habría estancado.
Stack técnico
¿Tienes un caso similar?
Si tienes un problema de forecasting, supply chain, clasificación o extracción donde la IA puede desbloquear un cuello de botella, hablemos. Diagnóstico gratuito 15 min, sin compromiso.