Warehouse Execution System Development: Why Automation Hits a Ceiling Below Its Design Rate

Why automated buildings underperform their design rate

A distribution centre has spent heavily. There is a goods to person system with robots delivering totes to pick stations, a shoe sorter for outbound, a print and apply, an automated carton erector and a mezzanine of manual pick modules for the long tail. On paper the building was designed for a certain units per hour. In practice it hits that in a benchmark and never in a peak.

Walk the floor at 2pm during a peak wave and you can see why. Four pick stations at the goods to person system are idle because the wave that was released is heavy on items stored in the manual module. The sorter is starved for twenty minutes, then floods and backs up onto the merge. Two operators are standing at a station whose robot queue emptied. Nobody made a bad decision. The building simply has no component whose job is to decide what work goes where and when, second by second, across subsystems from different vendors.

This is the gap a warehouse execution system fills, and it is genuinely a gap rather than a marketing category. Your warehouse management system (WMS) knows orders, inventory and shipping. It releases work in waves and expects the floor to absorb it. Each piece of automation arrives with its own controller from its own vendor, and that controller is excellent at driving its own machine and indifferent to everything else. Between those two layers is the sequencing and balancing decision, and in most buildings it is made by a supervisor with a radio.

What the incumbents actually do and where they stop

Körber, Honeywell Intelligrated Momentum, Dematic iQ and Manhattan Active Warehouse Management all offer execution capability, and all of them are credible. The distinction that matters when you are choosing is where each one came from.

Vendor execution software from an automation supplier is built around that supplier's equipment. Momentum orchestrates an Intelligrated building beautifully. Dematic iQ does the same for Dematic. Both can integrate other equipment, and both do, but the depth of control and the diagnostics are asymmetric, and the commercial reality is that your integration to a competitor's robot is a project scoped by the company that sells the competing robot. Manhattan approaches from the warehouse management side and is strong on order and inventory logic, less so on machine level orchestration timing. Körber sits between the two through a portfolio assembled from several products.

The honest position is this. If your building is a single vendor building, use their execution software. It will be cheaper and better than anything you commission. The case for a custom execution layer appears when the building is genuinely mixed, which most modern buildings are, because operators buy the best goods to person system, the best sorter and the best print and apply from three different companies. At that point no vendor's execution product is neutral, and the neutral layer is the one you own.

Problem one: order release is where throughput is won or lost

Most buildings still release work in waves because that is what the warehouse management system does. A wave is a batch of orders released together, and its composition decides the load on every subsystem for the next forty minutes. Release a wave that is 70 percent goods to person items and your manual module empties. Release one heavy on singles and your sorter runs half full while pack stations queue.

The correct behaviour is to release work continuously against the current state of every subsystem, keeping each one fed just above its buffer without flooding it. That is not exotic computer science. It is a control loop with feedback, and it is rare because it needs live state from equipment belonging to three different vendors, which is precisely what no vendor is motivated to build for you.

What we build here is a release engine that holds a work pool rather than a wave, scores candidate work by what each resource currently needs, and releases in small increments. Cutoff times, carrier trailer schedules and order priority all become constraints on the scoring rather than the reason for a wave. The measurable effect is fewer idle stations and fewer floods, and the first visible win is usually the end of the mid afternoon starve and surge cycle every operator recognises.

Problem two: the bottleneck moves and nobody can see it move

Ask a distribution manager where the constraint is and you get an answer from last quarter. The constraint in an automated building moves by the hour depending on order profile, staffing and equipment health. A robot fleet degraded by three charging units out of service is a different building from the one in the design document.

Each vendor controller has a screen showing its own machine. Nothing shows the building, so diagnosis happens by walking, and by the time a supervisor reaches the sorter the cause is at the merge upstream.

A custom execution layer owns the composite view because it already needs the data to make release decisions. That means live buffer occupancy at every handoff, throughput against capability per resource, queue ages, and a plain statement of which resource is currently limiting the building. Operators typically discover within a week that the real constraint is a decant or induction step nobody instrumented, because it involves a person rather than a machine.

Problem three: degraded mode is the mode you actually run in

Automation vendors design for the nominal case. Real buildings run with something down almost every day: a sorter arm out, an aisle blocked, a lift in fault, half a robot fleet charging. The question that decides whether your building copes is what the software does when a subsystem degrades.

