Understanding the forecasting engine

The forecasting engine refers to the specific component within Lokad that is responsible for core predictive analysis. This engine is an advanced piece of software, which can be aptly categorized as machine learning. Moreover, this engine is very different from the classic forecasting toolkits typically geared towards time-series forecasting. In this article, we explain what this engine does, how it differs from classic toolkits, and why these differences matter when it comes to delivering sound results from a supply chain perspective.

Integrated forecasts vs periodic forecasts

The classic time-series viewpoint emphasizes daily, weekly or monthly periodic forecasts. In this case, historical data is represented as periodic time-series, and forecasts are expected to be represented as periodic time-series as well. While this viewpoint might be appropriate for certain domains, such as energy consumption forecasting or highway traffic forecasting, we have found that this approach performs poorly whenever supply chain optimization is concerned.

Periodic forecasts don’t match the underlying reality of supply chain management: if the lead time to be considered is 10 days, should we sum the daily forecasts up to 10 days ahead? Should we sum 1 weekly forecast plus 3 daily forecasts? As a rule of thumb, summing forecasts is a big statistical no-no: the forecast of the sum is not the same as the sum of the forecasts. Therefore, if the lead time is equal to 10 days, then, it’s the responsibility of the forecasting tool to produce a 10-day-ahead forecast, and not a set of intermediate forecasts to be recomposed into the desired forecast.

As a result, Lokad’s forecasting engine is not restricted to the calculation of daily, weekly or monthly forecasts. As a superior alternative to those forecasts, it can directly compute demand forecasts that match the expected lead time. Moreover, the lead time is expected to be a probabilistic forecast of its own. At first, this behavior might appear a bit disconcerting, but unfortunately, the idea that arbitrary forecasts can be accurately recomposed through sums of periodic forecasts is wishful thinking in nearly all supply chain situations.

Probabilistic forecasts vs mean forecasts

Classic forecasting tools emphasize mean forecasts, or sometimes, median forecasts. Yet, when it comes to supply chain optimization, business costs are concentrated at the extremes. It’s when the demand is unexpectedly high that stock-outs happen. Similarly, it’s when the demand is unexpectedly low that dead inventory is generated. When the demand is roughly aligned with the forecasts, inventory levels fluctuate a bit, but overall, the supply chain remains mostly frictionless. By using “average” forecasts - mean or median - classic tools suffer from the streetlight effect, and no matter how good the underlying statistical analysis, it’s not the correct question that is being answered in the first place.

In contrast, Lokad’s forecasting engine delivers probabilistic forecasts, whereby the probabilities associated with every possible future ₍₁₎ are estimated. These probabilities provide much more granular insights into the future compared to single-valued predictions, such as mean or median forecasts. Through probabilistic forecasts it becomes possible to fine-tune supply chain risks and opportunities. More precisely, for each possible supply chain decision - such as buying 1 extra unit of stock for a given SKU - it is possible, for a given future demand level, to compute a back-of-the-envelope financial outcome ₍₂₎; and thus, ultimately prioritize all possible future decisions ₍₃₎ based only on a “weighted” financial outcome by combining financial estimations with probabilities.

(1) However, in practice, to keep the calculations feasible, probabilities that are deemed too low are rounded to zero. Therefore, only a finite set of configurations are actually investigated.

(2) For example, let’s imagine that we buy 1 unit now, and the future demand is 5 (meaning that we will sell 5 units), and have a stock of 2 at the end of the period. If we assume that the gross margin is 10 and the carrying cost per period for each unit unsold is 15, then the net profit is 5 x 10 – 2 x 15 = 20.

(3) Prioritizing all future decisions might sound like a dreadfully complex task, but Lokad’s technology happens to be dedicated to this very problem. This technology is distinct from the forecasting engine itself.

Toy datasets and synthetic data patterns

