Un reaprovisionamiento automático es tan bueno como la regla que le pones: y casi todas son fijas.

¿Qué es el reaprovisionamiento automático?

El reaprovisionamiento automático es que el programa, y no una persona, genere la propuesta de pedido o de traspaso cuando un producto lo necesita. La persona puede aprobarla, cambiarla o dejar que salga sola. Para hacerlo, el programa necesita responder dos preguntas por cada producto y cada sitio: cuándo hay que pedir y cuánto.

La forma de responderlas es lo que separa un reaprovisionamiento automático de otro. La más común es una regla fija: si baja de 20, pide hasta 60. La menos común, y la que más diferencia marca cuando el negocio tiene temporada o muchos sitios, es que el programa calcule esos números cada semana con una previsión de lo que se va a vender y el riesgo que aceptas de quedarte sin producto.

Antes de automatizar, conviene tener claras las dos piezas por separado. La guía del punto de pedido explica el cuándo y la de cuánto pedir, el cuánto. Aquí se trata de cómo las combina un programa.

¿Qué stock mira el programa para decidir?

Un algoritmo de reposición no compara la regla con lo que hay en la estantería, sino con un stock proyectado: lo que hay, más lo que ya viene de camino, menos lo que está comprometido con pedidos de clientes sin servir. Microsoft lo explica así en la documentación de Business Central: el sistema de planificación usa el inventario proyectado para vigilar el punto de pedido, y antes de proponer un pedido nuevo comprueba si ya hay suministro pedido que llega dentro del plazo del artículo.

Odoo usa la misma idea con otro nombre. Sus reglas de reabastecimiento trabajan con la cantidad prevista: cuando el stock previsto baja del mínimo, se crea la orden. Si te olvidas de esto y comparas con el stock físico, el programa pide otra vez lo que ya está en camino. El detalle de qué cuenta como «en camino» está en la guía de stock en tránsito.

Revisión continua: pedir en cuanto se cruza el nivel.

En la revisión continua, el programa mira el stock con cada movimiento (o varias veces al día) y lanza el pedido en el momento en que el stock proyectado cruza el punto de pedido. La cantidad puede ser fija (siempre 50, o siempre un palé) o la necesaria para volver a un máximo. Business Central llama a estas dos directivas «cantidad fija de reaprovisionamiento» y «cantidad máxima»; Odoo las resume en una regla de mínimo y máximo.

Odoo deja elegir si el disparo es automático o manual. En automático, crea la orden de compra o de fabricación cuando el planificador se ejecuta y el stock previsto está por debajo del mínimo, o cuando un pedido de venta confirmado lo baja de ese mínimo; según su documentación, el planificador se ejecuta por defecto una vez al día. En manual, el producto aparece en un panel de reabastecimiento y alguien pulsa el botón.

La revisión continua da el mínimo stock para un mismo nivel de servicio, porque pide justo cuando hace falta. Su inconveniente es práctico: genera pedidos sueltos cualquier día de la semana, a cada proveedor, y eso choca con los portes mínimos, con las rutas de reparto y con la forma en que trabaja un almacén.

Revisión periódica: mirar cada semana y pedir hasta un nivel.

En la revisión periódica, el stock se mira cada cierto tiempo (cada lunes, cada quince días, el día que pasa el camión del proveedor) y en cada revisión se pide lo que falte para llegar a un nivel objetivo. Es como trabaja la mayoría de empresas que reponen tiendas, depósitos o furgonetas: hay un día de pedido, y ese día se decide todo.

Business Central lo modela con el ciclo o intervalo de tiempo: el sistema acumula la demanda de un periodo y comprueba al final de ese periodo si se ha cruzado el punto de pedido. Su documentación lo describe como el reflejo del proceso manual de revisar el stock con una frecuencia fija en vez de con cada movimiento, y pone el ejemplo de juntar todo lo de un proveedor en un pedido semanal.

La revisión periódica necesita más stock de seguridad que la continua, porque el riesgo no termina cuando llega el pedido: dura hasta que llegue el siguiente. Con revisión semanal y un proveedor que tarda cinco días, el stock que pidas el lunes tiene que aguantar doce días (los siete hasta la próxima revisión y los cinco del plazo de esa siguiente), no cinco. Es el error más caro que vemos al pasar de pedir «cuando se acaba» a pedir «los lunes».

• Nivel objetivo = venta prevista durante (días hasta la próxima revisión + plazo del proveedor) + stock de seguridad para ese mismo horizonte.
• Cantidad a pedir = nivel objetivo menos stock proyectado (físico + en camino − comprometido).
• Se redondea a la caja o al lote del proveedor, y si sale cero o negativo, no se pide.

Contra pedido y lote a lote: cuando no se quiere stock.

No todo se repone por niveles. Business Central tiene otras dos directivas. «Pedido» compra o fabrica exactamente para una demanda concreta y la deja vinculada a ella; su documentación la recomienda para productos con demanda poco frecuente, plazo de entrega despreciable o características que cambian de un pedido a otro. «Lote a lote» repone según la demanda real de pedidos abiertos y previstos, agrupada en un periodo, y Microsoft la describe como la más flexible y la pensada para productos en los que el inventario se acepta pero se debe evitar.

