Demand Planning

Oracle Demand Planning is a web-based application that enables organizations to produce unconstrained forecasts for future demand and generate tactical, operational, and strategic business plans. Demand Planning captures and processes information from multiple sources and consolidates demand so that it can be summarized by item, product line, region, time, and organization. Demand Planning uses Oracle Workflow and supports control mechanisms based on an event or calendar.

What Demand Planning Does
Demand Planning collects time series information from many data sources including shipments, bookings, opportunities, and other forecasts. Feeds into ODP can be time series data from Oracle Shipping, bookings from Oracle Order Entry, or a forecast from Oracle Manufacturing or a third-party application. ODP allows the data to be viewed at multiple levels of aggregation. It enables you to summarize the item, geographic, organization, and time hierarchies. When used with the Advanced Planning and Scheduling system, it creates the demand forecast that will drive the planning and scheduling systems.
ODP has capabilities to model promotions, product introductions with associated cannibalizations, and product phase outs. When making changes to the forecast, planners also associate change reasons with comments, creating an audit trail and knowledge base for future plans. Forecasts can be created at any level and later reconciled on a top-down or bottom-up basis.

Demand Planning Terminology
You should be familiar with the following terms that will be used throughout this chapter:
  • Scenario A set of circumstances that might occur in the future, that you are creating a demand forecast for.
  • Measure An attribute of the plan that determines its success as a plan. One such attribute might be forecast error. Another might be the profit yielded by the plan.
  • Forecast A prediction of future demand in quantitative terms.
  • Baseline forecast The forecast generated by the assigned forecasting method for a given scenario, before planners make any changes based on local knowledge.
  • Dimension An attribute of the forecasts and planning data, that you might want to see quantities or measures aggregated by. For example, you might want to see the forecast error at various levels in the product dimension.
  • Hierarchy A number of levels within a hierarchy. For example, the geography dimension can contain the location hierarchy. This extends from the customer location through countries and regions to “All Geographies.”
  • Time series data Any collection information about something varying over time. Demand or shipment information is an obvious example. Quality data or machine failure information might be others.

Demand Planning Environment

ODP uses Oracle Express as the database that holds the forecast data. It is important to understand the distinction between the planning server, the demand planning consolidated database, and the individual planner databases.Below Figure illustrates how the different pieces of the Express Server relate to each other.

The planning server holds all of the time series data, sales plans, and demand from internal or customer sources. The demand planning shared database holds the consolidated forecasts from all of the planners. Only the Plan Manager has access to this environment. Each planner has a personal database that holds the forecast for his or her portion of the aggregated forecast. Planners can manipulate plans and create histories and forecasts in their own private databases

Demand Planning Roles
Your system administrator might have chosen different names for the roles and responsibilities in Demand Planning, but the following is a brief overview of the division of work. This division is delivered as different responsibilities.
Demand Planning Integration Administrator
The Demand Planning Integration Administrator is the individual who is responsible for a demand plan. You set up dimensions and hierarchies for Demand Planning and set up the ERP instances that Demand Planning will be working with. You set up demand plans with the express databases and run the collections from the source instances and publication of the forecasts. This work is done from within the Oracle Applications environment.

Planning Administrator
The Demand Plan Administrator assigns parts of the planning problem to individual planners. They track the progress of the Demand Planning cycle as well as defining and setting up planning alerts. This work is done from within the Express Server.

The Planner is responsible for the accuracy of the forecast in an assigned segment of the plan. You review his portion of the plan, make adjustments as necessary, and then submit the plan back to the planning manager.

Planning Manager
It is the role of the Planning Manager to review and adjust the entire forecast. It is only this role that gets this unrestricted view of the forecast data. The Planning Manager can use his or her judgment to adjust the plan in the shared database.

Configuring Oracle Demand Planning

To configure Demand Planning, you will need to log on with access to the Demand Planning Integration Administrator functions. The Demand Planning Integration Manager is the individual that sets up the data elements required to build a demand plan. These Data elements include Dimensions, Hierarchies, Planning Levels, Plan Names, Express set up data, Plans, and Output Scenarios. Oracle collects data into the planning server through a layer of views. As delivered these are collecting against the Oracle transaction systems, but the views provide an insulation should you need to integrate Demand Planning with other systems.

