To have a dynamic and efficient Warehouse, which quickly responds to any picking requirement is a challenging goal. Sometimes however the most obvious questions are the most important ones and they are rarely being told on sophisticated workshops (with all respect to appointed consultants, super users and process owners).
One good example of such obvious question is when shipping supervisor simply asks how many people he/she will need for picking on particular day. Or on another point: he/she does not ask the question in a good time ahead, but while looking at the picking queue he/she merely notes: “oh, where are my pickers?” The situation might be even more awkward in case the legacy system supported the resource planning in some way.
There might be some reasons why this data is missing in EWM. In most of the deployments it is a good practice to create delivery only a short time ahead of pick/pack time and in case of CD scenario the delivery is typically created just on the day it is needed. When delivery is short, it is a good practice to nilpick it or adjust the quantity and on the next day to start afresh. This industry best practice however does not allow to perform planning of picking personnel. In today’s system it is also not possible to limit the WT processing in a queue if LSD of the WO lies in future (the WO is for tomorrow for example).
For MTO or CD scenarios we can implement document flow for unchecked deliveries, we can get future pick list. Ie. that would be an equivalent of extracting the data from VBEP and EKET tables. That can help, but is not providing the real time needed for picking. An average picking time per item can help here, but currently this value is not stored anywhere in the system and we need to process it outside. In replenishment scenarios we are left in the dark, until the MRP run generates STOs.
On the other side, EWM provides very flexible tool how to calculate planned picking time once the WT exists in terms of utilizing different resource types, horizontal and vertical distance calculations, resource speed, process durations and warehouse order preparation time. It is not however currently possible to utilize this logic, when there is no warehouse request and when there is no available stock. There is no simulation functionality and to mimic this tool outside of SAP would mean to replicate all warehouse logic.
Having a second look onto the projection algorithm, there is a number of manual inputs as of the number of pick-HUs or number of pallets the picked stock can fit in. For picking itself we do not really require to know what the Means Of Transport will be, or what size of truck will arrive. The aim here is to make the stock available for loading. Rough determination for palletization based on customer and/or consolidation group, which is currently used for packing validation and basic weight/volume data can be enough for projection purposes. The algorithm could use past data as well.
So getting back to the source document, a good way how to achieve this would be to incorporate a new Expected Goods Issue logic, which could bypass the delivery creation constraints and which could also include the average replenishment requirements. For planning purposes such a document would allow to calculate and to project the outbound processing time based on current internal warehouse configuration and based on assumption the stock will be available in its fixed bins or in the most appropriate put away bin.
The expected goods issue information would provide data to internal resource planning, fixed bin management and internal slotting. The main benefits here are the warehouse optimization in terms of knowing how many FTEs is needed on particular day and in terms of dynamic fixed bin determination, which will have a major impact on the On Time Shipment KPI.
Having in mind the EWM configuration flexibility this idea will most likely stay as a consulting solution with the help of custom enhancement.
