Smart warehouse / Article
WMS vs WCS vs WES: Which Software Layer Actually Runs the Floor
Three layers, three different jobs. A WMS is the system of record: it owns inventory, locations, orders and labour, and it plans over minutes to hours. A WCS is the machine layer: it turns instructions into commands for cranes, shuttles, conveyors, sorters and robot fleets, and reports status back continuously. A WES sits between them and orchestrates execution: it decides sequence, batching and task allocation across people and machines according to what the floor is actually doing right now. They are complementary layers rather than competing products, and the expensive part of an automation project is almost never choosing between them. It is the interface where they meet.
The layers at a glance
01 / The three layers
One record, one orchestrator, one machine controller
Start with the plainest possible description of each, because the acronyms do most of the damage. A warehouse management system is a supply chain application that manages the flow of inventory into, within and out of a distribution centre, and it is where your stock figure, your locations, your order status and your labour tasks live. It is the layer your finance team, your customer service desk and your auditors care about, because it is the version of the truth the business runs on.
A warehouse control system works one level down and much faster. It is software that directly controls automation equipment such as conveyors, sortation systems and robotic pickers, and it is the layer that knows a shuttle is at level four, that a lift is occupied, and that a diverter has to fire in the next moment or the carton goes the wrong way. It is also, as one vendor puts it, the interpreter between software logic and physical hardware, without which automation cannot act on instructions from higher-level systems.
A warehouse execution system is the newest of the three and the one buyers find hardest to place. The clearest framing is a division of verbs: the WES orchestrates execution, prioritising and batching orders, managing material flow and assigning tasks to the control systems, while the WCS executes and reports back. Where a WMS plans a wave, a WES decides what actually happens in the next few minutes given that one station is backed up, one operator is on break, and the courier cut-off is in ninety minutes.
The sentence worth remembering
The most useful summary we have seen of how the three interact in practice is this: the WMS releases order data, the WES decides when and how to act on it based on live conditions, and the WCS carries those instructions to the equipment. When something changes mid-shift, a conveyor stops, labour arrives late, a station fills up, the WES reacts immediately, well before the WMS registers that anything happened. Hold that sentence and most vendor conversations become easier to follow.
02 / Side by side
What each layer owns, and on what clock
The distinction that matters operationally is not feature lists. It is time horizon and scope of decision. A layer that decides over hours cannot be trusted with a decision that must be made in a second, and a layer that thinks in machine cycles has no business owning your inventory valuation.
| Layer | Owns | Decision horizon | Typical trigger to buy | What it cannot do |
|---|---|---|---|---|
| WMS | Inventory, locations, order status, receiving, putaway, replenishment, labour, shipping documents | Minutes to hours, and the whole shift | You have stock and orders. Every warehouse needs a record | Command machines. It does not control conveyor sortation, carton tracking or machine signals |
| WES | Sequence, wave and batch decisions, task allocation across people and machines, live rebalancing | Seconds to minutes | Several automated subsystems and human zones must be sequenced against one cut-off | Replace your record. It optimises work, it is not where your inventory truth lives |
| WCS | Equipment commands and status: cranes, shuttles, lifts, conveyors, sorters, robot fleets, scanners | Sub-second to seconds | Comes with the automation. The machines cannot run without it | Reason about orders, customers or labour cost. It moves what it is told to move |
| ERP or MES | Financials, production orders, BOM, work orders and plant scheduling upstream of the warehouse | Days to weeks | Already in place. Warehouse automation must feed it, not fight it | Run a floor. Warehouse execution at machine speed is not what it was built for |
Scroll the table sideways on a phone / Vendor definitions of WES vary; this is the mainstream reading
One honest complication. Some vendors sell a WES that absorbs both neighbours: rather than using a WCS to manage automation and a WMS to manage everything else, a WES handles the work both were responsible for from a single system. Others sell a WMS with WES and WCS modules bolted on, and leading WMS platforms now offer functionality that can be integrated with or combined with other systems to provide WES and WCS behaviour. So the same three words describe both an architecture and a set of product boundaries that every vendor draws slightly differently. Ask what a product decides, not what it is called.
03 / The conflation
Four ways buyers get this wrong
We see the same four confusions on Malaysian floors, and each one has a predictable cost attached.
Notice that three of the four are scope errors rather than product errors. The buyer has correctly identified a problem and pointed it at the wrong layer. That is why we spend the first conversation establishing which layer a symptom belongs to before anyone opens a price list.
04 / The WMS
The record is the foundation, and it has to be true
A WMS earns its keep by being right. It manages inventory, orders, receiving, picking, packing, shipping and replenishment, and every layer above and below it inherits its assumptions. The functional list is well understood: order allocation and planning across longer time horizons, from minutes to hours, plus labour management and the inventory record itself.
What matters for an automation project is narrower than the feature list, and it is worth writing down before you talk to any hardware vendor. Does your WMS hold a location for every unit, at the granularity the automation will work in? Can it expose and accept task and inventory messages through a documented interface? Does it have a defined behaviour when a scan fails or a count does not match, or does that case currently get handled by a person walking over with a clipboard?
That last question is the one that decides project timelines. Automated retrieval trusts your records absolutely. It goes to the location the data names and it brings back whatever is physically there, quickly and without judgement. A floor where the system says forty and the shelf says thirty-two does not become accurate when a robot starts moving totes. It becomes wrong faster. This is why we treat inventory accuracy as a prerequisite rather than a benefit, and why the data layer of a smart warehouse is designed in at the start rather than added once the racking is up.
You probably do not need a new one
Two large projects at once double your risk and destroy your ability to diagnose. If your WMS holds accurate locations and can talk through a documented interface, keep it and build against it. If it cannot, that is a separate project with its own timeline, and it comes first. What almost never works is replacing the record layer and installing automation in the same quarter, then trying to establish which one caused the discrepancy.
05 / The WCS
The layer you do not shop for, but must specify
Almost nobody sets out to buy a warehouse control system. It arrives with the equipment, because the equipment cannot function without it. A crane needs something to sequence its moves, a shuttle fleet needs something to prevent two units contesting the same lane, a robot fleet needs something to assign tasks and manage charging, and a sorter needs something to fire a diverter at the right moment. Control software provides real-time control over automated systems, letting you optimise the movement of goods through the warehouse, and in a large facility multiple control systems may work in concert to manage different zones or equipment types.
Because it is bundled, it is also the layer that gets least scrutiny at contract stage, which is a mistake. Three things about a control layer determine how your floor behaves for the next decade. First, what it exposes: can the layer above see inventory position, task status, machine health and error state, or only a summary? Second, how it handles exceptions: what happens to a tote whose barcode will not read, and does a human get a queue to work or a mystery to solve? Third, whether more than one control layer has to coexist, which is normal the moment you run storage from one supplier and mobile robots from another.
Shuttle-based storage makes the point sharply. Field guidance notes that shuttle systems need robust execution software to coordinate vehicle traffic, manage charging cycles and optimise task sequencing across hundreds of moving parts. That is not a nice-to-have layered on top of the racking. It is the difference between the throughput on the quotation and the throughput on your floor, which is precisely why we simulate throughput before anything is built rather than after.
06 / The WES
The orchestrator, and the honest case for skipping it
A warehouse execution system exists because of a specific failure: a floor where every individual machine is fast and the operation still misses its cut-off. It focuses on real-time coordination and optimisation of material handling tasks and resources, acting as the operational brain that orchestrates order fulfilment and task allocation across automated systems and human operators. The value is in the word across. Its job is the seam between subsystems, and between machines and people.
The way it earns money is by replacing fixed release logic with live decisions. It coordinates day-to-day activities by directing workflows, prioritising tasks and balancing resources, reducing idle time. On a real floor that reads as: hold this order because its second line is in a lane a shuttle is already serving, send the operator at station three a batch that suits the totes already in transit, and stop feeding station one because it is two totes deep and the operator is falling behind.
When you genuinely need one
And when you do not: a single storage block feeding one or two stations, a stable order profile, one automation supplier, no hard cut-off. In that shape the control layer plus a competent WMS interface does the job, and adding an orchestration layer adds licence cost and a second place where rules live. The layers are complementary rather than competing, which cuts both ways: you can add the orchestrator later, when the floor is complex enough to need it, provided the interfaces underneath were built to be spoken to.
07 / Where integration happens
The seam between the record and the machines
Here is the part of the software question that actually consumes project time, and it is not on any of the three product datasheets. It is the interface. Your record layer knows what should move and where it belongs. Your control layer knows how to move it. Everything difficult happens in the messages between them, and in the physical identification that makes those messages true.
That physical identification is the piece buyers most often leave out of the software conversation, and it is where a CODETRACE deployment starts. Fixed-mount and handheld 1D and 2D scanners, printer applicators labelling on the fly in a consistent position, and RFID readers tie every pallet, tote and case back to your WMS. That is what turns a location record into something a machine can act on: a unit that identifies itself at each handover, so the record and the shelf agree without anyone reconciling at the end of the shift. If the reading technology decision is still open on your floor, we compare it directly in the inventory accuracy article.
Above that sits the integration layer proper, and the design goal is explicit: WMS, MES, ERP and your logistics providers operating as one connected operation. In practice that means agreeing a small number of things very precisely. Which system owns the location record, and which one defers. What a task message contains, and what a completion message returns. How an exception is raised, who owns the queue it lands in, and what the floor does while it waits. How inventory is reconciled if a message is lost, and how the two sides resynchronise. Where the ASRS and AMR control layers exchange task and status with the record, and at what granularity.
None of that is glamorous and all of it is decisive. A robot that moves a tote the WMS believes is somewhere else is not a hardware fault. It is a missing message contract. A putaway that has to be keyed twice is not an operator problem. It is an interface that was never specified. The reason we design the data layer alongside the movement and storage layers, rather than after them, is that these are the failures that survive commissioning and quietly cap what the floor can do.
08 / Vendor questions
Eight questions that decide whether integration goes well
Ask these before signing, in writing, of whoever is supplying the automation. The answers predict your commissioning experience more reliably than any throughput figure.
Question seven and question eight are the two we would not compromise on. Simulation is where expensive mistakes surface cheaply: that the lift rather than the shuttle count is your ceiling, that a two-hour evening wave needs buffering, that the third station adds nothing. And the last stretch of any integration is tuned against the real messages, the real scans and the real exception traffic, which cannot be done from a datasheet.
09 / On your floor
Floor study, then design and simulate, then integrate
We do not sell software on day one either. The software layer is a consequence of what the floor has to do, so the sequence starts with the floor: flows, volumes, SKU profile, real clear height and column grid, inbound and outbound patterns by hour, and where the queues actually form. Then the layout is designed and throughput simulated, so the system is proven before it is built. Only then does deployment happen: install, commission, integrate with your WMS and train your team.
Whether you need an orchestration layer falls out of that exercise rather than being decided in advance. A floor with one storage block and two stations usually does not. A floor running storage, an AMR fleet, manual picking and a hard cut-off usually does, and knowing which one you are before you buy is worth more than any feature comparison. The same applies to how much automation you need at all, which is the question we work through in what makes a warehouse smart and, for the movement layer specifically, in AMR vs AGV vs conveyor.
CODETRACE integrates on site from Shah Alam in Selangor and Batu Kawan in Penang, so the team that specifies the interface is the team that commissions it and the team you call when a message stops arriving at two in the morning. For plants where the warehouse is one part of a wider automation plan, the same integration discipline applies upstream into factory automation and MES.
Choose the layers by what they decide. Then spend your attention on the seam between them.
FAQ / Warehouse software layers
Questions, answered.
01What is the difference between WMS, WCS and WES?
They sit at three different levels. A WMS is the system of record: it owns inventory, locations, orders and labour, and plans over minutes to hours. A WCS is the machine layer: it controls automated equipment such as cranes, shuttles, conveyors, sorters and robot fleets, and reports status back in real time. A WES sits between them and orchestrates execution: it decides sequence, waves, batching and task allocation across people and machines based on live floor conditions. In practice the WMS releases the order, the WES decides when and how to act on it, and the WCS carries the instruction to the equipment.
02Do I need all three systems?
No. Every warehouse needs a system of record, and every automated warehouse gets a control layer with the equipment because the machines cannot run without one. The WES is the layer that is genuinely optional. You need it when several automated subsystems and human work areas have to be sequenced against each other under time pressure, or when a fixed wave release is leaving your stations idle. A single ASRS block feeding two stations rarely needs one. A floor running an ASRS, an AMR fleet, manual picking and a cut-off does.
03Can my existing WMS run an ASRS or an AMR fleet?
It can instruct them, but it should not try to control them. A WMS decides what needs to move and where it belongs. Deciding which crane, which shuttle, which robot, in what order, on what charge state, avoiding deadlock in a lane, is control-layer work that runs on a different clock. The correct answer for most Malaysian sites is to keep the WMS as the record, let the equipment control layer own the machines, and build a clean interface between them rather than pushing machine logic into the ERP or WMS.
04Where does the integration actually happen?
At the interface between the record and the machines, and it is almost always the part of the project that is underestimated. In a CODETRACE deployment that means scanners, printer applicators and RFID readers tying every pallet, tote and case back to your WMS, and the ASRS and AMR control layers exchanging task and status messages with it, so WMS, MES, ERP and your logistics providers operate as one connected system rather than four that reconcile at the end of the shift.
05What happens if the interface is wrong?
You get a fast machine and a slow operation. The usual symptoms are a robot that moves a tote the WMS believes is somewhere else, a putaway that must be keyed in twice, an exception that no system owns, and a shift that ends with a manual reconciliation. None of those are hardware faults. They are gaps in message contracts, in who owns the location record, and in what the system does when a scan fails.
06Should I replace my WMS before automating?
Usually not, and rarely at the same time. Two large projects at once double the risk and make it impossible to tell which one caused a problem. What matters more than the brand of your WMS is whether it holds accurate locations and can expose task and inventory data through a documented interface. If the records are wrong, fix that first, because automated retrieval trusts your data absolutely and will go to the location the record names.
07How does CODETRACE handle the software layer?
We treat integration as part of the system rather than a line item at the end. The sequence is a floor study first, then layout design and throughput simulation, then deployment: install, commission, integrate with your WMS and train your team, supported from Shah Alam in Selangor and Batu Kawan in Penang. The scanning, labelling and RFID layer is designed in from the start, because a floor that cannot identify what it is holding cannot be automated reliably no matter which software sits on top.
Sources / Every definition in this article
Where the definitions come from
Sources are listed by what they are rather than by brand name. All of these are software or automation vendors writing about their own category, so read every boundary as one drawn by a company with a product on one side of it. The layer model is consistent across them, which is why it is worth trusting; the exact product boundaries are not.