Disparadores de replenishment de WES: cómo iniciar el replenishment antes de que la zona forward pick se seque

Te digo el veredicto por adelantado: nunca dependas de un solo disparador de replenishment para tu zona forward pick. He hecho más de 30 implementaciones de WES, y la forma más común en que los proyectos mueren: solo disparadores por nivel de inventario configurados, luego pickers parados frente a slots vacíos el día uno mientras las tareas de replenishment están en cola. La configuración que realmente funciona capa los tres tipos de disparador: nivel de inventario como piso, pronóstico de demanda de ola para lead time, y ventanas de tiempo como red de seguridad. Este post cubre la configuración y los casos de falla de cada disparador, más cómo priorizar replenishment contra picking cuando compiten por gente y equipo.

Por qué un tipo de disparador nunca es suficiente

La zona forward pick tiene una contradicción incorporada: los slots son pequeños y rotan rápido. Quieres fast movers al alcance ergonómico para cortar el travel del picker, pero los slots ergonómicos no aguantan mucho inventario, y una ola grande los drena. Lo que WES hace aquí es matemática de tiempo: cuánto dura el inventario del slot, cuánto toma el replenishment, y si la brecha entre esos dos números deja a un picker esperando.

Cada tipo de disparador responde solo una de esas preguntas. Los disparadores de nivel responden «cuánto queda ahora». Los de pronóstico de ola responden «cuánto está a punto de consumirse». Los de ventana de tiempo responden «se nos escapó algo». Configura solo uno y estás manejando con un ojo cerrado.

Disparador tipo 1: nivel de inventario (Min/Max) — sostén el piso

La lógica más simple: cuando el inventario del pick-face cae bajo el min, genera una tarea de replenishment; para en el max. Checklist de configuración:

1. Define el min como (consumo máximo durante el lead time de replenishment) + buffer de seguridad — máximo, no promedio. Los promedios garantizan un desastre en día de promo.
2. Define el max como la capacidad física del slot menos 10–15% de espacio de trabajo. Sobrecarga un slot y el replenisher no puede meter producto sin retrabajo.
3. Nivela min/max por velocidad ABC: sube el min para A movers, manténlo bajo para C movers para no quemar mano de obra de replenishment en SKUs lentos.
4. Excluye la cantidad de replenishment en tránsito. Resta las tareas ya generadas y no ejecutadas del cálculo del disparador, o el slot recibe órdenes duplicadas.

He visto esta falla tres veces. La peor fue un DC de e-commerce en el este de China haciendo unos 20,000 pedidos al día, donde el min se había fijado sobre el consumo diario promedio. En día de promo a las 10 a.m., el pick face de un SKU caliente se drenó en 40 minutos mientras el lead time de replenishment era de 25 minutos — el min nunca sobrevivió lo suficiente para disparar una tarea. Peor, el sistema emitió tres órdenes duplicadas para el mismo slot — nadie había excluido la cantidad en tránsito. El fix: reconfigurar el min de SKUs calientes sobre picos por hora, agregar lógica de deduplicación de noche. Desde entonces, «exclusión de en tránsito» es una línea obligatoria en mi checklist de la víspera del go-live.

Disparador tipo 2: pronóstico de demanda de ola — cómprate lead time

La lógica: una vez que WES recibe el plan de ola, trabaja hacia atrás desde la demanda de ola de cada SKU — si un pick face no sobrevive la ola, genera la tarea de replenishment temprano. Checklist de configuración:

1. Pronostica sobre «demanda de ola + órdenes en vuelo», nunca solo sobre promedios históricos diarios. La historia no sabe lo que envías hoy.
2. Calcula el umbral del disparador hacia atrás: primero decide «el replenishment debe completarse X minutos antes de que la ola empiece», luego despeja la hora de liberación de la tarea.
3. Agrega una compuerta de calidad de datos: si la cobertura de SKU en el plan de ola cae bajo el 95%, automáticamente recurre a disparadores de nivel. No pronostiques sobre datos incompletos.
4. Dale a los SKUs calientes y de promo sus propias reglas. No compartas umbrales con SKUs regulares.

Caso de falla: un 3PL tenía hermosos disparadores de pronóstico, pero el plan de ola llegaba como una hoja de cálculo importada manualmente, rutinariamente dos horas tarde. Cada pronóstico corría sobre datos obsoletos — las tareas se disparaban temprano una hora, tarde la siguiente. La lección es contundente: los disparadores de pronóstico son tan buenos como los datos aguas arriba. WES necesita un chequeo de frescura — si el plan de ola no se ha actualizado dentro de la ventana configurada, recurre a disparadores de nivel y levanta una alerta.

Disparador tipo 3: ventanas de tiempo — la red de seguridad

La lógica: a horas fijas, barre los pick faces y rellena todo lo que esté bajo una línea. Checklist de configuración:

