Demand Management Overview

This chapter covers the following topics:

Oracle Demantra Demand Management Overview

Oracle Demand Management is a configurable web-based product to help your organization perform demand planning and forecasting. Demand Management is built around collaboration, and takes advantage of work flows to automate the Demand Management process.

The process of demand planning generally consists of studying historical sales data and trying to predict future demand as closely as possible. The goal is to achieve an appropriate balance between meeting customer demands as quickly as possible and making or buying only as much of each product as required.

A demand plan is based on a forecast, which in turn is a prediction of tendencies in the supply chain over a period of time, influenced by seasonal and other predictable factors. The result of a forecast is a projected curve that has been smoothed to show tendencies and deemphasize the exceptional variations.

In general, the demand plan and forecast are used in downstream operations such as production planning. Depending on how your system has been configured, it either exports such data automatically or contains reports that you use for that purpose.

The Demand Management Process

Demand Management is an iterative process, that typically takes place in the weekly, biweekly or monthly cycles. This process includes:

  1. Collecting the appropriate data from an ERP or other system of record.

  2. Downloading the appropriate data to the Demantra database.

  3. Generating a forecast and then sending a notification to demand analysts.

  4. Demand analysts work with the forecast and making any corrections or adjustments.

  5. Demand manager or designated forecast owner approves the forecast.

  6. The approved forecast is uploaded to your ERP system.

the picture is described in the document text

Collect and Download Data

Most businesses have a regularly scheduled Demand Management process that can be monthly, weekly or, in a few cases, daily. During this period, data from various sources are loaded into the Demand Management system for use in forecasting future demand. The source systems can be an ERP system, legacy system or another Oracle APS (Advanced Planning Suite) module such as Advanced Supply Chain Planning, Inventory Optimization, Global Order Promising or Collaborative Planning.

Once loaded, the administrator ensures that planners have access to the data they require. For example, each planner may be responsible for planning the demand for a particular region or product line. Although planners can view data for all lines of business they are given access to, they are only able to modify data for which they have permissions.

Generate the Forecast and Send Notifications

After the download is complete, the administrator (or an automated process) runs the forecast and resets the approval series. After successful calculation of the forecast, the appropriate users are automatically notified that their forecast is available for review. The forecast, forecast accuracy measures and Demand Priority information are available in predefined worksheets for analysis for all users.

Note: In the event of an unsuccessful download or forecast generation, the Administrator can check the batch log for information on problems that arose during processing and forecast generation.

Manage and Approve the Forecast

The approval process is built around two user-types: the Demand Administrator and Demand Analyst. During implementation, Demand Administrators configure the approval process by specifying a reviewer who has final approval of the forecast. Each group of Demand Analysts should have one final approver.

At the start of the approval process, a notification appears in the My Tasks window informing Demand Analysts that a forecast is available for the current planning cycle. Analysts can review their planning data (including the forecast) using one of the pre-seeded worksheets:

Using the graphs and reports found in these worksheets, analysts view and adjust their forecast data. They analyze history to understand shipped, booked and customer orders, inventory levels and other factors. For example, an analyst may consider any upcoming events or promotions that may impact the demand as well as their customer and sales forecast.

Based on this information, analysts modify the forecast and can run a simulation that repopulates the worksheet with the changed data. Once their analysis and modifications are complete, the analyst saves the changes and selects Done for the relevant notification in the Collaborator Workbench’s My Tasks view, which notifies the demand plan manager or administrator.

These changes to the forecast are available for review by an approver. One or more people can do the review. For example, if the analysts are responsible for demand by region, a regional manager may approve or change the analyst’s changes. Or, if an analyst’s responsibility is broken down into product lines, then the product line manager may have final approval. Demand Management’s pre-seeded approval process is setup for one level of review. Additional levels of review require changes to the pre-seeded Approval workflow.

