Every manufacturer eventually hits the same wall. A supplier misses a shipment. A port backs up. A lot fails inspection. Demand says build 1,000 and the warehouse has components for 700. Now what?
This is the "clear-to-build" question, and under disruption it's hard to answer well by hand. A clear-to-build report already does the first half of the work. It explodes each product's bill of materials, checks every component against demand, and tells you which orders are buildable and which are blocked, and by what. What it doesn't do is resolve the competition: when several blocked orders are all waiting on the same short part, which site should give up stock, and which should receive it? That allocation step, rebalancing material across the network against a stated objective, is the hard part.
The instinct is to sort a spreadsheet by some proxy for priority, like the biggest customer, the oldest order, or the deal that's top of mind, and allocate from there. It's a reasonable starting point, but it tends to miss how the parts are coupled.
Because material allocation is less an ordering problem than a trade-off problem, and disruption only adds to the complexity.
Take a concrete example. Imagine you bottle apple juice, and a storm wipes out half your apple delivery: you expected 1,000 kg and got 500. Two products use those apples. Your premium cloudy juice needs apples plus a special glass bottle, but the storm delayed those bottles too, so you can only make 200 units of it no matter how many apples you have. Your standard carton juice needs only apples and cartons, both in good supply. If you throw all 500 kg of apples at the premium line, most of it sits unused, because the bottles cap you at 200 units anyway. The smarter move is 200 units' worth of apples to premium and the rest into cartons. On top of that, another warehouse has 300 kg of apples with no orders this week, so part of the answer is shipping those apples over before they spoil. Same apples, very different output, and the bottle shortage is what should have shaped the apple decision in the first place.
This is where mixed-integer linear programming (MILP) can help. Think of a MILP as a way to write your situation down in math. Your business rules become constraints, your priority becomes the objective, and the answer it gives you is the decision you're after: how much of each scarce part each order gets, and which location it's pulled from. A solver then sifts through a huge number of possible allocations to find the best one. The catch is that it's only as good as the rules and priority you feed it.
Some of the value is in what the solver reports alongside the allocation: which constraints are binding, meaning the limits you actually ran out of. You can see that capacity, rather than a particular component, is what held this week's number down, and the binding constraint often shifts from week to week. That opens the door to what-if questions, like what if I had 10% more capacity?
It's worth being honest about the limits, too. Experienced planners often make better calls than the model alone, because they're working from signals it doesn't have, like a supplier email, weather in a key region, or an unfolding geopolitical situation. The aim isn't to replace that judgment. It's to let the MILP do what it's good at, mapping the feasible region and surfacing the trade-offs, then leave the final call to the planner, who can override the recommendation or re-run it with tighter assumptions once they know something the model doesn't.
