Warehouse Execution System Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the orchestration scope get underestimated so often?

Because an execution layer is frequently scoped as a dashboard. The proposal describes a screen showing the whole building, and everybody agrees that would be useful, and the actual gap is a control loop rather than a view.

Here is what gets missed. Your warehouse management system (WMS) knows orders, inventory and shipping, and releases work in batches because that is what it was built to do. Each piece of automation arrives with its own controller from its own vendor, excellent at driving its own machine and indifferent to everything else. Between those layers sits the sequencing and balancing decision, made in most buildings by a supervisor with a radio.

Making it properly means holding a work pool rather than a wave, scoring candidate work against what each resource currently needs, and releasing in small increments so nothing starves and nothing floods. Cutoff times, trailer schedules and order priority become constraints on the scoring rather than the reason for the batch. That is not exotic computer science, it is feedback control, and it is rare only because it needs live state from equipment belonging to three different companies, which is exactly what no vendor is motivated to build for somebody else's machine.

The consequence of the dashboard framing is that the project delivers visibility and changes nothing. Operators can now see the starve and surge cycle they already knew about. Insist the first release includes the release engine, not just the screen, measured against your current units per hour in the same building with the same people.

What goes wrong with location, item and event data?

An execution layer makes decisions in real time from data most buildings have never had to trust in real time, and the gaps show up immediately.

The location master is the first. Slotting changes constantly, and in most buildings the authoritative record is the warehouse management system plus local adjustments never written back. If your release engine believes an item sits in the goods to person system and it moved to the mezzanine last month, work gets routed to a resource that cannot fulfil it and recovery is manual.

Item dimensions and weights are the second, and they are worse than people expect. Conveyable and sortable decisions depend on them, so bad dimensional data produces cartons that jam a divert or recirculate indefinitely. Buildings frequently discover during commissioning that a meaningful share of the item master has estimated dimensions inherited from a supplier file.

Event history is the third, and it is missing rather than wrong. Post incident analysis is how you improve a building and it needs an event record complete enough to replay a shift. Most buildings can say what shipped and not why the merge backed up at eleven.

The fixes: make the execution layer authoritative for floor state and reconcile back to the warehouse management system rather than reading it as gospel, put a confidence flag on dimensional data and route low confidence items conservatively until measured, and capture every decision and every machine event with enough fidelity to replay a shift from the start.

Why do the equipment interfaces break after launch?

Because they are not application programming interfaces in the sense most developers mean. A programmable logic controller speaks an industrial protocol over a plant network. A sorter emits telegrams on a socket in a fixed message format defined in a document from the original integrator, which may be a printed manual. A robot fleet manager may offer a modern interface or a file drop. The print and apply expects a specific label at a specific moment relative to the carton reaching a scan point.

Timing is the part that breaks and it breaks in a way enterprise software does not prepare people for. A merge decision has to be made before the carton reaches the divert, and the divert is a physical position that the carton passes whether you answered or not. Enterprise developers reach for retries. A divert decision cannot be retried after the carton has gone past, so the correct behaviour for a late message is a defined fallback, usually recirculate or reject to a manual lane, and that fallback has to be designed rather than discovered.

The second failure mode is duplicate and replayed events after a controller restart, which arrive looking like new work and can double-commit a location or a label.

The third is network segregation, since plant networks are properly separated from corporate information technology and every change then touches two teams and a change window.

The fixes are specific: idempotent handling of every machine event, an explicit policy for late messages per decision point, a heartbeat per subsystem so a silent controller is visible within seconds, and interfaces scoped and scheduled individually rather than as one line item called integration.

What happens when degraded mode is not covered?

Real buildings run with something down almost every day: a sorter arm out, an aisle blocked, a lift in fault, half a robot fleet on charge. Automation vendors design for the nominal case, and an execution layer that does the same keeps releasing work to a resource that cannot take it.

What happens next is the expensive part. The buffers fill with work committed to a failed resource, a supervisor declares a manual workaround over the radio, and recovery afterwards takes longer than the outage did because everything has to be untangled by hand. Buildings routinely lose more throughput to the recovery than to the failure.

Designed fallback is a feature you have to specify and pay for, and it is unglamorous enough that it gets cut from scope in the first budget conversation. It means each resource carries a declared degraded capability rather than a binary up or down, the release engine respects that capability automatically, work already committed to a failed resource is re-routed with a clear audit of what moved and where, and each subsystem has a documented manual procedure with the labels or paperwork it needs.

In some estates the compliance half matters too: buildings handling controlled or lot traced goods cannot revert to paper without breaking traceability, so manual mode has to produce a record that reconciles afterwards. Degraded mode converts a bad day into a slow one.

Should you build custom or configure what you already own?

If your building is predominantly one vendor's equipment, buy theirs. Honeywell Intelligrated Momentum orchestrates an Intelligrated building well and Dematic iQ does the same for a Dematic building, with deeper machine level control and diagnostics than a third party can reach, plus one support relationship instead of two. Körber offers execution capability across a broader portfolio and Manhattan Active Warehouse Management is strong on order and inventory logic if that is where your gap sits.

Do not build if your automation is one sorter and some conveyor. The balancing problem does not exist yet, and a custom execution layer would be an expensive answer to a question nobody is asking.

Build 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 about which machine gets the work. Build also when you are consistently below design rate and cannot agree internally on why, when your bottleneck moves and no screen shows the whole building, when one subsystem degrading costs you disproportionate throughput, or when you are planning a second automated site and want the orchestration logic to be yours rather than a supplier's.

How do hidden costs get into the quote?

Test windows are the item that breaks schedules and they almost never appear as a cost. Integration testing against live automation happens at night or on a Sunday when the building is not shipping, and those windows are allocated by operations, not by the project. The critical path in nearly every execution build is the calendar of test windows rather than the engineering, and a plan that does not name specific dates is not a plan.

Equipment vendor count is the second driver, since each is a separate integration with its own protocol and its own documentation quality. Equipment age is the third: older controllers speak older protocols, and the interface specification may exist only as a paper manual held by whoever commissioned the building.

Plant network segregation is the fourth, where the cost is coordination rather than code. A second building is the fifth and never a copy, since layout, equipment mix and slotting behaviour differ enough to require rework of the release scoring.

What keeps the number down is starting with the subsystem that is currently your constraint plus the manual modules around it, and proving a throughput number before extending to anything else.

What separates a build that works from one that fails here?

Ask what industrial protocols they have written against, and demand specifics. 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 eleven at night watching a carton recirculate.

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

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

Ask how a shift is replayed. Without a complete event history there is no post incident analysis, and without post incident analysis the building stops improving after go live.

Then settle ownership in writing before kickoff: the repository, the cloud and plant infrastructure accounts, and the unrestricted right to hire another firm. This matters more here than almost anywhere else, because the entire reason to commission a neutral execution layer is to avoid being locked to an equipment vendor, and it would be absurd to escape that by accepting a software lock instead. At Digital Heroes the client owns the code from the first commit.