The final approver can lock the forecast at any time by checking the Final Approval column. After review, the final approver accepts the forecast by selecting the Done button in My Tasks for the forecast notification.

Upload the Forecast

Once approved, the Demand Administrator uploads the consolidated forecast for use in other systems (for example, Oracle Advanced Supply Chain Planning) where the unconstrained demand is used to drive the constrained demand.

Demand Management for Multiple Lines of Business

An organization’s data is typically divided into several Lines of Business (LOB). For example, a printer manufacturer may have Printers and Copiers lines of business. Different lines of business generally have different demand management processes. The difference in the planning process may be due to the following reasons:

When an organization has multiple LOBs, the data is often assigned to specific users (for example based on product line or region), and the analyst is responsible for determining the demand for that slice of data. When each analyst has reviewed and approved his or her forecast, a master approver is notified and approves the forecast as a whole.

The following diagram illustrates the demand management process with multiple lines of business:

the picture is described in the document text

Product Family Forecasting Overview

A product family bill of material is typically made up of a product family item at the top level and items (children) one level down

This is a sample product family bill of material,

Automobiles

. Sedan

. Coupe

. Sports

For product family planning, all the family members of a product family must:

If the item level does not have enough data to produce an accurate forecast, Oracle Demantra Demand Management forecasts at the Product Family level and allocates the product family forecast down to the children.

Configure to Order Overview

Configure to order products are configurations of components depending on the customer's preference. In most cases, this includes a selected base product (the model) and multiple optional (the options) and mandatory components.

Configure to order works on the principle of dependent demand forecasting. Dependent Demand Forecasting is the capability to forecast demand for partially or fully dependent products whose demand depends wholly or partially on the demand for another product. Some of the typical questions that are addressed by dependent demand forecasting are:

Configure to order products are also known as models. They are products, for example personal computers, whose:

The probability of an option is the likelihood that an item will be purchased when another item is purchased. For:

These inter-item probabilities can also vary across regions and across sales channels as customer preferences vary.

The probabilities become planning percentages on the mandatory components and options that help derive the forecasted demand for them.

The demand planning process for configure to order includes these processes:

Generally, if you are operating with configurable models and options, you follow the typical Oracle Demantra Demand Management process with some changes for configure to order products. In general, the business flow is:

Configure to Order Structure

The configure to order structure is typically:

. Base Model

..Option Classes

… Options (Buildable items)

..Mandatory Components (Buildable items)

A base model bill of material is typically made up of

This is a sample base model bill of material.

Sedan

.. Tires

… Standard

… Long Life

.. Seats

… Cloth

… Leather

… Vinyl

.. Roof Rack

… Luggage Style

… Bicycle Style

.. Operating Manual

The base model is Sedan. In the Sedan bill of material, the:

Base models can be of these types:

Planning Percentages

The makeup of the modular products is represented both by model bills and the ratio of the sales of options to the sales of models.

Oracle Demantra generates the independent demand forecast for an item, typically the base model, on the basis of the independent history for the item.

Each component item in a model bill of material has a planning factor. The planning factors are the attach rates, or ratios of options to model demand, that is, the percentage of time that customers order that component item when they order the model.

These ratios, called planning percentages, express the relationship of options to the models. They need to be derived in the demand planning process where changes in product mix can affect the revenue related to a forecast. Also, promotions and other demand planning activities can change the options that are being sold.

Estimating model demand is not enough but predicting the mix of options or features based on their relative sales is necessary using historical percent--the average historical sales of options to models:

Note: Refer to system parameters "CTO_Enable_Worksheet_Calculations" and "CTO_PLANNING_PERCENTAGE_CHOICE" documented in the Oracle Demantra Implementation Guide.

Bill of Material Explosion

Oracle Demantra calculates the dependent demand forecast for a dependent item (option class, option, mandatory component) by exploding the forecast from its respective parents using the corresponding bills of material. Dependent demand for an item is calculated by multiplying its planning percentage by the demand at the next highest level in the bill of material. Dependent demand items can also have an independent demand forecast, for example, the service parts portion of their demand