In most buildings a supervisor declares a manual workaround over the radio and the systems keep releasing work as if nothing happened. Recovery is then worse than the outage, because the buffers are full of work that has to be untangled by hand.

Designed fallback is a feature you have to specify and pay for. It means each resource has a declared degraded capability, the release engine respects it automatically, work already committed to a failed resource is re-routed with a clear audit of what moved, and there is a documented manual mode for each subsystem with the paperwork or labels it requires. It is unglamorous, and it converts a bad afternoon into a slow one.

Problem four: the interfaces are not APIs, and that is the real project

Talking to warehouse equipment is not the same as consuming a web service. A programmable logic controller speaks an industrial protocol over a plant network. A sorter emits telegrams on a socket with a fixed message format defined in a document from the integrator. A robot fleet manager may offer a modern interface, or may offer a file drop. The print and apply expects a specific label format at a specific moment relative to the carton reaching a scan point, and if you are late the carton recirculates.

Timing is the hard part. A merge decision has to be made before the carton reaches the divert, and the divert has a physical position, so the execution layer runs closer to real time than most enterprise software and has to handle a message that is late rather than lost.

What a custom warehouse execution build has to include

• A live model of every resource with capability, current buffer occupancy, health state and declared degraded capacity.
• A continuous release engine that scores and releases work against current resource state, with cutoffs and priorities as constraints rather than as waves.
• Order and work item state that is authoritative in the execution layer and reconciles cleanly back to the warehouse management system.
• Machine interfaces built per subsystem, with explicit handling of late messages, replays and duplicate events.
• Designed degraded modes per subsystem, with automatic re-routing of committed work and a documented manual procedure.
• A building level operations view showing the current constraint, throughput against capability and queue ages at every handoff.
• Labour balancing so that people are directed to the station that needs them, using the same release logic rather than a separate tool.
• An event history complete enough to replay a shift, because post incident analysis is how you actually improve a building.

What this costs and how long it takes

A focused first release, meaning the resource model, the continuous release engine, orchestration across one automation island plus the manual modules, and the building level operations view, runs $120,000 to $250,000 and ships in 14 to 20 weeks, and it should be measurable against your current units per hour in the same building with the same people. A full execution layer covering every subsystem, labour balancing, designed fallback modes and full replay runs $350,000 to $800,000 phased over 9 to 18 months.

What drives the number up: the count of distinct equipment vendors, since each is a separate integration; the age of the equipment, because older controllers speak older protocols and their documentation may be a printed manual; whether you have a plant network segregated from corporate information technology, which is correct practice and adds coordination; the number of buildings, since a second site is never a copy; and the availability of test windows, because integration testing against live automation is scheduled around production and that scheduling is the real critical path.

What keeps the number down: start with the subsystem that is your current constraint plus the manual modules around it, and prove a throughput number before extending.

When you should not build a warehouse execution system

Do not build if your building is single vendor. Buy Momentum in an Intelligrated building or Dematic iQ in a Dematic building, for deeper machine control and a simpler support relationship. Do not build if your automation is one sorter and some conveyor, because the balancing problem does not exist yet.

Build when two or more of these are true. Your building mixes goods to person, sortation and manual picking from different suppliers. You are consistently below design rate and cannot agree internally on why. Your bottleneck moves and there is no screen that shows the whole building. You lose disproportionate throughput whenever one subsystem degrades. You are planning a second automated site and want the orchestration logic to be yours rather than a vendor's. At that point the balancing logic across machines is the operating knowledge of your network, and it is worth owning.

How to choose a developer for warehouse execution software

Ask what industrial protocols they have written against, and ask for specifics. Programmable logic controller communication, telegram based socket interfaces and a robot fleet manager interface are three different problems. If the answer is a general statement about integrations, they have consumed web services and have not stood on a mezzanine at 11pm watching a carton recirculate.

Ask how they will handle a late message rather than a lost one. This question separates people who have done real time floor work from people who have not, because enterprise developers reach for retries and a divert decision cannot be retried after the carton has passed.

Ask them to describe degraded mode design for a subsystem in your building. If they have not thought about what happens when a lift faults with committed work behind it, they will build you a system that is excellent on a good day, which is the day you already cope with.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the unrestricted right to hire another firm. This matters especially here, because the entire reason to build a neutral execution layer is to avoid being locked to an equipment vendor, and it would be absurd to escape that lock by accepting a software one. At Digital Heroes the client owns the code from the first commit.