La pregunta que nadie hace hasta que ya es tarde
Un recurso entra al almacén. Tiene un dispositivo en la mano mostrando exactamente qué hacer a continuación. No una tarea — toda una secuencia de ellas, agrupadas, en un orden que tiene sentido para su ubicación física en ese momento.
Ese paquete agrupado y secuenciado es un Warehouse Order. Y la pregunta que la mayoría de los equipos nunca hace hasta que algo sale mal es: ¿quién decidió qué tareas van juntas, y en qué orden?
Por qué existe la agrupación
Imagina la alternativa. Un recurso toma una tarea de almacén, camina hasta una ubicación, la ejecuta, regresa por instrucciones, le asignan la siguiente, camina hasta una parte completamente distinta del almacén, la ejecuta, regresa de nuevo. Cada tarea es su propio viaje de ida y vuelta.
Así se ve un almacén sin Warehouse Orders: funcional técnicamente, agotador en la práctica. El tiempo de traslado domina. El recurso pasa más tiempo caminando entre tareas que ejecutándolas realmente.
Un Warehouse Order soluciona esto agrupando varias Warehouse Tasks en un paquete de trabajo ejecutable — asignado a un recurso, para un viaje, en una secuencia con sentido.
El diagrama de arriba es todo el caso de negocio de los Warehouse Orders en una sola imagen. Las mismas tres tareas, el mismo almacén. Sin agrupación: tres viajes separados, tres tramos de tiempo caminando sin producir. Con agrupación: un viaje, secuenciado, asignado como una sola unidad de trabajo.
Qué es realmente un Warehouse Order
En las propias palabras de SAP EWM: un Warehouse Order es el documento que representa un paquete de trabajo ejecutable que un empleado de almacén debe completar en un tiempo específico. Consiste en Warehouse Tasks — o, para inventario físico, ítems de conteo.
Eso es todo. No es un documento de negocio separado como una entrega o una orden de compra. Es un mecanismo de agrupación — la capa que toma la salida cruda de la actividad de almacén (tareas individuales) y la convierte en algo que una persona o una máquina puede ejecutar de forma eficiente.
El proceso completo de creación (pasos reales, customizing real)
Esto no es una caja negra. SAP EWM sigue una secuencia definida y configurable cada vez que crea un Warehouse Order. Aquí está de principio a fin, con la ruta de customizing real para cada paso configurable:
Recorrámoslo una vez en lenguaje simple:
- Se libera una wave, o se crean warehouse tasks directamente. Este es el disparador — la materia prima sobre la que trabaja todo el proceso.
- Las tareas se agrupan por activity area. Área de actividad de origen o destino, decidida por el Warehouse Process Type asignado a la tarea (por esto nuestra serie de WPT importa aquí — el WPT decide qué activity area aplica antes de que empiece siquiera la lógica de Warehouse Order).
- El sistema determina qué Warehouse Order Creation Rule (WOCR) aplica, según activity area y activity. Esto se configura, no es automático — tú lo defines.
- Las tareas se ordenan según un perfil de ordenamiento (sort profile) — hasta 15 campos, en la secuencia que tenga sentido para esa actividad (orden de ruta de picking, peso, lo que tu operación necesite).
- Se revisan los item filters, luego los subtotal filters para ver si cada tarea encaja con los criterios de la regla — peso mínimo/máximo, volumen, tiempo de procesamiento, ruta, y más.
- Se revisan los límites de tamaño, y el Warehouse Order se crea cuando se alcanza el límite o se consumen todas las tareas elegibles.
- Lo que sobra repite el proceso contra la siguiente WOCR en la secuencia de búsqueda. Si nada encaja en ningún lado, SAP EWM cae a una regla predefinida para que nada quede sin asignar.
Las reglas de respaldo que nadie configura (porque ya están ahí)
Aquí hay un detalle que vale la pena saber antes de abrir siquiera el customizing: SAP EWM viene con tres Warehouse Order Creation Rules predefinidas que no puedes personalizar y que existen puramente como red de seguridad.
| Regla | Cuándo se usa | Comportamiento |
|---|---|---|
| DEF | El warehouse process type tiene una WOCR asignada directamente, pero la tarea no cumple sus condiciones | Sin límites, excepto que todas las tareas deben compartir activity area, queue, y warehouse request/consolidation group |
| UNDE | Quedan tareas después de procesar todas las WOCR definidas por el cliente | Mismo comportamiento sin límites que DEF — un catch-all final |
| MFS | Un storage type controlado por Material Flow System (MFS) no tiene WOCR asignada por el cliente | Por defecto, límite de exactamente una warehouse task por orden |
Esto importa en la práctica: si nunca configuras ni una sola WOCR, tu almacén no se rompe. Cae a DEF. Las tareas se siguen agrupando y ejecutando — solo que sin ninguna de las optimizaciones que una WOCR bien diseñada te da. Muchas investigaciones de «por qué este warehouse order es raramente grande o raramente pequeño» terminan con la misma respuesta: nadie reemplazó nunca el fallback.
El reto práctico de esta semana
- Elige cualquier Warehouse Order de la actividad de hoy en tu sistema
- Ábrelo y revisa qué Warehouse Order Creation Rule se usó realmente
- Si es DEF, UNDE o MFS — pregunta por qué. ¿Es intencional, o es un hueco que nadie ha configurado todavía?
Cierre
Un Warehouse Order parece un detalle pequeño, casi administrativo — un contenedor de tareas. Pero es la capa que separa «técnicamente correcto» de «realmente eficiente» en la ejecución del almacén. Cada minuto que un recurso pasa caminando en vez de trabajando se remonta a qué tan bien — o qué tan mal — se diseñó esta configuración.
En el Post 2 de esta serie entramos en detalle a cada perfil de WOCR: item y subtotal filters, sort rules, limit parameters, y el packing profile que decide cómo se arman las pick handling units.
Parte de la serie Warehouse Orders
Deja un comentario