The Planning Horizon Is a Modeling Choice | Learn

A planning horizon sounds like a configuration setting.

It is not.

If your replenishment model plans 13 weeks, 26 weeks, or 52 weeks, that choice can change today’s order. The horizon determines which future consequences the model can see and which consequences effectively do not exist.

That makes the horizon part of the model.

This matters because supply-chain systems often inherit horizons for reasons that have nothing to do with economics. The forecast team publishes 26 weeks, so optimization uses 26 weeks. Finance plans quarterly, so the model uses 13 weeks. A legacy system had 52 buckets, so the replacement system has 52 buckets.

Then everyone argues about the order quantity without asking whether the model can even see far enough to value that order correctly.

Start with the decision

Before choosing a horizon, write down the actual decision.

Suppose today we decide purchase quantities:

[ x_{i,t} = \text{units of item } i \text{ ordered in period } t. ]

The state might include on-hand inventory, open purchase orders, expected arrivals, supplier status, prices, capacity, and current demand information.

The important question is not “how many weeks do we forecast?”

It is:

How far into the future can today’s decision materially change economic outcomes?

If an order placed today arrives in 20 weeks and then supplies demand for another 12 weeks, an eight-week optimization horizon is obviously nonsense. The model may technically run, but the consequence of the decision lives outside the model.

The same problem can be less obvious. A 26-week horizon may look long until a six-month supplier lead time, MOQ, seasonal peak, or end-of-life event makes week 35 economically relevant to today’s order.

Four clocks matter

I find it useful to separate four different clocks that planning systems often collapse into one number.

1. Decision cadence

How often can you make the decision again?

Daily? Weekly? Monthly?

A weekly ordering process does not mean you need a one-week horizon. It means you get another opportunity to revise the policy next week.

2. Commitment horizon

How far ahead are decisions actually binding?

A purchase order may become non-cancelable immediately. Production may be flexible for two weeks and frozen after that. Transportation bookings may have cancellation penalties.

This determines how much future flexibility really exists.

3. Consequence horizon

How long can today’s action affect the system?

Long lead times, shelf life, inventory carryover, capacity reservations, price breaks, and seasonal demand can make this much longer than the decision cadence.

4. Information horizon

How far ahead do we have useful information?

This includes forecasts, promotions, supplier outages, contracts, known events, and probabilistic assumptions.

These clocks do not need to be equal.

A good architecture represents them separately instead of forcing one planning-horizon parameter to do all four jobs.

The classic end-of-horizon failure

Consider the inventory balance

[ I_{t+1}=I_t+x_{t-L}-D_t, ]

where (L) is lead time.

Suppose the objective over (T) periods is

[ \max \sum_{t=1}^{T} \left( \text{margin}_t

\text{holding}_t

\text{ordering}_t

\text{shortage}_t \right). ]

What is inventory worth at the end of period (T)?

If the answer is zero, the model has a cliff.

A unit arriving in period (T) incurs purchase cost and perhaps holding cost, but receives no credit for demand it could satisfy in period (T+1). The optimizer may therefore stop ordering near the boundary.

If instead leftover inventory receives full retail value, the opposite problem can occur. The model may buy too much because it pretends every remaining unit will eventually sell at full economics.

The horizon did not merely truncate computation. It changed the economics.

Terminal value is not cleanup logic

A finite-horizon model needs some representation of what happens after the explicit horizon.

One approach is a terminal value function:

[ V_T(S_T), ]

where (S_T) is the state at the end of the modeled horizon.

Then the objective becomes

[ \max E\left[\sum_{t=1}^{T} C_t(S_t,x_t,W_{t+1}) + V_T(S_T)\right]. ]

The terminal value does not need to be perfect. It needs to be materially better than pretending the world ends on Tuesday.

For inventory, a simple approximation might value ending stock according to expected future contribution margin minus expected holding, markdown, and obsolescence costs.

For capacity, it might represent the opportunity value of unused future capacity.

For a rolling production schedule, it might penalize leaving an ugly state that makes the next planning run expensive.

This is one place where simulation is extremely useful. Instead of guessing a terminal coefficient forever, simulate what actually happens after the optimization horizon and estimate the continuation value.

Longer is not automatically better

The obvious response is to make the horizon huge.

That can also be wrong.

A longer horizon adds variables, constraints, scenarios, data dependencies, and assumptions. In a MILP, doubling time periods can do much more than double runtime if the formulation contains setup binaries, MOQ logic, shared capacities, or scenario-dependent decisions.

More importantly, distant periods are usually less knowable.

There is little value in building a detailed 104-week deterministic schedule if week 80 is mostly fiction.

The goal is not maximum horizon length. The goal is enough explicit horizon plus a reasonable continuation model so that today’s decision is economically stable.

That distinction matters.

Test horizon by decision stability

Do not choose 26 weeks because 26 feels reasonable.

Run an experiment.

For representative states, solve the same decision problem with horizons of, say, 8, 13, 26, 39, and 52 weeks. Keep the initial state and uncertainty samples consistent where possible.

Then compare the near-term decisions.

For example:

[ \Delta(H_1,H_2)=\sum_i |x_i^{H_1}-x_i^{H_2}|. ]

But quantity disagreement alone is not enough. Two order plans can differ while having nearly identical economics.

Evaluate each resulting policy in a longer out-of-sample simulation and calculate regret:

[ R(H)=J(\pi^*)-J(\pi^H), ]

where (J) is realized economic performance and (\pi^H) is the policy produced with horizon (H).

