A walkthrough on public-style data of the same network-optimization methodology I run for enterprise supply-chain clients. Methodology is real. Numbers are real LP solver output (PuLP + CBC); in production deployments the network is bigger and the constraints are denser, but the workflow is identical.
The Challenge
Walk into any supply chain network-design conversation and you'll see the same artefact: a spreadsheet where someone has assigned markets to warehouses by inspection. "NYC obviously goes through Chicago, LA obviously goes through Phoenix, Boston obviously goes through Memphis..." Each individual decision looks reasonable. The aggregate is almost never optimal — and worse, it's almost always infeasible, because the warehouse capacities the spreadsheet assumed don't exist.
The classic mistake: a network-design exercise that ships the cheapest direct route for every market, ignoring the capacity of the warehouse you just routed through. On paper that gives you a beautiful low number. In the real warehouse, that number requires running three pallet handlers at 130% utilization for the rest of the year.
The fix is linear programming. LP doesn't have intuitions about how supply chains "should" work. It only has the cost matrix you give it and the constraints you write down. It finds the cheapest combination of plant-to-warehouse and warehouse-to-market flows that respects every single capacity. The answer is often surprising. The answer is also defensible — to a CFO, to ops, to the board — because the math is recreatable.
The Approach
1. Define the network. Three plants (Atlanta, Dallas, Seattle), four warehouses (Memphis, Denver, Phoenix, Chicago), six markets (NYC, LA, Chicago, Houston, Miami, Boston). Per-unit shipping costs between every plant→warehouse pair and every warehouse→market pair. Plant production capacities. Warehouse throughput caps. Market weekly demand.
2. The naive comparison you're calibrating against. For each market, pick the single cheapest plant→warehouse→market path, ignoring capacity. Sum the costs. This gives you a number that looks good and is unattainable — but it's the right baseline for what executives often think the network costs.
3. Solve the LP. Two sets of decision variables — flow on each plant→warehouse lane and each warehouse→market lane. Objective: total transport cost. Constraints: plant capacity (≤), warehouse flow conservation (in = out), warehouse throughput cap (≤), market demand (= demand exactly). PuLP with the default CBC solver finds the optimum in well under a second for this size.
4. Read the dual story — not just the cost. The interesting output isn't "$71,340". It's which warehouses get used to 100%, which sit idle, which lanes are surprisingly active. That's a network-design recommendation, not just a transportation answer.
The Outcome
The LP returned a total weekly cost of $71,340 — about $4,000 (6%) more than the naive cheapest-direct number of $67,330. That number is doing a lot of work and is the most important thing on this page: the naive answer was wrong, not the LP. The naive answer requires shipping 23% more units through Memphis than its docks can handle and ignores Chicago's outbound costs entirely. The LP says what the system actually costs to run, capacity included.
The flow assignment tells you the network design:
- Memphis runs at 100% utilization. It's the cheap southern hub and gets pushed to its constraint. If you're going to add capacity anywhere first, it's here.
- Chicago runs at 96% utilization. Same story for the northeast — capacity-bound.
- Phoenix runs at 73% utilization. Sufficient as a western pass-through but has slack.
- Denver runs at 0% utilization. The LP doesn't use it at all under this demand pattern. This is a network-design question, not a routing one — if Denver's lease comes up, the LP is saying you can let it go.
On the flow side:
- Plant-Atlanta → Memphis (4,000 units) is the largest single lane in the network, feeding Memphis to its capacity.
- Plant-Dallas → Chicago (3,800 units) is the second-largest.
- LA gets served entirely by Phoenix. Houston and Miami get served entirely by Memphis. Chicago serves itself plus NYC plus Boston.
Business Impact
A network-design study like this typically gets rerun quarterly or whenever a major node changes (lease renegotiation, new plant, demand shift). The model earns its keep when leadership asks "can we shut Denver?" and the analyst can answer with a real number — "yes, projected weekly cost increases by $0 because the LP isn't using it anyway" — in five minutes instead of five weeks.
The pattern this case crystallises: cheap intuition feels right and quietly burns money. LP-driven network design is twenty years old as a technique, free to run with open-source tooling, and still beats the median supply-chain operating cost on contact.
Key Takeaways
- The right baseline is the feasible one. Comparing your LP optimum to a capacity-violating "ideal" is a teaching moment, not a failure of the LP.
- Read the throughput utilisation, not just the cost. The 100% nodes are your capacity-investment shortlist; the 0% nodes are your shutdown shortlist.
- PuLP + CBC is enough. Commercial solvers (CPLEX, Gurobi) get you 10-100× speedups at scale; for a four-warehouse demo, CBC is instantaneous.
- The interesting answer is which node sits idle. That's a structural finding the spreadsheet would never have surfaced.