Lead Time Is a Distribution, Not a Number

Most planning systems have a field called lead_time.

That field usually contains one number.

Maybe it is 28 days. Maybe it is 6 weeks. Maybe somebody calculated a historical average. Maybe a supplier entered it into a master-data system three years ago and nobody knows where it came from anymore.

The replenishment engine then treats that number as if it were a physical constant.

That is convenient. It is also often wrong in exactly the place where the decision is most sensitive.

A supplier that averages four weeks but sometimes arrives in two and sometimes in ten does not create the same inventory problem as a supplier that arrives in exactly four weeks every time. The means are identical. The decisions should not be.

Lead time is not merely an input to the order calculation. It is part of the uncertainty structure of the decision.

Start With What You Actually Decide

Suppose every Monday you decide how much of SKU (i) to order from vendor (v):

[ q_{i,t} = \text{units ordered at decision time } t. ]

The order enters a pipeline and becomes usable inventory only after some lead time (L_{i,t}).

If lead time were known perfectly, the arrival date would be simple:

[ a_{i,t} = t + L_{i,t}. ]

But in a real supply chain, (L_{i,t}) may depend on production congestion, sailing schedules, port delays, holidays, supplier behavior, transportation mode, customs, order size, and events nobody predicted when the purchase order was placed.

The decision therefore happens before you know exactly when the inventory will arrive.

That is the problem.

Before building a model, ask:

When is the order actually committed?
Can quantity or mode be changed after the order is placed?
What information about the supplier exists at that moment?
Do you receive updated expected-arrival dates while the order is in transit?
Can late supply be expedited?
Does the supplier partially ship orders?
Are lead times different by SKU, lane, vendor, order size, or season?
What happens economically when supply arrives late?

Those questions matter more than whether the historical mean is 27.4 or 28.1 days.

The Average Lead Time Can Describe Nobody

Consider two vendors.

Vendor A always delivers in four weeks.

Vendor B delivers in two weeks half the time and six weeks half the time.

Both have an average lead time of four weeks.

A deterministic planning model sees identical suppliers.

Operationally, they are not identical at all.

With Vendor A, four weeks of protection may be enough if demand is reasonably predictable. With Vendor B, an order sometimes has to cover six weeks before replacement inventory appears. If the model plans against the average, the long realizations create stockouts that look surprising even though they were visible in the historical distribution all along.

The average also hides skew.

A vendor might deliver in 20 to 25 days most of the time but occasionally take 70 days. The average may move only modestly, while the rare delay drives a disproportionate share of shortage cost.

This is common in supply chains because delay mechanisms are not symmetric. A shipment can miss a vessel, get held in customs, lose production priority, or wait for a component. There is usually no equivalent mechanism that makes it arrive 45 days early.

The tail matters.

Demand and Lead Time Interact

The inventory exposure is not lead time by itself. It is demand accumulated while you wait for replenishment.

If demand during period (k) is (D_k), then lead-time demand for an order placed at time (t) is roughly

[ D^{LT}t = \sum{k=1}^{L_t} D_{t+k}. ]

Now both the number of periods and the demand within those periods can be uncertain.

This is why treating demand uncertainty and lead-time uncertainty as separate spreadsheet adjustments can be misleading. The business cares about their joint effect on inventory.

Suppose a product sells 100 units per week on average. A four-week deterministic lead time suggests 400 units of expected demand before replenishment. But if lead time sometimes becomes eight weeks, the exposure can double before considering any demand uncertainty at all.

If high demand also contributes to supplier congestion, the situation is worse. Lead time and demand may be positively correlated.

Sampling demand from one distribution and lead time independently from another would then understate the probability of exactly the scenarios you care about: high demand arriving at the same time supply slows down.

Do Not Confuse Quoted Lead Time With Realized Lead Time

Supply-chain data often contains several different clocks that people casually call lead time.

There may be:

