| Oracle® Retail Demand Forecasting Cloud Service User Guide Release 19.0 F24922-17 |
|
 Previous |
 Next |
| Oracle® Retail Demand Forecasting Cloud Service User Guide Release 19.0 F24922-17 |
|
Previous |
Next |
This appendix provides the complete list of alerts defined for the GA version of RDFCS. While some alerts are only valid for short lifecycle or long lifecycle merchandise only, others are used for all type of merchandise.
The exception management framework available in RPAS CE works on different levels. First there is the dashboard component. The exception profiles allow the user to view the hit count for every exception, and enable the in-context launch of the Forecast Review workspace.
Once in the workspace, the user can use the workspace alerts to navigate to the item/location/weeks that have been flagged. Every dashboard exception has a workspace alert counterpart. The calculation expressions are not identical, because the dashboard exceptions are at the production/location intersection, while the workspace alerts also have the time dimension.
Finally, every defined exception can be used in the approval logic. The forecast approval method is one of the following options:
Manual
The system-generated forecast is not automatically approved. Forecast values must be manually approved by accessing and possibly amending values in the Forecast Review workspace.
Automatic
The system-generated forecast is automatically approved as is.
By exception
This list contains the exceptions that were configured for use in the forecast approval process. They should match the dashboard exceptions and workspace alerts.
Dashboard and the Workspace Alerts Process
The way the dashboard and the workspace alerts can be used together, is detailed in the following steps. For example purposes, we will use the Forecast versus Recent Sales alert, for both dashboard and workspace.
First the user selects the Forecast versus Recent Sales as the choice for the Approval method.
Then the batch is run. After the forecast is generated, it is compared to the recent sales. For item/stores for which the two values are different with respect to attached thresholds, the exception is triggered, and the time series is not approved.
The user reviews the exception dashboard, and decides which items and locations she wants to review. From the dashboard she launches in the Forecast Review which is ranged down to the item and locations filtered in the dashboard.
Once in the workspace, the user can use the workspace alert to navigate to flagged time periods. She makes changes or approves the forecast directly, and commits.
The dashboard needs to be refreshed, and the hit count for the exception, in this case Forecast versus Recent Sales, will go down according to the adjust and approve actions of the user
This exception is defined for both short and long lifecycle merchandise.
Usually it is not expected that demand values differ very much period to period. This also implies that the forecast magnitude generally is in line with the magnitude of the most recent sales. There are cases when this is not the case. For instance when an item enters a season, the forecast is probably higher than the sales in periods leading to the season. Or when an item is towards the end of the season, the forecast will be lower than sales in peak periods. For these cases, the user can be alerted to review the forecast, rather than auto approving it.
The following is the alert expression:
Where length, threshold1, and threshold2 are adjustable parameters.
Note how the calculations are not performed for the entire forecast horizon, but rather by the number of periods determined by the length parameter. The reason is that the forecast horizon can sometimes be very long; for example, 52 weeks, and average demand over such a long time period cannot be used as in-season versus out of season rate of sales.
This exception is defined for both short and long lifecycle merchandise.
RDF is typically set up to generate forecast weekly. Every week, new sales data is loaded, the forecast is regenerated. While the latest data points are expected to make the forecast more accurate, it is not expected that the difference in forecasts generated in two consecutive weeks to vary too much. If the forecasts differ, the user is alerted to review the forecasts.
The following is the alert expression:
Where threshold1 and threshold2 are adjustable parameters.
Note how summation of forecasts is not performed over the entire forecast length. It is stopped one period prior the forecast horizon ends, because this is the last populated period of the last approved forecast.
This exception is defined for long lifecycle merchandise.
The most reliable forecasts are generated from data that has a repeatable pattern year over year. However, this is not always the case. A change in business strategy, merchandise reclassifications, New Items can all lead to changing selling patterns over time.
To detect possible changes in selling patterns, the following alert will compare the last year's sales volume with the forecasted sales volume. If they are different by an adjustable percent, the alert is triggered.
The following is the alert expression:
Where threshold1 and threshold2 are adjustable parameters.
First we check if the forecast is close to the sales LY. If it is, no alert is triggered. If it is not, we check the rate of sales of the item. If the item is selling consistently, we trigger an alert. If the sales and forecast are different, but the rate of sales of the item is not significant - defined by threshold2, no alert is triggered. This way we avoid prompting the user to review forecasts for low selling items.
This exception is defined for long lifecycle merchandise.
The purpose of this alert is to check how large the forecast peaks are compared to historical demand. The peaks can come from various effects like promotions, price discount, demand transference due to assortment changes, and so on. The most common, though, are due to price changes and promotions.
The following is the alert expression:
Where the Causal Peak Factor is an adjustable parameter.
The business case this addresses is to alert you when the peaks in the forecast region are larger than any observed sales in the past. There may be valid justification for this, for instance, several events are active in the same time period, thus creating a huge spike in demand. You can review the alert and take action.
This exception is defined for short lifecycle merchandise.
This exception is only available for the dashboard, and is meant to give the user a heads-up of the number of items that will start selling in the near future.
The following is the alert expression:
Where the Calculation Periods is an adjustable parameter.
