Forecasting is the process of statistical forecasting whereas Demand Planning is the process of viewing and overriding the statistical forecasts with in-app edited or uploaded user defined forecast at any combination of hierarchical levels. This article covers the forecasting process in Advanced Business Planning.
Step 1: Define Default Forecast Settings
Configured in System Settings:
- Forecast History Type:Select either the customer order ship date or original order due date (Actual) as the basis for history used for forecasting.
- Auto Remove Outliers:The number of iterations specifies how many times the system will attempt to smooth history. The more iterations the smoother the history and the lower the standard deviation becomes. If the use of this feature is desired, we do not recommend more than two iterations. Setting the value to 0 disables the outlier setting.
- Sigma Threshold: Sets the number of standard deviations for DemandCaster to identify an outlier.
- Forecast History Length (months): The number of months of history to use for forecasting as a default. Default is 48 months for demand planning. The Advanced Planning app has an additional functionality that automatically sets the proper history length by removing leading 0's for forecasting.
- Ignore last N buckets: Provides the capability to ignore a set number of the most recent forecasting buckets. This is at times necessary when the most recent sales data is not available when running a new forecast. By ignoring the last period, for example, your forecast will not be influenced by a very low demand period. At present this option is an all or nothing setting meaning it is applied to all forecasts.
- ADI Threshold:The threshold set to establish the historical demand profile based on the measure of frequency of demand.
- CoV Threshold: The threshold set to establish the historical demand profile based on the measure of volatility of demand.
- Force Average forecast algorithm when history length equal or less than: This global system setting enables the user to force the use of the Average forecast algorithm when the number of periods of history (the period is tied to the forecast bucket type) is less than or equal to the specified number. For example, if the number of periods is 3, then the average algorithm is used when there are only 3 or fewer recent periods of history.
- Force Zero forecast algorithm if last period of demand is older than: This setting is used to specify the number of periods with zero demand in the immediate past that will trigger the application of a zero forecast to a context. For example, if a value of 6 is entered, if there is no demand over the last 6 months or 6 weeks (depending on the forecast buckets applied), the forecast for that context will be 0.
- PCL Ration Distribution Periods (months): Determines how many months in the past to allow the system to calculate the historical disaggregation distribution percentages.
Step 2: Determine the Forecasting Hierarchy
Every product based company has the same basic selling structure. It sells many items that are sold to many customers typically out of many locations. For some companies, it is quite OK to forecast an item based on its total sales. However, if you are a company that sells to retail, manages promotions, or is one to two tiers away from an OEM customer, you should consider forecasting by the context of your key customer, channel, product category, location, or other demand definition. Without context, going to sales and asking how a specific item or product family is going to sell guarantees a non committal response.
The hierarchy helps establish the context to which item forecasts are generated and managed. It is made up of two (3 if DRP is enabled) independent yet related components which for simplicity sake we will call the Product, Customer, and Location (PCL). This is the who, the what, and the where of sales. The table that ties these elements together is the sales register in your ERP - the record of who bought what when, how much, and from where.
Without a proper hierarchy, the ability to roll up data to any hierarchical level becomes more complex. Once the hierarchy is built, it is significantly easier to pivot, present, and edit data. With the ability to add hierarchical levels allows for an infinite number of pivot combinations.
In DemandCaster, the Customer Hierarchy typically defines the who. This is who the items are sold to and is commonly composed of elements such as the end customer, ship from location, market, channel, region, or other top down one to many definition. The key comes to sales marketing and in turn how you sell and promote. This is something that the front end of your company understands and responds to.
For companies that sell to thousands of one off customers such as those in brick and mortar retail or internet retail, the definition of customer is singular i.e. there is one customer and it is their direct internet and retail channel..
Ask sales or marketing how they define and plan their customers. This will help define the customer for demand planning
When building the forecast hierarchy, consider what grouping will provide the clearest picture of market behavior and will be able to be easily reviewed by persons that have accountability. For simplicity sake, we recommend a minimum of two forecasting levels and a maximum of four.
The top aggregate level sets the context to which forecasts will be calculated, and the bottom level where the forecast will be statistically calculated when middle-out approach is applied. The objective is to set the levels where the grouping is significant enough to generate a meaningful statistical forecast at an aggregate level i.e. defines seasonality and trend.
To view the hierarchy, click on the hierarchy button. In the example below, the context is item by customer.
The term customer is used to describe who creates demand. This could be a channel, discrete customers, or group of customers. The term location is typically used to describe a ship from location but it could also be a geography market location.
Once the forecast hierarchy is created, we recommend not changing it to ensure there is consistency from plan to plan.
If the hierarchy is changed, a new forecast needs to be run for the changes to apply.
Add your comment