Forecasting demanda: Python vs no-code

Cuando una empresa decide mejorar sus predicciones de demanda, una de las primeras preguntas que aparece es: ¿necesitamos programar modelos en Python o podemos resolverlo con herramientas que no requieran código?

La respuesta rápida es que ambas opciones son válidas, pero no para los mismos escenarios. El problema no es cuál es mejor en abstracto, sino cuál encaja con tus datos, tu equipo y la complejidad de lo que intentas predecir.

Cuándo tiene sentido usar código y cuándo no

Antes de entrar en herramientas concretas, conviene establecer los criterios que deberían guiar la decisión.

El código (Python, principalmente) tiene sentido cuando:

• Necesitas personalización profunda: feature engineering a medida, variables exógenas específicas de tu negocio, lógica de negocio integrada en el pipeline.
• Gestionas muchas series simultáneamente: cientos o miles de SKUs, tiendas o categorías.
• El modelo debe integrarse en un pipeline automatizado: producción con actualizaciones periódicas, conexión con otros sistemas.
• Tu equipo tiene (o puede acceder a) perfiles técnicos con experiencia en Python y machine learning.
• Necesitas reproducibilidad y versionado: control sobre exactamente qué modelo se ha ejecutado, con qué datos y qué parámetros.

Las herramientas no-code tienen sentido cuando:

• El caso de uso es relativamente sencillo: pocas series, estacionalidad clara, pocas variables externas.
• El equipo que necesita el forecast es de negocio, no técnico.
• Necesitas resultados rápidos sin montar infraestructura.
• El presupuesto o el tiempo no permiten un proyecto de desarrollo a medida.
• La predicción es un complemento del análisis, no el centro de una operación crítica.

El ecosistema Python para forecasting

Python es el estándar de facto para forecasting por una razón: tiene un ecosistema de librerías maduro, documentado y con comunidad activa. Estas son las herramientas más relevantes.

Prophet (Meta)

Prophet es una librería de Meta diseñada para series temporales con estacionalidad fuerte y datos faltantes. Su punto fuerte es la simplicidad: con pocas líneas de código obtienes un modelo que maneja tendencia, estacionalidad semanal y anual, y efectos de festivos. Es una buena opción para empezar y como baseline.

Limitaciones: no es el más preciso para series complejas con muchas variables exógenas, y su rendimiento puede quedarse corto frente a modelos de gradient boosting o deep learning en escenarios de alta dimensionalidad.

statsmodels (ARIMA, SARIMAX, ETS)

La librería clásica para modelos estadísticos de series temporales. ARIMA y SARIMAX son robustos para series con tendencia y estacionalidad cuando se configuran bien. ETS (Exponential Smoothing) es otra opción sólida para patrones regulares. Requieren más conocimiento técnico para elegir parámetros, pero son interpretables y están muy probados.

scikit-learn y gradient boosting (LightGBM, XGBoost)

Para forecasting con muchas variables exógenas (precio, promociones, meteorología, indicadores económicos), los modelos de gradient boosting suelen dar los mejores resultados. La idea es transformar el problema de serie temporal en un problema de regresión supervisada con features temporales (lag, rolling mean, día de la semana). LightGBM es el más usado en competiciones de forecasting por su velocidad y rendimiento.

NeuralProphet y modelos de deep learning

NeuralProphet es la evolución de Prophet con redes neuronales bajo el capó. Para series más complejas, modelos como N-BEATS, N-HiTS o Temporal Fusion Transformer (disponibles en librerías como Darts o NeuralForecast) ofrecen resultados competitivos, pero requieren más datos y más infraestructura para entrenar.

Herramientas no-code para forecasting

El mundo no-code ha avanzado mucho y ya hay opciones que permiten hacer predicciones razonables sin escribir una línea de código.

Power BI (función de forecast nativa)

Power BI incluye una funcionalidad de forecast integrada en los gráficos de línea. Usa modelos de suavizado exponencial y permite configurar el intervalo de confianza y la longitud de la predicción. Es útil para exploraciones rápidas y para añadir una capa predictiva a dashboards existentes, pero no permite personalizar el modelo ni incluir variables exógenas.

Excel avanzado

Excel tiene la función FORECAST.ETS que aplica suavizado exponencial triple (Holt-Winters). Para series con estacionalidad regular y pocas complicaciones, puede dar resultados decentes. Su limitación principal es la escalabilidad: no está pensado para cientos de series, no se automatiza fácilmente y no conecta con pipelines de datos.

Plataformas SaaS dedicadas

Herramientas como Forecast Pro, Anaplan, Oracle Demand Management o incluso módulos de forecasting dentro de ERPs ofrecen interfaces visuales con modelos preconfigurados. Su ventaja es la integración con procesos de negocio (compras, planificación) y la facilidad de uso. Su limitación: menor flexibilidad, costes de licencia más altos y dependencia del proveedor.

AutoML no-code (BigQuery ML, Azure AutoML)

Las plataformas cloud ofrecen servicios de AutoML que permiten crear modelos de forecasting sin programar. BigQuery ML permite entrenar modelos con SQL. Azure AutoML ofrece un entorno visual. Son un punto intermedio interesante: más potentes que las herramientas de BI pero sin necesidad de Python.

Comparativa directa: código vs no-code

Marco de decisión: cómo elegir