supplier quoted lead time,
requested ship date,
confirmed ship date,
actual ship date,
transit time,
requested delivery date,
promised delivery date,
actual receipt date,
inspection or put-away delay,
and the date inventory becomes usable.

These are not interchangeable.

If your decision is about when to place a purchase order, the relevant uncertainty starts from the moment the order becomes committed and ends when inventory is actually available for the downstream decision.

A shipment sitting at the receiving dock but unavailable to fulfill demand has not completed the economically relevant lead time.

Define the clock around the decision, not around whichever timestamps happen to be easiest to query.

Estimate Conditional Lead-Time Distributions

A single company-wide empirical lead-time distribution is usually too crude.

The useful object is closer to

[ P(L \mid x_t), ]

where (x_t) represents information known when the order is placed.

That information might include vendor, origin, lane, product family, shipping mode, calendar month, order quantity, supplier backlog, current congestion, or recent supplier performance.

You do not necessarily need a sophisticated machine-learning model. Start with segmentation that has operational meaning.

For example, estimate separate distributions by vendor and transportation mode. Then check whether seasonality or order size materially changes them. Avoid creating tiny segments with five historical observations just because the database allows it.

The goal is not to predict the exact arrival date. The goal is to represent enough uncertainty to make a better decision.

The Pipeline Is Part of the State

Once orders have been placed, the planning state is more than on-hand inventory.

A useful state might include

[ S_t = (I_t, P_t, F_t, C_t, \ldots), ]

where (I_t) is usable inventory, (P_t) is the outstanding purchase-order pipeline, (F_t) is current forecast information, and (C_t) represents relevant constraints or supplier state.

For every open purchase order, the pipeline should retain at least quantity and the current belief about arrival timing.

That belief can change.

An order placed four weeks ago may originally have had a broad arrival distribution. If the supplier now confirms it is on a vessel arriving Friday, much of that uncertainty has disappeared. A good policy uses the updated information.

This is one reason a static reorder-point calculation can struggle in messy real systems. Two SKUs with identical inventory positions may have completely different risk because one has reliable inbound supply arriving tomorrow and the other has an overdue PO with no confirmed date.

The state matters.

A Simple Simulation Is Often Enough

You do not need a giant stochastic program to start handling lead-time uncertainty better.

A simulator can do the job.

For each scenario (\omega):

Start from the inventory and pipeline state that genuinely existed at the decision date.
Generate an order using the candidate replenishment policy.
Sample or replay a plausible lead time for each new order.
Advance time and realize demand.
Receive inventory only when the sampled arrival occurs.
Apply stockout, backorder, holding, expedite, and other relevant economics.
Update forecasts and arrival information when the real process would have updated them.
Make the next decision using only information available at that point.

Repeat across many scenarios and compare policies.

The policy itself can remain simple. For example,

[ q_t = \max(0, S - IP_t), ]

where (S) is an order-up-to parameter and (IP_t) includes usable inventory plus appropriately represented inbound supply.

You can tune (S), review cadence, buying horizon, expedite thresholds, or other interpretable parameters through simulation.

The sophistication belongs where it changes the decision, not where it makes the architecture impressive.

Lead-Time Uncertainty Changes MILP Models Too

Suppose you use a MILP to create a multi-period purchase plan.

In a deterministic formulation, an order (x_{i,t}) placed in period (t) may simply appear in inventory balance at period (t+L_i):

[ I_{i,t} = I_{i,t-1} + x_{i,t-L_i} - d_{i,t}. ]

This is perfectly reasonable if (L_i) is sufficiently predictable for the decision.

But if arrival timing is highly uncertain, the formulation can create false precision. The solver may exploit exact future arrivals that operations cannot actually count on.

There are several practical options.

You can keep the deterministic MILP but use conservative or scenario-dependent arrival assumptions. You can solve across scenarios and evaluate the resulting policy in simulation. You can separate the planning model from the execution policy. Or, for problems that justify the complexity, you can introduce explicit stochastic structure.

The correct choice depends on the economic value of better uncertainty treatment and the computational cost of obtaining it.

