Warehouse automation software

Why the layers matter

Warehouse automation is usually discussed in terms of equipment — conveyors, shuttles, sorters, mobile robots, arms. In practice the equipment is the easier half. Most automation projects underdeliver because of software boundaries, not because a machine could not move fast enough.

There are three established layers, and knowing which one owns a decision is the difference between a coherent system and a set of machines that disagree.

WMS: the warehouse management system

The system of record for inventory and work. It knows what is in the building, where it is meant to be, what orders exist, and what needs to happen to fulfil them. It typically owns receiving, putaway strategy, inventory accuracy, order management, wave or batch planning, and the interfaces upward to the enterprise systems.

What a WMS is generally not good at is real-time physical coordination. It thinks in tasks and inventory states, usually on a timescale of seconds to minutes, and it is not designed to arbitrate between two machines that want the same aisle right now.

WCS: the warehouse control system

The layer that talks to equipment. It drives conveyors, diverts, sorters, carousels and similar fixed automation, operating close to real time and concerned with device state, interlocks and throughput at the machine level.

A WCS is typically deep and narrow: excellent at keeping specific equipment running, not designed to make strategic decisions about what work should happen next.

WES: the warehouse execution system

The layer that emerged because the gap between the other two was causing trouble. A WES decides, in the moment, how to get planned work done given the state of the building: which resource does which task, in what order, balancing across equipment and people, reacting to congestion and failures.

In practice the boundaries blur badly. Vendors ship WMS products with execution features and WCS products with execution features, and "WES" sometimes describes a distinct system and sometimes a capability bolted onto one of the others. The label matters far less than being able to say which system owns each decision.

Where robots fit

Mobile robots and manipulators arrive with their own software, and it overlaps the existing layers in ways that are frequently unresolved at purchase:

• Fleet management owns traffic: where each robot is, routing, congestion, charging, deadlock avoidance. This overlaps WES task assignment directly.
• Robot capability software owns what the machine does at a task level — grasping, placing, scanning — which sits below anything the WMS understands.
• The vendor's own interface is frequently a task-level API that assumes it is being told what to do by something, and the question of what that something is often goes unanswered until integration.

The practical consequence: introducing robots usually introduces a second scheduler. If the WES and the fleet manager both believe they are allocating work, you have two planners with partial information competing for the same resources, and the symptom is throughput well below the sum of the parts.

Where integrations actually fail

• Two schedulers. As above. The most common and the most expensive.
• Inventory truth drift. The robot moved something and the WMS does not know, or knows late. Everything downstream is then planned against a fiction.
• Exception handling. The happy path is specified in detail and the exceptions are left to be discovered. Exceptions are the majority of integration effort.
• Latency assumptions. A layer designed around second-scale responses being asked to participate in a decision that needs milliseconds.
• Identity and state. Two systems using different identifiers for the same tote, pallet or location, reconciled by a mapping nobody owns.
• No single operational view. When throughput drops, three dashboards each show their own layer as healthy and nobody can see the interaction.
• Undefined failure ownership. A task fails and triage stalls because no layer records enough to establish whether it was equipment, software or the physical world.

Questions to settle before signing anything

• Which system is the system of record for inventory, and how quickly does it learn about a physical move?
• Which system assigns work to a robot, and what happens if the fleet manager disagrees?
• Where is the single operational view when throughput drops?
• What is the exception taxonomy, and who handles each category?
• What are the real latency requirements at each boundary, and have both sides agreed them?
• Who owns the identifier mapping between systems?
• When a task fails, what is recorded, and who triages it?
• What is the measured baseline the new system will be compared against?

That last one is not a software question and it decides more projects than any of the others. An automation project without a pre-existing baseline cannot be shown to have worked.

The part that is not software at all

Two things decide warehouse automation outcomes more than any system choice, and neither appears in a software comparison.

Change management. The people doing the work know the exceptions, the workarounds and the reasons the documented process is not the actual process. A project that treats them as an obstacle loses access to exactly the knowledge it needs, and a project that involves them early tends to discover its real requirements before go-live rather than after. This is not a soft consideration; it is where the exception taxonomy comes from.

Process before automation. Automating a process that is badly designed produces a faster bad process and makes it harder to change. The questions worth asking first are whether the task needs doing at all, whether it could be eliminated by a layout or sequencing change, and whether the current step order exists for a reason or by accident. Those answers frequently deliver more than the automation would have.

What to measure

Automation claims are usually made in throughput, and throughput alone is a poor summary. The figures that actually characterise a system:

• Throughput at a stated accuracy, not peak throughput. Speed with a higher error rate is not an improvement if downstream correction eats the gain.
• Intervention rate. How often a person has to step in, in what categories, and how long each takes.
• Availability. Uptime against planned operating hours, including the time lost to recovery rather than to the fault itself.
• Exception distribution. Which exceptions dominate, since the long tail decides staffing.
• Inventory accuracy before and after, because an automation project that degrades record accuracy has created a problem elsewhere.
• Time to recover from a stoppage, which is usually longer than the stoppage.
• Cost per unit handled, fully loaded, against the measured baseline.

And the baseline has to exist before anything is installed. Retrofitting one afterwards means comparing the new system against a recollection.

What this has to do with capability software

A capability layer for robots sits beneath all of this and has to be a well-behaved participant in it. That means exposing task-level operations something else can schedule, reporting state changes promptly enough that the system of record stays true, surfacing exceptions in categories an operator already understands, and producing telemetry that makes failure triage possible across boundaries rather than only within one.

Capability that cannot be scheduled, monitored and triaged by the systems a warehouse already runs is not deployable in a warehouse, however good the manipulation is.