¿Cómo implantar la reposición automática sin arriesgar nada?

La respuesta en dos frases y para quién es.

La forma de no arriesgar es que el sistema no tenga poder de hacer nada hasta que haya demostrado, con tus propios datos, que lo haría mejor que tú. Primero lee, luego se compara con el pasado, luego propone sin que nadie le haga caso, y solo después se usa, con una persona aprobando.

Vale para cualquier empresa que repone a varios sitios, con el programa que sea. Es especialmente útil para quien tiene miedo a que una herramienta compre de más o se equivoque justo en la referencia que más pesa.

Cómo se decide hoy y por qué falla.

La práctica habitual con un sistema nuevo es probarlo en vivo: se activa, se mira qué hace y se corrige sobre la marcha. Con la reposición eso sale caro, porque los errores tardan semanas en verse, hay pedidos que ya no se pueden anular y el aprendizaje se paga con dinero real.

El otro extremo es no probarlo nunca: seguir como hasta ahora porque nadie quiere ser quien rompa una referencia. Así tampoco se aprende nada, y el coste de lo que se hace mal hoy (roturas y excedentes) sigue sin verse.

Hay una vía intermedia, que es probar con el pasado. Se sabe lo que se vendió cada día y lo que había en cada almacén. Con eso se puede preguntar al sistema qué habría propuesto cada semana, sin que nada de eso llegue a la operación real.

Paso a paso, con un ejemplo.

Primer paso, lectura sola. El sistema se conecta con un usuario que solo puede leer ventas, existencias y pedidos. No puede crear ni modificar nada en tu programa, así que el riesgo operativo es cero. Se comprueba que las cifras que ve coinciden con las tuyas.

Segundo paso, repetir el pasado (lo que se llama backtest). Se eligen unas semanas ya cerradas y se calcula, para cada una, lo que habría propuesto el sistema con lo que se sabía ese día, sin ver el futuro. Se compara con lo que se hizo. La práctica estándar en previsión es separar los datos en un tramo de ajuste y otro de prueba que el modelo no ha visto: Hyndman y Athanasopoulos recomiendan un tramo de prueba de alrededor del 20 % de la muestra y como mínimo igual de largo que el horizonte que se quiere prever.

Un ejemplo con cifras inventadas para enseñar la cuenta: 1.200 referencias, 26 semanas repetidas. Combinaciones referencia-semana con rotura: 310 en la realidad frente a 190 en la simulación, que son 120 menos (310 - 190), una reducción del 39 % (120 / 310). En euros de stock medio: 410.000 reales frente a 395.000 simulados. Lo importante no es el tamaño de la mejora, que cambia en cada empresa, sino que se vea con datos tuyos y se pueda discutir línea a línea.

Es importante que el backtest no haga trampas. El sistema solo puede usar lo que se sabía el día de cada decisión: las ventas hasta ese día, el stock de ese día, los pedidos ya hechos. Si se calibra con semanas que luego se usan para evaluar, el resultado sale mejor de lo que será en la realidad, y el modo sombra existe precisamente para comprobarlo con semanas que aún no habían ocurrido.

Tercer paso, modo sombra. Durante seis u ocho semanas el sistema propone cada lunes y tú compras como siempre. Se guardan las dos listas. Cuando acaba el periodo se comparan: dónde coincidían, dónde no, y qué habría pasado en las diferencias. Es la prueba con datos que aún no existían cuando se calibró.

Cuarto paso, aprobación humana. La propuesta pasa a ser la base de trabajo: la persona de compras la ve con el porqué de cada línea, cambia lo que no le encaja y aprueba. Se empieza por una familia de productos, por ejemplo, la que más roturas tiene, y se amplía cuando funciona.

• Lectura sola: usuario sin permisos de escritura y cifras verificadas con las tuyas.
• Backtest: semanas pasadas, con lo que se sabía cada día.
• Modo sombra: seis a ocho semanas, sin tocar nada.
• Aprobación humana: una familia primero, el resto después.

Errores típicos al implantar.

Los que vemos que arruinan una implantación.

• Probar con datos con trampa: calibrar con las semanas que luego se usan para evaluar. Hay que separarlas.
• Comparar solo una cifra (por ejemplo, el stock medio) y no roturas y excedente a la vez.
• Medir el error con un porcentaje que se rompe con ventas pequeñas o cero: el MAPE no funciona cuando las ventas son cercanas a cero, según el propio manual de Hyndman. En referencias lentas conviene un error escalado.
• Activarlo en todo el catálogo el primer día.
• No fijar de antemano qué resultado hace seguir y cuál hace parar.
• Dejar que el sistema escriba pedidos sin que nadie los vea.

Qué cambia con un sistema de reposición así montado.

La diferencia con empezar en vivo es que la decisión de seguir se toma con evidencia. En la simulación con tus datos detallamos el procedimiento y lo que se te entrega al final. En el uso diario, la previsión de demanda alimenta la propuesta, y tu programa sigue siendo el que manda: si el sistema escribe algo de vuelta, como un pedido en borrador, es solo después de tu aprobación y se puede deshacer.

Si ya usas las reglas de reabastecimiento de tu ERP (en Odoo, Inventario, Operaciones, Reabastecimiento), el sistema no las pisa: propone cambios a esos mínimos y máximos o pedidos concretos, y tú decides.

Qué datos hacen falta.

Para el backtest, ventas por referencia y sitio y semana de dos años como mínimo, existencias de cada semana (no solo la actual) y los pedidos de compra con fechas. Sin el histórico de existencias, no se pueden distinguir las ventas que no se hicieron por falta de producto, y la simulación sale optimista. En qué datos necesita un predictor de stock está el detalle.

Cuándo no merece la pena.

Si tu histórico es de menos de un año, el backtest tiene poca fuerza y la prueba más honesta es un periodo en modo sombra más largo. Si el stock registrado no coincide con el real, antes hay que resolver el inventario: ninguna prueba es fiable con existencias falsas. Y si repones de tres productos a dos sitios, probablemente no necesites ni lo uno ni lo otro: un pedido sugerido en hoja es suficiente.

Cómo empezar.

El primer paso es el que no compromete nada: el análisis gratuito, con un export tuyo, para ver si hay materia. Después viene la simulación con tus datos, y solo si los números lo justifican, el modo sombra. Para entender cómo se decide hoy la reposición en tu caso, mira la guía de reaprovisionamiento automático.