A new sortation line goes live on a Monday. By Wednesday, cartons are stacking up at a merge point. The warehouse management system shows every order released on time. The equipment controller shows every motor running and every sensor healthy. Each system reports that it is doing its job, and yet product is not moving. Nobody in the room can say which system is responsible for the jam.
This scene plays out on automation projects of every size, and it usually traces back to one gap: nobody defined which software layer makes which decision. Most facilities already run a warehouse management system (WMS). Adding conveyors, robots, or storage and retrieval equipment introduces two more layers, a warehouse execution system (WES) and a warehouse control system (WCS). This article explains what each layer controls, where the handoffs tend to break, and which questions to settle before any equipment is ordered.
What Each Software Layer Controls
The three acronyms are often used interchangeably, but each one answers a different question. Keeping them separate makes every later design conversation easier.
- WMS is the system of record for inventory. It knows what you own, where it sits, which orders are open, and how the warehouse connects to the ERP and transportation systems. It decides what work needs to happen.
- WES orchestrates that work in real time. It balances waves and orders against available labor and automation capacity, adjusts priorities as conditions change, and keeps flow even across zones. It decides when and where work happens.
- WCS talks directly to the machines. It sends commands to conveyors, sorters, shuttles, and lifts, and receives status and fault signals back. It decides how a device carries out an instruction.
A simple way to hold this together: the WMS decides what, the WES decides when and in what order, and the WCS decides how. In smaller systems, one product may cover two of these roles. The roles still exist, and someone still has to own each one.
Where Handoffs Break Down
Problems rarely live inside a single system. They show up at the seams, where one layer passes responsibility to the next. Four patterns appear again and again.
- Overlapping logic. The WMS releases work based on one set of rules while the WES re-sequences it based on another. When both layers try to control priority, the result is conflicting instructions and work that stalls between them.
- Mismatched timing. A WMS thinks in orders and waves, often on a scale of minutes. Equipment thinks in fractions of a second. If the layer in between cannot buffer that difference, equipment starves or floods.
- Unowned exceptions. A carton fails to scan, a tote arrives damaged, or a pick comes up short. If no layer is assigned to handle the exception, the item sits until a person notices.
- Inconsistent data definitions. Unit of measure, container identifiers, and location naming need to match across every system. A mismatch that looks minor on paper can block a whole lane.
Each of these is cheap to fix on a whiteboard and expensive to fix after installation.
Questions to Settle Before You Buy Equipment
The most useful integration work happens early, while layouts and requirements are still flexible. Working through these questions during discovery, before any automation solution is selected, gives every vendor the same clear target and keeps the design honest.
- Who owns task priority? Decide which layer can change the order of work once it is released, and which layer can only execute it.
- Who owns sequencing and buffering? Define where cartons or totes wait when downstream capacity is full, and which layer decides when they move.
- What happens at a no-read, short pick, or damaged item? Name the destination, the owner, and the system that records the outcome.
- Which system is the source of truth for inventory when equipment is down? Decide how counts are reconciled when a device faults mid-transaction.
- How will changes be handled later? New SKUs, new carriers, and new workflows will arrive. Agree on who edits rules and how those edits are tested.
- How will the system integrate with the ERP and the WMS you already run? Confirm interface methods, data formats, and response times early.
Answers written down at this stage become the requirements document that keeps scope from drifting during design.
Do You Need All Three?
Not every operation needs three separate products. A facility with a single conveyor loop and a capable WMS may be well served by a WCS and the WMS alone. Execution software tends to earn its place when several kinds of automation share the floor, when labor and equipment must be balanced against each other, or when peak volume makes real-time reprioritizing valuable.
The better question is whether each of the three roles has a clear owner. If a role is handled by an existing system, document that decision. If a role is unassigned, that gap is the place to look first when planning the project.
Test the Seams Before Go-Live
Standard testing proves that each system works. Integration testing proves that the three work together, and it deserves its own plan. Build test cases around the exceptions identified earlier: no-reads, short picks, full buffers, a device that faults mid-task, and a network interruption. Run them with the people who will operate the system.
Operator training belongs in the same plan. Teams that practice recovery steps, and not only the ideal flow, stabilize faster after launch. The goal is a floor where every associate knows who or what to check when work stops moving.
Back to Monday Morning
The sortation line from the opening did not fail because any one system was weak. It stalled because no one had decided which layer owned the merge. Writing down who decides what, in plain language, before equipment arrives is one of the lowest-cost steps in an automation project and one of the most valuable. Start with a single page that lists each decision, the layer that owns it, and the exception path when something goes wrong. That page will answer most of the questions that otherwise surface after go-live.