You are looking for the point where extending the horizon produces little improvement in the decisions that matter today.

That is much more defensible than picking a number from a planning template.

Uncertainty changes the answer

Horizon testing with one deterministic forecast can be misleading.

The farther out we look, the wider the range of plausible states usually becomes. Demand uncertainty accumulates. Lead times move. Supplier capacity changes. Promotions appear. Competitors react. Orders already placed become inventory or fail to arrive.

A long deterministic horizon can create false precision.

For operational decisions, I would rather have a shorter horizon with credible uncertainty and continuation economics than a very long horizon containing a single invented future.

If using scenarios (\omega), the model might optimize

[ \max_x \frac{1}{N}\sum_{\omega=1}^{N} P(x,\omega), ]

subject to the constraints that are actually known today.

The scenarios should preserve relevant temporal structure. Sampling every future week independently can destroy seasonality, persistence, and correlation. A horizon experiment is only useful if the future paths themselves are believable enough to stress the decision.

Constraints can create hidden horizon requirements

Some constraints make distant periods relevant even when demand does not.

Examples include:

supplier MOQs evaluated across a purchase window,
annual or quarterly capacity commitments,
container consolidation,
production campaigns with setup costs,
shelf-life constraints,
contract price breaks,
budget limits,
warehouse capacity,
vendor shutdowns,
end-of-life dates,
planned promotions.

Suppose a vendor MOQ requires

[ \sum_i x_{i,t} \ge Qy_t, ]

where (y_t) activates an order.

A SKU that would not justify an order alone may be economically attractive when combined with other SKUs. If some of those SKUs have relevant demand just outside the horizon, truncation can change whether the vendor order opens at all.

This is why horizon selection cannot be done independently for every SKU when the executable decision is coupled at vendor, facility, truck, or budget level.

Ask these questions before touching the parameter

When someone proposes changing the horizon, I want answers to these questions:

What decision are we making today?
Which part of that decision is irrevocable?
What is the longest lead time that can affect today’s action?
Which constraints couple today’s decision to future periods?
What happens to inventory, backlog, capacity, and commitments at the boundary?
How is terminal state valued?
Does extending the horizon materially change today’s executable action?
Does that change improve out-of-sample economics?
What does the extra horizon cost in runtime and engineering complexity?
Which future inputs are actual information and which are assumptions?

If the team cannot answer these, debating 26 versus 52 weeks is premature.

Rolling horizon does not eliminate the problem

A common argument is: “We rerun every week, so the end of the horizon does not matter.”

It still matters.

Yes, rolling reoptimization gives you recourse. Next week you observe new information and solve again.

But today’s model still chooses an action using the future it can currently see. If an economic consequence falls beyond that view, today’s action can be biased before next week’s run ever happens.

Rolling horizon helps because only the near-term decision is executed. It does not magically correct a bad valuation of that decision.

The right test is the full closed-loop policy:

observe state → optimize → execute near-term action → simulate reality → update state → optimize again.

Then compare horizon choices over many simulated paths.

Measure the whole system

A horizon benchmark should not report only solver runtime.

Track at least:

model-build time,
solve time,
number of variables and constraints,
MIP gap at the operational timeout,
near-term decision disagreement,
expected profit or cost,
stockouts or lost margin,
inventory and aging,
expedite usage,
capacity violations or slack,
order frequency,
decision stability across replans,
out-of-sample regret.

You may discover that a 52-week model improves the mathematical objective by 0.03% while taking six times longer and producing the same first four weeks of decisions as a 26-week model.

Use the 26-week model.

Or you may discover that a 13-week model consistently underbuys a long-lead seasonal category because the peak sits just outside the boundary.

Then the shorter model is not cheaper. It is wrong in a way that costs money.

Common failure modes

Horizon equals forecast length

The forecasting interface should not define the optimization problem. Extend uncertainty statistically if necessary, or use a continuation value.

Horizon equals lead time

Lead time is often only the beginning of the consequence window. Inventory arriving at the end of lead time still has future economic value.

Zero terminal inventory value

This creates artificial under-ordering near the boundary unless zero really is the economics.

Full-price terminal inventory value

This can create artificial over-ordering by ignoring holding, markdown, obsolescence, and uncertainty.

Making the horizon longer to fix a bad terminal model

Sometimes this works, but it can become an expensive way to push the same boundary problem farther away.

Tuning on one SKU

Shared MOQs, capacities, budgets, and transportation mean horizon effects can be portfolio-level.

Evaluating with the same deterministic future used to optimize

This rewards the assumptions you already made. Use out-of-sample paths and closed-loop simulation.

What I would build in practice

I would make horizon length an experimentally validated modeling parameter, not a business constant.

First, define the executable decision and its timing. Separate what is decided now from what can be revised later.

Second, map lead times, commitments, and coupled constraints to understand the minimum consequence window.

Third, make terminal economics explicit. Even a rough continuation value is better than an accidental zero.

Fourth, create a horizon sweep on representative production states. Reuse common uncertainty paths so differences are attributable to the horizon rather than Monte Carlo noise.

Fifth, evaluate each candidate as a rolling policy in a longer simulator. Measure economics and near-term decision stability, not just the optimization objective.

Finally, choose the shortest horizon that produces economically stable decisions within the runtime budget.

That last sentence is the point.

A planning horizon is not a statement about how far into the future your company can predict.

It is a computational representation of how much future consequence must be visible to make today’s decision well.

Choose it like a modeler, not like a calendar administrator.