# Calculating the lead times

The lead time is a variable that is fundamental to properly compute how much inventory is needed to cover the future demand. A proper measurement of the lead time is required no matter which forecasting technology is used. The lead time,as needed for inventory optimization purposes, involves some subtleties. In this page, we illustrate how the lead time should be measured in practical situations.

See also the lead time definition and lead time forecasting.

Lead times are best computed based on your past purchase orders, looking at the delays between the orders and the deliveries. In particular, we suggest not to trust the “official” lead times given by suppliers, as they frequently over or underperform those values. If your business is using an app natively supported by Lokad, then Lokad auto-computes the applicable lead times automatically based on your historical data.

**Table of contents**

## Lead times and forecasting horizons

The term *lead time* can refer to many things. There are manufacturing lead times, transportation lead times, ordering lead times, etc. When a supply chain decision need to be optimized, all those lead times need to be taken into account as whole. We refer to this “consolidated” lead time as the *forecasting horizon*. This horizon is then consumed as an input by the demand forecasting engine.

Classic forecasting methods tend to complicate the problem further because of their own limitations. Daily forecasts are frequently deemed as too erratic, and thus weekly or even monthly forecasts are used instead. However, when weekly or monthly forecasts are used, there is no longer a canonical way of adjusting the projected demand to the horizon of interest.

Lokad’s forecasting engine addresses this problem by directly taking a horizon expressed in days as input for its demand forecasts. Moreover, the engine is also capable of processing an *uncertain* horizon represented by a probability distribution.

Be aware that agreements with suppliers frequently involve lead times expressed in business days, thus those quantities need to be recalculated as calendar days.

## A segment covering the future starting from the “present”

A demand forecast typically starts from the “present” date and moves onward until the full horizon is covered. In practice the “present” does not always reflect the real wall-clock time, instead it represents the end of the historical data. As historical data tend to be retrieved in batches, there might be a small discrepancy. Lokad’s forecasting engine requires a `present`

variable to be provided, precisely because it’s not always possible to remove the ambiguity by just inspecting the historical data itself, as it’s not always possible to differentiate between lack of demand and truncated sales data for the last few hours of the dataset.

In the illustration here above, we have a lead time equal to 4 days, which is used as the horizon for the forecast. It means that if we compute a reorder point with this lead time, and say, a service level of 95%, the reorder point will be the minimal inventory value - as forecasted by Lokad - that is sufficient to cover the fluctuation of the future demand, so that 95% of the time the reorder point is higher than the demand - hence avoiding the stock-out.

In the following, we will see that probabilistic forecasts offer a superior alternative to the reorder points. In the meantime, for the sake of simplicity, we adopt the simpler viewpoint associated to reorder points.

## Reordering delays

The horizon, as presented above, must embed all factors that delay the actual replenishment. In particular, there is almost always a reordering delay. Reorders - orders passed to suppliers - are typically not made in real-time as SKU units get sold or consumed. For example, some SKU may only be reordered once a week.

In the illustration here above, we assume that reorders are made every 3 days, with a supplier lead time of 4 days. In this situation, it is tempting, but incorrect, to use a horizon of 4 days. This delay does not take into account the 3 days of delay until the next reorder. If a horizon of 4 days is used, the reorder point won’t properly cover the Days Five, Six and Seven.

Here, the proper horizon of demand to be considered is 4+3 = 7 days. Hence, starting from Day Zero, inventory should last, not until the end of Day Four when the first delivery arrives, but until end of Day Seven when the second delivery arrives. The reorder B has no impact until the end of Day Seven, so whatever quantity gets reordered on Day Zero, it should cover all demand fluctuations until the end of Day Seven. From Day Seven and beyond, it’s the reorder B that is to be in effect.

## Forecasting the same day twice

Looking at the illustration below, it might seem surprising that the same day gets forecasted twice. The Days Four to Seven are part of the first demand forecast starting at the end of Day Zero, but those days are also part of the second demand forecasts starting at the end of Day Three.

However, this is the intended behavior. The demand forecast is turned into the reorder point. Yet, the **reorder quantity** itself comes as the reorder point, minus the stock on hand and minus the stock on order. Thus, a single day might be forecasted twice as part of the reorder point calculation, yet the same day is not going to be counted twice as far as reorder quantities are concerned.

## Sample scenarios

In this section, we review a couple of typical scenarios to further shed light on calculating the relevant horizons when more complex lead times are considered.

### Next day delivery with closed days

Let’s assume that a retail store is as follows:

- The store is open every day of the week except Sunday.
- The store gets deliveries every day, except Sunday.
- The store reorders are made every day before 10am, and delivery happens the next day. The Saturday reorder is delivered on Monday.
- Data is pushed to Lokad every day at 5am. Sales data stops at midnight the previous day.

In this case, the horizon equals 2 days for all days, except Saturday where the lead time equals 3 days.

### After next day delivery with semi-closed days

Let’s assume that a retail store is as follows:

- Store is open every day of the week.
- Store is delivered every day, except Sunday.
- Store reorders are made every day before 10am, and delivery happens the day after the next day. Friday’s reorder is delivered on Monday. Saturday’s reorder is delivered on Tuesday.
- Data is pushed to Lokad every day at 5am. Sales data stops at midnight the previous day.

In this case, from Monday to Thursday, the horizon equals 3 days, one day of reordering delay, plus two days of supplier lead time. Then, on Friday and Saturday, the horizon equals 4 days. Those two days and the closed Sunday need to be taken in to account supply-wise. In particular, the decision made Friday morning needs to last until Tuesday end of day, because the Saturday reorder has no impact on Tuesday.