Quantile grids are the most advanced forecasting technology
offered by Lokad that delivers superior inventory optimization performance and capabilities. The forecasting engine can be configured to produce this type of forecasts by selecting the quantile grid as the forecasting mode. In this page, we shed some light on this forecasting mode and explain how you can better understand the purchase prioritization list calculated leveraging the quantile grid forecast generated by Lokad.
Classic forecasting produces one forecast value per SKU and per day (or week or month). Unfortunately, this approach is simplistic and does not capture all the irreducible uncertainty associated with future demand. In contrast, the quantile grid approach consists of forecasting the probabilities for (almost) every possible level of future demand. In practice, this means that the forecasting engine is creating:
- one forecast for the probability of observing zero units of demand,
- one forecast for the probability of observing one unit of demand,
- one forecast for the probability of observing two units of demand,
In theory, this process could go on to infinity. In practice, Lokad stops when the probability of observing a given level of demand is so low (when the demand levels become too high), that it is not even worth to further investigate its associated probability - for example, when the probability of observing over 1000 units of demand over a specific time period is less than 0.1%.
However, such raw
probabilities are hardly usable as such. As a result, Lokad also provides built-in dashboards that turn these raw probabilities into a prioritized list of purchase suggestions. This lists takes into account both the positive outcomes, such as selling the item and making a profit, as well as the negative outcomes, such as keeping the item in stock for a long period of time with the associated carrying costs. The probabilities computed by the quantile grid forecasts are used to properly weigh all the possible future outcomes.
Lokad offers the possibility to create a forecasting project and to configure this project by using the forecasting mode named quantile grid
. When such a project is run, all the forecasted probabilities are gathered into a file named
. This file can be quite large compared to the input data because every single item (or product, or SKU, depending on the situation) can be associated with many different demand levels, each one having its own estimated probability.
In addition, when data originates from one of the native integrations
supported by Lokad, the forecasting engine has its own dashboard that is designed to turn this quantile grid (i.e. raw probabilities) into a suggested purchase priority list. This screenshot below illustrates this process with the sample dataset
dashboard. Other data sources typically offer slightly different dashboards, but the overall principles remain the same.
On the left, the dashboard includes a form with several settings that control the suggested priority ordering list. While computing the quantile grid is an extremely intensive process, typically requiring 30 to 60 minutes to complete, reprocessing the forecasts in order to regenerate the prioritized list of purchase orders is a very rapid operation, typically lasting about 10 seconds. Be careful not to confuse the “Start run” button at the top, which triggers the forecasting engine, with the “Save and run” button below which merely re-prioritizes the items to be purchased according to the settings.
The dashboard that converts the raw demand probabilities into a shortlist of items to be replenished comes with a couple of settings. The most notable setting is the Max spend budget
. This setting put a constraint on the total size of the reorder. If you leave the budget at zero, then the shortlist will be empty. On the other hand, it is not recommended to use a very large budget either because in this case, the shortlist
is going to grow considerably, including very unprofitable suggestions in the process. As a rule of thumb, the budget entered in the simulator should not be more than twice as much as your usual periodic reordering budget as this carries the risk of making fairly unprofitable purchases.
We suggest sticking to budgets that closely match your inventory turns. For example, if your company is reordering on a weekly basis, then the reorder budget for the week should be very close to the amount of inventory sold last week. In practice, as you get started with Lokad, simply maintaining your usual inventory budget will gradually increase the service levels. Then, once the situation becomes stable, you can target a budget that is slightly above your current inventory spend if you want to increase your service levels, or on the contrary target a budget that is slightly below your inventory spend if you want to reduce your inventory costs. In both cases, Lokad puts an emphasis on gradual inventory transition towards a more profitable configuration.
The sample simulator also includes a setting named Capital interests
expressed in percentages. This value represents the total annualized inventory costs relative to the purchase cost of inventory. By default, it is assumed that keeping $1 worth of inventory in stock for a year costs $0.30, that is, a 30% interest rate. Inventory costs
are steep and should not be underestimated. For smaller companies, we recommend not to use any value smaller than 25%, if only because of opportunity costs.
Also, Lokad has an extensive multi-currency support as it frequently happens that goods are not purchased and sold in the same currency. In particular, Lokad can apply the correct historical currency conversion rates automatically. The sample simulator expects the ISO three-letter currency code of the desired currency to be entered.
Understanding the results
Beside the settings on the left, the dashboard includes multiple reporting elements. The most notable element is the DOWNLOAD
table that contains the suggested reorder shortlist. This table contains the list of items that are suggested to be reordered, with the other items being excluded from the list.
Let’s review the columns of this table:
Supplier: the supplier associated with this item. Unless items have an explicit affinity towards a primary vendor, this field is frequently populated using the last observed vendor for the item.
OnHand: the stock-on-hand quantity for the item. This field can be used to get a sense of the current stock level before triggering another purchase. Also, this quantity is taken into account when computing the expected ROI by using the suggested quantity to be purchased.
OnOrder: the stock-on-order quantity for the item. Same purpose as “OnHand”
Qty: the suggested order quantity. This quantity takes into account the probabilities of future demand over the lead time, but also the stock-on-hand and stock-on-order.
D: a simple measurement of the total demand observed for the item over the last year; it is expressed in units. This factor is primarily intended as a sanity check, to make sure that the suggested quantity makes sense compared to the yearly demand.
LT: the lead time expressed in days. Lokad typically tries to automatically compute the lead times by averaging observations per suppliers. However, the purchase order data is not always sufficient to generate the correct estimates of the lead times, and in this case the lead times can be adjusted manually.
SL: the current service level over the coming lead time, as estimated if no reorders are made for this specific item.
ExM: the expected additional gross margin to be earned thanks to the suggested reorder quantities if the reorder is triggered today.
ExC: the expected additional inventory carrying cost caused by the suggested reorder quantity if the reorder is triggered today.
Cost: the purchasing cost per unit multiplied by the suggested quantity to be purchased. The sum of the costs is lower than the spend budget specified in the simulator.
Above the table, there is a series of indicators that are primarily intended to act as sanity checks: the goal is to ensure at a glance that the data processed by Lokad is consistent with the overall business metrics. It is hardly surprising that if the input data is incorrect, this will typically result in wildly diverging overall figures. When this happens, there is no point in further analyzing the list of the reordering suggestions as the issues with the input data need be addressed first.
On the left, below the simulator settings, there are two additional SL
(service level) metrics. The SL before
metric indicates the present service level in the case of no reorder being made immediately. The SL after
metric indicates the improved service level if the items suggested by the reordering shortlist are purchased today as suggested by the software.
The transformation of the quantile grid into a shortlist of reorder quantities typically involves some domain specific-settings. For example, while Lokad can extrapolate the sales prices and the purchase prices from the sales order history and the purchase order history respectively, it is often more reliable to rely on the price lists containing prices that are guaranteed to be accurate. When applicable, our data connectors allow you to choose among the different price lists available in order to establish which lists should be used for the selling and buying prices respectively.
In addition, the purchase prioritization approach can also take into account your supply chain constraints
. For example, it is possible to handle minimum order quantities per SKU or per order, but also maximum quantities, for example when container shipments are involved.
Additional documentation is available on building your own priority lists
. However, as part of the service for our Premier subscription plans
, Lokad can entirely manage all the constraints on your behalf, and to deliver results that are not only highly optimized, but also fully compliant with all the processes and constraints applicable to your company.