The total demand for any item is the sum of the dependent and independent components of demand. For example, the demand for computer monitors is a composite of its direct (independent) demand and the demand deriving from the sale of personal computer systems (dependent demand).

This table shows a sample base model bill of material with the items, the planning percentages, and the results from the model bill of material explosion

Bill of Material Item Planning Percentage Demand Explosion Calculation
. Sedan - . 500 (forecast) -
.. Tires ..100% .. 500 ..500 * 1
… Standard set .. 75% … 375 … 500 * 0.75
… Long Life set .. 25% … 125 … 500 * 0.25
.. Seats ..100% .. 500 .. 500 * 1
… Cloth … 10% 50 … 500 * 0.1
… Leather … 45% … 225 … 500 * 0.45
… Vinyl … 45% … 225 … 500 * 0.45
.. Roof Rack .. 35% .. 175 .. 500* 0.35
… Luggage Style … 60% … 105 … 175 * 0.6
… Bicycle Style … 40% … 70 … 175 * 0.4
.. Operating Manual .. 100% .. 500 .. 500 * 1

Moving Configure to Order Data from Oracle e-Business Suite to Oracle Demantra

Data that moves from Oracle e-Business Suite to Oracle Demantra includes:

To move configure to order data from Oracle e-Business Suite into Oracle Demantra, use a two-stage process:

Configure to Order Levels

Configure to order structures work with these levels:

the picture is described in the document text

For example, there is a bill of material structure

Computer Package A

. Laptop A1

.. Option Class HardDisk

... Harddisk 120G

... Harddisk 150G

.. Option Class Processor

... Processor Pentium 2GHz

... Processor AMD 2 GHz

The level load contains these entries

Level1: Parent Item Level2: Item Level3: Base Model
Computer Package A 120G + Pentium 2 GHz Computer Package A
Computer Package A 120G + AMD 2 GHz Computer Package A
Computer Package A 150G + Pentium 2 GHz Computer Package A
Computer Package A 150G + Pentium 2 GHz Computer Package A
Computer Package A Computer Package A Computer Package A

Configure to Order Options

If a base model has history, all its options are loaded into Oracle Demantra.

Option information for Oracle e-Business Suite is dimensioned by the item and organization level. This information needs to be associated to the other dimensions, for example site and demand class, when stored and planned in Oracle Demantra.

Configure to Order Sales History

The Collect Shipment and Booking History process includes configure to order history.

It uses profile option MSD_DEM: Include Dependent Demand. Set it to Yes for the process to collect the bills of material for configure to order.

The process collects bills of material that are active within the Shipment History time span (or the time span of other selected series). The bill of material start date is required, but not the end date.

It calculates dependent demand through the bill of material effective end date, if there is a value on the bill of material.

It loads the History Dependent Demand series from the history of options. The series that is loaded into History Dependent Demand is determined by the independent demand history series in Oracle Demantra. The default is Shipment History - requested items - shipped date.

Note: Refer to system parameter "CTO_HISTORY_PERIODS" documented in the Oracle Demantra Implementation Guide.

The series available for configure to order collections are:

For every series that you mark Yes on the Collections parameter window, it loads the shipment and booking history of the options as follows:

The process only includes configured items with these attributes:

For example, there is a bill of material structure

Computer Package A

. Laptop A1

.. Option Class HardDisk

... Harddisk 120G

... Harddisk 150G

.. Option Class Processor

... Processor Pentium 2GHz

... Processor AMD 2 GHz

The sales history load contains these entries

Item Parent Item Base Model Date Quantity
120G Harddisk Computer Package A 1/1/2008 1
Pentium 2 GHz Processor Computer Package A 1/1/2008 1
Harddisk Laptop A1 Computer Package A 1/1/2008 1
Processor Laptop A1 Computer Package A 1/1/2008 1
Laptop A1 Computer Package A Computer Package A 1/1/2008 1
Computer Package A Computer Package A Computer Package A 1/1/2008 1