1. Pon la ventana en los huecos entre olas — nunca barres durante un pico de envío, cuando una inundación de tareas de replenishment solo agrega ruido.
2. La línea de red de seguridad puede ser más holgada que el min. Su trabajo es atrapar lo que los dos primeros pasaron por alto, no hacer el trabajo pesado.
3. Limítala: pon un tope al número de tareas de replenishment por ventana para que un barrido no inunde el piso.
4. Rastrea tareas-por-ventana como métrica. Ventanas consecutivas en cero significa que los dos primeros disparadores están sanos; un pico repentino significa que algo aguas arriba se rompió.

Caso de falla: un almacén puso su ventana en «cada hora en punto». Cada barrido generaba más de 200 tareas de replenishment que el equipo no podía terminar, el backlog se hizo bola de nieve, y el pool de tareas de WES se atascó por completo. El fix: una ventana cada cuatro horas con un tope de 60 tareas por ventana. Recuerda: la red de seguridad está para atrapar errores, no para hacer el trabajo principal.

Comparando los tres: qué elegir y cómo combinar

Ahora lo contraintuitivo: disparadores más tempranos no siempre son mejores. Disparar replenishment temprano explota el conteo de tareas — replenishers y pickers pelean por pasillos y equipo, y la productividad de pick cae. He visto el extremo: min tan alto que los slots nunca se vaciaban, pero replenishment se comía casi el 40% de la mano de obra del piso mientras los pickers esquivaban carritos de replenishment todo el día. El objetivo de la lógica de replenishment no es «los slots siempre llenos». Es «los pickers nunca esperan por producto». Esos dos objetivos están exactamente a un lead time de distancia. Clavar esa distancia importa más que subir la línea de flotación.

Cuando replenishment y picking pelean por mano de obra: cómo priorizar

Esta es la regla que la mayoría de los equipos aplica al revés. Mi lista de prioridades — cada línea pagada con un proyecto:

1. Normalmente, picking (outbound) supera al replenishment rutinario. Outbound es una promesa al cliente; replenishment es eficiencia interna. La promesa al cliente siempre va primero.
2. Pero replenishment urgente supera a picking ordinario. Cuando un slot está vacío y la ola está esperándolo, las tareas de pick de ese slot están muertas de todos modos — rellena primero, luego pickea.
3. Separa el equipo: replenishers en reach trucks o pallet jacks, pickers en order pickers, escalonados por tiempo o pasillo — sin deadlocks frontales en el mismo pasillo.
4. Haz la prioridad dinámica en WES: eleva automáticamente las tareas de replenishment 30 minutos antes de que empiece una ola; eleva picking una vez que la ola está corriendo. Una prioridad hardcodeada castigará a un lado eventualmente.
5. Entrega de turno: las tareas de replenishment sin terminar deben entregarse como checklist explícita, nunca como «el próximo turno lo maneja». El próximo turno se ocupa, y la tarea desaparece.

He visto esta falla tres veces, siempre el mismo guion. Una víspera de go-live, el cliente insistió en «replenishment primero» porque «los pickers nunca deben esperar». En día de promo, los replenishers taparon cada pasillo principal, los pickers no podían meter sus carritos, y el SLA de envío explotó. Lo volteamos de noche a «picking primero, replenishment urgente salta la fila», y al día siguiente se recuperó. Así que no discutas replenishment-first versus picking-first conmigo — la respuesta es «depende», escrita en las reglas para que WES cambie automáticamente.

Checklist de víspera de go-live: 12 ítems para la lógica de replenishment

1. Cada slot de forward pick tiene min/max configurado por nivel ABC — no un número para todo el edificio.
2. La exclusión de replenishment en tránsito está configurada y probada contra órdenes duplicadas.
3. El plan de ola alimenta a WES con menos de 15 minutos de rezago, con alerta de frescura en su lugar.
4. Compuerta de calidad de datos del pronóstico configurada: degradación automática bajo el umbral de cobertura.
5. Las ventanas de tiempo están en huecos de ola, con tope de tareas por ventana.
6. Los SKUs calientes y de promo tienen sus propias reglas de nivel y pronóstico.
7. Reglas de prioridad definidas: picking sobre replenishment rutinario, replenishment urgente sobre picking ordinario.
8. La regla de elevación de replenishment 30 minutos pre-ola está en vivo.
9. Desconflicción de equipo y pasillo confirmada con el equipo del piso.
10. El lead time de replenishment está medido, no adivinado.
11. El dashboard de monitoreo de tareas-por-ventana existe: alerta tanto en cero sostenido como en picos repentinos.
12. La plantilla de entrega de replenishment entre turnos está lista con dueños nombrados.

Ve a checar cómo está configurado el min en tus slots de forward pick mañana. Si es un número en todo el edificio, olvídate de dormir esta noche y empieza con niveles ABC.

Por Lin Xiao, Consultor de implementación WMS

Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.