At 05:30, the overnight routing batch job finishes and produces 412 routes. By 07:30, a senior dispatcher has edited 60 of them by hand in a spreadsheet. The optimization engine ran. The optimization did not happen.
IT leadership often looks at this manual intervention and assumes the algorithm needs an upgrade. They evaluate vendors promising artificial intelligence and machine learning for the supply chain. The reality is usually more mundane. The vendor’s proprietary engine is often a mixed-integer program from a decade ago with a new login screen and a per-seat license. The math for vehicle routing and bin packing was largely settled in the 1990s. Open-source libraries can solve most regional routing problems. The solver itself is a commodity. The model, the data, and the planner’s trust are the actual assets.
When a dispatcher rejects a route, they are rarely rejecting the math. They are rejecting the inputs. The algorithm did not fail; the master data lied. Every planner carries a set of constraints in their head that never made it into the system specification. The model assumes a delivery window of 06:00 to 14:00. It does not know the site gate opens at 07:00 and the receiving clerk takes lunch at 12:00. Those facts live in the dispatcher’s head.
A three-dimensional bin-packing solver generates a volumetrically perfect load plan for a mixed-temperature trailer. It places heavy pallets of ambient canned goods on top of fragile chilled fruit because the item master record lacked the necessary temperature and crushability flags. A warehouse slotting model optimizes the pick path but ignores the pallet build, forcing pickers to rebuild every pallet at the staging lane. The aisle width in the warehouse management system matches the original CAD drawing. In reality, the aisle is 200 millimeters narrower because of a rack repair from two years ago, and the routing algorithm sends two forklifts down a path where they can no longer pass each other.
Procurement teams focus on the solver license, which might cost less than two weeks of a senior planner’s time. The data remediation required to make the solver useful costs more than both. Master data is the tax you pay on every model, every run, forever. You cannot optimize your way out of a customer master with three addresses for the same loading dock. Before modeling begins, the team must geocode every ship-to location, deduplicate customer records, validate item dimensions against physical samples, and reconcile lane masters against carrier invoices. A distance matrix is a lie you tell the optimizer, and the trucks pay for it.
Steering committees frequently conflate prediction and decision-making. Machine learning predicts how many pallets of produce will be ordered or how long unloading will take. Operations research decides which specific trucks the goods go on and in what sequence. Predicting demand is statistics. Delivering it is physics. A better demand forecast improves the inputs to the optimizer, but it does not decide which trailer goes where under strict capacity and service constraints.
You cannot solve a cultural problem with a mixed-integer program. If you force the system on the planners, they will find a workaround. The first working model takes weeks. The first model the planners trust takes months. The difference is constraint capture, not algorithm development.
Run the solver in shadow mode for a few weeks. Show the planners the output and let them override it. When a planner rejects a route, they are applying a shadow price. They are implicitly deciding that the unmodeled cost of a difficult loading bay or a known traffic choke point is higher than the fuel savings the solver found. Log the reason for every override. That list is your constraint backlog, ranked by frequency and cost. An override reason can be more valuable than another month of solver tuning.
Most models treat every constraint as hard or nothing. If a model mandates a delivery before 17:00 and the truck arrives at 17:02, a hard constraint forces the solver to drop the delivery entirely or declare the problem infeasible. A soft constraint applies a penalty cost for every minute after 17:00. This gives the algorithm room to find compromises that reflect how logistics actually works. Translating municipal noise restrictions, driver preferences, and customer goodwill into mathematical penalty weights is the actual engineering challenge.
A solver that takes four hours to find an exact solution is fine for a weekly plan and useless for a same-day re-plan when the order book shifts at 10:00. Planners need interactive re-optimization. They need to lock a route, move a single drop, and re-solve in seconds. The solver becomes a tool, not an oracle. If the output cannot explain why a load stayed behind, the planning team will supply its own explanation. Show them the exceptions. Do not show a planner 400 routes; show the 12 the solver is least confident about and the constraints that prevented an assignment.
The overnight batch plan is a hypothesis. The dock is the experiment. The model does not need to know everything the dispatcher knows. It only needs to know the facts that change the assignment. Once the Tuesday access restriction is recorded in the system, the solver can work with it, and the next unexplained override becomes visible.
Take it with you
Takeaways
- Master data remediation costs more than solver licenses and matters more
- Planner overrides are a constraint backlog, not a failure signal
- Soft constraints and interactive re-optimization determine whether a solver gets used
Asked and answered
Questions
Why do planners override so many routes from an optimization engine?
Planners are usually rejecting the inputs, not the math. The model lacks constraints that live in the dispatcher's head, such as gate opening times, receiving clerk lunch breaks, or known traffic choke points.
Should we replace our solver with a machine learning system?
Machine learning predicts demand or unloading times. Operations research decides which trucks goods go on and in what sequence. A better forecast improves inputs to the optimizer, but it does not replace the constraint solver.
How do we get planners to trust the solver output?
Run the solver in shadow mode, let planners override it, and log the reason for every override. That list becomes a ranked constraint backlog. Show planners the exceptions and the constraints that prevented an assignment, not all 400 routes.