Mi veredicto, desde el inicio: nueve de cada diez veces, son los datos.
He visto esta película demasiadas veces en veinte años en el sector de almacenes. Un DC gasta una fortuna en un módulo de pronóstico de demanda con IA, el modelo entra en producción y, tres meses después, la reposición la sigue moviendo el instinto de un planificador veterano. El primer instinto de IT siempre es «el modelo está mal, probemos otro algoritmo». El mío es siempre el mismo: no toquen el modelo todavía — saquen los datos con los que lo alimentaron y mírenlos bien. Casi siempre, ahí vive el problema.
Un modelo es solo un estudiante muy aplicado. Denle un libro de texto lleno de páginas perdidas y erratas, y no podrán culparlo por reprobar el examen.
Primera pregunta: ¿sus datos están siquiera completos?
Muchos proyectos de pronóstico mueren en el paso uno: los datos maestros de SKU son un desastre.
Hace unos años recorrí una instalación 3PL en Ontario, California — bastante más de cien mil pies cuadrados, más de veinte mil SKUs — que había lanzado un pronóstico de reposición basado en ML. Seis meses después, la precisión era pésima. Escarbamos y encontramos que campos como la categoría de producto, la marca de estacionalidad y las relaciones de sustitución estaban en blanco para una enorme parte del catálogo. Los artículos nuevos pasaban meses en el sistema sin categoría asignada. ¿Qué se suponía que debía aprender el modelo? ¿Del aire?
Luego está el etiquetado inconsistente: el mismo producto etiquetado como "winter style" en un DC, "Winter-2023" en otro y en blanco en un tercero. El modelo ve tres productos distintos y aprende patrones equivocados para los tres.
La comprobación es simple: tomen 200 SKUs al azar y miren los campos de categoría, estacionalidad, estado del ciclo de vida y sustitución. Si las tasas de nulos superan el veinte por ciento, dejen de hablar de modelos y vayan a arreglar sus datos maestros. Es un trabajo poco glamuroso, pero sáltenlo y todo lo que venga después será esfuerzo desperdiciado.
Segunda pregunta: ¿están siquiera midiendo lo correcto?
Este es el modo de falla más traicionero que conozco. Las "ventas históricas" con las que se entrena el modelo muchas veces no son demanda real en absoluto.
Caso clásico: un SKU se agotó durante dos semanas el pasado noviembre, así que el sistema registró cero ventas. El modelo aprendió que «nadie quiere este SKU en noviembre» y lo subabasteció este año — salvo que este año no hubo agotamiento, la demanda llegó como siempre y el estante quedó vacío. Un cero durante un agotamiento no es demanda. Es el techo de lo que podían surtir. Enseñen al modelo a confundir el techo con el piso y es imposible que acierte.
Otro: las transferencias entre almacenes. El DC A se queda corto, así que 500 unidades se trasladan desde el DC B, y el registro de salidas del DC B suma 500 unidades de "ventas". El modelo ve una demanda fuerte en el DC B para ese SKU y les dice que se abastezcan — abasteciéndose de una demanda fantasma que en realidad fue solo una transferencia interna. Demanda real y movimientos internos mezclados en un solo número sesgarán cada pronóstico.
Y no olviden las devoluciones. En el cumplimiento de e-commerce, las ventas brutas frente a las netas pueden diferir enormemente. Entrenen con ventas brutas y el modelo sobrestimará crónicamente.
La comprobación: encuentren el documento que define su métrica de ventas — si existe — y hagan tres preguntas. ¿Cómo se manejan los periodos de agotamiento — alguien reconstruyó la demanda real? ¿Se excluyen los envíos de transferencia? ¿Brutas o netas? Si nadie puede responder, o la respuesta es «nunca nos ocupamos de eso», acaban de encontrar la causa raíz. Con una métrica turbia, cuanto más inteligente el modelo, más confiadamente se equivoca.
Una cosa más que vale la pena decir: bastantes almacenes sacan los datos de ventas directamente del ERP, y los registros de salida del ERP no distinguen «vendido a un cliente» de «enviado a nuestro DC hermano». Nadie hace ese paso de limpieza, así que el modelo estudia demanda falsa todo el día. Suelo pedir al equipo de datos que divida un año de registros de salida en ventas, transferencias y merma. Ese solo paso suele reducir notablemente la "demanda histórica" de varios SKUs — y cada unidad que desaparece era ruido.
Tercera pregunta: ¿alguien etiquetó los eventos?
Los modelos de pronóstico odian los picos sin explicación. Las ventas se duplicaron un mes el año pasado, el modelo memorizó el patrón y este año abasteció el doble — salvo que el pico del año pasado fue una gran promoción y este año no hay ninguna. Ahora están sentados sobre inventario muerto.
Promociones, eventos de liquidación, oleadas impulsadas por influencers, clima atípico, un agotamiento de un competidor — si nada de esto está etiquetado, el modelo lo absorbe como "demanda natural". Lo que aprende no es un patrón. Es ruido.
El peor caso que vi: tres años de datos de acaparamiento de la era pandémica sentados en el conjunto de entrenamiento sin anotación alguna. El modelo trató esos picos anormales como la línea base, mantuvo el stock de seguridad diario permanentemente alto y el inventario muerto llenó dos pasillos completos. Una vez que ese periodo se etiquetó y se ponderó a la baja, el pronóstico volvió a la realidad.
También hay una dimensión fácil de pasar por alto: los eventos del lado de la oferta. Una entrega tardía de un proveedor, una huelga portuaria que retrasó la recepción tres semanas — estos tallan agujeros inexplicables en la curva de ventas. El modelo no puede entender «no pudimos vender porque la mercancía nunca llegó». Solo aprende «nadie quiso este SKU ese mes». Así que su calendario de eventos no puede solo registrar promociones. Registren también las grandes interrupciones de suministro y las anomalías de recepción. Etiqueten ambos lados o el panorama seguirá incompleto.
La comprobación: tomen los diez SKU-meses con las oscilaciones históricas más salvajes y pregunten al equipo de negocio qué pasó. Si pueden explicar más de la mitad pero el sistema no registra nada, su calendario de eventos está vacío. Capturar las etiquetas de eventos le toma al lado de negocio diez minutos describirlo y al equipo de datos quizás dos semanas implementarlo — vale cada hora.
Entonces, ¿cuándo es realmente culpa del modelo?
Una vez que los datos pasan las tres comprobaciones — datos maestros completos, métricas limpias, eventos etiquetados — y el pronóstico sigue fallando, entonces sí, hablemos de modelos. Seré el primero en estar de acuerdo.
Los problemas reales del modelo se ven así: los datos están limpios, pero los modelos simples y los complejos rinden más o menos igual, a veces con el simple ligeramente por delante. O la distribución de la demanda cambió estructuralmente — digamos que el negocio pasó de mayorista a minorista, o de tienda física a online — y el modelo viejo aprendió las reglas de un mundo que ya no existe.
Luego está la ingeniería de features insuficiente. Alimentar al modelo con nada más que una serie temporal de ventas, dejando fuera precio, posición de inventario y lead time — las features con las que el negocio realmente opera. Eso es menos «algoritmo equivocado» que «el modelador no entiende de almacenes». Cambiar de algoritmo no ayudará; traer a alguien que entienda de reposición, sí.
En mi experiencia, en este dominio las features superan a los algoritmos casi siempre. Un planificador que entiende la lógica de reposición más una regresión simple suele superar a un modelo sofisticado afinado por alguien que jamás ha pisado un almacén. Los motores de la demanda en un almacén son concretos: el calendario de promociones, las órdenes abiertas, la estacionalidad, la variabilidad del lead time de los proveedores. Conviertan eso en features y llegarán más lejos que con cualquier cambio de arquitectura.
Mi regla de oro es simple: si tres modelos distintos puntúan más o menos igual sobre el mismo conjunto de datos limpio, el cuello de botella no es el modelo. Afinar la selección del modelo sobre datos sucios es solo trabajo pesado y caro.
Una lista de verificación de preparación de datos que sí pueden usar
Diagnóstico listo — ahora a limpiar la casa. En este orden, sin saltarse pasos:
- Datos maestros: campos de categoría, estacionalidad, ciclo de vida y sustitución para cada SKU, tasas de nulos por debajo del cinco por ciento
- Métricas: reconstruyan la demanda real de los periodos de agotamiento (como mínimo, márquenlos), eliminen los envíos de transferencia, entrenen con ventas netas
- Eventos: construyan un calendario de eventos — promociones, liquidación, clima atípico, órdenes masivas puntuales, todo etiquetado
- Granularidad: asegúrense de que la granularidad del pronóstico (SKU-DC-semana) coincida con la granularidad de sus decisiones de reposición; el pronóstico correcto en la granularidad equivocada es inútil
- Backtest: corran un backtest de tres meses sobre los datos limpios y estudien la distribución del error antes de que nada entre en producción
La mayoría de los almacenes que terminan estos cinco pasos descubren algo curioso: su modelo viejo de repente se volvió «más inteligente». Nunca fue tonto. Solo había estado leyendo un libro de texto lleno de erratas.
Una pregunta de autoevaluación para llevarse a casa: en las ventas históricas con las que están alimentando ahora mismo su modelo de pronóstico, ¿pueden decir qué filas son demanda real, cuáles son agotamientos y cuáles son transferencias internas? Si no pueden distinguirlas, no se apresuren a cambiar de modelo — separen primero esas tres. Una vez respondida esa pregunta, la mayor parte del misterio de los malos pronósticos se disuelve.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