Viewing Bill of Material Information in Worksheets

To include a bill of material tree in a worksheet, follow these steps:

  1. In the Aggregation tab, select the Base Model and Item

  2. In the Layout tab, right-click and select Show BOM Tree.

The system uses a parent level and a child level to display the bill of materials tree in the worksheet. You can see these levels in the Aggregation Tab:

However, if you select these levels in the Worksheet Designer and then attempt to enable the Show BOM Tree option, the following error message displays:

Error: The Show BOM Tree option cannot be enabled when either of the following levels are selected: CTO Parent, CTO Child. To display the BOM Tree, remove these levels.

In any worksheet with the Show BOM Tree option enabled, you can create additional views. The bill of materials tree is then enabled in every additional view. Conversely, if you disable the Show BOM Tree option in any view, it is disabled in every view in the worksheet.

You can add notes to any item that is an option or option class displayed in the bill of materials tree. When you right-click and select Notes for an option or option class in the bill of materials tree, the note appears on that option or option class when the bill of materials tree is displayed.

If the item is not displayed in the bill of materials tree format (for example, item's dependant demand across all base models and independent demand), all notes assigned to that item in the bill of materials tree is visible.

In all display formats, the display:

the picture is described in the document text

If you do select Show BOM Tree, you see the bill of material in indented fashion.

the picture is described in the document text

If you do not select Show BOM Tree and Item is on the crosstab, you see the bill of material as a flattened list of all levels.

the picture is described in the document text

If you do not select Show BOM Tree and both Item and Parent Item are on the crosstab, you see a typical crosstab without multi-level recursion of the bill of material.

the picture is described in the document text

If you want to display information grouped by level, a new level can be added to the CTO levels. For example, you can add a new level if you want to view all the BOMs for base models in the Product Family server, a CTO level called BM Product Family can be created during implementation and placed to the right of the BOM tree (associating the base models to the Product Family server is also an implementation task).

To view level information in the BOM tree

A level is usually placed to the right of the BOM tree for information purposes, such as viewing associated level values. You can do this by creating a series on the level in the Business Modeler.

  1. In the Business Modeler, click the Series icon.

  2. Click the New icon.

  3. In the General Properties tab, enter the following:

    • Enter the Series name

    • Editable = No

  4. In the Display Properties tab, enter the following:

    • Table only

    • No summary

  5. In the Data Properties tab, enter the following:

    • Data Table = Level. For example:

      <Level> Product Family

    • Aggregation Function = MIN

  6. In the Expression Properties tab, enter the following:

    • Server Expression = Select relevant table for MIN function. For example:

      min (t_ep_ebs_prod_family.ebs_prod_fmly_desc)

  7. Click Save.

Editing Planning Percentages in a Worksheet

An option-class item combination may be part of the configuration of more than one base model.

After the initial download of planning percentages, the planning percentage for an option class-item combination in multiple base models is the same.

If you use a worksheet to edit an option class-item combination that is in multiple base models, the planning percentages that result can be different depending on whether or not the base model in included in or excluded from the worksheet.

Note: Refer to system parameter "CTO_Enable_Worksheet_Calculations" documented in the Oracle Demantra Implementation Guide.

This example shows two central processing unit base models after the initial download of planning percentages.

Bill of Material Item Planning Percentage Bill of Material Item Planning Percentage
. CPU 1 (model) - . CPU 2 (model) -
.. Drives (option class) ..100% .. Drives (option class) 100%
… Hard drive 120g .. 40% … Hard drive 120g … 40%
… Hard drive 220g .. 60% … Hard drive 220g … 60%

In this example:

Bill of Material Item Planning Percentage
. CPU 1 (model) -
.. Drives (option class) ..120%
… Hard drive 120g .. 40%
… Hard drive 220g .. 80%

Continuing with this example where base model is a worksheet level:

Bill of Material Item Planning Percentage Bill of Material Item Planning Percentage
. CPU 1 (model) - . CPU 2 (model) -
.. Drives (option class) ..120% .. Drives (option class) 100%
… Hard drive 120g .. 40% … Hard drive 120g … 40%
… Hard drive 220g .. 80% … Hard drive 220g … 60%

In this example:

Bill of Material Item Planning Percentage
.. Drives (option class) ..120%
… Hard drive 120g .. 40%
… Hard drive 220g .. 80%

Continuing in this example where base model is not a worksheet level:

Bill of Material Item Planning Percentage Bill of Material Item Planning Percentage
. CPU 1 (model) - . CPU 1 (model) -
.. Drives (option class) ..120% .. Drives (option class) 100%
… Hard drive 120g .. 40% … Hard drive 120g … 40%
… Hard drive 220g .. 80% … Hard drive 220g … 80%

Simulations

You can run simulations to get an approximate forecast based only on the current worksheet as opposed to all the data.

When you make a change to Dep Demand - History that affects the forecast, for example overriding the history of a model or an option and accept the simulation, the simulation process:

When you make a change to Dep Demand - Existing that affects the forecast, for example overriding the history of a model or an option and accept the simulation, the simulation process:

Overrides

You can make changes to the planning percentages, dependent demand and, independent demand (forecast) by overriding any of these three series via the corresponding override series, for example, Planning Percentage Override.

You can make changes at any depth level of the bill structure. The changes propagate through the entire bill structure; you do not have to make any additional manual changes.

Configure to Order Worksheets

See Configure to Order Worksheets

Configure to Order Series

See Configure to Order Series

Settings for Planning Percentages and Dependent Demand

You must instruct e-Business Suite to collect configure to order structures, demand, and history.

You can specify the number of history periods to use when calculating planning percentages based on the history of the options.

You can specify upon what entities to calculate planning percentages:

You can specify where to calculate dependent demand and derive planning percentages:

For more information, see Setting up Configure to Order in Oracle Demantra Implementation Guide.

Planning Percentage Calculation Based on Sales History Options

The historical planning percentages do not change with time and the same planning percentages are used for all the forecasting periods.

For example, if there is a forecast for January 2009 and February 2009 based on history, the calculation of the options’ dependent demand for both January 2009 and February 2009 use the same planning percentages.

Planning Percentage – History =

History of the item during the past CTO_HISTORY_PERIODS / History of its parent item during the past CTO_HISTORY_PERIODS.

The process does not calculate planning percentages prior to an item’s BOM Effective Start Date or after an item’s BOM Effective End Date.

It calculates planning percentage for all the active items to the lowest levels of the bill of material.

Dependent Demand Calculation Based on Planning Percentages

The dependent demand calculation for options and items is based on the base model’s information.

It occurs at the following stages:

The calculation propagates changes in the intermediate level data to all the children of that level.

Dep Demand – Existing =

Plng Pct- Existing * Immediate parent forecast

Dep Demand – History =

Plng Pct- History * Immediate parent forecast

Forecast Dependent Demand =

Final Plng Pct  * Immediate parent forecast

Final Forecast Dependent Demand =

If there is a value in Forecast Dependent Demand Override, it is the Forecast Dependent Demand Override value. Otherwise, it is the value of Forecast Dependent Demand.

Forecast Calculations

For global forecasting:

For product family forecasting:

Configure to Order MAPE Calculation

The series MAPE CTO holds the results of the MAPE CTO procedure that calculates the accuracy statistics for Consensus Total Demand. This provides the information Inventory Optimization requires to calculate Safety Stock. The calculation is:

sum(abs(Total History – Archived Consensus Total Demand))/sum(History)
where
- Total History = History + Final Forecast Dependent Demand  for the 13 week period of the archived forecast
- Consensus Total Demand = Independent Demand + Dependent Demand

Moving Configure to Order Data from Oracle Demantra to Oracle e-Business Suite

Data that moves from Oracle Demantra to Oracle e-Business Suite includes:

To move configure to order data from Oracle Demantra into Oracle e-Business Suite, use upload workflows:

For more information on the CTO Upload and CTO Upload Product Family workflows, see Setting up Configure to Order in Oracle Demantra Implementation Guide.

Oracle Advanced Supply Chain Planning loads and processes the data for Consensus Total Demand and Planning Percentage information for models and their options as follows:

Oracle Advanced Supply Chain Planning loads and processes the data for Consensus Total Demand and Planning Percentage information for product families and their children as follows:

Oracle Demantra calculates Plng Pct- History at the lowest level for all levels.

When you upload planning percentages to Oracle Advanced Supply Chain Planning, you do so at the level Item-Organization for items with item attribute Forecast Control set to None. Oracle Advanced Supply Chain Planning uses the Oracle Demantra planning percentages to explode demand from model to option class to model.

When you upload dependent demand to Oracle Advanced Supply Chain Planning, you do so at levels Item, Organization, Zone, and Demand Class for items with item attribute Forecast Control set to Consume or Consume & derive. Oracle Advanced Supply Chain Planning uses the Oracle Demantra dependent demand and does not use the Oracle Demantra planning percentages

Data in the seeded export workflows matches the worksheet data when you view it at the viewed at the lowest levels Item, Organization, Week, Demand Class, and Zone.

Service Parts Planning and Service Parts Forecasting Overview

Service Parts Planning

Repair service operations need service parts planning systems to ensure that the right parts are at the right locations, at the right times, and in the right (usable) condition, while being consistent with inventory budgets and service level targets.

Service parts inventory management differs from product inventory management; hence the need for functionality designed to handle special service parts situations such as: supersession and intermittent demand.

The Oracle Service Parts Planning solution supports the following forecasting modes:

In either mode, forecasts can be based on usage history or shipment history.

In the case of new product introductions or similar situations where there is insufficient history for a reliable basis, the inline mode provides the ability to base forecasts on the item's install base population and average failure rate.

This document describes the inline scenario, in which Demantra generates the service parts forecast and it is then exported for use in Oracle Service Parts Planning or other legacy application.

For more information about Oracle Service Parts Planning, Oracle Field Service Spares Management, or Oracle Depot Repair, refer to the appropriate Oracle product documentation.

Service Parts Forecasting

Demantra forecasts demand for service parts using two methods. One method uses analytical models, and the other method is calculated using install base data and failure rates. Demantra generates forecasts using both methods and then allows you to select the preferred forecast based on past experience, industry-specific knowledge, or other information.

By applying a service part specific failure rate to the projected install base at an organization, it is possible to project future demand for service parts.

Failure Rates

Failure rates are based on a comparison of the supported units for the finished good and a specific quantity of service parts that are used to service them. A seeded process calculates the ratio between the number of supported base models and usage. The result of the process is the failure rate.

The level at which these values are calculated can vary by business requirement and is configurable as part of an implementation. It is possible to calculate failure rates at very granular levels. This results in planning percentages that closely reflect part usage for a specific spare and location. However, this method is also susceptible to large variations in demand over time that are due to inherent intermittent part usage. It is also possible to calculate failure rates at more aggregate levels; here the rates generated are more generic but are less susceptible to variation.

When generated in aggregation all underlying combinations are assigned the same failure rate.

For more information about how to configure the failure rate calculation, refer to Oracle Demantra Implementation Guide.

Process Overview

The following example describes a typical Service Parts Forecasting cycle:

For more information about Service Parts Forecast worksheets, refer to Service Parts Forecasting (SPF) Worksheets.