¿Estás comprando en agosto con los datos de julio?
Hay un error que se repite cada año en distribuidoras de alimentación y bebidas, y casi nadie lo detecta hasta septiembre: comprar en agosto como si aún fuera julio.
No es un error de criterio. Es un error de sistema. Tu ERP mira hacia atrás, ve tres o cuatro semanas de ventas altísimas, y te propone reponer al mismo ritmo. El problema es que el pico ya pasó. La demanda ha empezado a desacelerarse mientras tu propuesta de compra sigue acelerando.
El resultado lo conoces: llegas a septiembre con almacén lleno, caducidades apretadas, tesorería tocada y una campaña de promociones improvisada para sacar producto que nunca deberías haber comprado.
Este artículo va de por qué pasa esto, en qué categorías duele más, y cómo la previsión de demanda estacional con inteligencia artificial corrige el problema antes de que se convierta en stock.
¿Por qué agosto es el mes más delicado para planificar compras?
Porque agosto no es un mes. Son tres microperiodos distintos con comportamientos opuestos, y la mayoría de sistemas los tratan como si fueran uno solo.
Semana 1–2: todavía hay pico. Turismo en máximo, consumo fuera del hogar alto, rotación fuerte.
Semana 3: empieza la inflexión. Se vacían zonas urbanas, cambian los canales.
Semana 4: la demanda ya está girando hacia septiembre. Vuelta al cole, recuperación del consumo en hogar, caída del canal terraza.
El problema es que la mayoría de motores de compra trabajan con medias móviles de las últimas 4, 8 o 12 semanas. Cuando llega la semana 3 de agosto, esa media está dominada por julio y por las dos primeras semanas de agosto: los dos periodos de mayor consumo del año. El sistema no ve un punto de inflexión. Ve una tendencia al alza y actúa en consecuencia.
A eso se suma un factor operativo que agrava todo: en agosto los lead times se alargan. Proveedores con plantilla reducida, transportistas de vacaciones, fábricas paradas. Y cuando el lead time sube, el sistema calcula un punto de pedido más alto y te pide comprar más. Justo cuando deberías estar comprando menos.
Demanda que baja + lead time que sube = la tormenta perfecta para sobrecomprar.
¿En qué categorías se nota más este desfase?
No todas las familias sufren igual. Estas son las cinco donde el error de agosto se paga más caro:
Categoría | Qué pasa en agosto | Riesgo si compras con histórico |
|---|---|---|
Bebidas (refrescos, cerveza, agua) | Pico en las dos primeras semanas, caída brusca en la última | Sobrestock de palés enteros con rotación que se desploma en septiembre |
Helados y congelados de temporada | La demanda es hipersensible a la temperatura: una semana fresca lo cambia todo | Ocupación de cámara de frío (el metro cuadrado más caro del almacén) |
Producto de terraza (aperitivo, snacks, vermut, tónicas) | Depende del canal HORECA, que cierra escalonadamente | Stock atado a un canal que literalmente baja la persiana |
Zonas turísticas | El comportamiento no es nacional, es local: costa y ciudad van en direcciones opuestas | Reparto de stock entre almacenes basado en la media, no en la realidad de cada zona |
Alimentación estacional (fruta, ensaladas, gazpacho, productos frescos) | Vida útil corta y transición de campaña agrícola | Merma directa: producto que caduca antes de venderse |
Fíjate en el patrón: en las cinco, el error no es comprar mal un SKU. Es aplicar el mismo criterio a familias que se comportan de forma radicalmente distinta.
Un ejemplo sencillo. Imagina una distribuidora con almacén en Barcelona y almacén en Costa Brava. En agosto, el primero pierde consumo (la ciudad se vacía) y el segundo lo gana (llega el turismo). Si tu sistema calcula la previsión a nivel nacional y luego la reparte por almacén con un porcentaje fijo, estás haciendo exactamente lo contrario de lo que necesitas: mandando producto a donde no hay demanda y quedándote corto donde sí la hay.
Y esto no es un caso extremo. Es lo que le pasa a la mayoría de distribuidoras multi-almacén o con dispersión de clientes cada verano.
¿Por qué tu ERP te propone comprar de más en agosto?
Un motor de compras clásico (MRP tradicional) funciona con una lógica que se puede resumir así:
Calcula el consumo medio de las últimas N semanas.
Multiplícalo por el lead time del proveedor.
Suma un stock de seguridad, casi siempre fijo (días de cobertura o un porcentaje).
Resta el stock disponible y las compras en tránsito.
Propón la diferencia, ajustada al mínimo de pedido del proveedor.
Es una lógica razonable, robusta y que funciona bien... en meses estables.
Estas son las tres limitaciones estructurales:
1. Asume que el futuro se parece a la media del pasado reciente. Es una hipótesis válida el 70% del año. En puntos de inflexión estacional es exactamente la hipótesis equivocada.
2. No distingue estacionalidad de tendencia. Para el sistema, que vendieras un 40% más en julio es "más demanda". No sabe que es "más demanda porque es julio". Y por tanto no sabe que en tres semanas ese efecto desaparece.
3. No incorpora ninguna variable externa. El calendario, el clima, la ocupación hotelera, los festivos locales, el calendario de vuelta al cole, las promociones del canal... nada de eso entra en el cálculo. Y todo eso es precisamente lo que mueve la demanda en verano.
Y hay un cuarto punto, más humano y muy importante: en agosto tu equipo de compras está de vacaciones o cubriendo a quien lo está. La persona que normalmente corregiría a mano la propuesta del sistema, porque lleva quince años y "sabe" que la semana del 20 cae, no está. Se lanza la propuesta tal cual sale.
Esa dependencia de una sola persona con criterio es, en la práctica, el verdadero sistema de previsión de muchas distribuidoras. Y en agosto, ese sistema está en la playa.
¿Qué es la previsión de demanda estacional con IA y cómo funciona?
La previsión de demanda estacional es el cálculo de la demanda futura separando qué parte del comportamiento se explica por el momento del año y qué parte por la evolución real del negocio. Suena a matiz. No lo es: es la diferencia entre comprar para el pico que ya pasó o para la demanda que viene.
Un motor de previsión con inteligencia artificial descompone el histórico en tres componentes y añade un cuarto que el ERP no tiene:
Tendencia
La dirección de fondo del producto, limpia de ruido estacional. ¿Este SKU está creciendo de verdad o solo está en su mes bueno? Sin esta separación, cada verano parece un éxito comercial y cada septiembre parece una crisis.
Estacionalidad
Los patrones que se repiten con periodicidad conocida: anual (verano), mensual, semanal (el patrón lunes-viernes de una distribuidora HORECA no se parece en nada al de una que sirve retail) e incluso el efecto de festivos móviles.
Eventos y ruido
Promociones pasadas, roturas de stock (crítico: una venta que no ocurrió porque no había producto no es demanda baja, es demanda perdida, y un histórico sin corregir la aprende como si fuera real), aperturas de clientes, pedidos puntuales atípicos.
Variables externas
Lo que ningún ERP mira: temperatura y previsión meteorológica, calendario escolar y laboral por comunidad autónoma, festivos locales, indicadores de ocupación turística en zonas de costa, precios y actividad promocional del canal.
Con eso, el modelo no responde "cuánto vendiste", sino "cuánto vas a vender, con qué nivel de incertidumbre, y en qué almacén".
Y ese último punto, la incertidumbre, es el que más cambia las decisiones. Un buen modelo no te da un número, te da una distribución. Sabe que un helado en agosto tiene una varianza altísima (depende del clima) y que una conserva la tiene baja. Con esa información, el stock de seguridad deja de ser un parámetro fijo que alguien puso hace cuatro años y pasa a ser un cálculo por SKU, por almacén y por semana.
En Valerdat esta es la base de nuestro motor de planificación de la demanda: modelos propios que combinan histórico, estacionalidad y variables externas, y que se recalculan de forma continua en lugar de una vez al mes.
¿Cómo se traduce eso en una propuesta de compra distinta?
Esta es la parte que importa de verdad. Un forecast que no cambia una orden de compra no sirve para nada.
Estas son las cuatro decisiones que cambian cuando la previsión incorpora estacionalidad:
1. Cobertura dinámica en lugar de días fijos. En vez de "cubrir 21 días" todo el año, el objetivo de cobertura se ajusta a la demanda esperada de esas próximas semanas concretas. En la semana 33, cubrir 21 días de julio significa comprar para una demanda que no va a existir.
2. Punto de pedido que anticipa la caída, no que la persigue. Si el modelo prevé que la demanda de una familia baja un 30% a partir de la semana 34, el punto de pedido baja antes, no después de que el consumo se haya desplomado.
3. Gestión de caducidades integrada (FEFO real). En alimentación esto no es opcional. Comprar de más un producto con 45 días de vida útil en la última semana de agosto no es un problema de stock: es una merma anunciada. El sistema debe cruzar la previsión con la vida útil restante antes de proponer la compra, no después.
4. Decisión consciente sobre el mínimo de pedido. Muchos sobrestocks de agosto no vienen del cálculo, vienen del MOQ del proveedor: "necesito 800 unidades pero el palé son 1.200". Con una previsión fiable puedes valorar ese salto con números, cuánto tardas en vender las 400 extra, cuánto cuesta financiarlas, si llegan a caducidad, en lugar de aceptarlo por defecto.
Y por encima de todo esto: automatización. Nuestra suite de agentes de compras revisa las propuestas de forma continua y alerta de las excepciones, para que en agosto, con medio equipo fuera, alguien siga vigilando las 500 referencias que nadie va a revisar a mano.
Conclusión
El error de agosto no es comprar mucho. Es comprar con la información de un momento que ya terminó. Tu ERP no está roto: está haciendo exactamente lo que le pediste, que es mirar el pasado. El problema es que en un punto de inflexión estacional, el pasado es la peor referencia posible.
La diferencia entre una distribuidora que llega a septiembre con el almacén ajustado y otra que llega con tres semanas de sobrestock casi nunca está en el equipo de compras. Está en si su sistema sabe distinguir entre lo que pasó y lo que va a pasar.
En Valerdat construimos esa distinción.
¿Quieres saber cuánto habrías ahorrado este agosto? Podemos hacer un backtest con tus últimos 12 meses de datos y enseñarte, referencia a referencia, la diferencia entre lo que compraste y lo que deberías haber comprado. Sin compromiso y sin integraciones.