El escenario que todo almacén conoce
Son las 9:47 a.m. Tu wave cierra a las 10:00.
Noventa y cuatro de noventa y siete órdenes avanzan sin problema por picking. Entonces un supervisor llama por radio: tres SKUs, cuatro pick faces, stock cero. La ubicación no miente — el stock está a cuarenta metros, en reserva, intacto, esperando que alguien lo note.
Ahora tienes dos malas opciones. Sacar a un operador de montacargas de otra tarea para hacer un movimiento manual urgente, o dejar que esas tres órdenes se retrasen y explicar el fallo en la llamada de outbound al mediodía.
Este es exactamente el modo de falla que Order-Based Replenishment (OBR) existe para eliminar.
En el Post 1 establecimos que el replenishment no es un proceso de fondo — es el sistema que mantiene vivo el picking. Hoy bajamos un nivel más: la primera de las cuatro estrategias de replenishment en SAP EWM, y en muchas operaciones, la que hace más trabajo día a día.
Qué es realmente Order-Based Replenishment
Order-Based Replenishment dispara un movimiento de stock desde un storage type origen (normalmente reserva o bulk) hacia un storage type destino (normalmente un pick face fijo) porque una orden de entrega outbound específica necesita stock que no está ahí en cantidad suficiente.
Una nota de nomenclatura: el propio Customizing de SAP llama a este método Order-Related Replenishment — Repl. Strat. 3 en los ajustes del storage type. Esta serie usa «Order-Based» porque se lee más natural, pero es el mismo mecanismo. Si buscas esto en SPRO o en SAP Help, ese es el término que debes buscar.
Lee esa definición otra vez, porque la palabra clave es «específica». OBR no es forecasting. No es una estrategia de buffer. No le importa la wave de mañana ni la promoción de la próxima semana. Reacciona a una señal de demanda real y confirmada que existe ahora mismo en el sistema — una entrega, una wave de picking, un requerimiento real.
En términos de EWM: cuando se crea una tarea de almacén (warehouse task) u orden de almacén (warehouse order) para una entrega outbound, el sistema revisa el pick face. Si el stock disponible es menor a lo que la orden necesita, EWM crea automáticamente una tarea de replenishment para reabastecer el pick face antes — o en paralelo — a la tarea de picking.
Esto es lo que diferencia a OBR de las otras tres estrategias que veremos más adelante en esta serie:
- Automatic Replenishment se dispara en el momento en que se confirma una tarea de picking y la ubicación cae por debajo de su cantidad mínima.
- Planned Replenishment se ejecuta como un barrido programado o disparado manualmente en todo el almacén, usando esa misma cantidad mínima.
- Direct Replenishment reacciona a una excepción de bin denial durante el picking — no monitoriza niveles de stock en absoluto, se dispara solo cuando un picker encuentra una ubicación fija vacía.
Por qué suele ser la primera estrategia que configuran los equipos
La mayoría de las implementaciones de EWM empiezan aquí por una razón simple: OBR requiere la menor infraestructura de forecasting. No necesitas datos limpios de MRP. No necesitas un proceso maduro de planeación de demanda. Solo necesitas datos de stock precisos y un pick face bien configurado — el sistema hace el resto, reaccionando a órdenes reales conforme llegan.
Eso convierte a OBR en el punto de entrada natural para almacenes que pasan de un modelo manual de replenishment («el supervisor camina el piso y decide») a un modelo dirigido por el sistema.
Pero — y esta es la parte que muchos equipos pasan por alto — OBR por sí solo es reactivo por diseño. Resuelve el problema en el momento en que ya está ocurriendo. No previene el sprint de las 9:47 a.m.; solo hace que la respuesta sea automática en vez de manual. Entender esta limitación desde el inicio importará mucho cuando lleguemos a la sección de mentalidad más abajo.
El flujo, paso a paso
Esto es lo que ocurre realmente dentro de EWM cuando Order-Based Replenishment está activo y bien configurado:
Paso 1 — Se crea la entrega outbound Una orden de venta o entrega outbound genera demanda de productos, cantidades y una fecha de envío específicos.
Paso 2 — Liberación de wave o creación de tarea de almacén La entrega se libera en una wave, o el sistema crea directamente una tarea de picking para esa entrega.
Paso 3 — Revisión de stock en el pick face Antes (o durante) la creación de la tarea de picking, EWM revisa la cantidad disponible en la ubicación fija (pick face) asignada para ese producto.
Paso 4 — Detección de faltante Si la cantidad disponible en el pick face es menor a la que requiere la orden, el sistema marca un faltante.
Paso 5 — Creación de la tarea de replenishment EWM crea automáticamente una tarea de almacén para mover stock desde el storage type origen (reserva, bulk, o una fuente designada de replenishment) hacia el pick face — típicamente dimensionada para cubrir la orden (o hasta una cantidad/lote definido).
Paso 6 — Secuenciación de ejecución Según la configuración, la tarea de replenishment se ejecuta antes de la tarea de picking (secuencial) o queda disponible para ejecutarse en paralelo, usando configuración de colas y prioridades, para que el operador de montacargas y el picker no se bloqueen entre sí innecesariamente.
Paso 7 — El picking continúa Una vez que el pick face está reabastecido, la tarea de picking original puede confirmarse, y la orden avanza con normalidad.
Siete pasos. La mayoría de las veces, ninguno es visible para nadie en la operación — que es exactamente el punto. Cuando OBR está bien configurado, desaparece en el fondo. Solo lo notas cuando falta.
Para consultores: ruta de configuración y ejecución
Si estás implementando Order-Based Replenishment en un proyecto, esta es la secuencia real que sigue un consultor — primero customizing, después ejecución. Esto no es un resumen simplificado; son los paths de IMG y las transacciones reales usadas para construir y probar OBR de principio a fin.
El diagrama muestra el flujo de ejecución con las transacciones reales:
Parte A — Pasos de Customizing (SPRO)
La configuración ocurre una sola vez, durante el build del proyecto, antes de que exista cualquier dato de prueba.
-
Definir Storage Type
SPRO → IMG → SCM EWM → EWM → Master Data → Define Storage Type -
Activar estrategias de replenishment en el storage type
SPRO → EWM → Internal Warehouse Process → Replenishment Control → Activate Replenishment Strategies in Storage Type -
Mantener categoría de documento/ítem para Replenishment Warehouse Request
SPRO → EWM → Internal Warehouse Process → Replenishment Control → Maintain the Document/Item Categories for Replenishment Warehouse Request -
Warehouse Process Type (picking estándar) 4.1 Define Warehouse Process Type 4.2 Define Process Type Determination Indicator (PTDI) 4.3 Determine Warehouse Process Type
SPRO → REF IMG → EWM → Cross Process Settings → Warehouse Task -
Picking Strategies (picking estándar) 5.1 Specify Storage Type Search Sequence 5.2 Assign Storage Types 5.3 Define Stock Removal Control Indicator 5.4 Determine Storage Type Search Sequence
SPRO → REF IMG → SCM EWM → EWM → Goods Issue Process → Strategies -
Warehouse Process Type (replenishment) 6.1 Define Warehouse Process Type 6.2 Define Process Type Determination Indicator 6.3 Determine Warehouse Process Type Mismo path que el paso 4, configurado para el process type de replenishment.
-
Picking Strategies (replenishment) 7.1 Specify Storage Type Search Sequence 7.2 Assign Storage Types 7.3 Define Stock Removal Control Indicator 7.4 Determine Storage Type Search Sequence Mismo path que el paso 5, configurado para la salida de stock de replenishment.
-
Configuración de Wave 8.1 Maintain Wave Type 8.2 Maintain Wave Categories 8.3 Maintain Wave Capacity Profile 8.4 Define Field Catalog 8.5 Define Condition Table 8.6 Define Access Sequence 8.7 Define Condition Type 8.8 Define Determination Procedure 8.9 Assign Procedure to Document Type
SPRO → REF IMG → SCM EWM → EWM → Goods Issue Process → Wave Management
Saltarse cualquiera de los pasos 4 a 7 es la razón más común por la que OBR «no dispara» en un build nuevo — el sistema no tiene process type ni secuencia de búsqueda que le indique de dónde debe salir el stock de replenishment.
Parte B — Pasos de Ejecución / Testing (transacciones reales)
Una vez completado el customizing, esta es la secuencia usada para probar y confirmar que el proceso funciona de principio a fin:
| # | Paso | Transacción |
|---|---|---|
| 1 | Crear Material Master | MM01 |
| 2 | Extender Material Master (vistas de almacén) | MMSC |
| 3 | Extender Product Master en EWM | /SCWM/MAT1 |
| 4 | Definir Wave Template | /SCWM/WAVETMP |
| 5 | Mantener registro de condición (determinación de wave) | /SCWM/WDGCM |
| 6 | Crear orden de venta | VA01 |
| 7 | Crear entrega outbound | VL01N |
| 8 | Crear Wave (manual) | /SCWM/WAVE |
| 9 | Verificar en Monitor | /SCWM/MON |
| 10 | Mantener Product Master (datos de bin fijo) | /SCWM/MAT1 |
| 11 | Asignar Fixed Bin | /SCWM/BINMAT |
| 12 | Verificar stock en Monitor | /SCWM/MON |
| 13 | Crear tarea de Replenishment | /SCWM/REPL |
| 14 | Confirmar Warehouse Task en background | /SCWM/MON |
| 15 | Verificar stock en la ubicación tras el replenishment | /SCWM/MON |
| 16 | Procesar la wave order en la entrega outbound | /SCWM/PRDO |
| 17 | Verificar stock tras la liberación de la wave | /SCWM/MON |
Nota cuántas veces reaparece /SCWM/MON — el Warehouse Management Monitor es donde verificas que cada etapa del proceso realmente ocurrió, no solo donde configuras.
Tip de consultor: corre esta secuencia completa una vez en sandbox, con un material desechable, antes de tocar datos maestros reales del cliente. Los pasos 4 a 7 del customizing son los que más probablemente necesiten un segundo ajuste una vez que veas el comportamiento real del stock en los pasos 12 a 17.
Los parámetros que realmente controlan esto
Aquí es donde la mayoría de las implementaciones triunfan en silencio o fallan ruidosamente. Tres parámetros hacen casi todo el trabajo:
1. Indicador de control de replenishment Se configura a nivel de producto/storage type e indica si OBR está activo para ese producto en ese storage type. Si está apagado, ninguna cantidad de demanda de orden va a disparar nada — el sistema simplemente dejará que el pick face se vacíe.
2. Cantidad de replenishment / tamaño de lote Determina cuánto stock se mueve cuando se dispara el replenishment. Si lo configuras muy pequeño, dispararás replenishment constantemente — saturando la cola de montacargas con movimientos pequeños e ineficientes. Si lo configuras muy grande, sobrellenarás los pick faces, desperdiciando capacidad y generando congestión en ubicaciones diseñadas para picking rápido, no para almacenamiento.
3. Determinación del storage type origen Define de dónde viene el stock de replenishment. Si esto está mal — apuntando a un storage type que frecuentemente está vacío, o que requiere un paso extra de putaway primero — tu tarea de replenishment simplemente fallará o quedará en cola indefinidamente, rompiendo silenciosamente todo el mecanismo.
Un cuarto factor que vale la pena nombrar aunque no sea un solo «parámetro»: el diseño de prioridad y colas de tareas. Si las tareas de replenishment caen en la misma cola que trabajo de putaway de baja prioridad, esperarán detrás de él. Si caen en una cola que nadie está trabajando activamente, esperarán para siempre. OBR es tan rápido como la cola a la que está asignado.
Cuándo Order-Based Replenishment es la herramienta correcta
OBR se gana su lugar en casi todos los almacenes, pero brilla más en condiciones específicas:
- Entornos de alta mezcla dirigidos por orden — donde la demanda de SKU es demasiado variable para un forecasting ajustado, pero las órdenes individuales están bien definidas y confirmadas.
- Operaciones sin planeación de demanda madura — OBR no necesita precisión de forecast; necesita datos precisos de stock y órdenes en tiempo real, algo que la mayoría de operaciones con WMS ya tienen.
- Pick faces con rotación moderada — suficientemente rápida para que las ubicaciones vacías sean un riesgo real, pero no tan explosiva como para necesitar lógica de buffer preventiva (eso está más cerca del territorio de Direct Replenishment, que veremos en el Post 4).
- Operaciones multicanal — donde el mismo pick face sirve a retail, e-commerce y mayoreo con timing distinto, y un solo disparador basado en forecast no capturaría la mezcla real.
Dónde OBR tiene dificultades: pick faces de altísima velocidad que se vacían varias veces por turno. En ese escenario, esperar a que una orden dispare el replenishment suele llegar tarde — necesitas un disparador proactivo de cantidad mínima, que es exactamente lo que veremos en el Post 3.
Cinco errores que sabotean silenciosamente Order-Based Replenishment
Error 1 — Tratar el tamaño de lote como un número que se configura una sola vez. Los equipos configuran una cantidad de replenishment en el go-live y nunca la revisan de nuevo. Seis meses después, el volumen de órdenes se duplicó, y ese mismo tamaño de lote ahora dispara tres veces más seguido, sobrecargando la cola de replenishment. Los tamaños de lote deben revisarse contra la velocidad real de picking en una cadencia definida — no configurarse y olvidarse.
Error 2 — Ignorar la confiabilidad del storage type origen. Si tu storage type origen para replenishment es propenso a quiebres de stock (porque el putaway de inbound es lento, o porque se comparte con otro proceso), se crearán tareas de OBR pero no podrán completarse. Esto genera una cola de tareas «atascadas» que erosiona la confianza en el sistema — los operadores empiezan a evitarlo y regresan a la expedición manual.
Error 3 — Sin separación de prioridad entre replenishment y otras tareas de almacén. Sin un diseño deliberado de colas y prioridades, las tareas de replenishment compiten con putaway, conteo cíclico y otros movimientos. El operador de montacargas no tiene ninguna razón dirigida por el sistema para tratar un reabastecimiento urgente de pick face distinto a un putaway rutinario — así que no lo trata distinto.
Error 4 — Confundir OBR con una estrategia de stock de seguridad. OBR reacciona a órdenes confirmadas. No te protege contra picos de demanda que aún no ha visto. Los equipos que esperan que OBR por sí solo prevenga cada quiebre de stock le están pidiendo a una herramienta reactiva que se comporte de forma proactiva — y luego culpan a la herramienta cuando no lo hace.
Error 5 — No monitorear los tiempos de confirmación de las tareas de replenishment. El KPI más valioso que la mayoría de los equipos no rastrea: el tiempo entre la creación de la tarea de replenishment y su confirmación. Si ese número sube, tu sistema «automático» se está convirtiendo silenciosamente en un cuello de botella — y nadie lo nota hasta que la wave falla.
Un recorrido completo: lunes, 8:00 a.m., wave de 100 órdenes
Hagamos esto concreto con un solo escenario, seguido de principio a fin.
8:00 a.m. — Se libera la primera wave del día: 100 entregas outbound, cubriendo 340 líneas de orden en 85 SKUs únicos.
8:02 a.m. — EWM comienza a crear tareas de picking para la wave. Por cada línea de orden, revisa el pick face asignado.
8:03 a.m. — El SKU «FLTR-2210» (una unidad de filtro de alta rotación) se requiere en 22 de las 100 órdenes. Demanda combinada: 480 unidades. El pick face tiene actualmente 310 unidades. Faltante: 170 unidades.
8:03 a.m. — Como el indicador de control de replenishment está activo para FLTR-2210 en este storage type, EWM crea automáticamente una tarea de replenishment. La configuración de tamaño de lote redondea el movimiento a 200 unidades (una capa completa de tarima), tomadas del storage type de bulk, dos pasillos más allá.
8:04 a.m. — La tarea de replenishment entra a la cola «Replenishment — Prioridad 1», monitoreada por un operador de montacargas dedicado durante las ventanas de wave (una decisión deliberada de diseño de colas tomada durante la configuración).
8:04–8:11 a.m. — Otros 17 SKUs de la wave disparan tareas de replenishment similares, de tamaños variados. Nada de esto requiere intervención del supervisor. Nada aparece en el radar de nadie como un «problema» — es simplemente trabajo generado por el sistema en una cola.
8:12 a.m. — El operador de montacargas completa el replenishment de FLTR-2210. El pick face ahora tiene 510 unidades — suficiente para cubrir las 480 necesarias, más un pequeño buffer contra una adición de última hora.
8:13 a.m. — Las tareas de picking de FLTR-2210 en las 22 órdenes se ejecutan sin interrupción. Ningún picker reporta una ubicación vacía. Nadie llama por radio al supervisor.
9:58 a.m. — La wave cierra a tiempo. 100 de 100 órdenes completas. El único rastro visible de lo que pasó son 18 tareas de replenishment completadas en el log de transacciones — invisibles para quien no las estuviera buscando.
Compara esto con el escenario de apertura de este post. El mismo problema de fondo — el pick face no puede cubrir la demanda de la orden — pero un resultado completamente distinto, porque el sistema atrapó el faltante antes de que un humano tuviera que hacerlo.
Tips para optimizar Order-Based Replenishment una vez en producción
- Segmenta los tamaños de lote por velocidad de SKU, no por un default único a nivel almacén. Tus 20 SKUs principales por frecuencia de picking probablemente necesitan cantidades de replenishment distintas a tus artículos de baja rotación.
- Dale a replenishment su propia cola con personal real durante las ventanas de wave, no una cola compartida que compite con trabajo de menor prioridad.
- Rastrea la «edad de la tarea de replenishment» — tiempo desde creación hasta confirmación — como un KPI permanente, no una métrica de go-live única.
- Audita semanalmente los niveles de stock del storage type origen para tus SKUs que más disparan replenishment. Una ubicación origen rota rompe OBR en silencio.
- Revisa los indicadores de control trimestralmente. Los SKUs migran entre categorías de rotación rápida y lenta; tu configuración de replenishment debe migrar con ellos.
El reto práctico de esta semana
Antes de cambiar cualquier configuración, corre este diagnóstico:
- Extrae el historial de tareas de replenishment de los últimos 7 días
- Calcula el tiempo promedio entre creación y confirmación, específicamente para tareas de Order-Based Replenishment
- Identifica los 10 SKUs que más tareas de replenishment generan
- Para esos 10 SKUs, revisa si el tamaño de lote y el storage type origen se revisaron en los últimos 6 meses
Si tu tiempo promedio de confirmación está subiendo, o si alguno de tus 10 SKUs principales no ha tenido su configuración revisada recientemente, ahí tienes tu punto de partida — antes de tocar una sola pantalla de configuración.
Cierre
Order-Based Replenishment no es la herramienta más sofisticada del kit de replenishment de EWM — pero es el caballo de batalla. Es la estrategia que con más probabilidad está corriendo, en silencio, detrás de casi cada wave que liberas hoy.
Configura bien los tres parámetros clave — indicador de control, tamaño de lote, storage type origen — y combínalos con un diseño disciplinado de colas, y OBR se vuelve invisible de la mejor manera posible: simplemente funciona.
Más adelante en esta serie veremos los métodos proactivos basados en cantidad mínima — y Direct Replenishment, la estrategia pensada para pick faces que no pueden esperar a que una orden les avise de que están vacíos.
Parte de la serie Replenishment Mastery
Siguiente →
Deja un comentario