El problema real no es el stock — es la información
Un retailer de artículos deportivos en Guadalajara con cuatro sucursales llega a fin de temporada con 40% del inventario de chamarras sin vender, mientras en diciembre tuvo quiebres de stock en tallas M y L por tres semanas seguidas. Compró bien en volumen, pero compró mal en mezcla.
Ese patrón —sobreinventario en unos SKUs, quiebre en otros— es el síntoma más costoso del retail local y casi siempre tiene la misma causa: las decisiones de compra se basan en intuición y en el histórico del año anterior visto en una hoja de Excel, sin considerar estacionalidad granular, tendencias de venta por canal ni velocidad de rotación por tienda.
La predicción de demanda con IA no resuelve el problema con magia. Resuelve el problema procesando más variables, con más consistencia, de la que un comprador puede hacer manualmente cada semana.
Qué hace realmente un modelo de predicción de demanda
En términos operativos, un modelo de predicción toma el historial de ventas por SKU, lo descompone en tendencia, estacionalidad y ruido, y proyecta cuántas unidades probablemente se venderán en el próximo período (semana, quincena, mes). Los modelos más usados en retail son:
- Series de tiempo clásicas (Prophet, SARIMA): funcionan bien con historial limpio de 12+ meses. Baratos de entrenar, interpretables.
- Gradient boosting (XGBoost, LightGBM): permiten añadir variables externas como precio, promociones, clima o día festivo. Más potentes, requieren más datos y más trabajo de ingeniería.
- Redes neuronales recurrentes (LSTM): útiles para demanda muy volátil o muchos SKUs interdependientes. Generalmente innecesario para retailers medianos.
El criterio que usamos en Eurema para decidir qué tipo de modelo proponer es simple: si el cliente tiene menos de 500 SKUs activos y datos en Excel, empezamos con Prophet o un modelo de suavizamiento exponencial. Si tiene POS integrado con más de dos años de transacciones y quiere incorporar variables de precio o marketing, subimos a gradient boosting. No se propone complejidad que no se justifique con el volumen de datos disponible.
Datos: el cuello de botella que nadie menciona en los demos
Antes de hablar de modelos, hay que hablar de datos. El 70–80% del tiempo en un proyecto de predicción de demanda para retail local en LatAm se va en esto:
- Exportar y consolidar: ventas por sucursal en archivos separados, con columnas distintas, fechas en formatos distintos.
- Limpiar: días sin venta vs días cerrados (no es lo mismo para el modelo), devoluciones que aparecen como ventas negativas, SKUs duplicados con nombres distintos.
- Etiquetar eventos: Buen Fin, quincenas, aperturas de tienda nueva, desabasto de proveedor. Sin estas etiquetas, el modelo aprende los picos como si fueran tendencia real.
Un retailer que lleva sus ventas en Bind o en Microsip puede exportar todo lo necesario. El problema no es el sistema — es que nadie ha definido un proceso para que los datos sean consistentes semana a semana. Eso hay que resolverlo antes de entrenar cualquier modelo.
En proyectos de Análisis de datos con clientes de retail, lo que vemos frecuentemente es que la primera entrega de valor no es el modelo predictivo — es el dashboard de diagnóstico que muestra, por primera vez, cuáles SKUs tienen datos suficientes para predecir y cuáles no.
Métricas que importan antes de implementar
No todo SKU merece un modelo de predicción. Una forma práctica de priorizar:
| Criterio | Candidato para predicción | No candidato |
|---|---|---|
| Historial de ventas | 12+ meses continuo | Menos de 6 meses o muy irregular |
| Frecuencia de venta | Venta semanal o más frecuente | Venta esporádica (1–2 veces/mes) |
| Impacto financiero | SKU de alto volumen o margen | SKU de cola larga con bajo peso |
| Variabilidad | Demanda con patrón estacional claro | Demanda aleatoria sin patrón |
Un retail mediano en LatAm suele tener 20–30% de sus SKUs con datos suficientes para predecir con confianza. El resto se maneja con reglas simples: mínimos de seguridad, reorden automático por punto de quiebre, o criterio del comprador.
Concentrar el modelo en el 20–30% de SKUs de alto impacto ya captura la mayor parte del valor. No es necesario predecir todo el catálogo para reducir quiebres y sobreinventario de forma medible.
Integración con el proceso de compra: el paso que se salta
El error más común en implementaciones de predicción de demanda es entregar el modelo al equipo de TI y asumir que el comprador lo va a usar. No funciona así.
El modelo tiene que integrarse en el flujo de trabajo del comprador: en el momento en que revisa el inventario y decide la orden. Eso puede ser tan simple como una hoja de Google Sheets que se actualiza automáticamente con las predicciones de la semana, o tan integrado como un módulo dentro del ERP. Lo que importa es que la predicción llegue en el formato que el comprador ya usa, no que el comprador cambie su proceso para buscar el modelo.
Lo que estamos viendo en Eurema con retailers de entre 3 y 15 sucursales es que la adopción sube significativamente cuando la predicción se presenta como “sugerencia de compra” con un rango de confianza, no como un número exacto. El comprador mantiene criterio y ajusta; el modelo reduce el tiempo que tarda en llegar a ese ajuste.
Si tu operación ya tiene un proceso de reorden, el siguiente paso no es reemplazarlo — es añadir una capa de predicción que lo alimente. Para entender cómo se conecta eso con el stack tecnológico de tu empresa, la página de Análisis de datos describe cómo trabajamos ese proceso de integración.
Por dónde empezar sin invertir en infraestructura nueva
Si quieres evaluar si la predicción de demanda tiene sentido para tu operación antes de comprometer presupuesto, el ejercicio más útil es este:
- Exporta 18 meses de ventas por SKU y por tienda en cualquier formato.
- Identifica tus 50 SKUs de mayor facturación — son los que concentran el riesgo de quiebre y el capital inmovilizado.
- Calcula manualmente tu MAPE actual: toma tus órdenes de compra del último trimestre, compáralas con la venta real, y mide el error promedio. Si tu error supera el 25–30%, hay margen claro para que un modelo mejore.
- Define un ciclo de prueba de 8 semanas con esos 50 SKUs: modelo simple, comparación contra el método actual, decisión basada en datos.
Ese proceso no requiere ERP nuevo, no requiere data warehouse, no requiere contratar un data scientist de tiempo completo. Requiere datos ordenados y un ciclo de compra completo para medir.
Si el error baja y el capital inmovilizado en sobreinventario disminuye, tienes el caso de negocio para escalar. Si no, sabes exactamente por qué y dónde está el límite real del modelo para tu operación.