Para no quedarte atascado en la comparativa teórica, aquí va un marco de decisión práctico basado en cuatro preguntas.

1. 1¿Cuántas series necesitas predecir? Si son menos de 10-20, el no-code puede ser suficiente. Si son cientos o miles, Python (con LightGBM o similar) es más práctico.
2. 2¿Necesitas incluir variables externas (precio, promociones, meteorología)? Si la respuesta es sí, necesitas código o AutoML cloud. Las herramientas de BI estándar no lo soportan.
3. 3¿El forecast debe actualizarse automáticamente? Si va a funcionar en producción con actualizaciones diarias o semanales, necesitas un pipeline programático. Las herramientas no-code no están diseñadas para eso.
4. 4¿Quién va a mantener el modelo? Si es un equipo de negocio sin soporte técnico, el no-code reduce la dependencia. Si hay perfil técnico, el código da más control y mejores resultados a largo plazo.

El enfoque híbrido: lo mejor de los dos mundos

En la práctica, muchas empresas acaban con un enfoque híbrido. Python para el desarrollo del modelo, la ingeniería de features y el entrenamiento. Herramientas no-code para la visualización, la entrega de resultados a negocio y el seguimiento del rendimiento.

Un flujo típico es:

1. 1Los datos se procesan y almacenan en un data warehouse (BigQuery, Snowflake, PostgreSQL).
2. 2Un pipeline de Python (orquestado con Airflow, Prefect o n8n) entrena el modelo periódicamente y escribe las predicciones en el warehouse.
3. 3Power BI o Looker conecta con el warehouse y presenta las predicciones en un dashboard accesible para el equipo de negocio.
4. 4El equipo de negocio revisa las predicciones, ajusta planes de compra o producción y reporta desviaciones que alimentan la mejora del modelo.

Este enfoque requiere una infraestructura de datos mínima que conecte las piezas. Es exactamente lo que abordamos en nuestra plataforma de datos: diseñar la capa que alimenta los modelos con datos fiables y actualizados.

Qué infraestructura de datos necesitas según el enfoque

La herramienta de forecasting no funciona en el vacío. Necesita datos limpios, actualizados y accesibles. Y el nivel de infraestructura necesario varía según el enfoque.

Para el enfoque no-code, lo mínimo es un origen de datos fiable (una tabla en un warehouse, una exportación limpia del ERP) y una herramienta de visualización que pueda conectar con él. Power BI con una conexión a BigQuery o PostgreSQL cubre la mayoría de casos sencillos.

Para el enfoque con Python, necesitas además un entorno de ejecución (puede ser tan simple como un notebook en Google Colab o tan robusto como un servidor con Airflow), un sistema de versionado del código (Git) y un lugar donde persistir las predicciones para que negocio pueda consumirlas. Si el modelo se ejecuta periódicamente, necesitas orquestación: algo que lance el pipeline cada día o cada semana sin intervención manual.

Para el enfoque híbrido, necesitas las piezas de ambos mundos conectadas. El warehouse como punto central donde convergen datos brutos, datos transformados y predicciones. Esto es precisamente lo que una plataforma de datos bien diseñada resuelve.

Errores comunes en proyectos de forecasting

Independientemente de la herramienta que elijas, hay errores que se repiten en los proyectos de predicción de demanda.

• No tener un baseline claro. Si no sabes cuánto error tiene tu estimación actual (manual o por intuición), no puedes medir si el modelo mejora algo.
• Sobreajustar el modelo al histórico. Un modelo que predice perfectamente el pasado pero falla en datos nuevos no aporta valor. La validación con datos fuera de muestra es obligatoria.
• Ignorar la calidad de los datos de entrada. Si el histórico de ventas tiene errores, huecos o cambios de criterio no documentados, el modelo va a heredar ese ruido.
• No incluir el contexto de negocio. Promociones, apertura de nuevas tiendas, cambios de precio: si no están en los datos, el modelo no puede tenerlos en cuenta.
• Elegir la herramienta equivocada para el problema. Usar deep learning para 50 datos mensuales o usar Excel para 5.000 SKUs.

Si quieres profundizar en cómo medir si tu modelo funciona, tenemos una guía dedicada sobre cómo medir el error de un forecast.

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

Preguntas frecuentes

¿Python es gratis para uso comercial?

Sí. Python y todas las librerías mencionadas (Prophet, statsmodels, scikit-learn, LightGBM) son open source y gratuitas. El coste está en el equipo que las usa y en la infraestructura de cómputo (servidores, cloud), no en las licencias.

¿Puedo pasar de no-code a Python más adelante?

Sí, y es un camino habitual. Muchas empresas empiezan con Power BI o Excel para validar que el forecasting aporta valor, y después migran a Python cuando necesitan más precisión, más series o automatización. Lo importante es que la infraestructura de datos permita esa transición sin reconstruir todo.

¿Qué pasa si mis datos tienen muchos huecos o irregularidades?

Los datos imperfectos son la norma, no la excepción. Prophet maneja bien los datos faltantes. Statsmodels requiere series más completas. Los modelos de gradient boosting toleran huecos si se diseñan las features correctamente. Pero si los huecos son masivos (más del 30-40 % del histórico), el primer paso es resolver la calidad de datos antes de intentar predecir. Lo abordamos en requisitos para predicción de demanda.