Demand Planning Dimensions
Dimensions are the ways that you “slice and dice” your data within the Demand Planning. You should think about the ways that your company assigns responsibility for tracking and achieving volume.

Oracle provides six predefined dimensions and two dimensions that can be user defined. You can also change the names and descriptions for the dimensions that Oracle delivers. For example, Oracle delivers a dimension for “Ship From Location.” You might want to rename this to “Shipping Warehouse.” Navigate to the Dimensions form in the Set Up menu.

Demand Planning Hierarchies
Hierarchies are the routes up the dimensions that you aggregate data. For example, you can aggregate data from customer site level up a geography dimension. To set up a dimension, navigate to the Hierarchies form in the Set Up menu. You will see the Oracle has seeded a number of hierarchies. For example, there are three hierarchies sharing the geography dimension: Customer Class, Customer Group, and Geography.

Demand Planning Levels
You might want to show projected volumes for a product grouping at various levels. Levels might include

  • Customer site to plan distribution requirements, aggregated to
  • Customer to verify with the account manager, aggregated to
  • Customer class to verify with the sales manager, aggregated to
  • All Geography to verify with the factory manager

To define the levels within a hierarchy you can either navigate to the Levels form in the Set Up menu, or you can create the Hierarchy Levels from the Hierarchy Definitions form. In the level definition you can state whether the level is Top, bottom or intermediate. This determines the navigation up and down the hierarchy.

Demand Planning Hierarchy Levels
To set up this hierarchy, click the Hierarchy Levels button in the Hierarchies form. You will see that levels within a hierarchy refer to their parent levels to form the hierarchy. Figure 9-3 illustrates how the hierarchies and hierarchy levels fit together.


You will also notice that the relationship between the parent and child levels is in a view. As delivered this view is over Oracle Applications, but if you are integrating to other systems, you can name a view that defines the relationship. For the form to work correctly the view that you define must return the following columns:

Name                      Null?  Type
 ———————————————- —--------——— ——
 LEVEL_VALUE               VARCHAR2(4000)
 PARENT_VALUE              VARCHAR2(4000)
 ATTRIBUTE1                VARCHAR2(0)
 ATTRIBUTE2                VARCHAR2(0)
 ATTRIBUTE3                VARCHAR2(0)
 ATTRIBUTE4                VARCHAR2(0)
 ATTRIBUTE5                VARCHAR2(0)

Defining Events
You can define marketing promotions, new product introductions, and phase outs to be considered within a demand-planning scenario. Navigate to the Promotions and Other Events form. Enter the name of the promotion. You can promote an individual product, a product family, a category, or all products. Enter the Start Date and End Date for the promotion. Click the Details button to record the effects of the promotional activity. The promotion will affect demand in different ways for different periods during the promotion. For example, if the promotion is a retail promotion and the retailers fill the shelves, there will be an initial peak followed by a plateau in demand at a higher level than unpromoted demand. The promotion will be running within a portion of the plan identified by the dimensions and levels. For example, the promotion might be running on the West Coast, through the Direct Sales Channel, in the Major Accounts Sales Organizations, serviced from the Nevada Distribution Center. Events are used in the definition of the Demand Plan scenario.

Defining Introductions
New Product Introductions enable you to use history of the Base Product to calculate forecast for the new item. It enables you to specify the Cannibalized Items whose demand is likely to fall due to the new product being introduced. For example, a manufacturer of communications equipment may move into the PDA market. The sales of PDAs will be based roughly on the sales of the smaller cell phones. The older cell phones will be unaffected by the PDAs as the buyers are likely to be early adopters who will choose between the high-end cell and the PDA.

Defining the Instances and Organizations to Be Collected from
Demand Planning is designed to get time series data from many data sources. These data sources could be on many instances. An enterprise might be running some divisions on one instance of Oracle Applications and other divisions on another. You can define the instances to collect from and the Organizations within those instances by navigating to the Instances form in the Set Up menu.

 Note  You will have to run the Demand Planning Setup Data Collection once to collect the organization and item category information.