El problema que nadie nombra

Cuando las organizaciones eligen una herramienta de forecasting, la discusión suele ser sobre qué algoritmo usar: ¿ARIMA? ¿Prophet? ¿Redes neuronales? La pregunta correcta es diferente: ¿todos tus SKUs necesitan el mismo algoritmo?

La respuesta — en casi cualquier catálogo de más de 200 SKUs — es no. Y sin embargo, la mayoría de los ERP y herramientas de forecasting aplican un modelo configurado globalmente a todo el catálogo. La razón es simple: configurar manualmente el modelo de cada SKU es imposible a escala.

El resultado es predecible: el sistema funciona "razonablemente bien" para los SKUs en el centro de la distribución, y falla sistemáticamente en los extremos — que suelen ser exactamente los SKUs que más impactan el negocio.

Tres SKUs, tres realidades distintas

Considera estos tres productos de un catálogo típico de retail:

SKU A
Producto estrella estacional
Ventas estables con pico claro en diciembre. 36 meses de historia. Sin tendencia marcada.
Necesita: TBATS / TES
SKU B
Repuesto industrial
Meses enteros en cero. Picos esporádicos de 2–5 unidades sin patrón temporal.
Necesita: Croston
SKU C
Lanzamiento reciente
3 meses en el catálogo. Historia insuficiente para cualquier modelo estadístico robusto.
Necesita: Reglas de negocio

Si configuras un modelo estacional como TES para todo el catálogo, el SKU A funciona bien. Pero el SKU B — con su demanda errática — recibe un forecast que asume un patrón que no existe. El resultado es over-forecast constante en los meses de silencio. Capital inmovilizado que paga WACC mes a mes.

"Si tienes un martillo, todo parece un clavo. Si tienes un modelo de forecasting, todo parece una serie de tiempo que responde a ese modelo."

Las consecuencias concretas

El error de modelo-único no produce resultados ligeramente incorrectos. Produce los errores más grandes posibles para cada tipo de demanda mal clasificada.

Tipo de SKU Modelo aplicado Error esperado Impacto en inventario
Intermitente Modelo estacional o promedio Over-forecast masivo Stock acumulado sin rotación
Estacional Modelo sin componente estacional Under-forecast en picos Roturas en temporada alta
Con tendencia Modelo suavizado sin tendencia Siempre llega tarde Stock insuficiente en crecimiento
Nuevo lanzamiento Modelo estadístico con 2 meses de historia Volatilidad extrema Over o under según el primer mes
Maduro estable Cualquier modelo robusto Error bajo Funciona correctamente
⚠️ El costo real
Si el 30% de tu catálogo es demanda intermitente (un porcentaje típico en retail y manufactura industrial), y ese 30% está sistemáticamente sobre-forecasteado, estás financiando inventario innecesario. A un WACC del 12% sobre $2M de inventario, eso son $72,000 anuales de costo de capital en stock que no debería estar ahí.

El síntoma más visible: los overrides manuales

Hay un indicador claro de que el modelo de forecasting no está funcionando: el porcentaje de SKUs que el equipo de planeación sobreescribe manualmente antes de publicar el forecast.

En organizaciones donde el modelo único falla, ese porcentaje suele estar entre el 50% y el 70%. El equipo compensa con conocimiento tácito: "este SKU siempre da más en diciembre", "este no vende en Q1".

💡 El diagnóstico simple
Si más del 30% de tus SKUs son sobreescritos manualmente antes de publicar el forecast, el modelo no está haciendo su trabajo. No es un problema de datos — es un problema de que el modelo no corresponde al tipo de demanda del SKU.

En ese punto, la organización no tiene un sistema de forecasting. Tiene un sistema que genera un punto de partida que el equipo ajusta manualmente. El sistema estadístico es un trámite, no una herramienta.

La solución no es un modelo más sofisticado

El impulso habitual es buscar un algoritmo mejor. Machine learning, redes neuronales, modelos de deep learning para series de tiempo. La promesa es siempre la misma: "este modelo aprende los patrones de cada SKU automáticamente".

El problema es que incluso los modelos más sofisticados cometen errores sistemáticos cuando se aplican a tipos de demanda para los que no fueron diseñados. Un LSTM entrenado sobre datos de series estacionales no sabe manejar la estructura Poisson de demanda intermitente.

La solución correcta no es un modelo más poderoso. Es hacer la pregunta correcta antes de modelar: ¿qué tipo de demanda tiene este SKU?

Esa pregunta — la segmentación — determina qué familia de modelos es candidata. Después, el backtesting elige el ganador dentro de esa familia. El resultado es que cada SKU compite con los modelos correctos para su tipo de demanda.

En el próximo artículo, explicamos exactamente cómo funciona el árbol de decisión de segmentación M8 — las ocho reglas que determinan qué familia de modelos aplica a cada tipo de SKU.

¿Quieres ver cuántos SKUs de tu catálogo están mal segmentados?

Análisis de segmentación gratuito en 48h

Mandamos tus datos. En 48 horas tienes el reporte completo: distribución de los 8 segmentos, modelos ganadores, y MAPE estimado de tu catálogo.

Solicitar análisis gratuito →