Demand Management Course Rel 19C - Student Guide

Schedule: Timing Topic
05 minutes Lecture and Demonstration

0 minutes Practice
05 minutes Total
This slide lists the learning objectives for this course.
Oracle Demand Management Implementation 1 - 2

This slide describes training environment preparation steps.

This slide lists the lesson topics included in this course.

This slide describes the instructional approach for this course.

• Oracle Supply Chain Management Cloud documentation,
https://docs.oracle.com/en/cloud/saas/supply-chain-management/18c/index.html available in the
Oracle Help Center:
• Getting Started with Your Manufacturing and Supply Chain Materials Management
Implementation: https://docs.oracle.com/en/cloud/saas/supply-chain-
management/18c/fammi/toc.htm
• Implementing Supply Chain Planning: https://docs.oracle.com/en/cloud/saas/supply-chain-
management/18c/implement.html
• Using Demand Management: https://docs.oracle.com/en/cloud/saas/supply-chain-
management/18c/fasdm/index.html
Oracle SCM Cloud: Sales and Operations Planning Implementation 1 - 6

Cloud Customer Connect (https://cloudcustomerconnect.oracle.com/pages/home ) is Oracle's online
cloud community — specifically designed to promote peer-to-peer collaboration and sharing of best
practices, enable members to keep pace with product strategy, and provide a cloud solution feedback
channel directly to Oracle development. Within this community, members benefit by leveraging the
collective knowledge of Oracle Cloud customers and product experts.
• The Forum (https://cloudcustomerconnect.oracle.com/resources/58ae2339bb/summary) enables
you to network and collaborate on real-life challenges and solutions with fellow members. Share
best practices as you strive to deliver consistent, personalized customer experiences, and connect
every customer engagement with your brand.
• The Idea Lab (https://cloudcustomerconnect.oracle.com/resources/0d217b91cc/summary) allows
you to contribute to our product roadmap that is derived from a variety of influences, such as market
changes, compliance and regulatory forces, industry trends, and one of our best sources, our
customers.
• The Events (https://cloudcustomerconnect.oracle.com/resources/4cb7a01b8c/summary) tab lists
upcoming and replays of Supply Chain Management Events
The Supply Chain Planning Release Readiness Materials
(https://cloud.oracle.com/saas/readiness?offering=scp) allows you to learn about the latest innovations
in our Supply Chain Planning products.

Specific Release Readiness topics are highlighted on this and subsequent slides.
REST API for Oracle Supply Chain Management Cloud:
• Table of Contents: http://docs.oracle.com/en/cloud/saas/supply-chain-
management/19a/fasrp/toc.htm
Use a Calculated Measure Across Multiple Planning Work Areas

• Video:
http://download.oracle.com/ocomdocs/global/apps_19C/scm/Use_Calculated_Measure_Across
_Work_Areas/index.html
• Handout:
_Work_Areas/Use_Calculated_Measure_Across_Work_Areas.doc
Monitor Planning Processes and Improve Planning Data Quality

• Video:
http://download.oracle.com/ocomdocs/global/apps_19C/scm/Monitor_Planning_Processes_and
_Improve_Planning_Data_Quality/index.html
• Handout:
http://download.oracle.com/ocomdocs/global/apps_19C/scm/Monitor_Planning_Processes_and
_Improve_Planning_Data_Quality/Monitor_Planning_Processes_and_Improve_Planning_Data_
Quality.doc
Oracle SCM Cloud: Planning Foundation 1 - 8

Plan with Telescoping Time Buckets
• Video:
https://download.oracle.com/ocomdocs/global/apps_19B/scm/Plan_with_Telesco
ping_Time_Buckets/index.html
• Handout:
https://download.oracle.com/ocomdocs/global/apps_19B/scm/Plan_with_Telesco
ping_Time_Buckets/Plan_with_Telescoping_Time_Buckets.doc
Oracle Demand Management Implementation 1 -

Use a Calculated Measure Across Multiple Planning Work Areas
• Video:
_Work_Areas/index.html
• Handout:
_Work_Areas/Use_Calculated_Measure_Across_Work_Areas.doc
Update Planning Supplies Using a REST Service

• Video:
https://download.oracle.com/ocomdocs/global/apps_19C/scm/Update_Planning_Supplies_usin
g_REST_Service/index.html
• Handout:
https://download.oracle.com/ocomdocs/global/apps_19C/scm/Update_Planning_Supplies_usin
g_REST_Service/Update_Planning_Supplies_using_REST_Service.doc
Update Planning Demands Using a REST Service

• Video:
https://download.oracle.com/ocomdocs/global/apps_19C/scm/Update_Planning_Demands_usi
ng_REST_Service/index.html
• Handout:
Oracle SCM Cloud: Planning Foundation 1 - 9

https://download.oracle.com/ocomdocs/global/apps_19C/scm/Update_Planning
_Demands_using_REST_Service/Update_Planning_Demands_using_REST_S
ervice.doc
Oracle Demand Management Implementation 1 -

Product experts schedule Customer Connect training. These sessions provide more information on
topics already discussed in this training or discuss topics relevant to the implementation and use of the
product. The replays of these sessions are listed in a single forum post to make them easy to find:
https://cloudcustomerconnect.oracle.com/posts/67548c46b6
You can also find replays of these sessions from the Events area. In the Find Events box, enter
training and Supply Chain Planning and click Find. This filters your results to list only Supply Chain
Planning training events.
You can also select one of the available Event Series. The event series filters the events by training
and product areas.
Training event: Configuring Demand Planning in Planning Central Cloud and Demand Management
Cloud for Scalability
https://cloudcustomerconnect.oracle.com/posts/f58998083e
The Oracle Supply Chain Management Integration Lesson
(https://cloudcustomerconnect.oracle.com/posts/5d7d178db7) discusses core integration capabilities
for Supply Chain Management including external web services, integration with PaaS, business events,
file-based data import, ADFdi and common messaging framework.

0 minutes Practice
25 minutes Total

In this lesson, we will review and discuss several important aspects of demand planning.
The lesson will highlight some key differentiators of Oracle Cloud Demand Planning, key demand planning
flows and capabilities.
After completing this lesson you will know how to:
•Describe the demand plan workflow and process overview.
•Define elements of a plan.

This topic discusses the basic concepts for Demand Planning.

This slide discusses the modern best practices for Demand Management. These include improving
demand visibility, managing demand variability, and achieving business objectives.
Let’s re-focus on the key practices for Demand Management.

Oracle Cloud Demand Planning enables your end to end demand planning process. In the process
you gain the ability to load and review historical demand whether shipments, bookings or a user-
defined demand stream. Generate a world class statistical forecast, analyze the results, forecast
inputs and outputs. You can then modify the forecast inputs or results and collaborate with
stakeholders to approve.
The forecast can then be used in Supply Planning or other processes.
At any time you can review a fully configurable Plan Summary page which gives you a snapshot of
your plan’s health using key metrics.

New plans require a unique name. It is recommended that the plan have a short description to allow
other users and stakeholders to quickly identify the scope and purpose of the plan.
The type of plan must be set based on the use of the plan. Plans accessed via the Demand Planning
work area are fixed to type “Demand”. If accessed via Integrated Demand and Supply, the interface
can be either type “Demand” or type “Demand or Supply”.
Access determines whether only you, a selected list of users, or all users can see and access the
plan. Choose Public to allow all users access to this plan. Choose Private to select which specific
users have access to the plan.

Use the Scope tab to configure plan organizations, items, time horizon, and planning level for
demand forecasting.
Note: Dimensions and hierarchies modeled in a plan are limited to the ones specified in dimension
catalog chosen for the plan. A catalog can be maintained by using the Configure Planning Analytics
task.
Plan Organizations
Specify which organizations to include in a plan by selecting Organization Hierarchy, Hierarchy
Level, and Level Members from the same Source System. If the selected level is above the
organization level, then organizations that belong to that parent level will be included.
For Oracle Cloud Demand Planning, organizations can be forecasted independently and the plan
administrator has full freedom regarding which organizations are included. When the plan is
executed, a forecast will be generated for all items and organizations included in the plan.

Use the Scope tab to configure plan Products. Dimensions and hierarchies modeled in a plan are
limited to the ones specified in the plan’s dimension catalog. This catalog can be maintained by
using the Configure Planning Analytics task. Specify which product dimension will be used to
manage the plan’s population.
Note: The item level itself cannot be chosen due to the very large list of products available to most
customers as well as the continuous change to the products available. It is far more suitable to use a
more aggregate level in product dimension to control the list of items in a given plan.
The plan’s population will be based on an intersection of organizations and products. The
comprehensive list of products and organizations will be filtered to only include products and
organizations matching the plan’s scope.
Unlike the mandatory Organization Filter the product filter is optional.

By choosing the Enterprise hierarchy and Business Unit level, you can filter which business units are
part of the plan.
You can then choose North America, only organizations belonging to this business unit are part of
the plan.
By choosing the Product hierarchy and product category level, you can filter which product category
is part of the plan.
Then you choose Automotive and Service parts. Notice that only products belonging to these
product categories are included in the plan.
The resulting plan will include all products for categories Automotive and Service Parts associated
with organizations fitting Business Unit North America.
Note: Since the names of pre-defined product hierarchy levels are typically technical names, you
should rename them to something which will make more sense to planners and other users. You can
rename product hierarchy levels using the Configure Analytics pages.
The plan’s population will be based on an intersection of organizations and products. The
comprehensive list of products and organizations will be filtered to only include products and
organizations matching the plan’s scope.

Plan Horizon Days
Specify the plan horizon in terms of days.
Forecasting Calendar
The calendar used for forecasting.
The calendar must be specified in the chosen dimension catalog. This catalog can be maintained by
using the Configure Planning Analytics task. Forecasting Calendar allows for selection of
Manufacturing, Fiscal, and Gregorian calendar types and includes any calendars in the dimension
catalog. The Gregorian calendar is generated in VCP and does not have a source system instance
code. Other calendars may need to be loaded prior to use.
Forecasting Time Level
The time level used for forecasting.
Time levels vary as per the selected Forecasting Calendar. For example, Forecasting Time Levels
for a Manufacturing calendar are Day, Week, and Period.
The levels quarter and year are not available because they are currently not supported as the
Forecasting time level.

Measure Catalog
A flexible way to group sets of measures for use in different plans. By selecting a catalog, user
chooses to access only those measures that are needed for any specific plan, users will be able to
do a focused analysis with improved performance.
Measure catalogs can be maintained by using the Configure Planning Analytics task.
Note: Some measures are required for Demand and Supply Planning and must be included in the
measure catalogs. For example, measures used by the forecasting engine as input and outputs..
Price Lists
Price Lists are used in value calculations for display in pivot tables and graphs. Select from the list of
collected price lists or use the Item List Price from the Items table by default. Mark one of the Price
Lists as ‘Primary’. The primary price list’s data is populated into the Price measure.

This slide reviews the objectives you learned in this lesson.

20 minutes Practice
50 minutes Total

After completing this lesson you will know how to analyze a demand plan and forecast while navigating
demand plans.

This topic discusses analyzing a demand plan.

When you log into the demand planning work area the default layout displays an overview of your
demand plan. The layout called Demand Plan Summary contains a top region with five infotiles
each showing a key demand planning metric. When a tile is selected by clicking on it, the content
beneath the tiles shows additional more detailed information regarding the specific area of demand
planning. The detailed region serves as the first step in conducting a more detailed analysis of
various aspects of your demand plan and typically allow further drilling to additional and more
detailed view.
Note that the pre-defined layout is a starting place. Your business may want to view additional or
different information and you can create one or more layouts to match your exact needs.

The infotile Shipments History Comparison serves to give you a quick visual snapshot how current
year’s shipments compare to the shipments 12 months before.
The main tile displays shipments for the last twelve months as one total and the previous twelve
months as a second total. When the totals have a wide gap, this indicates that there is a large
difference between the two which indicates areas which require more attention.
The detailed graph associated with the tile shows a treemap allowing users to focus on areas
where shipment volume is large as is the year over year difference.
• Square size indicates shipment amount.
• Square color indicates the variety in year over year demand quantity.
From the detailed graph users can drill to product categories which show substantial year over year
increase or decline.

The infotile Shipments Forecast MAPE gives you a quick visual snapshot showing the accuracy of
last cycle’s shipments forecast when compared to shipments.
The main tile displays the Mean Absolute Percentage Error (MAPE) for the last completes
shipments forecast cycle. The settings of the range can be configured by modifying the goals of the
measure Shipments Forecast MAPE.
The detailed graph associated with the tile shows a treemap allowing users to focus on areas
where shipment forecast value is large as is the forecast error.
• Square size is tied to the Shipments Forecast Value measure.
• Square color indicates Shipments Forecast MAPE.
From the detailed graph users can drill to product categories which show substantial forecast error.

The tile New Product gives you a quick visual snapshot of percentage of forecast tied with products
with lifecycle attributes which are considered new.
The main tile displays the measure New Products Shipments Percentage. The measure is filtered
for a set of item attributes. These attributes can be modified in the measure’s expression.
The graph shows the same measure for the next six quarters.
Finally the table displays shipment forecast and marketing forecast by product category.
This view allows you to quickly determine the amount of forecast associated with new products and
which categories are meeting business goals and where attention is required.

The Forecast comparison tile focuses on identifying any gaps between shipment forecast and sales
forecast. A wide gap indicates a mismatch in expectations between planning and sales teams and
requires attention. Untreated, the gap can lead to a shortfall in available supply when sales
executes their future plans.
The tile shows the total gaps between shipments and sales forecasts for the plan
The bottom left graph shows analysis by quarter and includes last years shipments for reference.
The bottom right graph shows a more detailed view, by product category. You can immediately
identify which categories are contributing to the gap.

Meeting the yearly budget is a key responsibility of the demand planning group. This tile includes a
side by side comparison of history shipments forecast with the yearly budget. The detailed views
allow you to identify if the issue stems from a specific quarter or product category. Understanding
where the shipment forecast does not meet the budget allows you to focus on areas where demand
needs to be shaped. You can also use the information as the basis for discussion with sales and
marketing.

The Lock Cells When Editing or Allocating Values feature provides you the ability to lock one cell or
multiple cells in order to prevent manual edits, or changes resulting from the edits made at a summary
level. In addition, it provides the ability to unlock the locked cells, and to allocate data and verify
different scenarios interactively in one table and view.
The Lock, Unlock and Unlock All options are available when summary level totals are configured for
the table using the View>Configure Summaries option available on the table toolbar.
An example of how the feature is used is:
The 2018 Shipments Forecast is already approved through June 2018. Adjustments are needed for
the year 2018 based on additional marketing estimates, but the months January-June should not be
changed.
Create a table with the Adjusted Shipments Forecast measure for the Year and Months in 2018, and
configure a "Summary" option for the “Year" level using the Configure Summaries option under the
View menu on the toolbar.
Lock the "Adjusted Shipments Forecast" measure for the months January to June 2018, where the
forecast was already approved. Then update the Year summary line with a value that will be
disaggregated down to the months July - December. The "Adjusted Shipments Forecast" measure will
remain intact for January – June, and only July through December 2018 will automatically be modified
proportionally (based on the measure definition).

The Lock Cells When Editing or Allocating Values feature allows the users to lock and unlock single or
multi cells in a table from 3 places:
• The actions menu,
• The table’s toolbar,
• And by right clicking on a specific cell.
When choosing to lock or unlock several cells in parallel, the user can use the Lock and Unlock options
inside the Actions menu or use the corresponding icons in the toolbar.
When choosing to lock a single cell, it can also be done by using the right click on the selected cell.

The ‘Audit Trail of Measure Updates’ feature documents all updates on editable measures by users
which occur in pivot tables and maintains an audit trail of these changes.
You can view the audit trail data of all editable measures and on all users, with the updated date for
each value.
You can also filter the audit trail table and view the audit data per user, measure, audit date. This is
done by using the search panel in the top of the table. You can search all updates that were done
on a specific measure (for example, Adjusted Bookings History). Alternatively, you can view the
audit on all editable measures per specific user or per the date the update occurred.
You can also view the filters that were in place, such as Year 2022, for the pivot table when the
update was performed.

The ‘Audit Trail of Measure Updates’ documents all updates on editable measures by users which
occur in pivot tables in order to maintain an audit trail. The Audit Trail table gives you the ability to
view the audit trail data of all editable measures and on all users, with the updated date for each
value.
You can also filter the audit trail table and view the audit data per user, measure, audit date. This is
done by using the search panel in the top of the table. You can search all updates that were done
on a specific measure (for example, Adjusted Bookings History). Alternatively, you can view the
audit on all editable measures per specific user or per the date the update occurred.

When you select the audit trail row which you wish to view in the main audit trail table, you can
open the details icon and view all the relevant information of the update that was made. This
information includes the measure name, previous value and new value, and also the population on
which the measure was updated. In addition, the details screen includes the filtered levels and
members within the pivot table where the actual update was performed.
Audit Trail:
• Is available for all measure types (Numeric/Date/String)
• Covers shared measures and plan specific measures
• Covers user-defined and seeded measures
• Captures updates of the same value
• Captures all measure updates made interactively
Note: Measure updates resulting from Collections processes are not captured in the Audit Trail

Security
• Only the user who performs the actual update will be able to view the previous and new
values in the main audit trail screen.
• Other users will be able to view the previous and new values only via the Audit Trail Details
screen.
• Users with security restrictions will get a message when trying to see the audit details.

In this demonstration, you will learn how to analyze a demand plan.

In this practice, you will learn how to analyze a demand plan.


0 minutes Practice
30 minutes Total

•Review and determine which forecasting methods and at what aggregation level the forecast was generated.
•Identify where outliers in demand were smoothed and view the forecast decomposed to causal factors and
forecasting methods.

This topic discusses analyzing forecast methods.

When a demand forecast is generated as part of the run plan process, the forecast is generated for
individual combinations. Combinations are a predefined data aggregation used by the forecasting
profile and can be Item + Organization, Product Category +Customer or other meaningful
aggregations of your demand data. For each forecast combination different forecasting methods
are evaluated and one or more are used to generate the forecast. The Demand forecast has fifteen
forecasting methods that may be used. Understanding which forecasting methods were used in a
specific combination will help you understand why the forecast behaved in a specific manner as
different forecasting methods capture differing aspects of demand.
You can control which forecasting methods are active using the Manage Forecasting Profiles
interface.

Each forecasting method has a letter associated with it. When a forecasting method is used the letter
representing it is written as part of the forecast output. For example when using forecasting profile
“Forecast Shipments” the letters of forecasting methods is written into the measure Shipments
Forecasting Methods. Use the Bookings Forecast Forecasting Method for Bookings; use the
Shipments Forecast Forecasting Method for Shipments
X- Auto Regressive External Inputs
V- Auto Regressive Integrated Inputs
A- Auto Regressive Logistic
B- Causal Winters
E- Combined Transformation
F- Croston for Intermittent
D- Dual Group Multiplicative
H- Holt
G-Logistic
M-Modified Ridge Regression
K- Multiplicative Monte Carlo Intermittent
C- Multiplicative Monte Carlo Regression
R- Regression
J- Regression for Intermittent
L- Transformation Regression

When reviewing a forecasting combination the forecast methods measure easily shows you which
methods were used in the last execution of that forecasting profile.
Three of these forecasting methods are associated with forecasting sparse demand: Croston for
Intermittent, Regression for Intermittent and Multiplicative Monte Carlo Intermittent.
It is useful to understand how frequently a combination was forecasted using sparse methods. Pre-
defined reports provide you that insight.

Access to the Review Planning Messages is through shipped job roles:
• Demand Planner
• Demand and Supply Planner
• Sales and Operations Planner
Business Processes affected by this feature are:
• Manage Demand Planning
• Manage Integrated Demand and Supply Planning
Messages are available related to issues impacting the ability to:
• generate a demand forecast.
• provide the ability to generate a demand forecast.
• provide the ability to open a plan for which a forecast could not be generated for a selected
forecasting profile.
This could potentially impact business flows related to validating plan runs and reviewing forecasts.
In sum, the business impact is Small Scale.
• New messages to identify issues related to forecasting profiles are added to the existing “Review
Plan Messages” functionality.
• You can also open a plan when there is a warning due to a forecasting profile issue, as part of the
“Open Plan” functionality.
For more information, refer to the Readiness Training video and handout for the Demand Planning

topic Monitor Planning Processes and Improve Planning Data Quality.
Oracle Demand Management Implementation 4 - <#>

This topic discusses analyzing forecast levels.

When demand forecast is generated, the data aggregation level at which it is generated can vary
from combination to combination.
Most combinations should get forecasted at the first attempted level but there are times where data
quality is poor or it is difficult to explain variation in history and forecast is generated at a more
aggregate level. It is important to understand where and how often forecast at aggregation occurs,
this information is critical in understanding the forecast itself and can drive you to take actions to
reduce the number of combinations with an aggregate forecast.

The data aggregation levels at which forecast is attempted are derived from the table provided to
forecasting profile parameter “Forecasting Table”. The table’s definitions are used to determine
which is the first aggregation level used and which subsequent levels will be used.
In addition the input and output measures available for the profile will be based on this table.
For good sample tables, refer to pre-defined tables “Forecast Shipments Definitions and “Forecast
Bookings Definitions”.
The data aggregation level at which a combination’s forecast is generated is stored in a measure
specific to that forecasting profile. A value of 1 denotes the first aggregation level, 2 is the next
higher level and so on.
Pre-defined tables enable you to view the average forecast levels for product categories.
Categories with higher forecast levels indicate that forecast is typically failing at the first attempted
level. This may meet your business expectations but you can investigate the data for these
categories and determine if there are inherent challenges or errors in loaded demand history.

This slide shows the organization/item forecast combination in the example.

This topic discusses analyzing forecast methods.

Outliers are extreme demand points in historical demand that the forecasting process can not
explain well. Many spikes and dips in demand can be explained by seasonality or causal factors
but there are times that a particularly high or low data point can’t be explained well and is causing
the engine to be unable to understand demand patterns.
In these instances the forecasting methods can adjust historical demand and smooth extreme data
points.
The forecasting process also marks the points which were smoothed.
Understanding where outliers occurred can help understand the underlying characteristics of your
demand and where the forecasting process made adjustments to the data.

Available reports allow you to easily identify:
• What percentage of forecast combinations have had outliers found
• The actual number of combinations where outliers were detected and smoothed
• Average number of outliers found per combinations
Pre-defined layouts for viewing outliers

• Bookings Forecast Outlier Analysis
• Bookings Forecast Outlier Details
• Shipments Forecast Outlier Analysis
• Shipments Forecast Outlier Details
In addition, any table or graph showing historical demand can easily be augmented by adding the
measures showing outlier values to better understand how historical demand was modified during
the forecast.

This slide shows example data, with weekly dates as column headers and item measures, including
Shipments Forecast Outlier Values, as rows.


20 minutes Practice
50 minutes Total

•View a forecast decomposed to causal factors and forecasting methods.
•Use the demand simulation capabilities to analyze various what if scenarios.

This topic discusses analyzing forecast decomposition.

Most planning applications provide the forecast as a single value. This value is critical in driving
demand planning and other processes but provides no insight as to how that value was reached
and what makes up that value. Forecast Decomposition provides substantial insights on how the
forecast was generated. It exposes the varying components that come together into a single
forecast.
Method forecast decomposition shows the individual forecasting method that generated the
forecast.
Causal forecast decomposition displays the key components of each of these methods.

Without decomposition, you have the ability view the forecasting methods as described earlier.
To view additional information including the weights associated with each method and each
method’s forecast select the “Include details of forecast methods” option in the Details section of
dialogue when you run the plan.
Once active you can view the final combined forecast side by side with the individual method’s
forecast. You can then determine which forecasting methods better meet your expectations and
can choose to disable forecasting methods which you do not find appropriate.
In the same view you can see the weights assigned to each forecast method and understand how
the combined forecast was generated.
Note that forecasting methods with no forecast and no weight were not in use for the specific
forecast combination you are viewing.
While it is possible to view forecast decomposition results above the forecast combination level,
since different combinations can receive forecast from a different mix of methods it is not
recommended.

Using the first Organization (EX9:003), Item (AS35001), and Time Period (2019-01-21) as an
example:
The Modified Ridge Regression method forecasted 1,835 and was assigned a weight of 3% so
the contribution to the total forecast is 1,835 multiplied by 0.03 or 55.
The Regression method forecasted 1,719 and was assigned a weight of 52% so the contribution to
the total forecast is 1,719 multiplied by 0. 52 or 893.
The Transformation Regression method forecasted 1,867 and was assigned a weight of 45% so
the contribution to the total forecast is 1,867 multiplied by 0.45 or 840.
The total Shipments Forecast of 1,788 is calculated by adding together the contributions from
each of the methods (55 + 893 + 840).

This slide shows a graph of the Decomposed Shipments Forecast.

Causal decomposition provides insights into what contributed to a specific forecast method’s
forecast. Forecast can be composed of various factors including but not limited to seasonality,
holidays and price. This capability actually breaks down the forecast method’s forecast into
subcomponents which together add up to the total forecast.
The method with which the demand forecast is broken down into components is driven by a
grouping of causal factors called Decomposition Groups. We discuss how to view and configure
decomposition groups in a later lesson, but you can simply think of them as a definition of what you
would like to see your forecast broken down into. If you want the forecast broken down into smaller
blocks you can configure smaller decomposition groups.
To view causal decomposition information select the “Include details of causal factors” option when
you run the plan.

This screen shows a bar graph of the causal factors.

When using forecast decomposition you need to remember it is an opt-in type of activity. When
running a plan you need to choose to enable these settings. Enabling decomposition does increase
plan runtime and based on plan size may not be advisable for every run.
The perfect place for decomposition is when conducting forecast simulations. These simulations are
typically performed on a subset of the plan and as such any incremental addition to runtime is
mitigated. The focused nature of simulation is also a good fit for decomposition as you can focus on
a specific part of the plan to analyze how different forecasting methods and decomposition groups
behave.
Do note that the results of forecast decomposition are stored in two additional dimensions beyond
the typical demand planning dimensions of product, organization, customer, demand class, and time.
Demand Forecast Method dimension contains the various forecasting methods used. Any view
pertaining to the different methods forecast should include this dimension. Similarly causal
decomposition is stored using both Demand Forecast Method and Decomposition Group. When
viewing causal decomposition make sure to include these dimensions.

In this practice, you will learn how to analyze forecast methods, analyze forecast levels, identify and
view outliers, and analyze forecast decomposition.

In this practice, you will learn how to analyze forecast methods, analyze forecast levels, identify and
view outliers, and analyze forecast decomposition.

This topic discusses simulating forecast scenarios.

When a plan is run, a demand forecast is typically generated for the entire population of the plan;
all products and organizations in the plan with relevant demand data will get a forecast. This
process, while comprehensive, does take time. There are situations when you want quick feedback
as to how changing a specific input will impact the forecast. This change could include restatement
of historical demand, changes in past or future values of a causal factor, or modification to the
forecasting profile itself.
Simulation enables this quick turnaround and quick refresh of the forecast. Simulation is executed
directly from your plan in a table or graph. You click on Simulate demand to launch the Simulate
Demand screen.
Note that when executing a forecast in simulation, the forecast may be assigned different output
measures. This capability allows you to view the results of your complete plan run side by side with
simulation results by having each be written into a different output measure.
The simulate demand screen allows you to enter values for up to six output measures. When
populated the simulation will write to these measures instead of the measures the complete plan
forecast would write to. Typically you may wish to only modify the Forecast Measure setting to
control where the forecast is written to and not alter the other settings which write out forecast level,
methods, and decomposition information.

When executing a simulation you pick the context for which it will be executed. It can be executed
on
• table or graph which will generate a forecast based on the population of the table and graph
(respecting selector tool filter)
• you may choose pivot filter which will apply your selector tool filter plus any pivot table filter
• you can also choose Selected Member which will filter the simulation to only execute on the
actual table or graph member you have selected (plus any other filters for pivot or selector tool)
All selections are valid for different use cases but remember that for fastest results you want the
most specific filter applied.
Once you choose to run the simulation the demand forecast process will be initiated on the
simulation’s population.
Due to the rapid execution times and reduced population, simulation is an excellent way to call
forecast decomposition.
Simulation is also the best way to quickly create new forecasting profiles, modify some of their
definitions and view the output side by side with established forecasting profiles. If the new results
look like an improvement you can then modify the established forecasting profiles as needed.

Simulation provides you with an easy way to view the results of different scenarios side by side. To
accomplish this you need to ensure that your scenarios have a different output measure. You can
do this by modifying the output measure each time you run a simulation or create several profiles
you use for simulation purposes and execute each scenario using a different profile.
As part of Demand Planning two sets of output measures have been created. The forecast output
measures as “Simulation 1” and “Simulation 2” and other output measures begin with the word
“Simulation”. You can create additional measures based on these measures to support additional
scenarios.
Note that if multiple users are conducting what if simulations using the same forecasting profiles
and modifying the profile, each user’s changes can impact other users. It may be best for different
users who are running simulations to each have their own forecasting profile.


20 minutes Practice
80 minutes Total

In this lesson we will review the key concepts of creating a demand plan and focus on areas critical
to the configuration.
We will then transition to creating and manipulating forecasting profiles. After the lesson you should
be comfortable viewing and creating forecasting profiles and understand the level at which the
forecast is generated.
You will be exposed to causal factors and will be able to modify an existing causal factor or add a
new one.
Finally, you will be able to view the various parameters for a forecasting profile and modify them.

This topic discusses defining a Demand Plan.

Plan Horizon Days
Specify the plan horizon in days. The amount of future data available for review as well as the
forecast horizon is driven by this parameter.
Forecasting Calendar
The calendar used for forecasting.
The calendar must be specified in the selected dimension catalog. This default catalog can be
maintained by using the Configure Planning Analytics task. Forecasting Calendar allows for
selection of Manufacturing, Fiscal, and Gregorian calendar types. The Gregorian calendar is
generated in VCP and does not have a source system instance code.
It is recommended you pick a calendar which has the time aggregation you wish to forecast at.
Forecasting Time Level
The time aggregation level used for forecasting.
Time levels vary as per the selected Forecasting Calendar. For example, Forecasting Time Levels
for a Manufacturing calendar are Day, Week, and Period.
When forecast is generated the underlying demand data will be aggregated to this level. Forecast
generated at daily level will have different results than one generated at a monthly level. When
deciding which level to choose think of what sort of patterns you want the engine to look for. If the
pattern of demand within the week is critical to the business then daily aggregation is likely the right
choice. If the forecast will only be viewed and used in monthly aggregation then weekly or monthly
may be a better choice.

Measure Catalog
A flexible way to group multiple sets of measures for use in different plans. By enabling only those
measures that are needed for any specific plan, users will be able to do a focused analysis with
improved performance.
Measure catalogs can be maintained by using the Configure Planning Analytics task.
Note that any measures which you wish to view on screen, or that are used by the forecasting
profile you will pick in your plan, should be included in the measure catalog. This includes but is not
limited to historical demand, any measures used as causal factors and any of the forecast profile’s
output measures.
Also note that if a measure has a complex formula where it refers to other measures, those
measures should be included in the plan catalog as well.

You may not need to have plan data stored at the daily level if your analysis is on the demand
plan at weekly or higher levels. The “Planning Time Level” plan option in the scope tab
determines the time level at which the plan data is stored.
The list of values available for the “Planning Time Level” option are based on the “Planning
Calendar” option selection. Only time levels relevant to the selected planning calendar will be
available for selection for Planning Time Level. For example, if you have chosen “Gregorian
Calendar” as the Planning Calendar, then only “Day” and “Month” levels will be available for
selection for “Planning Time Level.”
When you define a demand plan using this feature at an aggregate time level, such as
Gregorian Month, data volume is reduced by 30 times compared to a demand plan defined at
lowest day level. Less data volume improves application performance across the board (Pivot
tables, Plan Run, Data Load, Publish Plan, Plan Archival…for example).
The “Forecasting Time Level” plan option has been moved from the Scope tab to the Demand
tab. The selections available for the “Forecasting Time Level” option will be limited to the
selected planning time level and any parent levels above it in the selected planning calendar.
For example, if “Month” level in the “Gregorian” planning calendar is selected for planning time
level, then the Forecasting Time Level plan option is limited to Month, Quarter, and Year.

For each plan, you need to define the forecasting profiles that will be available for users to choose
when running the plan.
By default each Forecasting Profile applies to the entire scope of the plan. To limit a Forecasting
Profile to a subset of the full plan scope, you can select an Analysis Set. The member filter in the
Analysis Set is used to identify the subset of the plan that the Forecasting Profile applies to.
Analysis Set is an optional selection.
Once you choose the profiles, it is important to define the amount of historical data which will be
used during the forecasting process. The number of time buckets entered in the Historical Buckets
field will be used by the statistical demand forecasting process to define the amount of historical
data used.
Additional information in the screen includes History End Date, which is driven off plan definitions
and current date. This informational field will change as time passes and you load more data into
the plan.
History Start Date is calculated by subtracting Historical Buckets from History End Date.
The Forecast Buckets field provides users with a quick reminder of how far into the future a
demand forecast will be generated, and is driven by the planning horizon set for the plan. There is
no independent way to control the forecast horizon. It is always driven by plan definitions to ensure
forecast availability for the entire plan horizon.
The Locked Forecast Periods field is used when you want to retain the existing forecast values for
the initial time periods in the forecast.
Historical Periods, Forecast Buckets, and Locked Forecast Periods are represented in the
Forecasting Time Level selected for the Plan. For example, if the Forecasting Time Level is “Day”
then these values would all be in days.

The feature Forecast and Consume Internal Orders is for use with internal orders, otherwise known as
transfer orders from the source organization to the destination organization. Demand management can
now use transfer order history to create future forecasts of transfers based on the transfer order history.
Supply planning can consume the transfer order forecasts with actual transfers.
To use the option, check the “Include transfer orders” check box in the Advanced Options on the
Demand tab. This option is available for Demand plans, and Demand & Supply plans. It is not
currently available for Planning Central Cloud.
Additional information is available in the Forecast and Consume Internal Orders feature in the
Planning Foundation TOI.

When should a demand plan be run? The answer is not clear cut, but you want to ensure that it is
run as part of an established planning cycle. For most companies, this will mean running the plan
once a week after new bookings and shipments data has become available.
You may run a demand plan daily or even several times a day, but this may not have any
significant benefits. The incremental data associated with a day will have a small impact on the
forecast and may introduce noise in the supply chain.
Run a demand plan if major changes have been made to historical data, causal factors, or new
products have been added.
You can also run simulations to quickly review the impact of changes without executing a full plan
run.
When a statistical forecast is available, users can review and modify the forecast. It is strongly
recommended that before overriding the forecast, planners review historical data, if possible one to
two years worth, but at least six months. Causal factors should also be reviewed to determine if
there is a reason forecast is not meeting their expectations. In cases where the issue cannot be
addressed or the planner has additional business intelligence, the planner then modifies the
forecasting profile’s definitions or override the forecast directly.
Note that planner forecast overrides will remain in place after the next plan runs, and will take
precedence.

As part of running the plan, you may select whether, and what data elements will be refreshed.
The first time a plan is run, Refresh with Current Data must be selected. This option will refresh
historical data, import sales orders, as well as advance the plan start date to align with current date.
Running a plan while selecting “Do not refresh with current data” will do the opposite. It will call the
forecasting engine, though without advancing the plan date or modifying historical data. This sort of
run may be useful if reforecasting item-organizations as an ad hoc activity within the planning cycle.
Finally, the ‘Selected current data’ option allows users to pick the type of data that is being
refreshed. This option is mostly of use when running supply or integrated demand and supply
plans.

Under Demand Plan Run Options, select which forecasting profiles will be executed as part of a
plan.
The best practice is to define only the profiles that are relevant to the plan in Plan Options. As such,
there should be no excess selections when running the plan.
In almost all cases, when running a demand plan, you will want at least one forecasting profile to be
selected. If no forecasting profile is selected plan run can still refresh data but no new forecast will
be generated.

This topic discusses configuring forecasting profiles.

A forecasting profile is a collection of definitions used during the demand forecast generation
process. Each profile includes the definitions of the forecasting methods used and at what level
demand data is aggregated. The profile also includes the causal factors used to explain variations
in demand as well as the groups they are assigned to for decomposition purposes.
This interface also includes a comprehensive list of the parameters used as part of the demand
forecasting process and enables you to modify them as most appropriate for your business use
case.
To reach this interface, log into Demand Planning or Integrated Demand and Supply Planning work
areas. Open the panel drawer by clicking on Tasks, scroll down and click on Manage Forecasting
Profiles.

After clicking Manage Forecasting profiles the screen will show you a list of the forecasting profiles
which exist in your Demand Planning system.
In this release we have two pre-defined forecasting profiles:
Forecast Bookings
Forecast Shipments.
You can not edit the definitions of these profiles but they can serve as a basis (using duplicate) for
creating your own editable forecasting profiles.
You can create a profile from scratch, but for best results it is recommended an existing profile be
duplicated and the new profile then modified.
Non-pre-defined profiles can be deleted but only if it is not associated with any plan. If you click on
the In Plans field for the profile you will be shown any plan the profile is associated with. You will
need to go to each listed plan’s plan definitions and remove the forecasting profile in the plan
definitions screen.

When creating or editing a forecast profile the top of the screen will contain general information
regarding the profile while the three tabs below contain additional information which will be
discussed later in this lesson.
Profile name is the unique name given to the profile, while description should contain a short
paragraph to enable planners to better understand what differentiates this profile from others when
they are choosing which profile to use.
Forecasting table defines the data aggregation levels used in forecasting – discussed later but
also impacts the input and output measures available for selection.
Input Measure is critically important. The data in this measure will be used as the historical
demand basis for your forecast.
Output Measure determines into what measure the forecast will be written. Note that demand
forecast contains over ten output measures, these are used to store not only the forecast but other
pieces of information including metrics and decomposition information. Instead of needing to enter
a measure for each of these outputs you enter a single measure into which the actual forecast is
written. The system will automatically add additional measures to accept the additional information.
The automatically added measures will be prefixed with the name of the chosen output measure.
For example for an output measure called “Consumption Forecast” the measure to store forecast
MAPE values will be created and named “Consumption Forecast MAPE”.
The dynamic creation of output measures will occur once per use of a chosen output measure. If
the same measure is used in multiple profile the required output measure will exist after the first
time it is used.

Measure Catalog contains a drop down list with all available measure catalogs. Check any
measure catalog you want the input and output measures of the profile to be added to. This will
help ensure that any newly generated measures are associated with the measure catalog you are
using for a plan.

This topic discusses defining forecast levels.

Demand forecast is generated at an aggregated level of historical demand. Historical demand
typically is stored at an intersection of product, organization, demand class, customer and day. It is
very unlikely that you would want to generate statistical forecast at this low level. Instead you would
want the demand data to be aggregated to a business relevant level and analysis and forecast
done there. For example, the most common level at which a Demand Planner wants to forecast at
is product and organization. The reason for this is that a chief consumer of demand planning-
supply planning consumes and executes the forecast at this level.
While you have a level you want to forecast at, there are times where forecast at this level will not
be possible. Data may be insufficient or may have poor quality. In these instances you will get a
better forecast by generating a forecast at a more aggregate level, and then allocating it down to
the problematic areas. Aggregate demand tends to be more robust and smooth and while you may
lose some more granular information, the fact that forecast failed at a more detailed level indicates
an inability to deal with these details.
The example above shows a scenario where forecast is first attempted at Product and
Organization. For the boxes with the “check” mark, forecast succeeds there. In cases marked with
an “x” forecast fails and is then attempted at Product and Line of Business. From there forecast is
attempted at Product Family and Line of Business and finally it goes up to Product Family.

The table which drives the data aggregations used during the demand forecast process is entered
in the Forecasting Table parameter. The levels in the table control data aggregation and the
measures included impact which input and output measures you can choose.
Note that currently forecast aggregation is limited to two dimensions. One is based on either
Product or Bill of Material dimensions while the other can be Organization, Customer or Demand
Class.
For sample table see the pre-defined tables Forecast Bookings Definitions and Forecast Shipments
Definitions. On screen you can see the level layout in Forecast Bookings Definitions. The levels
from innermost to outermost are Product, Organization, Category Level , Legal Entity and Category
Level 2.
Based on these table levels the four forecast levels are constructed as seen here.
It is recommended to build your Forecasting Table in a similar manner. Stick to 2 hierarchies and
have the lower levels be the innermost levels in the layout. The level pairs will begin with the two
innermost levels for each dimension. Additional levels are then added based on the order.
If the table you have defined, has more than two dimensions or the level order is not from
lowest(innermost) to highest (outer) then automated logic will create the aggregations.

This topic discusses configuring causal factors.

Causal factors enable several forecasting methods to understand the variation in historical demand
and produce a highly accurate and adoptive forecast. Demand planning comes with a large number
of predefined causal factors to meet the most common demand planning needs and allows user-
defined causal factors to be added. Pre-defined and user-defined causal factors are all based on
measures, so it is quite easy to view and modify a causal factor’s information in tables.
Causal factors are the best way for a business to add information that they know drives demand
into the forecasting process and thereby improve forecast results and accuracy.

The simplest way to think of decomposition groups is as a container for the measures we use as
causal factors. These groups allow you to organize measures which will have similar impacts and
effects on the forecast together. These definitions are also used when the forecast is decomposed
into causal factors, when using the forecast decomposition run plan option.
For your forecasting profiles, you can add or delete decomposition groups. You can also toggle
whether they are on or off. Note that toggling a group on or off will enable or disable all causal
factors associated with that group.
You can click on the arrow next to a group to expand it and view and causal factors (measures)
already in the group. Clicking edit will open a separate screen where you can add or remove causal
factors from the group.

Once you have selected which causal factors are part of a decomposition group you can configure
specific settings for the causal factor.
Short assigns this causal factor for the models which use a limited set of causal factors and are not
efficient at determining which causal factors are useful and which are unnecessary. These models
include Regression and Winters. Most of your causal factors will be set to Yes for short.
Long assigns this causal factor for the models which use an extended set of causal factors and are
good at determining which causal factors are useful and which are unnecessary. These models
include Monte Carlo Regression.
Multiplicative assigns the causal factor for use in the Dual Group Multiplicative forecasting method.
Non-Seasonal assigns the causal factor for use by autoregressive models which try to detect
seasonal and repeating patterns automatically. Only causals that do not occur on the same date or
with a fixed lag should be enabled here.
Fill missing controls whether 0 values for this causal factor will be replaced by another value. This
should only be enabled for causal factors which should always have values, for example price. A
price of 0 is typically driven by data issue and you want the forecast process to interpolate what
price was during periods where it is missing.

This topic discusses configuring forecasting parameters.

Forecasting parameters control the various aspects how the forecasting methods treat demand
data. These parameters control how missing values are handled, outlier and regime change
detection as well determining if a forecasting method did a good job understanding history and
generating a forecast (validation). The parameters also affect when models specific to sparse
demand are used.
All parameters come with default settings which you can modify based on business requirements.
All parameters tied to time periods are in days, with the parameter being adjusted automatically in
cases where forecast is in weeks or months. For example the parameter FitTestPeriod which
controls how much of history is used for forecast method validation has a default of 182. If
generating a forecast with weekly aggregation this would get automatically adjusted to 26.
The 12 parameters you see on the screen are the ones which are most frequently relevant to
impacting a forecast. You should review these first. If you want to review other parameters click
Add and you will see all other available parameters listed. If you add a parameter it will then be
shown in the parameter list and you can modify it’s value.
For a brief description of each parameter see the description field.

Please take the time to review the description of each parameter for a better understanding of it’s
function. Here we will highlight five parameters which may be of specific interest.
DetectOutliers controls whether exceptional demand whether low or high may be smoothed by a
forecasting method. In cases where you believe the extreme demand is a key part of the demand
pattern you may wish to disable this parameter.
RemoveExtremeOutliers will smooth any extreme values prior to any forecasting method
attempting to forecast them. This should be used if you believe extreme values are rare and may be
due to data errors, or if you want a very smooth forecast.
FitValidationSensitivity may be the most important parameter, it controls how strict the validation
applied to the forecasting methods is. If you determine that forecast is failing at the desired forecast
level increasing this value will help with this issue. You rarely want to reduce this parameter below
.35 (very tight validation) and only in special cases should it be set to more than 1 (fairly loose
validation).
MetricsPeriod- When relying on engine generated MAPE, MAD and Bias the amount of history
used to generated these metrics is controlled by this parameter. For metrics more focused on
recent history reduce this amount.
PeriodsUntilInactive- Prior to forecast generation, the system determines which combinations
should receive a forecast. Combinations which have not had demand for a long period of time are
typically set to inactive. If you want combinations to remain active longer, increase this parameter
while if you want combinations to become inactive more quickly (often the case) reduce to 90 or 60.

This topic discusses troubleshooting concepts.

In cases where the forecast is not capturing seasonality well, you have several areas to review.
Check the amount of history associated with the forecasting profile. To capture yearly seasonality
well, you need at least a year of historical demand.
Exponential smoothing models, typically do not capture seasonality well. You may consider
disabling these models and analyzing the results.
Finally you want to ensure that the data granularity selected in the demand plan is granular enough
to capture the seasonality. If you execute a forecast at a monthly level, then weekly and in-month
seasonality can not be captured.

It is common for some combinations to get forecasted above the first attempted level. In cases
where this aggregation happens very frequently this may indicate issues with some configurations.
Review the history length for the forecasting profile as well as the availability of demand for your
plan. Insufficient demand history can cause forecast to fail and aggregation to occur.
You also want to ensure a large number of forecasting methods are enabled; if you’ve disabled
most forecasting methods, failure at the lower data aggregations is more likely.
Finally the sensitivity of the most common validation is controlled via parameter
FitValidationSensitivity. Increasing this parameter will help forecast to succeed at lower level.

In this demonstration, you will learn how to create a demand plan and a forecasting profile.

In this practice, you will learn how to review a demand plan and a forecasting profile.


25 minutes Practice
65 minutes Total

In this lesson, we will learn about various aspects related to Configure-to-Order products and their
forecasting using Oracle Demand Management Cloud. The different terminology that is used
through out the lesson will also be discussed. We will also discuss about the set up required for
CTO modeling and collect the data for forecasting and dependent demand calculations. Finally we
will review how to view and adjust the forecast to improve the option forecasts.

This topic discusses utilizing component hierarchies.

Configure-to-Order system allows the customers to select the base product at the very moment of
ordering and then configure the different features of that product from the different available options.
The various options or components are manufactured to stock and based on the customer order,
the end product is configured to order.
The classic example of Configure-to-Order products is Laptops, where manufacturers make
different components to stock. For example, Hard Disk, Monitor, RAM, Processor, and so on are
make-to-stock components. Customers can select the various component options and configure the
model of the laptop based on their requirements while ordering.
Planning (the) demands for configure to order products imposes certain challenges. A customer's
selections of the components of the product need to be anticipated to ensure the correct mix of
components is available. Oracle Demand Management Cloud provides the capability to learn from
historical trends in component mix when generating a forecast. Since the customer gets the ability
to configure the end-product, the demand of its components becomes dependent on the end-
product. Sometimes various components are sold individually and not as a part of assembly in an
end product; components may have independent demand too.

It is important to understand the terminologies used it Oracle Demand Management Cloud for
forecasting Configure-to-Order products.
The end-product that is ordered by customer is called a Model and it can be configured based on
the requirement given by customer.
A Model can be configured using different components and some of the components can be
optional, and you can have different options to choose from – such components are called Optional
Components.
In the configuration you may have some components which are standard and need to be there in
end product – such components are called Mandatory Components.
We also group different components with same features under Option Class.
For a laptop, the power cord would be a mandatory component. An optional component might be a
touch screen.
There could an Option Class Hard Drives with options on the amount of storage, and an Option
Class Monitors which allow the user to pick their preferred monitor type.

Finally different options that are configured for a particular Model, and their relationship, can be
represented in a structure form called Bill of Material.
Using Planning Percentage in any Bill-of-Material, we can define the quantity of different options
that will be used to configure the end-product. In the given example if the Model forecast is 100 and
its option 1, 2, and 3 have different planning percentages as 20%, 100% and 80% respectively; the
dependent forecast:
• Option 1 will be = 100 * 20% = 20
• Option 2 will be = 100 * 100% =100
• Option 3 will be = 100 * 80% = 80
In order to forecast the Configure-to-Order products in Oracle Demand Management Cloud, we
need to set up the Item in Product Information Management (PIM).
The Item Attributes for an Item that are relevant for Configure-to-Order models are Model, Option
Class and Option. This needs to be set up as Structure Item Type in Item Structure.
Another important setting that needs to be defined is for Manufacturing in Item Organization
under the same Specifications tab. There is a parameter for Forecast Control and that needs to
be set up as Consume then Explode for enabling the explosion of dependent forecast for options
in Demand Management Cloud.
Note: In addition to “Item” or “Item/Organization”, you now have the option of selecting
“Item/Organization/Demand Class”.
Information on PIM is available on the Oracle documentation site: Product Master Data
Management.

This slide shows the screen selections to set up Structure Item Type.

In the Item Structure for the model and its components, the component Quantity and Planning
Percentage is specified. Planning Percentage is used to arrive at the correct production forecast
quantities for the respective components while exploding CTO model forecasts. Oracle Demand
Management Cloud supports a multi level Bill of Material.
Please note that the screen shown here is for illustration purposes only and may differ from the
actual product.

In order to plan configure-to-order products and their options in demand management, you should
collect their shipment and or booking history. The collections user interface provides two
checkboxes in the Additional Options section to collect the option history: one for bookings and the
other for shipments.
If selected, the collections process reviews the Bill of Material in PIM and creates the Bill-of-Material
(aka BOM) structures for Demand Planning.
You should only select the demand stream you wish to drive your CTO process, there is little benefit
in selecting both shipments and bookings and it will add processing time.

This topic discusses calculating dependent demands.

Consider a Configure-to-Order model consisting of Option Class A and Option Class B. Both
Option Classes have two options under them. Forecast control for the model and all components is
set to Consume then Explode.
The independent demand for Model is 1000 units. The Existing planning percentage for Option
Class A and Option Class B are 100% and 80% respectively. Also the quantity used to make one
unit of the model is 1 for both Option Classes.
Dependent Demand for Option Class A will be (Demand for Model * Usage * Planning Percentage) :
1000 * 1 * 100% = 1000 units.
Similarly Dependent Demand for Option Class B will be 1000 * 1 * 80% = 800 units.
In the same way, dependent demand for Option 1 will be (Demand for Option Class A * Usage *
Planning Percentage) 1000 * 2 * 60% = 1200 units.
And the dependent demand for Option 2 will be 1000 * 1 * 40% = 400 units.
Also the dependent demand for Option 3 will be (Demand for Option Class B * Usage * Planning
Percentage) 800 * 1 * 20% = 160 units.
And the dependent demand for Option 4 will be (Demand for Option Class B * Usage * Planning
Percentage) 800 * 1 * 80% = 640 units.

In order to view configure-to-order products and their options within demand management,
the Include dependent demand option should be checked in advanced options in Plan
Options. There are three additional parameters that control the planning percent history
calculation. The first parameter controls the history periods (number of days) to use, the
second controls the measure to use and the third controls the aggregation level to use to
roll up the measure and calculate the planning percentage history.
Please note here that Attach Rate and Planning Percentage convey the same meaning
and can be interchangeably used.
The configure to order process uses planning percentages to explode independent demand
down to the different levels of the bill of material (BOM). There are two planning
percentages available. Historical planning percentage is calculated based on the rate
between historical independent demand of the model and the dependent demand of the
option. The existing planning percentage is based on user entered information in PIM.
Planning Percentage History Periods control the length of history which will be used
when calculating historical planning percentages.
Planning Percentage History Calculation Measure controls the measure to use to
calculate the planning percentage history. Currently the measures available for calculating
planning percentages are limited to Option Shipments History and Options Bookings History
only. Either of them can be selected from the drop down.

Planning Percentage Calculation Level controls the aggregation level of data used when
calculating historical planning percentages.
Independent and dependent demand will be aggregated to the selected level and results
will be available for all underlying combinations.

In Demand Management Cloud, there are two types of Planning Percentages: Existing and
History, where Existing is user defined and History is calculated by system.
The user can enter the Planning Percentage while creating the Item in PIM and, by default, that
value will be used for calculating the dependent demand for options. The demand planning process
also has the capability to calculate Planning Percentages based on actual historical usage of
options, as explained on the previous slide. This provides a more reactive and often more accurate
result.
Regardless of the type of planning percentage, the user can also apply an override to a specific
planning percentage based on their own insights and knowledge.

Consider an example where Planning Percentage is set to History. User can toggle between
History and Existing while working on worksheet by adjusting the Planning Percentage Type.
Also assume that historical measure is Shipment History, calculation level is set to Item and
number of history periods is set to 30.
If the shipment history for parent at item level for past 30 days is 650 and for child is 580; the
planning percentage for child will be 580 / 650 which comes close to 89%.

This topic discusses analyzing the bill-of-materials view.

In Demand Management there are two pre-defined tables to view the finished product and
underlying BOM structure in the context of customer and organization.
The table focuses on showing Final Shipments Forecast, and the underlying forecast for option
classes and options. It also enables user to select Planning Percent Type from either Existing or
History.
Finally any changes made to the forecast, Planning Percent Type and Planning Percent will be
propagated throughout the bill of material in real time.

Here the table focuses on showing Final Shipments Forecast, and the underlying forecast for option
classes and options. It also enables user to select Planning Percent Type from either Existing or
History.
Finally any changes made to the forecast, Planning Percent Type and Planning Percent will be
propagated throughout the bill of material in real time.

When multiple base models are chosen for display in a table, they appear sequentially in the first
column of the table. The vertical scroll bar is used to scroll through the data.
Now, the Filter Tables by Configure to Order Model feature allows you to page within a table from one
base model and its options to another base model and its options.
To filter tables by configure to order models, select the Set Page Filter to Base Model option under the
View menu of the toolbar.
This places the base models on the page filter of the table. The base model in the page filter is still
visible in the table along with its option classes and options.
Using the page filter, you can page through the base models one at a time by selecting from the list of
base models in the page filter.
Save Layout can be used to retain this setting.

In this practice, you will learn how to collect historical data for options, define the CTO parameter for
a demand plan, and analyze the bill-of-materials view.
Note to instructor: Please demonstrate these tasks prior to practice.


In order to see the option forecast in Demand Management the Forecast Control setting in Item
Specifications for Manufacturing should be set to Consume then Explode. If it is not set to this value,
then dependent demand for corresponding option will not be exploded in Demand Management.
Also while defining the CTO options for Plan run, ensure to check Include dependent demand in
order to explode demand for options.

This slide poses questions for discussion and review of concepts.
a. Planning Percent Type

b. The forecasts of the Option Classes and Options


0 minutes Practice
25 minutes Total

In this lesson, we will learn about integration of Demand Management with different systems like
External Source System, Sales and Operation Planning Cloud, Supply Planning Cloud, and
Planning Central Cloud.

This topic discusses demand management in Oracle value chain planning.

The focus of every business today is on its customers and it is critical to understand their
requirements in order to remain profitable and sustain in competitive world. Oracle Demand
Management Cloud processes demand signals from various sources and predicts the optimized
customer demand. This projection of demand is then used as a starting point for supply planning
and sales & operations planning processes.
Then, using the Demand Planning forecast, various stakeholders from marketing, sales, and
production planning collaborate in Oracle Sales & Operation Planning Cloud to come up with
consensus forecast. This consensus and unconstrained forecast is the input for Oracle Supply
Planning Cloud which considers all the constraints to generate a supply plan.

This topic discusses the integration with internal and external source systems.

History is the key input for Oracle Demand Management Cloud. User can collect the historical data
from Oracle source system as well as from any other external system. There are two seeded
measures available wherein user can collect the historical data: Shipment History and Booking
History. User can define which of the seeded bookings and shipments measures will be collected
into the commonly used Bookings History and Shipments History measures. Bookings History and
Shipment History are referenced in seeded forecast generation process and by a variety of other
measures. In the profile option, you should choose the measures which best reflect the demand
stream you want to drive your demand planning process.
• Bookings History: Booked Item by Booked Date
• Bookings History: Booked Item by Promised Date
• Bookings History: Booked Item by Requested Date
• Bookings History: Requested Item by Booked Date
• Shipments History: Requested Item by Shipped Date
• Shipments History: Shipped Item by Promised Date
• Shipments History: Shipped Item by Requested Date
• Shipments History: Shipped Item by Shipped Date
• Bookings History: Booked Item by Scheduled Ship Date
• Shipments History: Shipped Item by Scheduled Ship Date

The historical data is a plan input and can be collected from flat files. There are templates available
in Oracle Help Center website for loading the data into Shipment History or Booking History
Measures. The Load Planning Data from Files UI can be used to select the source system and to
load the files from those external systems into Demand Management Cloud through a scheduled
process. For additional information regarding loading data, refer to Oracle Help Center
(https://docs.oracle.com/en/).

You can organize your customers in order to view data by individual key customers, and by
grouped non-key customers. This allows you to focus your analysis and issue resolution on the
most important customers. By default all customers will be considered non-key and aggregated to
“All Other” unless you identify the Key Customers in the predefined Supply Chain Planning Key
Customer Options template. The customers not identified in the uploaded key customer template
are grouped into an All Other category. When analyzing forecasts and other data, the key
customers and the All Other group are displayed.
It’s important that the data used for planning is accurate and organized for efficient business
analysis. Sometimes, only a small fraction of the customers of an enterprise are important for
supply chain planning processes.
The Load Planning Data from Files UI can be used to select the source system and to load the
Key Customer Option file into Demand Management Cloud through a scheduled process. For
additional information regarding loading data, refer to Oracle Help Center
(https://docs.oracle.com/en/).

Information on extracting Customers from E-Business Suite
To extract the data from your Oracle E-Business Suite source system, run the Extract Data for
Oracle Supply Chain Planning Cloud process.
Consider the following conditions for the MSD_DEM_CUSTOMER attribute when you run the
process:
• If the MSD_DEM_CUSTOMER_ATTRIBUTE is set to null, then all sites are extracted.
• If the MSD_DEM_CUSTOMER_ATTRIBUTE is set to none, then all records are aggregated
to Default Customer Site.
• If the MSD_DEM_CUSTOMER_ATTRIBUTE is set to a valid customer attribute, then all
sites are extracted.
The extracted data is stored in a file in the zipped file format in the middle tier of your source
system. Steps for this are:
1. Download the Key Customer Options template for file-based data loads
2. Enter your Key Customer data to the file.
3. Generate the CSV file.
4. Include the Key Customer Options CSV file in the EBS zipped file.
For details on preparing files for loading planning data, refer to these help topics: Loading Planning
Data from Files: Overview and Creating CSV Files Used to Load Planning Data: Procedure.

Populate the Key Customer Options Import spreadsheet. The spreadsheet has 3 tabs.
The first tab contains instructions on the template.
On the second tab, enter the name of the customer hierarchy and the hierarchy level name to be
used to identify key customers.
In this example, the hierarchy name is Customer Accounts, and the level use in identifying Key
Customers is “Customer”. All the members of that level will be considered key customers, unless
specific members are identified in the 3rd tab. The optional third tab is completed if only specific
customers are to be identified as key-accounts. (See next slide)
The Aggregation Level column on the second tab is used to specify the customer data that will be
available for plan creation. The levels are:
1 - Retain and aggregate non-key customer sites

2 - Aggregate non-key customer sites
3 - No aggregation of customer sites
Aggregation Level 1 must be used if there are new or existing plans that will not use the
Aggregate Data for Non-Key Customers feature. This will retain all customer site data for plans that
will not use this feature, and it will also aggregate the non-key customer site data for plans that will
use the feature. In other words, plans can be created with all customers aggregated or NO
customers aggregated.

Aggregation Level 2 is used to aggregate non-key customer site data when a valid hierarchy and
level name are supplied. The data for non-key customers will only be available as an aggregate of
all the non-key customer sites. However, if no hierarchy or level name are supplied for Aggregation
Level 2, then all customer site data is treated as non-key. This means the All Other customer
members by zone will be the only customer sites available.
Aggregation Level 3 can be used to turn-off the feature. It will remove aggregated non-key
customer site data, and store data for all the individual customer sites. This will invalidate
existing plans that use the Aggregate Data for Non-Key Customers feature.

The third tab is required only if specific customers are to be identified as key-accounts.
The members identified in the Level Member Name column of the 3rd tab will be considered key
customers. All other customers will be aggregated to an “All Other” member for each Zone in the
plan.
In this example, Customer1 and Customer2 are the only key-accounts in the Customer level of the
Customer Accounts hierarchy. All other members of the Customer level will be aggregated into a
member “All Other” by Zone.

You have the option to create plans with or without non-key customers aggregated. To aggregate
non-key customers for a plan, navigate to Tasks and select Manage Plans to create or edit a plan.
On the Demand tab of Plan Options, select the checkbox Aggregate non-key customer data to an
All Other level member. This will aggregate all non-key customers to an All Other member by Zone.
Non-key customers are those customers that were not identified in the Key Customer Options
template.
If you want to have all customers visible in the plan, that is no aggregation of non-key customers,
do not check the checkbox.
Additional information on the check box default settings:
• When you create or copy a plan, you select the check box when key customers have been
identified and you want the non-key customers aggregated to the All Other level member.
• For backward compatibility of existing plans, the check box inherits the state from the
existing plans.
• For copied plans, the check box inherits the state from the copied plans.
• For new plans, if the ScpKeyCustomerOptionsImportTemplate.xlsm file is used to set the
aggregation level to Level 1 (keep all customers, and also aggregate non-key customers),
or Level 2 (aggregate all non-key customers), then the check box is selected by default.

Additional information on the check box default settings:
• If the ScpKeyCustomerOptionsImportTemplate.xlsm file is used to set the aggregation level to

Level 3 (no aggregation of customers) for all plans, the following validation is run:
• If any existing plans use the aggregated customer data, there is an error in the scheduled
process. The log file contains the names of the plans that have the check box selected.
The check box must be deselected for these plans to successfully set the aggregation
level to Level 3.
• If the validation is successful, that is no plans use aggregated customer data, and the
check box is not selected for any plans, then all the existing aggregated data is
deleted and the check box is disabled.

This topic discusses integration with the sales and operation planning cloud.

The various stakeholders in Supply Chain forecasting use Demand Planning as the basis for Sales
and Operation Planning. As such, Sales and Operation Planning and Demand Management are
tightly integrated. The shared seeded measures are available in both the applications; if you adjust
any shared measure in one application, the change would reflect in other application as well. The
measures from Demand Plan can be loaded into Sales & Operation Planning.

Using Load Measures from Other Plans UI, the selected measures from any Demand plan can
be copied into a Sales & Operation Plan. This way the measures will be visible in particular Sales
and Operation Plan for collaboration. Select ‘From Plan’ as a Demand Plan and ‘To Plan’ as S&OP
Plan on this page. Also select the measures you want to load from Demand Planning to Sales and
Operation Planning. By clicking Save and Close, the selected measures from Demand Plan will be
copied to the Sales and Operation Planning Plan.

This topic discusses integration with the supply planning cloud.

Oracle Demand Management Cloud integrates with Oracle Supply Planning Cloud in order to
generate optimized supply plan by providing final forecast input.
Four different measures can be used as demand plan input for a supply plan:
1. Final Shipment Forecast
2. Approved Final Shipment Forecast
3. Final Booking Forecast
4. Approved Final Booking Forecast
For any selected Supply Plan, a Demand Plan can be selected under Organizations and
Schedules sub-tab of Supply tab. Now this Supply Plan will use the forecasting measure from
Demand Plan selected. A supply plan can get inputs from more than one demand plan; in order to
do so, a new demand plan under Demand Schedule should be added.


This slide discusses troubleshooting considerations.

This slide poses questions for discussion and review.
1. a
2. d

This slide poses additional questions for discussion and review.
3. a
4. a, b, c, d


20 minutes Practice
50 minutes Total

In this lesson, we will learn about the overview of New Product Management and how it is handled
in Oracle Demand Management Cloud.

This topic discusses an overview of new product management.

New Product management is gaining importance in modern era supply chain as companies are
having a noticeable volume of new products in their portfolio. The life cycle of products are getting
shortened, and customers are expecting new and advanced products more frequently. To remain
profitable and sustainable in the competitive market, companies are launching new products more
frequently. While on one side it is helping to satisfy the customer’s dynamic requirement, on the
other, it imposes certain challenges to manage the new products.

As there is no sales history available for new products, it is difficult to forecast them. Also unless we
perform simulation, it is difficult to determine the correct launch date and the most profitable market
to launch the new product. Moreover, in the case of new products, sending demand forecast well
ahead of time for supply planning becomes more important as the planning time for new products is
longer compared to existing products.

Oracle Demand Management Cloud offers a solution for New Product Management by enabling the
user to create a New Product. It provides the ability to specify a source product that will be used for
copying historical sales to the new product for forecast generation. It also provides the ability to
define the ‘Launch Date’ that specifies when the new product will be available for sale. Users can
also run simulations to evaluate the performance of a new product launch at a particular site, and if
that doesn’t seem correct, users can change the site or adjust the launch date.

This topic discusses managing a product launch.

There is a user interface for Manage Product Launch which can be navigated from the Actions
menu of a Table; however this menu will only be available for the Item level in the Product
Dimension. There are different fields in this user interface that are used for launching new products.
Search -The default search will be set to Source Product and Source Product will come from the
table context. This is an optional field.
Source Product - Product that is assumed to have similar selling pattern as the new product. This
is a mandatory field. [Please correct your handouts]
New Product - Product that is to be introduced. User is only allowed to use a product that is
already existing in the planning cloud.
Status - The options are:
• In Progress – This is the initial status and shows that a new relationship has been
established. Copy process invoked. Status will change to Active as soon as copy is
completed.
• Active – This status shows that the data from Source product has started being copied to
new product and copy process will occur every time new data is collected. Copy process is
currently setup and will occur every week till launch date is reached.
• Complete – This status shows that the copy process is completed and launch date for new
product has passed. After this, no copy will happen from Source product to new product.
Last Updated Date - When the relationship was setup or last updated.
Last Updated By – User who setup the relationship.

The Source Relation tab allows the user to select the source product’s population to copy data
from. The options available are:
• Available Members - This displays a list of Organizations and Customer/Sites that have
transactions with the source product in fusion planning. The list of organizations is also pre-
filtered to only display the organizations that are valid for the New Product per the item/org
relationships defined in the source. For e.g. Assume the new product ‘Hazelnut Milk’ has an
item-organization relationship defined only with DC South, DC North & DC East. The source
product ‘Vanilla Milk’ has history in DC South, DC North, DC East & DC West. The available
members screen will only display DC South, DC North & DC East. This will prevent this dialog
from creating combinations that are not valid item-organization relationships defined in the
source system. Customer and relevant sites under the customer are displayed based on
combinations available with the source product.
• Shuttles – These icons can be used to move members over to the selected members.
• Selected Members - Displays the Organizations and Customer/Sites selected.
• Insert – User can click this to populate the selections from the selector to the table below. The
combinations displayed in the below table will be the valid source combinations based on the
‘Organization’ & ‘Customer’ selections. For example, DC South ships to customer Bigmart and
DC North ships to Valuchoice. The selected members are DC South & DC North for
organizations, Bigmart & Valuchoice for customers. Clicking ‘Insert’ should only display DC
South/Bigmart & DC North/Valuchoice.

• Launch Date - A launch date can be entered at the customer level or site level. The user can
set it at the customer level and if desired can override it at the individual site level. After the
override if the user decides to re-enter at the customer level, then the value at the customer
level will be applied across all sites under the customer. Data from source to new product will
be copied every time new data is collected, the forecast engine copies updated historical data
from the source product to the target product up until the launch date. This will be an ongoing
sync process till the launch date is reached for a combination. Forecast should not be
generated prior to the launch date for the combination.

The Measures tab allows the user to select the source and target measures. The options available
are:
• Source and Target measures -Users can modify the copy settings from the Source to the
Target measure only in the Edit mode. Target measures will be restricted to only display
editable measures. Source and Target measures should have the same dimensionality and
stored level settings. During definition an error message will appear if the dimension and
stored level settings do not match.
• Factor (%) – The data of source measure will be multiplied by this factor for copying into the
target measure. User can increase or decrease the historical reference sales based on the
expected sales of the new product. For example if the Shipment History for a period of
Source Product is 500 and the factor is defined as 150%, the value of Adjusted Booking
History which is Target Measure will be 750. (Since 500 * 150% = 750)
Once the historical measure data is copied into New Product, a plan can be run to generate the
forecast.

In this practice, you will learn how to review a navigate a product launch and define the relationship
between a source product and new product.
Note to instructor: Please demonstrate this task before practice.

This slide poses questions for discussion and review.
1. d
2. a

This slide poses additional questions for discussion and review.
3. a
4. b

This topic discusses how to foresee the impact of events.

You can assess the impact of events, such as temporary price reductions and sales and marketing
tactics, on the demand forecast.
This feature provides preconfigured measures and forecasting profiles to analyze the effects of
event activity. It also provides a new decomposition group definition to help you visualize the
baseline forecast and the effects of event activity.
Within your Plan, you create a table containing the event activity measures and relevant levels, and
enter values for the event activity measures by item, customer site, organization, demand class,
and day.

Generating your forecast using an event profile and event measures, incorporates the event
activities into your demand forecast.
This will allow you to analyze the contribution that these activities make to the total forecast
resulting in:
• Improved forecast accuracy

• Better visibility to future demand increases
• Reduction in out-of-stocks
• Reduction in safety stock
• Improved customer satisfaction

There are four new measures for capturing event activity:
• Discount Percentage - The reduction from the regular price represented as a percentage.
• Discount Percentage Calculated - Discount percentage calculated from discounted price,
final price, and discount percentage measures.
• Discounted Price - Final reduced price corresponding to event activity.
• Event Type - Type of event activity, such as an advertisement or in-store display.
Discount Percentage, Discounted Price, and Event Type are all editable measures for which you
can populate values.
Discount Percentage Calculated is a calculated measure based on either the Discount Percentage
or Discounted Price.
The four new measures are grouped into a new measure group named Event Modeling.

Create a table containing the event measures, and populate values for either the Discounted Price
or Discount Percentage measure to reflect temporary reductions in price. Also populate the Event
Type measure to indicate the type of event activity. Populate values both in history, to indicate
actual event activity, and in the future, to indicated planned event activity.
The measures must be populated for:

• Item
• Customer site
• Organization
• Demand Class
• Day
Do NOT populate both the Discounted Price and Discount Percentage measures for the same item,
customer site, organization, demand class, day combination.
Populate the Discounted Price measure if you want to provide the actual reduced price (for
example, $1.99 sale price).
Populate the Discount Percentage measure if you want to provide the percentage reduction in
price (for example, 20% discount).

The valid values for the Event Type measure are:
• None
• Feature Only
• Display Only
• Feature and Display, and
• Temporary Price Reduction

In Manage Forecasting Profiles, there are two new forecasting profiles for incorporating event
activity in the forecast:
• Forecast Shipments Including Event Activity - Generate forecast based on historical shipments
and incorporating the impact of event activity.
• Forecast Bookings Including Event Activity - Generate forecast based on historical bookings
and incorporating the impact of event activity.
These are based on the existing Forecast Bookings and Forecast Shipments forecasting profiles
with the addition of causal factors for event activity.

Generate a demand forecast using either the Forecast Shipments Including Event Activity or
Forecast Bookings Including Event Activity forecasting profile.
You can generate a demand forecast using either the Run Plan or Simulate Demand actions.

This slide provides troubleshooting tips.

Do not populate both the Discounted Price and Discount Percentage measures for the same item,
customer site, organization, demand class, day combination
• Populate the Discounted Price measure if you want to provide the actual reduced price (for
example, $1.99 sale price).
• Populate the Discount Percentage measure if you want to provide the percentage reduction
in price (for example, 20% discount).
Populate values both in history and in the future.

• Populate the Discounted Price or Discount Percentage measure to reflect actual temporary
price reductions in history and planned temporary price reductions in the future.
• And populate the Event Type measure to indicate actual event activity in history and
planned event activity in the future.


Demand Management Course Rel 19C - Student Guide

Uploaded by

Copyright:

Available Formats

Demand Management Course Rel 19C - Student Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Demand Management Course Rel 19C - Student Guide

Uploaded by

Copyright:

Available Formats

Schedule: Timing Topic

05 minutes Lecture and Demonstration

Oracle Demand Management Implementation 1 - 2

Oracle Demand Management Implementation 1 - 3

Oracle Demand Management Implementation 1 - 4

Oracle Demand Management Implementation 1 - 5

Oracle SCM Cloud: Sales and Operations Planning Implementation 1 - 6

Oracle SCM Cloud: Sales and Operations Planning Implementation 1 - 7

Use a Calculated Measure Across Multiple Planning Work Areas

Monitor Planning Processes and Improve Planning Data Quality

Oracle SCM Cloud: Planning Foundation 1 - 8

Oracle Demand Management Implementation 1 -

Update Planning Supplies Using a REST Service

Update Planning Demands Using a REST Service

Oracle SCM Cloud: Planning Foundation 1 - 9

Oracle Demand Management Implementation 1 -

Oracle SCM Cloud: Sales and Operations Planning Implementation 1 - 10

Oracle Demand Management Implementation 2 - 1

Oracle Demand Management Implementation 2 - 2

Oracle Demand Management Implementation 2 - 3

Let’s re-focus on the key practices for Demand Management.

Oracle Demand Management Implementation 2 - 4

Oracle Demand Management Implementation 2 - 5

Oracle Demand Management Implementation 2 - 6

Oracle Demand Management Implementation 2 - 7

Oracle Demand Management Implementation 2 - 8

Oracle Demand Management Implementation 2 - 9

Oracle Demand Management Implementation 2 - 10

Oracle Demand Management Implementation 2 - 11

Oracle Demand Management Implementation 2 - 12

Oracle Demand Management Implementation 3 - 1

Oracle Demand Management Implementation 3 - 2

Oracle Demand Management Implementation 3 - 3

Oracle Demand Management Implementation 3 - 4

Oracle Demand Management Implementation 3 - 5

Oracle Demand Management Implementation 3 - 6

Oracle Demand Management Implementation 3 - 7

Oracle Demand Management Implementation 3 - 8

Oracle Demand Management Implementation 3 - 9

Oracle Demand Management Implementation 3 - 10

Oracle Demand Management Implementation 3 - 11

Oracle Demand Management Implementation 3 - 12

Oracle Demand Management Implementation 3 - 13

• Is available for all measure types (Numeric/Date/String)

• Covers shared measures and plan specific measures

• Covers user-defined and seeded measures

• Captures updates of the same value

• Captures all measure updates made interactively

Oracle Demand Management Implementation 3 - 14

Oracle Demand Management Implementation 3 - 15

Oracle Demand Management Implementation 3 - 16

Oracle Demand Management Implementation 3 - 17

Oracle Demand Management Implementation 3 - 18

Oracle Demand Management Implementation 4 - 1

Oracle Demand Management Implementation 4 - 2

Oracle Demand Management Implementation 4 - 3

Oracle Demand Management Implementation 4 - 4

Oracle Demand Management Implementation 4 - 5

Oracle Demand Management Implementation 4 - 6