Cuando se trabaja en predicción de demanda, uno de los problemas más comunes — y más silenciosos — es el de las roturas de stock. Durante los períodos en que un producto no está disponible, las ventas caen a cero. No porque no exista demanda, sino porque el producto no se puede comprar. Si el modelo se entrena con esos datos sin corregirlos, aprende que la demanda era cero cuando en realidad era invisible.
La pregunta de negocio no es cuánto vendimos: es cuánto habríamos vendido si siempre hubiera habido stock.
Cuando trabajamos en predicción de demanda, es imprescindible analizar exhaustivamente, limpiar y corregir las series temporales antes de entrenar el modelo.
Uno de los problemas más comunes aparece cuando existen roturas de stock. Durante esos periodos las ventas caen a cero, no porque no exista demanda, sino porque el producto no está disponible.
Si no corregimos estos datos, el modelo aprenderá patrones incorrectos.
Además, tras recuperar el stock suele aparecer un segundo efecto: picos artificiales de ventas, provocados por demanda acumulada de días anteriores. Estos picos tampoco representan la demanda normal del producto y también deben corregirse.
En este artículo veremos cómo reconstruir una serie de demanda más realista mediante dos métodos de imputación diferentes, y compararemos sus resultados.
La serie temporal: qué tenemos y qué queremos corregir
Partimos de una serie temporal diaria con un histórico de un año que contiene tres componentes principales: venta con estacionalidad semanal, períodos de rotura de stock donde la venta observada es cero, y picos de rebote tras la reposición (demanda acumulada).
El gráfico de la serie muestra claramente los dos problemas: las ventas caen a cero durante las roturas y posteriormente aparecen picos de recuperación anormalmente altos. El objetivo es reconstruir una serie de demanda plausible corrigiendo ambos fenómenos.
Identificar los picos de rebote
Hay dos tipos de días que hay que corregir: los días de rotura de stock y los días de rebote posteriores.
Los primeros están identificados directamente en los datos mediante la variable de disponibilidad de stock. Los segundos deben detectarse mediante un método de detección de outliers.
Para ello se utiliza el rango intercuartílico (IQR), uno de los métodos más habituales para detectar valores atípicos. Se considera outlier cualquier valor que supere Q3 + 1.5 × IQR. En este caso solo interesan los outliers superiores, ya que los picos de rebote se manifiestan como ventas anormalmente altas.
Una nota importante: si aparecieran outliers que no se encuentran después de un período de rotura, habría que analizarlos por separado. Podrían deberse a promociones, campañas o compras extraordinarias, y no deberían corregirse de la misma forma.
Trataremos los días de rotura y los días de rebote con los mismos dos métodos de imputación y después compararemos resultados.
Método 1: imputación estadística
El primer enfoque busca una solución simple, interpretable y rápida de desplegar.
La idea consiste en separar la demanda diaria en dos componentes: la probabilidad de que ocurra demanda en ese día, y el tamaño esperado de esa demanda cuando ocurre. Formalmente: E[Demanda] = P(Demanda > 0) × E[Demanda | Demanda > 0].
Como la serie tiene estacionalidad semanal y la demanda se comporta de forma diferente en días entre semana y fines de semana, se calcula cada componente por separado para ambos grupos. El cálculo se hace exclusivamente sobre días limpios: días con stock disponible y sin outliers. Esos días son la única fuente de señal fiable.
Una vez estimados los parámetros, se simula la demanda para cada día afectado: se decide probabilísticamente si hay demanda ese día y, si la hay, se toma un valor aleatorio de la distribución histórica correspondiente (entre semana o fin de semana).
El resultado es una serie temporal corregida donde los días de rotura y los picos de rebote quedan sustituidos por valores plausibles y consistentes con el comportamiento normal del producto.
Este método permite reconstruir rápidamente una serie de demanda plausible. Sin embargo, presenta limitaciones: no incorpora tendencia, no utiliza información temporal más rica y no aprovecha la dinámica reciente de la serie. Por ello, exploramos un segundo enfoque basado en Machine Learning.
Método 2: imputación con Machine Learning
El segundo enfoque utiliza un modelo supervisado — un Random Forest Regressor — para predecir la demanda esperada en los días a corregir.
La lógica es la siguiente: entrenamos el modelo solo con días limpios, usando variables temporales y valores retardados de la propia serie (lags), y luego predecimos sobre los días afectados.
Las variables del modelo son de dos tipos. Por un lado, variables cíclicas que capturan la estacionalidad — mes y día del mes codificados en seno y coseno para que el modelo entienda que el día 31 y el día 1 son continuos. Por otro, lags de ventas: los 7 días anteriores de la serie, que permiten al modelo capturar la dinámica reciente.
Un detalle crítico: los lags se construyen sobre una copia de la serie donde los días afectados ya están marcados como nulos. Si no se hace así, los lags podrían construirse usando valores incorrectos — ceros de rotura o picos de rebote — y el modelo aprendería sobre datos que precisamente queremos corregir.
El entrenamiento se hace únicamente sobre los registros completos: días limpios con todas las variables disponibles. El Random Forest aprende los patrones temporales de la demanda normal del producto.
La imputación es iterativa y secuencial, y este punto es importante. No se pueden imputar todos los días afectados de golpe, porque cada predicción actualiza los lags de los días siguientes. Si hay tres días consecutivos de rotura, el segundo día necesita el lag del primero ya imputado, y el tercero necesita los del primero y el segundo. Saltarse este orden rompe la coherencia temporal de la serie.
Comparación de ambos métodos
La pregunta que queremos responder es: ¿qué método reconstruye mejor la demanda plausible en los días afectados?
El Random Forest captura mejor la tendencia, la estacionalidad y las dinámicas recientes de la serie. El método estadístico es más simple, más interpretable y más robusto cuando el histórico es corto.
Al visualizar ambas imputaciones juntas — marcando los fines de semana para verificar que la demanda baja esos días, como debería — se confirma que ambos métodos producen series coherentes, pero el comportamiento difiere en momentos de cambio de tendencia o con patrones temporales más complejos.
Cuándo usar cada uno:
El método estadístico es adecuado cuando el histórico es corto, cuando se necesita una solución fácil de explicar a negocio, o cuando la demanda es relativamente estable sin muchas variaciones temporales.
El Random Forest es preferible cuando hay suficiente histórico, cuando la demanda tiene patrones temporales más complejos, o cuando existen variables exógenas relevantes que el modelo puede incorporar.
Conclusión
Antes de entrenar cualquier modelo de forecasting es fundamental entender qué representan realmente los datos.
Cuando existen roturas de stock, las ventas históricas no reflejan la demanda real, sino la disponibilidad del producto. Los picos de recuperación tras una rotura añaden ruido adicional. Si no se corrigen ambos efectos, el modelo aprende patrones que no existen y genera predicciones sesgadas que se trasladan directamente a decisiones incorrectas de planificación, producción o compra.
La lección no es cuál método gana. Es esta: si no corregimos las roturas de stock, el modelo de demanda aprende la disponibilidad, no la demanda real.
En los proyectos de predicción de demanda de Kraz, el preprocesado de datos — incluyendo la corrección de roturas de stock — forma parte del proceso estándar. Porque un modelo es tan bueno como los datos con los que se entrena.
Conoce los proyectos de predicción de demanda de Kraz →
¿Quieres ver el código completo y ejecutable de este proceso? Está disponible en el artículo original en Medium →
¿Tienes roturas de stock en tu historial y necesitas construir un modelo de demanda fiable? Habla con el equipo de Kraz.