Downstream first

WHILE WAREHOUSE control software is focused on controlling the flow of goods through automated warehouses, execution software, is used to optimise workflows by controlling the timing and location of order processing. By optimising order release timing, execution software is able to avoid bottlenecks by avoiding differential throughputs of upstream and downstream workflows. For example, by slowing down order release if the put-wall is flooded.

Warehouse Execution Software (WES) emerged in response to two key trends: the shift from ‘Islands of Automation’ to ‘End-to-End Solutions’; and the transition towards waveless picking for omni-channel and eComm fulfillment. The shift towards end-to-end solutions led to the need for better orchestration across multiple sub-systems. This was particularly true for the US where the ‘pure-play integrator’ model is more common, compared to Europe, where, ‘turn-key solutions’ from a single OEM/Integrator is more typical.

The emergence of omni-channel retail put pressure on the traditional wave picking methodology. If a direct-to-consumer order was received, it couldn’t be released to the warehouse until the previous wave was complete, which could take several hours. It also made it difficult to expedite high-priority direct-to-consumer fulfillment which is often more profitable.

In addition to the difficulties associated with expediting priority orders, wave-based picking also led to inefficiencies during the order consolidation phase. This is because if the release of waves doesn’t match the rate at which batch-picked orders are consolidated downstream, bottlenecks and throughput constraints occur.

Downstream first

With waveless picking individual orders are released to the warehouse based on the throughput of downstream order consolidation. If, for example, downstream order consolidation slows down (e.g. if the put-wall is flooded), the waveless picking algorithm releases orders at a slower rate. Conversely, if downstream workflows are taking place at a rapid rate, the algorithm will release orders to the warehouse at a faster rate. Using the rate at which the downstream workflows occur to dictate the rate at which orders are released to the warehouse is referred to as a ‘pull’ system, because the downstream throughput is ‘pulling’ the upstream order release.

In order to use waveless picking, you need to know the rate at which different workflows are happening since the order release timing is based on downstream throughputs. Early systems used approximations of these throughput rates to improve the order release timing. However, WCS vendors were able to collect accurate, real-time data on the throughput of various systems in the warehouse, such as automated sortation or put-to-light systems, allowing them to create high efficiency waveless picking algorithms, becoming what we would describe today as WES.

The benefits of WES are not limited to order release timing. Because the WES has visibility of the utilisation (and thus, the throughput) of all automated systems, it can promote manual workflows if the automated systems are at full capacity. For example, if the automated sortation system is flooded, it may direct batch-picked totes to a manual put-wall.

As we’ve described, the WES orchestrates the timing and location of warehouse workflows in order to optimise throughput. We have three criteria for a system to be described as a WES: 1) it must be able to dynamically release orders to the warehouse based on the utilisation status of the automation equipment, 2) it must be able to orchestrate multiple sub-systems, and 3) it must be able to orchestrate both man and machine.

Types of WES

The first WES were developed from WCS solutions because they had real-time visibility of the utilisation of the equipment and could therefore control the order release timing based on system availability. We define warehouse execution systems that ‘grew’ out of WCS solutions as ‘Warehouse Control Execution Systems’ or cWES solutions.

However, a warehouse execution system doesn’t ‘need’ to control the automation in order to gain real-time visibility into the system availability. In many cases, the execution layer doesn’t actually ‘control’ the automation at all. For example, Manhattan Associates’ Active WM solution receives real-time information from the WCS and uses this data to provide execution capabilities. In the case of Manhattan Associates’ solution, the WES is ‘embedded’ into its WMS. We therefore define WES solutions that sit above the WCS as ‘embedded WES’ (or eWES) solutions.

While most eWES solutions are truly ‘embedded’ into the WMS, some can be sold as standalone solutions, such as Softeon’s WES. If an eWES is sold as a standalone solution, it would sit between the WCS and the WMS as an additional layer.

The argument for having a stand-alone execution is that most end-customers’ network of facilities have a heterogenous makeup of WMS and automation solutions. Using a stand-alone execution layer means that you’re not tied to a specific automation vendor or WMS provider, allowing the end-customer to have execution consistency across different facilities.

The term warehouse execution system has become blurred and one of our aims is to provide clarity and objective criteria for defining warehouse automation software.

Rueben Scriven, senior analyst, Interact Analysis

To learn more about Interact Analysis’ research on warehouse automation software, click here