Stockout prediction con recuperación de lost sales

Grow2.ai despliega un stockout-prediction pipeline que lee datos del data warehouse y predice cuándo cada SKU entrará en déficit. El modelo tiene en cuenta el historial de ventas, la estacionalidad y el inventario actual, y cuando la probabilidad de stockout supera el umbral, envía una alerta a los canales de trabajo del equipo de compras.

Qué hace la automatización

1. Recopila datos del data warehouse: historial de pedidos, inventario actual por SKU, parámetros de suministro (lead time, MOQ).
2. Calcula la previsión de consumo para cada SKU en el horizonte hasta la fecha de la próxima entrega.
3. Compara el consumo previsto con el inventario y calcula la probabilidad de stockout antes de la llegada del reaprovisionamiento.
4. Envía una alerta estructurada al canal de communications: categoría, SKU, inventario, fecha prevista de out-of-stock, volumen de pedido recomendado.
5. Registra el hecho de la alerta y la decisión del equipo para ajustar los umbrales y mejorar el modelo con el tiempo.
6. Paralelamente, identifica SKU con exceso de inventario donde conviene reducir la compra.

Qué NO hace la automatización

• No coloca pedidos a proveedores automáticamente — la decisión final de compra corresponde al buyer.
• No reemplaza al ERP ni al WMS como fuente de verdad sobre el inventario; el pipeline lee datos, pero no escribe en los sistemas de almacén.
• No garantiza una precisión del 100%: los eventos poco frecuentes (ventas virales, fallos del proveedor, cambios bruscos de demanda) requieren corrección manual.

El objetivo principal es desplazar la decisión de compra de «el producto se agotó» a «el producto se agotará en N días». En el e-commerce citado, esto redujo los stockouts de 47 a 8 por trimestre (-83%), recuperó £18,000 en ventas perdidas y redujo el exceso de inventario en £43,000.

La solución es adecuada para e-commerce y retail con un catálogo de cientos de SKU activos e historial de ventas de al menos 6 meses. Cuanto más limpios sean los datos en el data warehouse, más precisa será la previsión; una configuración básica con granularidad diaria produce un efecto notable en 2-3 ciclos de pedido.

Técnicamente la solución es un pipeline en custom-code (habitualmente Python), que se conecta al data warehouse, calcula el pronóstico por cada SKU y envía alertas al canal de comunicaciones. El despliegue toma varias semanas con los datos listos.

Flujo principal

1. Extract diario.El scheduler (cron, Airflow o motor de workflow) lanza el pipeline por la mañana antes del inicio del turno del equipo de compras. El script realiza consultas al data warehouse y extrae las ventas del período relevante, el inventario actual y el directorio de SKU.
2. Feature engineering. Se calculan las medias móviles de ventas por SKU, la estacionalidad semanal y anual, la tendencia y la velocidad de rotación. Se tiene en cuenta el lead time del proveedor — desde el momento del pedido hasta la llegada del producto al almacén.
3. Modelo de pronóstico. Para cada SKU se calcula el consumo esperado en el horizonte hasta la próxima entrega posible. En la versión básica se utilizan métodos estadísticos (exponential smoothing, Prophet); en la avanzada — gradient boosting con consideración de factores externos (promociones, festivos).
4. Stockout score. En base al pronóstico y al inventario actual se calcula la probabilidad de out-of-stock hasta la llegada de la siguiente entrega y el volumen de pedido recomendado.
5. Filtro y priorización. Los SKU con alta probabilidad de stockout y margen o rotación significativos se incluyen en la alerta. Los demás se registran sin notificaciones para no generar ruido.
6. Notificación. La alerta se envía al canal de comunicaciones con la lista de SKU, los motivos, la recomendación y el plazo para la resolución.
7. Feedback loop. Las decisiones del comprador (ordenó / pospuso / ignoró) se registran y se utilizan para la calibración de umbrales y la recalibración del modelo.

Componentes de la solución

Orden de implementación

1. Auditoría de datos en el data warehouse: integridad del historial de ventas, sincronización del inventario, directorio de SKU.
2. Desarrollo del modelo baseline sobre una muestra de SKU (categoría A por rotación) con retrovalidación sobre datos históricos.
3. Configuración del pipeline y del scheduler, extracción de parámetros (umbrales, horizonte, lead time) al config.
4. Integración con el canal de comunicaciones y acuerdo del formato de alerta con el equipo de compras.
5. Piloto 2-3 semanas: comparación de pronósticos con la realidad, calibración de umbrales, retroalimentación de los compradores.
6. Escalado a todo el catálogo y consolidación del feedback loop para la mejora continua.

El modelo no reemplaza la planificación — le da al equipo visión anticipada del riesgo de déficit y datos para la toma de decisiones. La precisión del pronóstico depende de la calidad de los datos de entrada: con inventarios sucios o un history corto, el efecto será menor.

Para ejecutar stockout prediction, Grow2.ai requiere datos preparados y disponibilidad del equipo para trabajar con el pronóstico, y no con informes post-factum.

Datos y accesos

• Data warehouse o capa BI con historial de ventas mínimo 6 meses (preferiblemente 12+ para la estacionalidad anual).
• Stock actual por SKU, sincronizados con el warehouse o ERP no menos de una vez al día.
• Catálogo de SKU con categorías, proveedores y lead time.
• Parámetros de compras: volúmenes mínimos de pedido, plazos de entrega, stock de seguridad por categorías.
• Canal de comunicaciones (Slack, email o Telegram) para el envío de alertas con acceso a la API.

Preparación del equipo

• El responsable del proceso de compras toma decisiones sobre alertas y da retroalimentación al modelo.
• Tech lead o analista para configurar el pipeline y trabajar con el warehouse.
• Formato acordado de alerta y SLA de respuesta (por ejemplo: alert llega por la mañana — decisión antes del fin del día).
• Política de actuación ante falso positivo / falso negativo: quién y cómo actualiza los umbrales.

Plazos

Para la variante simple con datos limpios, la implementación lleva 2-4 semanas:

1. Semana 1: auditoría de datos, modelo baseline, retro-validación.
2. Semana 2: pipeline, scheduler, integración con comunicaciones.
3. Semana 3-4: piloto, calibración de umbrales, escalado al catálogo.

Si el historial de ventas está fragmentado, los stocks no están sincronizados o hay que cubrir decenas de miles de SKU con cola larga — los plazos crecen hasta 6-10 semanas y la solución pasa a la categoría medium.