Do not turn every uncertain lead time into a massive stochastic MILP by reflex. But do not pretend uncertainty disappeared because the database schema requires an integer.

Constraints Can Change the Distribution You Care About

Suppose a vendor has an MOQ of 5,000 units.

Small replenishment decisions are impossible, so orders occur less frequently and each order creates a larger exposure to lead-time uncertainty.

Suppose ocean freight is cheap but slow and air freight is expensive but fast. Now transportation mode becomes a decision variable:

[ x^{ocean}{i,t}, \qquad x^{air}{i,t}. ]

The modes have different costs and different lead-time distributions.

The decision is no longer simply how much to buy. It is how much to buy, when to buy it, and potentially how to move it.

Capacity can couple the problem further. If multiple SKUs share supplier production capacity or container space, a late order for one item can change what is feasible for another.

This is why independently calculated SKU-level buffers often break down in real networks. The uncertainty may be item-specific, but the decisions are coupled by shared constraints.

What Should You Optimize?

A common response to uncertain lead time is to increase safety stock until a service target is met.

That can work, but it hides the economics.

A better evaluation starts with consequences:

[ \max_{\theta} ; E[\text{revenue} - \text{purchase cost} - \text{holding} - \text{shortage} - \text{expedite} - \text{obsolescence}], ]

where (\theta) represents the policy parameters.

Then track operational metrics alongside the economic objective:

average and percentile inventory,
fill rate or contractual service where relevant,
stockout duration,
late-order frequency,
expedite frequency and cost,
inventory write-offs,
cash tied up in pipeline and stock,
order stability,
and downside profit across scenarios.

A policy that adds 30% more inventory to eliminate a tiny amount of economically harmless shortage may be worse than the original. A policy that pays for occasional air freight may be better than permanently carrying months of extra stock.

You cannot know from lead-time variance alone. You have to evaluate the decision.

Common Failure Modes

Using the mean because it is easy. The average can hide the exact tail events that create shortages.

Using the latest promised date as truth. A supplier estimate is information, not a guaranteed arrival. Measure how reliable confirmations are at different stages of the order lifecycle.

Mixing incompatible timestamps. PO creation-to-ship time and ship-to-receipt time describe different processes. Define what your decision actually waits for.

Ignoring censoring. Open orders have not completed their lead times yet. A naive historical extract that only contains completed orders can underrepresent long-running delays.

Sampling lead time independently from everything else. Vendor congestion, demand surges, holidays, and transportation disruptions can create correlation.

Treating overdue orders as if they will arrive immediately. Once an order exceeds its expected lead time, its remaining-time distribution does not necessarily collapse to zero.

Using future information in replay. If a historical PO eventually arrived on October 20, a backtest on October 1 cannot act as if that date was already known unless the business genuinely had that information then.

Optimizing the forecast of arrival instead of the ordering policy. A better ETA model is useful only to the extent that the decision system knows how to react to it.

What to Do in Practice

Start by defining lead time around the decision you actually make. Identify the timestamp when the commitment occurs and the timestamp when supply becomes economically usable.

Then build a basic distribution by meaningful operational segment. Plot the full distribution, not only the mean and standard deviation. Look at the 50th, 80th, 90th, 95th, and 99th percentiles. Inspect the long delays manually. Some will be data errors. Others will explain why your planning system keeps getting surprised.

Next, reconstruct the purchase-order pipeline as part of the state. Preserve what was known about each open order at each historical decision date. This is essential for honest replay.

Then simulate your existing replenishment policy under realized or sampled lead times. Do not change the policy yet. Measure how much economic loss and operational pain actually comes from lead-time uncertainty.

Only then decide whether the answer is more inventory, earlier ordering, a different cadence, expediting, supplier diversification, mode choice, a better ETA model, or a different policy entirely.

Sometimes the best answer will still use a fixed lead time.

The difference is that you will know why the approximation is acceptable.

A number in a master-data table is not reality. It is a modeling choice.