Warehouse automation software is used to control, execute, and manage the operations of automated warehouses. Control software is focused on controlling the flow of goods through automated warehouses. This includes warehouse control systems (sometimes referred to as material flow controllers) used to control the flow of goods across fixed automation, as well as fleet management systems which control the flow of AMRs and AGVs.

Execution software, on the other hand, is used to optimize workflows by controlling the timing and location of order processing. By optimizing 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. Furthermore, the execution layer is used to avoid congested areas of the warehouse. For example, if the shuttle-system is operating at full capacity, the execution layer can direct pickers to the forward-pick area for manual picking.

Visual Depiction of What’s Included within the Scope of Our Analysis

This insight will discuss the story of how the execution layer emerged and the criteria we use to assess whether a WES is ‘truly’ a WES. We’ll finish off by outlining the two types of warehouse execution systems on the market today: Warehouse Control Execution Systems (cWES) and Embedded Warehouse Execution Systems (eWES).

How the Execution Layer Emerged

The execution layer emerged in response to two key trends: 1) the shift from ‘Islands of Automation’ to ‘End-to-End Solutions’, and 2) the transition towards waveless picking for omni-channel and e-commerce fulfillment.

End-to-End Solutions

As automation become more advanced and more processes were able to be automated, we started to see more end-to-end solutions, rather than islands of automation. 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 far more common. These companies integrate disparate sub-systems, requiring a high degree of orchestration which can be hard to achieve when dealing with equipment built by different manufacturers. This is because each manufacturer has their own communication protocol and it can be difficult to get each system to communicate with one another. Europe, on the other hand, ‘turn-key solutions’ are far more common whereby a single OEM/Integrator is responsible for building and integrating the entire solution, making it easier to orchestrate and optimize the overall system. As a result, the ‘need’ for an execution layer was less pressing in Europe because there was less friction in the communication between sub-systems which is why much of the hype around WES has been limited to the US.

Trend towards Waveless Picking

The second trend which led to the emergence of the execution layer is the transition towards waveless picking for omni-channel and e-commerce fulfillment. Prior to e-commerce and omni-channel retail, warehouse picking for wholesale and store-replenishment was done using waves; groups of orders that are released to the warehouse at the same time. Typically, 2 to 4 waves were processed per day and, from an efficiency stand-point, the larger the number of orders grouped into each wave the better.

However, the emergence of omni-channel retail put pressure on the traditional wave 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. Most warehouses which use wave-based picking release waves either periodically or once the previous wave has been complete. The problem with releasing waves periodically is that you can end up with bottlenecks if waves are released at a faster rate than the downstream consolidation. Conversely, waiting until the previous wave is complete before releasing a new wave can lead to the upstream pickers waiting idly whilst the downstream consolidation finishes.

How the Execution Layer Enabled Waveless Picking

As the name suggests, waveless picking doesn’t use waves. Instead, individual orders are released to the warehouse based on the throughput of the 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 warehouse execution systems (WES).

However, the benefits of a WES are not limited to just order release timing. Because the WES has visibility of the utilization (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 shuttle-based AS/RS is working at full capacity, it may direct pickers to the manual forward-pick area. Similarly, 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 optimize 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 utilization 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 (e.g. if the automated shuttle-system is at capacity, the system directs a manual picker to the forward pick area instead of using the shuttle system).

Two Types of Warehouse Execution Systems

The Various Types of Warehouse Execution Systems

As we mentioned before, the first warehouse execution systems were developed out of existing WCS solutions because they had real-time visibility of the utilization of the equipment and could therefore control the order release timing based on system availability. In effect, execution capabilities were ‘bolted on’ to existing WCS solutions. 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.

Whilst most eWES solutions are truly ‘embedded’ into the WMS, some can be sold as stand-alone solutions, such as Softeon’s WES which can either be embedded into its WMS or sold independently. If an eWES is sold as a stand-alone solution, it would therefore 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.

Final Thoughts

The term Warehouse Execution System has become blurred and distorted. One of our core objectives is to provide clarity and objective criteria for defining warehouse automation software. To learn more about our warehouse automation software research, reach out to Rueben Scriven.