Practitioners who have already used a forecasting toolkit in the past might be tempted to test Lokad against a time-series of a few dozen data points, just to see how it goes. Furthermore, one might also be tempted to check out how Lokad reacts to simple patterns, such as a linear trend, or a perfectly seasonal time-series. While it may come as a surprise to practitioners, our forecasting engine actually performs poorly in such situations. Unfortunately, this “poor” behavior is necessary in order to obtain satisfying real-life results.

One major specification of our forecasting engine is to deliver accurate forecasts while requiring zero manual statistical fine-tuning. In order to achieve this, Lokad has pre-tuned the forecasting engine using hundreds of real-life well-qualified datasets. Synthetic data patterns, such as a perfectly linear trend, or a perfectly cyclical time-series, are very unlike the patterns we found in real-life datasets. Consequently, such synthetic data patterns, albeit being seemingly straightforward, are not even considered. In fact, what is the point of delivering “good” results on “fake” data, if it comes at the expense of delivering “good” results on “real” data? Our experience indicates that a good forecasting engine is very conservative in its choice of forecasting models. Introducing a “perfect fit” linear regression model just for the sake of succeeding on toy datasets is downright harmful at scale, because this model may be used where it should not have been.

Furthermore, in order to entirely skip all the manual fine-tuning, our forecasting engine relies heavily on machine learning algorithms. As a result, the engine needs a sizeable dataset to work. In fact, the forecasting engine establishes its own settings by performing many statistical tests over the datasets. However, if the overall dataset is too small, the forecasting engine won’t even be able to properly initialize itself. As a rule of thumb, at least 1000 historical data points spread over 100 SKUs are needed to start getting meaningful results. In practice, even small e-commerce businesses, making less than 1 million € in turnover per year, tend to accumulate over 10,000 data points, typically spread over more than 200 SKUs. Therefore, the forecasting engine’s data requirements are actually very low, but not so low that the forecasting engine can be expected to work on “toy” datasets.

Forecasting engine’s data requirements

Here is a short checklist for the forecasting engine’s minimum data requirements:

• items: min 100, better 500, best 2000+
• item attributes: min 1, better 3, best 5+
• past sales orders: min 1000, better 10000, best 50,000+
• past purchase orders: min 50, better 500, best 2000+
• history depth in months: min 3, better 18, best 36+

The items refer to the SKUs, products, part numbers, barcodes, or whatever element needs to be forecast depending on the specific business situation at hand.

Purchase orders are required for forecasting the lead times. While they may be omitted at the initial stage, incorrect lead time estimations may wreak havoc on your supply chain, and hence, we strongly recommend providing this data whenever possible.

Input data can be further enriched by providing a history of stock-outs and promotions. In reality, the forecasting engine supports even more advanced data scenarios. The present section only focuses on the “must-have” data.

Macro forecasts and high-frequency forecasts

Lokad’s forecasting engine is geared towards supply chain situations in commerce and manufacturing. These situations are characterized by their numerous SKUs and their erratic demand. It is in such situations that our forecasting engine shines the most. On the other hand, there are other types of forecasts that don’t fit our technology.

Macro-forecasts, which involve forecasting highly aggregated time-series, typically very smooth - once cyclicities are taken care of - and very long, are not Lokad’s forte. Such scenarios are witnessed in energy consumption forecasts, highway traffic forecasts, cash flow forecasts, incoming call traffic forecasts, and so on. Our forecasting engine is geared towards many-items forecasts, where correlations between items can be leveraged extensively.

High-frequency forecasts, which involve time-series with intra-day granularities, are also not handled by Lokad. These situations include most financial forecasts, including commodity and stock exchange forecasts. Here, the challenge lies in the fact that statistical patterns are already exploited - by other people - and have an impact on the future itself. This case is very different from supply chain, where demand forecasts have only a moderate impact, ₍₄₎ on the observed future demand.

(4) It would be incorrect to say that demand forecasts have no impact on the demand at all. For example, forecasting more demand for a product in a given store is likely to increase the facing of this product, and hence boost the demand. However, such patterns tend to be marginal in supply chain.