Son la respuesta correcta para lo que se vende poco y caro, lo que se hace a medida o lo que el cliente pide con antelación. Aplicarles un mínimo y un máximo, como se hace a menudo por inercia, llena el almacén de stock que solo se vende cuando alguien lo encarga. La guía de demanda intermitente trata ese caso.

Mínimos de pedido, múltiplos y calendario.

Encima de la regla principal van los modificadores: la cantidad mínima de pedido que acepta el proveedor, la máxima que cabe en un envío y el múltiplo (la caja de 12, el palé de 80). Business Central los aplica después de calcular la cantidad: sube al mínimo, divide en varios pedidos si se pasa del máximo y redondea al múltiplo. Odoo tiene un campo de múltiplo en la propia regla. Parecen detalles, pero en un producto que vende tres al mes y viene en cajas de 24, el múltiplo decide más que la previsión.

El calendario también cuenta. Business Central mueve al siguiente día laborable un pedido que caería en festivo, según el calendario de la empresa y del almacén. Un algoritmo que no sabe que el proveedor cierra en agosto o que la tienda no abre los domingos propone pedidos que nadie va a servir o recibir.

Dónde se rompen las reglas fijas.

La regla «si baja de 20, pide hasta 60» funciona mientras el producto venda lo mismo todo el año, en un solo sitio, con un proveedor que sirve siempre en el mismo plazo. En cuanto falla una de esas tres cosas, la regla queda mal y nadie la cambia, porque cambiar a mano los mínimos de miles de combinaciones de producto y sitio no lo hace nadie.

• Temporada: el mínimo de julio deja sin producto en septiembre, y el de diciembre llena el almacén en enero.
• Muchos sitios: la misma referencia necesita un mínimo distinto en cada tienda o depósito, y se acaba poniendo el mismo a todos.
• Productos nuevos: arrancan con el mínimo de otro «parecido» y nadie lo revisa.
• Promociones: la regla ve la venta de la promoción como demanda normal y sube los pedidos de las semanas siguientes.
• Plazos que cambian: el proveedor pasa de cinco a diez días y el punto de pedido sigue calculado para cinco.
• Productos que se venden a trompicones: ningún mínimo fijo acierta con algo que vende cero cinco semanas y seis la sexta.

Cómo decide un algoritmo con previsión.

Un reaprovisionamiento con previsión no sustituye las reglas de arriba: recalcula sus números. Cada semana estima, para cada producto en cada sitio, qué se puede vender hasta que llegue el siguiente envío, no como una cifra sino como un abanico. Hyndman y Athanasopoulos, en su manual de referencia sobre previsión, lo llaman intervalo de predicción: el rango en el que se espera que caiga el valor futuro con una probabilidad dada. De ese abanico sale el nivel objetivo para el nivel de servicio que has elegido, y del nivel objetivo, la cantidad.

Un ejemplo: una referencia vende de media 30 unidades a la semana en una tienda, con revisión cada lunes y un proveedor que tarda una semana. El horizonte es de dos semanas: 60 unidades de media. Con la variación de sus ventas, el 95 % de las veces se venden menos de 78 en esas dos semanas. Si la tienda tiene 25 y vienen 20 de camino, se piden 33, redondeadas a la caja de 12: 36. En octubre, cuando esa referencia vende el doble, el mismo cálculo da otra cifra sin que nadie toque un mínimo.

Lo que no cambia es quién decide. Un buen reaprovisionamiento automático enseña la propuesta con su porqué (lo que se espera vender, lo que hay, lo que viene y el riesgo que queda) y deja que la persona la apruebe o la cambie. Si algo se cambia, el programa lo anota, y si alguien corrige siempre lo mismo, es una señal de que falta un dato. La guía de nivel de servicio explica cómo elegir ese 95 % por familia de producto.

Cuándo dejar que el pedido salga solo.

Automatizar del todo, sin que nadie apruebe, tiene sentido en productos de mucha venta y comportamiento estable, con un proveedor fiable, cuando el programa ha demostrado durante meses que acierta. Para el resto, lo razonable es que el programa proponga y una persona apruebe en bloque, revisando solo lo que se sale de lo normal: un pedido mucho mayor que el habitual, un producto nuevo o uno con poca historia.

La forma de saber si te puedes fiar no es la demo del fabricante, sino tu propio histórico: repetir fechas pasadas con lo que se sabía cada día y comparar lo que habría pedido el programa con lo que pasó. Es lo que hacemos en la simulación con tus datos, seguida de uno o dos meses en modo sombra, en los que el programa propone sin que nada salga.

Cómo lo hace un programa de control de stock con IA.

El sistema que montamos en Arume lee las ventas, el stock y los pedidos pendientes de tu programa de gestión (Odoo, Business Central, Sage, Holded, SAP Business One o un Excel), con un usuario que solo puede leer. Cada semana calcula el riesgo de quedarse sin cada producto en cada sitio y propone qué mandar, cuánto y cuándo, redondeado a tus cajas y a tus días de reparto, con el porqué de cada línea. Tu equipo aprueba o cambia, y el pedido se pasa al ERP como siempre.

Las reglas de tu ERP no desaparecen: siguen ahí como red de seguridad. Lo que cambia es que los mínimos y máximos dejan de ser números puestos una vez. Si quieres ver qué propondría con tus datos, el análisis gratuito de tu stock es el primer paso.