Probabilistic lead time forecasting

Accurately estimating future lead times is critical for accurately estimating the amount of inventory needed to fulfill the future demand. Lokad’s forecasting engine features a lead time forecasting mode that is specifically tailored for lead times. Indeed, lead times need to be forecast just like one forecasts demand. Lead times also exhibit multiple statistical patterns, such as seasonality or day-of-the week effects. The lead time forecasts produced by Lokad’s forecasting engine are probabilistic, and represent the expected probabilities of every single lead time duration expressed in days. In this section, we detail the syntax used for computing lead time forecasts through Lokad.

Table of contents

General syntax

The forecasting engine has a special function - a call function as it is known in Envision terminology. The syntax is the following:

// "PO" stands for PurchaseOrders
T.Leadtime = forecast.leadtime(
  category: T.C1, T.C2, T.C3, T.C4
  hierarchy: T.H1, T.H2, T.H3, T.H4
  supplier: T.Supplier
  offset: 0
  present: (max(Orders.Date) by 1) + 1  
  leadtimeDate: PO.Date
  leadtimeValue: PO.ReceivedDate - PO.Date + 1
  leadtimeSupplier: PO.Supplier)

Unlike regular functions, call functions have named arguments instead of positional arguments. These named arguments are more suitable for complex functions, because they make the source code much more readable - at the expense of a limited extra verbosity. These arguments behave just like regular function arguments, thus, they are permitted for Envision expressions.

The function returns a vector Leadtime that is of type ranvar (see also the Ranvar algebra). Ranvars are an advanced data type that represent functions $p: \mathbb{Z} \to \mathbb{R}$. More specifically, the forecasting engine returns random variables - that is - distributions that are positive and have a mass equal to 1. In the present case, $p(k)$ represents the lead time probability associated with $k$ days. Each item - in the Envision sense - becomes associated with its own ranvar.

The full forecast.leadtime syntax includes many arguments, however, only two of them are mandatory:

• present: a scalar date value
• leadtimeDate: a date vector with an item affinity

The present value is the date intended as the first day to be forecast, following the assumption that data is complete up to the day before. Indeed, some businesses may be closed on Sundays for example, and if the most recent date found in the dataset is a Saturday, there is an ambiguity as to whether the forecast should start on Sunday or Monday. In the illustrative syntax above, we use max(Orders.Date) + 1, assuming that orders are observed every day, and that the input data is fresh from the day before.

The leadtimeDate and leadtimeValue are expected to belong to the same table, which exhibits an item affinity, that is expect [Id] in Envision terminology. The dates represent the starting days (inclusive) of the lead time observations. The values are expected to be expressed in days. Fractional days are not supported. This table contains the actual lead time history being forecast by the forecasting engine.

When leadtimeValue is omitted, the successive durations in-between the leadtimeDate dates are used as lead time values instead. This behavior is intended to forecast the ordering lead time; which is typically performed separately from forecasting the supply lead time.

Ideally, the history length should be as long as possible, although in practice there are limited benefits in exceeding 5 years’ worth of lead times. The forecasting engine accommodates both short and long lead time history alike, when this history is long, older data points simply fade into statistical irrelevance.

Beyond these mandatory arguments, the accuracy of forecasts can be greatly improved by providing more data to the forecasting engine. The following sections explain this in more detail.

Categories and hierarchy

Categories and hierarchy play a very similar role from the forecasting engine perspective: they help the forecasting engine to cope with sparse historical data. See Forecasting with attributes.

Supplier

The choice of supplier frequently plays an important part in the lead time estimation. Supplier data can be communicated to the forecasting engine in two ways that are complementary.

First, the history of lead time observations can be categorized by supplier. This is the purpose of the leadtimeSupplier argument. When this argument is present, the forecasting engine leverages this information to assess whether the lead times associated with a given supplier are correlated or not. Supplier information offers a granularity of information that may not be found through the simple item hierarchy or categories, because items may come from different suppliers over time.

Second, one can inform the forecasting engine as to which supplier is to be considered for the next shipment. This is the purpose of the supplier argument. When this argument is present, the forecasting engine can anticipate that an item may experience sudden lead time modifications, because the supplier has just been changed. Naturally, the forecasting engine may only leverage this information if the lead time history itself is properly categorized by supplier, as seen above.

Lead time offsets

By default, the forecast begins at the present day. However, sometimes, one might wish to have a forecast that starts at a later date. If the lead times are seasonal, the start date of the lead time might have a significant impact on its distribution of value. This case is handled through the offset properties. This optional property expects to have a number vector of the Items table. The values of this vector represent the offsets - expressed in days - to be considered for the lead time forecasts. For example if an item has an offset value of 10, then the first day of the forecast lead time will be present + 10. When offset is omitted, all offsets are considered to be zeros.