| Oracle® Retail Demand Forecasting Implementation Guide Release 16.0 |
|
 Previous |
 Next |
This chapter describes the advanced RDF configurations including:
Configuring Daily Causal, as opposed to using Daily Demand, has these advantages:
Creates a more robust forecast
Saves disk space by avoiding measures at the day dimension
Performs much better in terms of runtime
To configure RDF for Daily Causal implementation, complete the following steps.
Create a Daily Final Causal level.
Set both Causal Calculation Intersection and Causal Data Source at the week level.
Causal External baseline is provided at week level.
Promotions can be provided at day or week level.
Provide a week to day profile (based on DOW) to spread external baseline to day level prior to system forecast output. If no spread profile is provided, the default of 1/7 is used. The profile can be created using a few weeks of daily data.
The same week to day profile (based on DOW) can be used to aggregate promotion from day to week. If no aggregation profile is provided, the default of 1/7 is used.
|
Note: Although the forecast is at the day level, the majority of the historical inputs are at weekly level. The daily measures are possibly some promotions (which are sparse), and very few weeks worth of daily demand to generate the DOW profile. |
RDF is proven to work well for items with long life cycles. It also offers methods to forecast short life cycle, but these methods require additional input, other than the historical demand. This input is a life cycle profile which is a pre-season estimate of how the items will sell.
Once the item starts selling (in-season), the life cycle is combined with the actual sales to create the forecast.
To configure RDF for Short Life Cycle Merchandise, complete the following steps.
Calculate a baseline forecast:
If price information is available, use the deprice filter to deprice historical demand
If promotion information is available, use the STD ES filter to depromote historical demand
After demand has been cleaned, it can be used to create a life cycle profile.
You can configure rules to achieve a life cycle profile, or use the Curve solution. In Curve, you specify which part of the history should be used, the intersection at which the profile is created, and the periods in the future, when the items will sell. Curve will handle the stretching/compressing and time-shifting of the profile to periods in the future. This profile can be transformed to units if the total buy for the items is known. It is common for short life cycle items to order a certain quantity, that sells over a certain period. The total quantity multiplied by the profile gives the number of units sold every period.
This represents the pre-season forecast.
Finally, the profile-based or Bayesian forecasting methods, combine the life cycle profile or the pre-season forecast with actual sales, to generate the in-season short life cycle forecast.
If the merchandise is promotional, use Causal Effect Estimation to be configured to generate a causal forecast
Use Causal Effect Estimation:
Use base RDF Causal functionality for data pooling.
Data pooling allows promotion effects estimation at an agggregate level. The level/intersection can be the same as the level used to generate the life cycle curve in the previous steps. These effects are used for the new short life cycle merchandise.
Generating a Causal Forecast:
Combine the baseline and promotional lifts calculated in Steps 1 and 2, respectively, to generate the final forecast.
|
Note: The aggregation level for generating the life cycle profile and the causal effects works best when it includes item/locations which share similar selling patterns. RDF has the ability to group item/locations based on attributes, and not always be tied to the hierarchy dimensions.For example, you can write rules to group together all item/locations that started selling in the winter season and had a life cycle of three months. The life cycle profile created using these items, is probably more accurate (in terms of life cycle) than a profile created at, for instance, department level. |
In an RDF causal implementation, an annual event that does not occur in the same period every year, but has a spike in demand associated with it, is handled by associating a causal factor to it. The system then determines the associated lift, and applies it to the relevant point in time in the forecast horizon.
In an RDF-lite implementation, where there is no Promote module, these events may still exist. For example, an increase for sales leading to Easter, happens even if there is no promotion specifically associated with Easter (chocolate bunnies sell more during Easter even though they are not specifically promoted). Since Easter does not occur at the same time every year, the Easter spike appears randomly any time in March or April. The spike is baked in the seasonality of each item/store, making its prediction; timing and magnitude, inaccurate at best. RDF-lite can support floating events and holidays through extra configuration efforts. RDF GA configuration has configured an example to show how to support floating events forecasting without enabling the Promote module.
To configure RDF-lite for Floating Annual Events and Holidays forecasting, complete the following steps.
Twenty (20) floating event indicators are configured as Boolean measures at Item/Store/Week in PrepDemandCommon module. These indicators are expected to be loaded.
Combined Weekly Floating Event lift Estimation is configured as a rule group named gen_floatlift in the PrepDemandCommon module. In this rule, the CausalEstimation special expression is used to estimate the floating event effects at Item/Store level using preprocessed sales history and floating event calendar.
The input sales is corrected for out of stock, outliers and seasonal effects.
The forecast150 special expression is used to transform the floating event effects at item/store into a combined weekly floating event lift. The lift ratio is 1 in normal week and it will be more or less than 1 when there is a floating event.
This step can be invoked through running rdf_gen_float_lift.ksh
Configuring Baseline forecast in RDF. (Level 1 in RDF/RDFCS configuration). The input sales history is corrected for out of stock, outlier and promotion spike. Several source level are set up for the final level.
Configuring a final level (in RDF configuration, level 8) to run component based forecast. Refer to the Oracle Retail Demand Forecasting User Guide for more information about the component forecast method. The component baseline is pointing to the approved forecast from level 1. The component promotional lift is mapped to the combined floating weekly event lift calculated in Step 1.
