This chapter provides an overview of forecasting and discusses:
Forecasting concepts and components.
Forecast development.
Forecast review.
Forecast tuning and collaboration.
Integration with other applications.
Forecasting is predicting the sales and use of products and items, making it possible to manage their purchase and manufacture. The goal of the PeopleSoft Demand Planning forecasting system is to help you effectively manage the forecasting process, improve forecasting accuracy, and publish forecasts for use across other PeopleSoft applications and third-party systems. The quality of the forecast helps balance inventory investment with target customer service levels.
When used with PeopleSoft Inventory Policy Planning, forecasts drive the inventory investment. If you have a poor forecast, one with a high forecast error, PeopleSoft Inventory Policy Planning compensates by suggesting higher safety stock. Conversely, an improvement in the forecast error results in lower safety stock. High finished-goods inventory offers the best opportunity for savings through a combination of PeopleSoft Demand Planning and PeopleSoft Inventory Policy Planning. This is especially true when little prior attention has been given to a systematic process of setting statistical safety stock levels and customer service levels.
To meet forecast goals, the PeopleSoft Demand Planning forecasting system provides a comprehensive set of forecasting tools that produce quantitative forecast results and a group of features that incorporate business knowledge into the forecast. The qualitative and quantitative factors are general methods of forecasting. While each has its benefits, good forecasting ultimately involves some combination of both methods.
PeopleSoft Demand Planning uses ForecastX™, its mathematical calculations, and its methodologies to meet quantitative values for forecasts. In addition to using 14 basic forecasting models to arrive at forecast results, ForecastX uses a best-fit program that automatically determines the best model on which to base a forecast.
Along with the quantitative means, PeopleSoft Demand Planning has a variety of features and methodologies for which you can use subjective judgment and opinions concerning future trends. For example, life profiles, seasonality groups, and forecast events lend themselves to qualitative forecasting. Through structured groups, marketing research, estimates, and historical-analogy methods, you can better predict the future.
These features are useful in forecasting demands when there is little or no data to support quantitative methods and where it can be assumed that past history is not a good indication of the future. You also use qualitative methods to adjust quantitative forecasts.
Extrinsic Methods
Each forecasting environment is unique. This means that each organization must determine what makes up a forecast. Two major forecast methods that go into determining what makes up a forecast are extrinsic and intrinsic methods.
Extrinsic methods identify a relationship between some external factor and the target time series. For example, sales of chilled beer on a day in Australia might depend on how hot the weather is that day. When the relationship between the external factor and the target demand pattern is understood, then you can project the external factor and use that projection to forecast the target series. The selection of the best forecasting method depends on factors such as forecast time horizons, data characteristics (variability), organizational needs, and available data.
Intrinsic (Data Series) Methods
Intrinsic methods, also known as data-series methods, use the time-phased history of demand for a target item as the basis for developing a future forecast of demand for that item. They identify, or model, the demand pattern and use the historical model of the pattern to project a forecast into the future.
Intrinsic methods attain their results by performing data series analysis. Generally, you can think of a data series as consisting of these components:
Cyclical (non-annual).
Base.
Trend.
Seasonal.
Random.
The cyclical component traditionally refers to long-range trends in the overall economy. It is of little use in forecasting demand for individual products over the short and medium term. These products rarely have sufficient data to permit a distinction to be drawn between the effect of the business cycle and the product life cycle. For PeopleSoft Demand Planning, you use data series for short- and medium-term forecasting consisting of base, trend, seasonal, and random components.
The system models trends in the data as a line that is described as an intercept or base component, and a slope or trend component. You can change the trend line by seasonality (usually indexed based on the trend line). Unpredictable variations, such as random or irregular data, reduce the predictability of a forecast.
Trends are directed toward time series that can be developed from the set of data points without the introduction of any external causal factors. To provide reasonable results, at least two years of data is required, and the data points should be well disbursed across the span of periods. Data series with significant zero-value periods, erratic demand, or heavy spikes are not good candidates for accurate forecasting.
This section discusses:
Concepts and components.
User-defined fields.
User-adjusted forecasts.
Forecast views.
Control groups.
Summarization.
Calculations.
Proration.
Events.
Dynamic views.
Disbursement views.
Cross-view reconciliation and view balancing.
To assist you in reaching forecasting goals, PeopleSoft Demand Planning uses a set of forecasting components for structuring what you want to forecast. These next sections provide details about the practical use of these major forecasting components.
The most important part of forecasting is to review and understand what to forecast, how to develop the forecast, and who is going to use forecast. Each organization is different in how it looks at its marketplace. Some portion of the marketplace is determined by the organizational structure, such as whether it is managed by region, channel, or product group. The marketplace may also be segmented into different businesses, product categories, or brands. The primary objective of an organizational and market review is to determine who within the organization needs to review and contribute to the final forecast.
The view structure of the data representation ideally suits product markets that have many dimensions (such as brand, channel, color, flavor, and so on). Dynamic views support this structure by enabling additional mechanisms for adjusting data.
PeopleSoft Demand Planning is set up so that different groups within the organization can review the forecast in terms to which they can relate. Additional organizational units may also need to use the output of the forecast, but in a different form, for example, demand by source plant or intermediate product volumes. This analysis helps define the additional characteristics (user data fields) that must be set up for the forecast item and promotes collaboration.
After determining organizational requirements, you design the forecasting structure. Designing the structure involves setting up the required user-defined fields. You must set up these fields before creating the forecast views. The system provides existing planning fields that contain specific inventory data. When mapping user-defined fields, use that same data while referring to it by that name or a name that you assign to it.
The system enables the use of up to 50 user-defined fields for the forecast item. The system combines these fields to create a user data code that forecast views use to develop item forecast data.
A user-adjusted forecast is a set of data where the system stores a different data value for each period defined in the forecast view. This is also called a data series or time-phased data. These 10 user-adjusted forecasts sets enable an organization to perform collaborative adjustments by assigning users to a specific user-adjusted forecast with which to work. This maintains the adjusted forecast for internal use only, while enabling other planners or partners to make adjustments to the user-adjusted forecasts that can be reviewed before updating the system-adjusted forecast data. The system stores data for both historical and future periods in user-adjusted forecast datasets and because they are time-phased, the data related to a particular period in time remains associated with that period.
For example, you can create two user-adjusted forecasts and assign them to two different customers for review. The customers can provide their intended changes to the forecast, upon which the corporate planner can review the changes and incorporate them into the system-adjusted forecast. This enables the organization to review the changes separately, maintain customer confidential data, and collaborate with partners on the forecast.
Using forecast reconciliation, you can reconcile user-defined forecast for items in a view at a specific level.
Views are multilevel pyramid structures that enable summarization of the underlying historical and future data. Levels make it possible to use forecast data that is aggregated to different summary levels for business needs. For example, you can roll up quantities from one level to another.
Views enable detailed sales history to be summarized into several levels of aggregation. So, suppose the base data is composed of the details of sales of items at each location. You can summarize the data into sales of the item across all locations, and then further summarize the data by brand or channel.
Using working and dynamic views, you can interact with the data by making adjustments to historical and forecast data at each level in those views. An evaluation of working and dynamic view requirements helps determine what master record data needs to be set up for each item.
At some level of the view, the forecast item normally represents a stock-keeping item. At other levels of the view, the forecast item may represent a summarization of product groups, customer groups, color, product type, and so on. These fields can be imported directly from the PeopleSoft Order Management, Inventory, and Billing applications.
In addition to the fields, you can maintain unit of measure (UOM) conversion factors and set up additional factors to roll up the data from one level in the view to the next. If you provide standard cost and price data, forecasts can be viewed in monetary terms, as well as in units.
A considerable amount of data is processed during the forecast and adjustment processes; therefore, to contain the complexity of managing the activities, the number of views and the size of the views should be kept to a minimum.
Although any number of working views can be constructed with any number of levels from the same set of historical sales data, for practical purposes, it is best to try to use only one working view. Also, two to five levels within a working view seem to be the most manageable. At the time that the view is set up, you must decide how much history to keep (generally, at least two years of data) and how far out to project the forecast.
In general, historical patterns become unreliable if projected out more than 24 months. The system enables you to measure the forecast error to be calculated relative to the time at which the forecast was made. This time offset is known as an evaluation period. If operational decisions are typically made three months in advance (evaluation periods equal three), the best forecast is the one that gives the least forecast error three months after the system generated the original forecast. In essence, the forecast can become frozen within the evaluation periods so that the accuracy of that forecast can be measured. The adjusted forecast can continue to be modified within the evaluation periods, but evaluated forecasts cannot be modified.
To provide sufficient data for the development of a statistical forecast, you might need to link newer items to the sales history of other similar items. Also, some of the history of phased-out or superseded items may need to be merged or converted to history for newer or replacement items.
A control group determines the major forecast process options, such as which forecast models to use, how to process outlier deviations, and what accuracy statistic to use for evaluating forecasts. This section discusses control groups and how you use group components in forecasting.
The system creates a forecast for each item in a forecast view, based on the parameters that are defined in the control group. A control group is associated with the template item for each level of the view, and there can be a different control group at each level. Forecast items inherit the control group from the template item when the forecast item is created. Control groups label specific sets of items that are to be processed the same way. For example, you can separate older and more stable items from newer items. Or, you can separate higher-volume or higher-value items for processing. The system uses Work Queue alerts to identify exception situations that occur during processing.
Control groups contain the parameters that determine how many of the previous processes the system performs and what action it takes when it encounters specific exception situations.
The control group makes a determination whether to filter demand data during forecast calculations and period-end processing. Filtering adjusts exceptionally high or low historical sales demand to the highest or lowest point within a specified band. The outliers standard deviation sets the upper and lower limit of this band. It identifies filtered demand with a Work Queue alert and aligns the original sales history value with an adjusted demand value. The new value is set to the boundary of the acceptable values.
To return to the underlying market trend, the system can automatically remove the effect of any past promotions, thus depromoting or resetting the history where prior adjustments to demand have been identified as promotional adjustments. The forecast item may be suspended if the actual sales are zero for a predefined number of periods.
The system generates a statistical forecast based on the adjusted demand and can determine the best-fit forecast from 14 different models. You can either select a model or have the system test the models and determine the best fit. Model examples include Holt-Winters, linear regression, and Box Jenkins.
When a seasonal model is being evaluated, the system applies year weights, enabling you to make the calculation more sensitive to later years.
If you use the moving average model, the system sets up several values for the number of periods (weeks, months, or user-defined periods) over which to calculate the average. The objective is to try different time spans to achieve the best result (for example, three, five, and six periods). Each time span is tested, and the system selects the best model.
In building a forecast, the system might also apply some adjustment to the long-term trend. An excessive long-term trend, either upward or downward, could be reduced or eliminated by using trend-elimination periods.
In generating a statistical forecast, the system makes adjustments to the model parameters to create a more reasonable forecast. These are minor adjustments to eliminate dramatic changes in the forecast from period and to period.
For example, you can determine the high or low growth percentages that are acceptable. If forecast values are outside of either the minimum or maximum percentages, the system automatically sends an alert to the Work Queue. The system also defines when a forecast violates a reasonability test. Use the control group to set reasonability limits.
Seasonality Adjustments and Profiles
When an item is new or the item history is erratic, you might not be able to adjust the data adequately and therefore might not be able to provide a good basis for statistical analysis. In these situations, try to apply the seasonality index from another product, or even an average seasonality index derived from a number of products. Applying group seasonality is useful in overcoming these historical data problems.
Some items follow predetermined cycles throughout their lives. This cycle is a set of characteristics that the system applies to a forecast item. It includes three basic parts: introduction, full life, and retirement. The profile provides a basis for forecasting for the item. For example, you can base future statistical item forecasts on the new item's total expected life volume.
Create profiles manually or derive them from actual results of other similar products, and then apply the total volume to determine a forecast for the life of the product. You can add products to a life profile that may have a statistical forecast that the system calculated by using another forecasting method. Full-life profiles assume a zero forecast before the profile begins and after the profile ends.
Demand History and Forecast Adjustments
The fundamental assumption of statistical time-series-based forecasting is that historical trends and patterns repeat over time. An objective of forecasting is to uncover that underlying market pattern by cleaning up the history. Essentially, you try to change the history to make it more representative of what is expected in the future. This involves two types of adjustments: correcting and adjusting the history.
Historical data might contain mistakes, errors, or anomalies that are misleading and are not indicative of a true selling or shipping pattern for an item. When errors are made through data entry or other means, you can correct history by changing both the actual and adjusted demand for that period of history. If there were shipments made as replacements for defective products, you may want to adjust the demand history down to remove the effect of the dual shipments. These are manual adjustments that you might make to history.
Other adjustments that you might make could be to remove automatic data filtering that occurred to abnormally high or low sales. If the sales are truly indicative of what is expected to happen in the future, such as adding or losing a customer, then remove the filtering adjustment so that the process can take that demand into account when generating a new forecast.
Other types of historical adjustments might be performed automatically by the system. These could include depromotion of demand due to a forecast adjustment that had been identified as a proration. As the period for that forecast adjustment rolls into history, the demand can be depromoted to remove that artificially inflated demand with the prorated forecast for that period.
The adjustment is either to correct history (no adjustment) or to adjust history (direct adjustment or depromotion). Corrections to history replace the original value, while adjustments to history are stored separately from the original history. You can also store a comment regarding the correction or adjustment for later review.
The quality of a forecast is determined over time by the extent to which the new actual sales match, or track to the forecast. The more dispersion of the actual sales from the forecast sales, the greater the forecast error and the less useful the forecast. Because the statistical forecast only represents a projection based on past results, known future events result in actual sales being different from the forecast.
You can make adjustments to the forecast in order to account for these known and anticipated changes in sales levels. Forecast adjustments include specific discrete events, such as a contract order, a planned new warehouse opening, or a planned change in safety stock. Other adjustments represent events planned by the organization, such as specific promotions. These changes could be positive (increase in sales due to the promotion) or negative (sales taken away or cannibalized by promoted items or sales moved in time due to promotions).
Other adjustments can be attributed to external factors, such as competitive actions, environmental factors, or economic trends. Sometimes it might be a person making a judgment based on experience. Make changes to forecast data by importing change transactions from an external system, or by entering the data directly into the Adjustment Workbench.
In making an adjustment, you select whether the resulting adjusted forecast might subsequently change through proration. This is when an adjustment made at a higher level in the view is passed down the levels on a prorate basis and may or may not influence an adjustment at a lower level. You might decide that an adjusted forecast should not be adjusted through proration because the new values are firm—maybe an agreement with a customer—or aren’t influenced by the higher-level adjustments.
A product group not subject to competitor activities, for example, might be left as is. An adjustment made for a promotion (whether or not it allows proration) should be identified as a promotion so that it can be depromoted as it moves into the history. This autodepromotion is a PeopleSoft Demand Planning control group setting.
In a collaborative forecasting environment, some departments may prefer to interact with the forecast using quantity units of measure, while others may prefer to use monetary values. PeopleSoft Demand Planning enables you to make forecast adjustments in units of measure other than the forecast item’s base UOM, as well as the standard price, standard cost, weight, and volume.
An alternative way to make adjustments is through a dynamic view. This process creates a two-level view based on a selected level of an existing working view. You can construct a new summarization of the selected level, but using a different grouping than the original view. Adjustments are then made using the new grouping level and reintroduced into the source view at the selected level.
For example, a dynamic view could be built that shows items by pack size, a summarization that wasn’t used in the original view. Now, all the items within a pack size can be adjusted in the dynamic view and the adjustments carried back to the working view. Following the transfer of the adjustments, the dynamic view can be deleted.
You can make adjustments to demand history or forecast directly in a number of ways:
Replace.
Replaces the old value with a new value.
Add.
Adds the adjustment to the existing value.
Subtract.
Reduces the old value by the adjustment.
Factor.
Multiplies the old value by the factor.
An evaluated forecast is one that is calculated for a previous period that is determined by a set number of previous periods. The number of evaluation periods is defined for the view. If, for example, the number of evaluation periods is set to three, the evaluated forecast for June would be the forecast (statistical, prorated, and adjusted) that was produced in March. The evaluated forecast for May would be the forecast that was produced in February. Using the control group, you can indicate to reset or overwrite historical forecast time-phased data when you perform a simulation or calculate the forecast. Historical data includes statistical, adjusted, and prorated data.
The evaluated forecast is sometimes referred to as a frozen forecast. Because the statistical forecast can change from month to month for a given future period, the evaluate statistical forecast can be used to track what the forecast was predicted to be last month.
While the adjusted forecast enables changes in the current forecast period so that production can change their near-term production plans to reflect a sudden increase or decrease in the forecast, use the evaluated adjusted forecast to track what the adjusted forecast was when materials might have been purchased to support the projected production relative to that forecast.
The quality of a forecast is determined over time by the extent to which the new actual sales match, or track to, the forecast. The more dispersion of the actual sales from the forecast sales, the greater the forecast error and the less useful the forecast. Because the statistical forecast represents only a projection based on past results, known future events result in actual sales being different from the forecast. Again, using the control group, you can define when to reset evaluated forecasts.
A fundamental feature in PeopleSoft Demand Planning is summarization. When you summarize a forecast, the system aggregates data and updates it from a lower level in the forecast view hierarchy to higher levels. The starting level and the higher levels are updated based on the number of levels that you select to process.
You use views to develop forecasts at different levels of aggregation of the historical data. For example, if you use level one to develop a forecast for all items, it provides a forecast of all items for each location.
The next level, level two, then could be used to combine the locations to provide a forecast at the item level. This is accomplished by aggregating the history to the item level and then generating a forecast at that level. The forecast would be based on the summarized adjusted history at level two, but would already include any summarized adjustments from level one.
Use further levels for additional summarization. For example, level three might combine all the packaging sizes, such as small, medium, and large pack, to give a historical demand at the content level: kilogram, liter, and so on. The system can then generate a forecast at the formula level. Further levels could be used for brand and channel.
Here's an example of summarizing data. Suppose that products 1, 2, and 3 are all part of Brand X and are sold out of locations A, B, and C. The demand for each product is summarized across the location and then summarized by brand. The total demand for Brand X during this period is 425, as illustrated in this table:
Brand X Products and Locations |
Product 1 |
Product 2 |
Product 3 |
Location A |
50 |
75 |
30 |
Location B |
40 |
50 |
40 |
Location C |
35 |
75 |
30 |
Product totals |
125 |
200 |
100 |
Brand X total |
425 |
Not applicable (NA) |
NA |
The actual groupings in the situation depend on how you define the view.
You use the Period End Forecast process (DP_CALCFC) to calculate a forecast. This is the business process that you perform at the end of a sales cycle. These cycles are recurring business events that are normally driven by the date on which new demand is brought into the forecasting system. Because forecasts are driven by demand, the new data represents a new cycle of forecasting, regardless of the cycle's length. PeopleSoft Demand Planning helps you control forecast parameters, establish forecast cycles, and process forecasts through the cycles.
This diagram illustrates how the summarization and proration processes are intertwined to produce a more accurate forecast:
Period-end processing using summarization and proration
Forecast calculations take place at step three. But, as part of the forecasting flow, you perform steps one through five. Step five is similar to step two because it arrives at a final summarized forecast. Steps six through 10 are optional tuning steps that you perform after the completion of the required steps one through five.
After the forecast has been developed at each level of the view, you can adjust the forecast to better reflect known future events and trends. To view the effect of these higher-level adjustments at the lower levels, the system passes the adjusted and prorated forecast back to the lower levels through a desegregation process that allocates the adjustments in the same ratio as the underlying data. This process is called proration. Proration takes the prorated and adjusted forecasts at higher levels and allocates them to lower levels on a prorated basis.
Sometimes the item forecasts at a lower level have been developed in conjunction with known business partners. In such cases, it might be inappropriate to allocate higher-level adjustments. You can define these items as not proratable, in which case the adjustments would be allocated only to the remaining items.
Where a lower-level item is not proratable, it deducts its prorated quantity from the total to determine the quantity that must be spread over the balance of the items. You can sometimes allocate more than the amount you want to other items at the lowest level of the view, so it should be determined which methodology works best for you. Use either nonproratable adjustments at the lowest levels and not prorate down to the lowest levels, or after proration is complete, reapply a business partner's forecast adjustments back onto the prorated forecast.
Forecasting events are distinct activities in the planning horizon that relate to promotions. Events help you to manage multiple promotions across consecutive time periods. To better understand the benefits of using the Forecast Event Management feature, you must be familiar with promotions.
A promotion focuses on the marketing of a product through activities such as sales, increased advertising, or publicity. Promotions vary in practice. An organization might have a three-day sale or a month-long sale, a two-for-one campaign, or increased radio advertising. In forecasting, a promotion is an adjustment to a forecast in anticipation that a deviation in the forecast will occur.
The Forecast Event Management feature is useful for organizations that must make a large number of adjustments to planned future events through automation. The system calculates weight estimates by defining the impact of the event and applying it to specific items for specific time periods.
After you define an event, you can remove the effects of the event from the demand to make a judgment on the underlying demand trend. With data on the underlying trend, you might want to spread a promotion over several periods to smooth demand, or, for example, pull back some demand into a prior period to help solve a supply problem.
With enough historical data and a definition of an event, you can predict the event's impact on future demand more accurately.
A dynamic view is a unique, two-level view that is created on a one-off basis from the data contained in a permanent view, also called a working view. You can use a dynamic view to examine or interact with the forecast data in an aggregate form not supported by the working view. For example, use the view to make forecast adjustments by using an attribute not defined as a key field in the working view.
When the system populates a dynamic view, it builds forecast items and related data from the view definition that you created for the view. The source data for the view is the forecast item data at the specified level of the source view. In addition, other information, such as UOM conversions, control groups, and seasonality profiles, are copied for the new view.
A disbursement view is a unique view with two or more levels. This view is also created on a one-off basis from the data contained in a working view. Intended mainly as read-only views, you can make adjustments to disbursement views but you cannot release those changes back to the working view. Disbursement views allow aggregation of the forecast data in a form not supported by the working view. For example, use the disbursement view to review forecasts at a different aggregation by using an attribute not defined as a key field in the working view.
When the system populates a disbursement view, it builds forecast items and related data from the view definition that you created for the view. The source data for this view is the forecast item data at the specified level of the working view from which this view is to be populated. In addition, other information, such as UOM conversions, control groups, and seasonality profiles, are copied from the working view.
Forecast reconciliation is the collaboration of user-adjusted forecasts to arrive at an integrated set of forecast values. PeopleSoft Demand Planning uses a series of features that enable you to use multiple forecasts in the creation of a reconciled forecast that is more realistic and accurate for an organization.
Planners, suppliers, and customers can reconcile forecast on key differences and make adjustments to arrive at a forecast. This reconciled forecast then becomes the forecast most suitable for use by PeopleSoft Inventory Policy Planning and Supply Planning.
Cross-view reconciliation involves synchronizing or balancing forecast data between selected levels of related views with the same forecast item key. View balancing brings the levels within a view back into balance, making the forecast consistent after you make adjustments and calculations. Using cross-view reconciliation, you can reconcile several different (but related) views.
The balancing steps depend on the levels of the view and the scale of the changes made since the last time the view was balanced.
To balance a view:
Assess the effect of the adjustments.
The processing depends on the relative size of the change and the level at which it is applied.
Forecast adjustments made at a level lower than the highest prorate from level must be reviewed to see if the change affects relativity only. In other words, they have negligible effect at the next level up. If this is so, you can bypass this step. If not, the net effect of the change must be applied at the group level and then reviewed again at that level. This process stops when the net change is insignificant at the next level up.
Many small changes that impact the same group can have their net effect reduced by using summarization. You would normally perform this check when you make a forecast adjustment. You can make the manual adjustments implied by the previous discussion, or use the system roll-up option (summarization) to automatically roll net effects of forecast adjustments to higher levels of the view.
Prorate from top to bottom of the view.
Prorate from the highest prorate level down to level one of the view. The Proration process transfers the prorated and adjusted forecasts, and the effects of the adjustments down the view.
Refresh the summary forecast in the view.
Summarize from the lowest to the highest level of the view. Set the options to create the summary forecast only.
(Optional) Roll up the adjusted forecast.
Summarize from the lowest summarization level to the highest level in the view. Set the options to summarize to the adjusted forecast. You can, optionally, summarize the statistical and prorated forecasts and the forecast adjustments and reasons. This is necessary only in views with summary-only levels. Normally, you do not have to roll up the adjusted forecast when you set the view to automatically roll up forecast adjustments for you.
This section discusses:
Prerequisites.
The development of a forecast.
Cycle start-up tasks.
Forecasting steps.
Forecast generation.
Before developing forecasting data:
Analyze the organization.
If there are several different divisions involved, you should analyze each separately. Review and understand the product structure and the marketing, sales, and distribution organizations, and develop a consistent structure. To develop the structure:
Develop a common structure or view for all products.
Confirm the common structure against all individuals.
Analyze the product structure for each product.
Document native or base units, alternate units, and conversions at each level of the structure. The following examples may assist you in reaching a consistent structure.
In the first structure, company X manufactures and distributes a range of toiletries. The products are classified into hair care, skin care, and dental care product lines with family brands within each product line. Several of the brands have subbrands embedded within them. For example, a hair spray and shampoo product may have the same brand name. Most products are available in different variants, and each variant in different sizes.
In this structure, all products are sold in cases. Product forecasts are presented in pounds, tons, cubic feet, dollars of cost, dollars of price, pallets, and the organization's standard cases when products are aggregated higher than the size level. Document the marketing, sales, and distribution functions, paying attention to the physical and reporting structure of each. If there are several divisions or subgroups, analyze each separately.
Another example of structure might be if products are manufactured at two plants and distributed through a northern and southern distribution center. Products are made at only one plant, and a preferred distribution center is associated with each customer.
Sales are also organized into northern and southern regions with one vice president in charge of marketing and regional managers in charge of each region. Product managers handle a basket of products within each region. Customers are classified by trade channel and pricing, and promotions are set by channel.
Analyze forecast requirements for individuals in the organization.
The objective in this step is to understand the reporting requirements of the working view. A good place to start is to understand how individuals prepare and receive their base forecast and how they develop their forecast reporting requirements. Document data relationships and reporting time periods such as days, weeks, and months.
For example, marketing may require summary forecasts by product line and brand by month in standard units, and value units based on standard price, cost, and margin. Sales may require monthly standard unit and value forecasts by region, product line, channel, product, variant, and size for the next year with a comparison to history for the corresponding period in the previous year. Manufacturing may need weekly aggregate source plant unit forecasts by product and size for the next six months.
Document the forecast preparation cycle— for example, weekly, monthly, or semiannually—and the anticipated needs to interact with the forecast. Distinguish between frequent or occasional needs. Determine the finest breakdown of historical demand that supports all of the forecast reporting requirements.
Review and understand existing classifications.
You must understand the existing data model of the organization and pick the item, customer, and stock-keeping classifications that are applicable in PeopleSoft Demand Planning. Determine how historical demand is analyzed to furnish the finest breakdown required to support forecast reporting requirements.
For example, items determine the product line, brand, source plant, and product type; whereas, channel and customer types are determined by the customer.
Outline the working views.
Analyze the different requirements and develop a first-cut working view and data requirements.
Working views must support forecast preparation and contain sufficient detail to populate and drive the views. Here are some guidelines to keep in mind while developing the working views:
Keep the views as streamlined as possible.
Have separate levels for aggregates with which you interact on a regular basis.
Do not have a level for an infrequently used aggregate; this can be accommodated through the dynamic view process. View-only levels should be kept out of working views.
Minimize the number of levels.
Try not to have more than four levels in a working view. View balancing becomes more difficult as the number of levels increases.
Calculate the average number of forecast items at each level of each view.
Calculate the average parent and child ratios at each level. Make sure that the view is not too flat. For example, ratios that are less than 1:100 may be too flat.
Make sure that the relationships between parents and children are logical.
Proration must make business sense.
Avoid using value units as an aggregate UOM in working views.
This might include using, for example, pesos. If the value unit is the only logical unit for the aggregate, it may be that the relationship between a parent and its children is not logical.
Try to minimize the number of different working views.
The more working views there are, the more effort it takes to reconcile them.
Make sure that the disbursement views satisfy the reporting requirements of all users.
Walk through the forecast development process, including working view reconciliation, and make adjustments if necessary.
Summarize the user-data requirements necessary to support all views and classifications. Be specific about field names and lengths. Determine the valid-to level for each data element at each level of each view and document the validation rules associated with each data element.
Finalize and maintain user data and forecast views.
Determine how many different user data codes you need to support all views. You create these codes by using the User Data Code feature. You should have no more than one user data definition for each separate business. Define only those fields for which there is a known need. You can add additional fields as needed.
For example, a working view requires Brand and Channel fields. The disbursement views requires the Brand, Region, and Channel fields. Now, you should select or change the appropriate user data codes.
The development of a forecast involves numerous tasks that often overlap from one process to another. The forecast process, as supported by PeopleSoft Demand Planning, involves a number of stages, each of which requires supporting data and design choices. The major stages are:
The processing and adjustment of historical data.
The application of time-series techniques to develop a statistical forecast.
PeopleSoft Demand Planning does this automatically for you by using a management by exception concept to produce alerts about conditions that warrant attention when developing the statistical forecast.
The review of the proposed forecast and the application of management judgment.
The progression and review of the forecast over time as new actual data becomes available.
A setup process in which you:
Design the forecast view configuration using user-defined fields.
Define the forecast calendars.
Design how the data is summarized in the view.
Set up control groups.
Create group seasonality.
Before you generate a forecast, you must perform several set up tasks to prepare forecast views for use and processing. You perform the tasks for each view that you use to generate a forecast. These tasks control a number of parameters of the forecast, and once you complete them, you can reuse them each time that you use the view. You can also change the setup data as needed.
These procedures are performed once per view.
To perform start-up processing:
Set up users.
Anyone who wants to use PeopleSoft Demand Planning must be set up as a user. System administrators normally set up users.
Define at least one calendar.
Calendars provide control parameters for each day of the year. They are defined for an overall time frame that may extend across several years. PeopleSoft Demand Planning requires at least one calendar. You must create at least one period that represents the time period of days that represents the frequency of the forecast cycle. This is typically set to months, but some planners might prefer weeks.
Define and maintain user data.
In setting up user-defined fields, you should include all information that is required to support the views and to calculate and report about the forecast. This usually includes product, customer, sales organization, and distribution center attributes. Typical sources for this information include current forecast reports, as well as the item database fields.
Design the view.
A key factor in developing good forecasts is to define a structure that represents how the organization does business. You must have a thorough understanding of the products (how they are made, distributed, and delivered), the customers, and the reporting requirements within the organization.
Each view in the system can have its own set of user data identified by a user data code. There are 50 user data fields (UD01– UD50) available for each user data code.
This is a good time to decide on a consistent format for the caption and description fields associated with the item at each level of the forecast. The caption appears with the key on most panels. The caption field contains a maximum of 40 characters, and the description field is a maximum of 100 characters.
Maintain the working view.
A working view is a view used by the organization for forecasting, as opposed to a dynamic view that is not permanent in nature. In this step, you must enter the data for each working view, including the ID (maximum 20 characters) and description (maximum 30 characters). You also identify the owner of the view and associate it with a user data code and a calendar.
Maintain UOMs.
UOMs describe the recording measurement used for the forecast items. Examples are box, case, and pallet.
You must set up the conversion factors needed to roll up UOM conversions from level to level.
Maintain template items.
A template item is a model or pattern record that supplies default field values to the item add process. When items are created by demand posting or summation, the system starts with the template for that level and adds the appropriate maintenance to it.
When new items are created by using item maintenance, the system displays a new record with all fields set up from the template and lets you make changes before saving the item. You can create multiple templates at each level; however, only one of these can be designated as the default template at any one time.
The item template supplies default data that has not been overridden. A forecast item can be entered only at the lowest level in the view. Forecast items for higher levels are created automatically from the data at level one.
Maintain control groups.
A control group is assigned to one or more forecast items and controls the forecast development and tracking for each of the forecast items in the group. For example, a starting point for establishing control groups may be the ABC classification assigned to the item.
Associate users with views.
Now you must associate at least one user with the newly created view. Only users who have security access to PeopleSoft Demand Planning are eligible.
To put together the components of the forecasting system:
Define calendars.
Set up a calendar pattern code that represents demand spread across a typical week, overall start and end dates, period codes, and weight profiles. The system uses the profile as a default profile to spread demand from one period code to another, or to spread the demand down to a daily level within the current period.
Define forecast components, including user data codes and the forecast view hierarchy.
Define security for the forecast view.
Define the control groups.
You can maintain the group that is the default group for the view or create additional control groups.
(Optional) Define UOMs for the view.
(Optional) Set up adjustment reasons.
Maintain user preferences.
Select the default value for the grid format, display templates, the number of periods to be displayed in reviews and the Adjustment Workbench, and the default fields for charting.
Import forecast data by either internal demand history or external data.
Process the forecast, including summarizing, running period-end processing, and prorating for the view.
Review Work Queue Workbench, which provides you details about forecast item exceptions.
Review forecast information.
Use the Review Forecast Item feature by selecting a forecast view and the item for review.
Fine-tune forecast items by:
Applying simulation.
Using the Adjustment Workbench.
Making mass changes for items and then running the midperiod forecast calculation.
Reconciling the forecast.
Commit the forecast.
Define a publish specification to report data from the forecast view to internal systems, such as PeopleSoft SCM, or external systems, such as a flat file to publish to an external system, such as Microsoft Excel.
Forecast generation involves a number of processes that begin when you define start-up information for generating forecasts. You perform the start-up tasks to define forecast parameters for use in generation.
You can generate forecasts in a forecast cycle with:
Midperiod forecast, when you must recalculate forecast to reflect changes in items or forecast models.
Period-end forecast, when the cycle is complete and you are ready to start on the next forecast cycle.
During period-end processing, the forecast start date is moved forward and the demand is processed.
These steps describe the basic forecast generation steps that you use with period-end processing:
Post the new demand and forecast data that begins the forecasting cycle.
You import demand data directly from PeopleSoft Order Management, Inventory, and Billing.
You can also import PeopleSoft Demand Planning data from external systems. This data can consist of new demand, demand adjustments, forecast adjustments, user period data, or forecast item information.
Only demand that has not been processed should be included. Typically, the demand is from the period just closed, which is the current period in PeopleSoft Demand Planning. But demand can also affect previous periods; for example, returns or demand that missed the previous period close. You need at least two years of history for seasonal products in order to develop an accurate seasonality profile.
Each piece of demand must include the view ID, level-one key information, and the posting period. New product information and product changes can also be included in the interface. There are predefined file layouts for importing external data into the PeopleSoft Demand Planning system.
Each transaction is validated and either rejected with errors or included during processing. You can review errors and make corrections as needed, and then reload the corrected transactions.
Summarize the actual demand.
Now information is at the lowest level of the view. Summarization rolls up actual demand in the view structure from the lowest to the highest level for periods that you select. The adjusted demand is the same as the actual demand, if there are no adjustments to demand. You might not want to summarize adjusted demand because it may contain filtering adjustments that are not relevant at higher levels and may not provide the results that you want from the forecast.
A summary forecast is created when you summarize at the completion of the forecast cycle. The summary forecast for an item in a period is equal to the sum of the adjusted forecasts in that same period over all of the item's children (directly related items at the next level down). Therefore, a summary forecast is created for each forecast item at each level, except level one.
If you are performing period-end processing, the demand data is normally for the current first forecast period. This period becomes the latest historical period after period-end processing completes.
To summarize demand:
Create a summarization specification.
The specification provides more control over summarization parameters, such as which levels or periods to summarize. Use the specification to run the Summarization process (DP_SUMMCALC). Ensure that you select the Create Missing Groups check box and select Actual Demand as one of the roll up options. Select the Delete Groups with Details check box to remove parent forecast items where the child items related to that parent may have been removed or deleted from the system. This keeps the view from having items that are no longer relevant.
Run the summarization.
When the system summarizes demand, it summarizes demand information up through all levels of the forecast view pyramid. This is done so that a forecast can be calculated independently for each forecast item at each level of the view based on the aggregate demand.
Review the Work Queue for added items.
Check for warnings generated during the roll up. These normally relate to new items added at upper levels of the view, but can also relate to deleted groups and period demand changes that have exceeded the threshold. Other alerts to look for would be for demand filtering messages that may need to be removed if the demand represents new customer demand, or demand for inhibited items that may need to have inhibiting removed.
Verify that actual demand is summarized correctly.
Ensure that the next-level conversion factors are correct, and that description, caption, UOM, UOM conversion factors, standard price and cost, and so on are set up correctly. Ensure that the forecast effective date, model, and model components are set correctly for future-dated items. These are groups that will not generate a forecast until a future date.
Correct the errors and, if necessary, rerun summarization.
Create a forecast by using the period-end forecast processing.
When calculating a forecast, the system makes demand adjustments for promotions, filters for abnormal demand, and generates a statistical forecast for each item at each level of the view. The system generates the forecast at each level so that you can compare aggregate and statistical forecasts. Midperiod processing is an optional technique for updating all forecast items in a forecast view. Use period-end processing to complete a cycle. In this case, the system advances the forecast start period by one.
The view determines the number of future forecast periods that the system calculates—typically two years. You can create a forecast as many times as you need during a period; however, only those items that have their calculation type set to a specific value are affected by midperiod forecast calculations. You can forecast individual items again and at any time by using item simulation.
Items that are associated with an active life profile follow the same process for the depromotion of events and filtering of demand. The system recalculates the item's expected life-to-date and demand-to-date values.
After generating the forecast:
Review poorly forecasted items by using the Analyze Forecast feature.
This feature lists all forecast items for a selected level of the view in descending sequence, based on the error ratio. You should consider the demand average and error ratios together. The error ratio is a relative error. Items with a high forecast deviation are not necessarily a problem, provided that the demand average is much higher. The error ratio provides an analysis technique so that items with high deviation and low demand are ranked accordingly to items with low deviation and high demand.
After reviewing items by the error ratio, you can also analyze the items by sorting them by demand average. Improvements in forecast accuracy on high-volume items can provide significant benefit for the organization. Also, you may want to analyze the items by sorting them by standard cost. Forecast improvements on these items can significantly impact the bottom line.
Among the factors that can cause poor results are insufficient history, unfiltered events in the demand, or promotions. You may need to make adjustments to the demand, add control groups, or add seasonality groups.
For example, suppose that you do not have enough history (fewer than two years) for an item that is obviously a seasonal item. In this case, you can associate it with a seasonality group that has been set up for the product group to which the item belongs. Another example is a new product launch that caused extremely high demand in the earliest demand period. You could eliminate the launch data by shortening the effective periods or by manually adjusting the demand.
Review Work Queue alerts created during the forecast generation.
Concentrate on biased, unreasonable forecasts and on model changes. Make adjustments as necessary and use simulation routines to correct problems.
Tune the forecast.
The statistical forecast calculated by the system is the starting point for management review and input. It is management's responsibility to apply overrides that reflect promotions not already adjusted for, new product introductions, competitive product activity, and other market activity.
This step may also include investigating and correcting notifiable events, such as resetting the model, and out-of-threshold warnings, such as filtering outliers, that have been logged to the Work Queue during the processing. Management makes adjustments more often at higher levels in the view because it has a more general picture of what adjustments might be required.
Prorate the forecast.
The Proration process (DP_PROCALC) allocates the item (group) forecasts for each future period. It makes the allocation by period to the forecasts of the related items (children) at the next lower level. The allocation is on a prorated basis and is based on the future forecasts of the children. The effect is to make the aggregate forecast of children equal to the group forecast. The prorated forecast tends to be more accurate than the statistical forecast.
The Proration process factors the group forecast down one level at a time to make the sum of the item forecast as equal as possible to the aggregate forecast.
To prorate a forecast:
Create a proration specification.
Verify that the proration specification is set to include the processing parameters that you want. Prorate the view from the highest proration level to level one. The highest proration level is normally the highest level in the view, but this may not be so if there are summary levels (one or more) at the top of the view.
Prorate the forecast.
Balance the view.
Balancing ensures that individual forecasts are consistent with (equal to) higher level forecasts. At this point, it is also necessary to balance the view. To do this, you must run the Summarization process again from the bottom (level one) to the top of the view.
Review the Work Queue for proration alerts.
These relate to things like abnormal proration ratios, missing children, and so on. Proration errors are usually serious and must be reviewed carefully. Make adjustments as necessary and run the Simulation process to correct the problem.
Make adjustments and rebalance the view.
Apply management forecast adjustments to reflect market influences that are not reflected in the forecast. This can easily include adding items that are to be introduced at some time in the future. Make sure that the forecast effective date, model, and model components are set correctly for these items. You must prorate and summarize the forecast again to bring all the numbers back into balance.
Rerun the Proration process after making adjustments.
Run the Summarization process a last time from the bottom to top of the view:
Select the necessary roll up options, including creating a summary forecast, on the summarize specification Rollup Options page.
Check the Work Queue for alerts generated during the process run.
There should not be any warnings.
PeopleSoft Demand Planning provides several different methods of reviewing the results of the forecasting process. This section discusses:
Forecast accuracy and evaluation.
Forecast reviews.
An objective in reviewing forecast information is determining which forecast best fits an organization's needs. PeopleSoft Demand Planning calculates a number of performance measures to help you identify unusual or changed conditions that require review. The control group parameters identify what action, if any, to take following the most recent comparison of the forecast to the latest actual sales data.
Accuracy measures determine how well a forecast model is predicting the forecast. Each accuracy measurement is based on different statistical criteria. Understanding how and why the system applies an accuracy measurement helps you to determine which forecast model best meets the business needs. Depending on forecasting requirements, these measurements provide you with a meaningful measure of model accuracy.
The forecast models, accuracy measures, and statistical parameters that you use in forecasting are provided through ForecastX. This forecasting tool makes it possible to perform complex forecasting and statistical calculations using PeopleSoft Demand Planning. You can perform statistical analysis on any single or multiple sets of data series. You can also perform statistical analysis on a series of observations or process a set of series in a batch process or batch mode.
Use the Analyze Forecast feature to assess individual forecast item accuracy and the overall forecast accuracy rate of change. Use this feature to check for error ratios that might not be within the standards or requirements. The inquiry displays items ranked by their error ratio that meet selection criteria that you enter. Using the feature, you can single out items that you can fine-tune or adjust.
PeopleSoft Demand Planning calculates a number of statistics and uses these in conjunction with control group parameters to determine what action to recommend. In addition to Work Queue alerts, the forecast analysis review helps to focus the analyst towards the exception situations. This inquiry shows the error ratio for each forecast. These ratios are ranked highest to lowest (worst forecasts at the top). Use them as a checklist to identify the items requiring the most attention.
To aid you in evaluating and working with forecasts, PeopleSoft Demand Planning gives you a snapshot of forecast items at any level in the view through the Review Forecast Information feature. You can use forecast inquiries to display historical demand and historical and future forecasts in both numerical and graphical formats. The feature is an effective tool to use in resolving problems with the forecast.
While you can use inquiries by themselves, you typically use them in conjunction with other tools, to tune the forecast. For example, the analyze forecast review highlights forecast items with large error ratios. A work queue message alerts you to issues or problems, such as demand filtering, growth limits, or tracking signals.
An inquiry display template is a grouping of forecast fields that the system uses to retrieve data for the forecast item inquiry. Among the type of reviews available that you can perform are:
Analyze Forecast.
Forecast Items.
A detailed inquiry that includes period-by-period demand and forecast information. The inquiry also includes adjustment details for items, quantity changes, and their reasons, forecast item fiscal year data, and charts to review forecast item values.
Adjustment History.
Provides a snapshot of forecast and demand adjustments at any level in the view.
Event Comparison.
Uses two different of sets of data and their associated events to review the differences in the effect of an event on another set of data. In addition, the system interactively graphs the comparison as you select different sets of data.
Event Profitability.
Review nonpromoted-basis criteria for profitability calculations.
Life Profiles.
Review life periods, life-to-date information, and forecast information about life profiles.
Function Audits.
Indicates whether functions completed successfully.
This section discusses:
Forecast simulation.
Forecast tuning.
Collaboration.
Forecast item simulation uses forecasts in a controlled and interactive environment to perform a what-if analysis. Using simulation, you compare forecasts that the system develops for a selected forecast item. You can use one or a combination of different models, forecast effective periods, control groups, and item or group seasonality as part of the simulation. You can also calculate or recalculate the forecast by using any combination of model or model components.
Tuning a forecast is when you review results of the summarization and make adjustments to the forecast before actually running a period-end or midperiod forecast. The objective of tuning is to ensure that the best possible forecast models are defined for all items after you complete the start-up tasks and prior to publishing the forecast. During tuning, you can determine if the system selected the best model for the forecast item.
For example, a seasonal product with fewer than two years of history is not allowed to use a seasonal model. You can correct this problem by relating it to a seasonality group. You should make sure that the retrospective forecast was accurate and that extreme demand is being filtered. Check that the forecast looks reasonable.
Tuning is difficult to quantify because it involves many techniques and differs each time. Use the Analyze Forecast feature to detect high relative errors. When you tune forecast, use the Proration process to detect mismatches between the levels, and use Work Queue alerts to detect bias in forecasts.
You can use PeopleSoft Demand Planning in a collaborative planning environment through the use of several features. Collaborative planning in forecasting begins with managing the collaboration process. This is where you establish security and set up audit usage for those who will be making changes and providing input to the forecast.
Throughout an organization, several different departments can be involved in creating a forecast. A collaboration scenario might, for example, include representatives from finance, sales, and marketing. After departments establish roles and security, representatives can work with their portions of the view.
The sales representative enters his numbers at a lower level in the forecast view, and later, a marketing manager can make adjustments at a higher level in the view based on her knowledge about pipeline information. The marketing manager could then prorate his updates back down through the view for use by the sales and finance representative. A customer representative can also provide input to the forecast by defining anticipated needs.
You can use time-phased fields for collaboration. You can import user period data and adjusted forecast data fields, work with them in the Adjustment Workbench, perform inquiries against them, and publish them to other internal and external applications. You can assign different users of a view their own copies of the forecast for adjusting and tracking. You can also arrive at the best reconciled forecast that is weighed by how accurate each forecast user has been in the past.
All adjustments must include the view, level, and forecast item key fields for the level that is being adjusted. If you perform forecast adjustments in this manner, you should document the changes with detailed comments against the period for the item that is being adjusted.