- The Quantitative Supply Chain Manifesto
- The Lokad test of supply chain performance
- An overview of quantitative supply chain
- Generalized probabilistic forecasting
- Decision-driven optimization
- Economic drivers
- Data preparation
- The Supply Chain Scientist
- Timeline of a typical project
- Project deliverables
- Assessing success
- Antipatterns in supply chain

- Inventory forecasting
- Prioritized ordering report
- Old forecasting input file format
- Old forecasting output file format
- Choosing the service levels
- Managing your inventory settings
- The old Excel forecast report
- Using tags to improve accuracy
- Oddities in classic forecasts
- Oddities in quantile forecasts
- Stock-out's bias on quantile forecasts
- Daily, weekly and monthly aggregations

Home » Resources » Here

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.

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.

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

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

`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.

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 5, 6 and 7.

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 4 when the first delivery arrives, but until end of Day 7 when the second delivery arrives. The reorder B has no impact until the end of Day 7, so whatever quantity gets reordered on Day Zero, it should cover all demand fluctuations until the end of Day 7. From Day 7 and beyond, it’s the reorder B that is to be in effect.

However, this is the intended behavior. The demand forecast is turned into the reorder point. Yet, the

- 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.

- 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.