Data & ML
Caso de estudioPronóstico de demanda retail
El área de compras operaba en reacción. Los SKUs A se rompían. Los lentos inmovilizaban capital. Cada stockout era una venta que no volvía.
-27% stockouts
en SKUs clase A, sin inflar cobertura de inventario
- #Forecasting
- #SQL
- #Python
- #Retail
El pronóstico solo sirve si entra en la rutina de quien pide mercadería. Por eso el output no fue un notebook: fue una serie por SKU-tienda-semana que el dashboard de compras ya sabía leer.
El SQL armó la grilla temporal. Encima, un baseline estacional y un boosting con features de calendario y promociones. El backtesting fue rolling de 12 semanas, no un split aleatorio que filtra el futuro.
La métrica que importaba era quiebre en clase A, no el MAE promedio. Los SKUs jóvenes y los cambios de surtido quedaron fuera de alcance, por escrito.
- Problema
- Compras reactivas: quiebres en productos A y capital inmovilizado en categorías lentas. Cada stockout era venta perdida.
- Solución & pipeline
- Agregaciones SQL por SKU-tienda-semana, features de calendario y promociones, baseline estacional + gradient boosting y backtesting rolling de 12 semanas exportado a dashboard de compras.
- Límite / alcance
- La performance se degrada en SKUs con menos de 12 meses de historia o con quiebres estructurales de surtido. No modela transferencias entre sucursales.
SQL
WITH weekly AS (
SELECT store_id, sku_id,
DATE_TRUNC('week', sale_date) AS week,
SUM(units) AS units
FROM sales
GROUP BY 1, 2, 3
)
SELECT *
FROM weekly
WHERE week >= CURRENT_DATE - INTERVAL '18 months';