Understand SAP EWM
Note: This post belongs to the blog-series ‘Understand SAP EWM task interleaving’. The purpose of these series of blog-posts is to explain the concepts of the core features of SAP EWM in a simple way. We want to focus on the basic understanding rather than the smallest details.
Germany is famous for its Oktoberfest.
This queue type sequence makes sure that the resources which are operating within the respective resource groups will always get the subsequent task from a queue with queue type B once they’ve completed a task in a queue of type A.
In EWM Standard, the selection of the WT from the subsequent queue is based on the latest-start-date (so called LSD) and the travel distance. The LSD is calculated based on the times from the wave template and the expected processing time. The travel distance is calculated based on the coordinates of the bins or storage type edges. This sorting can be influenced by a Badi but we will neither go into detail how the Standard is calculating, nor do we look at the Badi option. We will keep focusing on the basic understanding.
The queue for putaway is setup to be semi-system guided. Thus, the operator is guided to the receiving bin on the staging area and is free to scan any of the HUs which are sitting there (would be annoying to ask for a specific one as there might be hundreds on the same bin). Once the operator has selected an HU, the system will show the destination bin on the RF screen.
The queue for stock removal is not setup as semi system-guided so the system will show a warehouse task for a specific bin & source HU.
If you now compare all this system-related stuff with our example process from the Oktoberfest you will notice that there are not much differences. Oktoberfest waiters are also working in two queues. One to delivery full mugs to empty tables – similar like incoming pallets have to be putaway to empty bins – and one to move empty mugs to the bar (similar like outgoing pallets have to be removed from the bins and placed to the outbound staging area).
The queue to deliver full mugs to the table – the counterpart to the putaway queue – is semi-system guided and the tasks are created with generic destination, based on the destination table types. That means that the waiters can grab any full mug from the bar and can decide to which table they are going to deliver it. Usually they will pick one where somebody is crying for more – if multiple guests are crying, usually the table with the best tipper.
The queue to remove empty mugs – our counterpart to the pallet removal queue – is also semi-system guided. So here is a small point where we have a difference to our warehouse example. The waiter can take any empty mug from any of the tables – the warehouse operator is guided to remove a specific HU. Still we could argue that we have some kind of in-build guidance or at least a sorting in our mug-process, as the number of empty mugs provides a good visibility of the urgency to head for a specific table. So the table with the most of the empty mugs is at the top of the empty-mug-removal queue.
The queue determination for the empty-mug queue is based on the the source tables. In those party-tents usually one waiter is responsible for a fixed set of tables – his ‘activity area’. But this is a topic we might look into with a separate post.
So in summary and as you can see – is almost the same thing.
In Germany we call it Oktoberfest – in EWM we call it Task Interleaving!