Every supply chain leader has seen it happen. The optimization team spends months building a sophisticated network design model, presents findings to the executive committee, and recommendations get shelved within weeks. The math was impeccable. The software was expensive. Yet somehow, the answers felt disconnected from reality.

The uncomfortable truth is that network design models don't fail because of computational limitations or data quality issues. They fail because we feed them the wrong questions. The model faithfully optimizes whatever we tell it to optimize—and therein lies the problem. When input assumptions oversimplify uncertainty, when constraints reflect mathematical convenience rather than strategic intent, the optimal solution optimizes for a world that doesn't exist.

This matters more than ever as supply chains face unprecedented volatility. Network decisions lock in infrastructure, relationships, and capabilities for years. Getting the questions right isn't a technical refinement—it's the difference between building resilience and embedding fragility into your operations.

The most common network design mistake is treating demand forecasts as facts rather than hypotheses. Models receive a single demand projection—perhaps with high and low variants—and optimize accordingly. This creates the illusion of precision while ignoring the fundamental uncertainty that makes network design difficult in the first place.

Better practice constructs scenarios around structural uncertainty, not numerical variation. Instead of asking "what if demand is 20% higher," ask "what if demand shifts from Product A to Product B?" or "what if our fastest-growing customer segment concentrates in different regions?" These scenario dimensions capture the kinds of changes that actually stress network configurations.

Consider a consumer goods company evaluating distribution centers. A traditional approach might test demand at 90%, 100%, and 110% of forecast. A scenario-based approach would test different channel mix assumptions: what if e-commerce grows faster than retail? What if wholesale consolidation changes delivery point density? These scenarios reveal which network configurations remain robust across different futures—not just different volumes.

The practical technique involves identifying three to five dimensions of uncertainty that would genuinely change network strategy. For each dimension, develop two or three distinct states. Then select representative scenario combinations that span the uncertainty space without creating computational explosion. The goal is strategic insight about robustness, not exhaustive enumeration of possibilities.

Takeaway

Don't optimize for a single predicted future—test which network configurations perform acceptably across genuinely different scenarios that stress your assumptions about where, what, and how customers will want things.

Service level constraints seem straightforward until you realize there are dozens of ways to define them—and each definition implies a different network structure. The constraint you choose is itself a strategic decision, often made unconsciously by whoever built the model.

Take a simple example: "95% of orders delivered within two days." Does this mean 95% of order lines? Order value? Customer accounts? Does the two-day clock start at order placement or payment confirmation? Does it measure to first delivery attempt or successful receipt? Each interpretation leads to different optimal configurations. High-value orders might justify different infrastructure than high-volume orders. Customer-weighted metrics might prioritize dense markets over dispersed ones.

More fundamentally, service level constraints embed assumptions about what customers actually value. A 48-hour delivery promise assumes customers care about speed—but they might care more about reliability, visibility, or flexibility. Networks optimized for speed concentrate inventory near customers. Networks optimized for reliability might favor centralization with better demand pooling. Networks optimized for flexibility require different capabilities entirely.

Before running optimization, interrogate your service constraints. Ask: who defined these requirements and when? What evidence supports them? How would customer behavior change if we offered different service tiers? The answers often reveal that constraints reflect historical aspirations or competitive reactions rather than current customer research. Re-examining constraints frequently uncovers opportunities that no amount of computational power could find within the original problem formulation.

Takeaway

Service level constraints aren't neutral technical inputs—they encode strategic assumptions about customer value. Choose your constraint definitions deliberately, because the model will optimize exactly what you tell it matters.

Optimization models live in a frictionless world where warehouses open and close on command, inventory teleports between locations, and organizations execute changes flawlessly. Real supply chains don't work this way. The gap between model recommendation and implementable strategy is where most network design efforts fail.

Reality checks should be built into the modeling process, not applied as afterthoughts. This means adding constraints that reflect genuine implementation limitations. How many major facility changes can your organization execute simultaneously? What's your realistic capital budget, including the initiatives competing for the same funds? Which existing facilities have lease terms, workforce considerations, or strategic relationships that limit flexibility?

The change management dimension deserves particular attention. Network redesign isn't just infrastructure reconfiguration—it's organizational transformation. Every facility change affects people, processes, and systems. Organizations have finite capacity to absorb change. A model that recommends simultaneously opening three facilities, closing two, and restructuring transportation across fifteen lanes might be mathematically optimal but organizationally impossible.

Practical implementation checks include phased scenario analysis (what's optimal given that we can only make two major changes per year?), sensitivity testing around key constraints, and explicit trade-off quantification. When a slightly suboptimal network proves far easier to implement, decision-makers need that information. The best network design models generate three to five genuinely implementable alternatives rather than a single "optimal" solution that falls apart on contact with reality.

Takeaway

The optimal network on paper means nothing if your organization can't implement it. Build realistic constraints around capital, change capacity, and execution timelines into your model—not around your final recommendations.

Network design optimization is fundamentally a question-asking exercise that happens to involve mathematics. The model is a tool for exploring implications of assumptions—it cannot tell you what to assume. When recommendations feel disconnected from reality, the problem usually traces back to inputs that oversimplified the world.

Getting questions right requires bringing operational leaders, finance, and strategy into the modeling process early. They understand the constraints that matter and the uncertainties that keep them awake. Their judgment should shape problem formulation, not just evaluate final answers.

The goal isn't a perfect model—it's a better conversation about trade-offs, risks, and strategic priorities. When network design becomes a vehicle for that conversation, even imperfect models generate valuable decisions.