Basics of Demand Forecasting

SK's Chpt 04 Demand Forecasting

Publish at Scribd or explore others: Academic Work demand Methods

Demantra: Analyical Engine - A deeper look - Part2

Analytical Engine's Demand planning(DP) mode run comprises of Prepossessing stage, followed by model application & testing stage. In Promotion Effectiveness(PE) mode run of engine, various promotional CFs are prepared and used before Forecast phase starts. 

Forecast Phase of Engine Run:

Pre-processing Stage:

1. Treatment of missing values.

2. Detection of intermittency.

3. Preliminary outlier and regime change detection.

4. Removal of obvious (gross) outliers.

5. Data transformation for use in specific models.

Model application & Testing Stage:

1. Checking that the number of data points exceeds at least by two the number of causal factors. This is done to ensure that, No over-fitting occurs and coefficients for all causal factors can be determined.

2. Estimation. Statistical algorithms, are implemented to data and their parameters are calculated.

3. Fit and Residuals calculation. Fit is calculated by applying an estimated model to the historical period. It reflects the ability of the model to reproduce the actual series. The deviation of fit from the actual forms the residual series. The variance of residual, along with complexity (number of estimated parameters) is utilized to compute the weights for model averaging.

4. To check the ability of a model to mimic the actual series, a Fit validation is performed, provided the nableFitValidation flag is on.In Fit validation the residuals undergo a battery of statistical tests.Forecast performs identical calculation to Fit, only for the future period, lead.

5. To perform Forecast validation, both the parameter EnableForecastValidation and the variable ValidFit have to be “True”. This is because if a model reached this stage with invalid fit, it must be running at the highest forecast level, and at this level forecast validation is disabled, allowing a somewhat more liberal treatment of models. In Forecast validation models undergo three tests:

• A test for an unusual zigzag-type jump

more details on Demantra's Engine can be found in Oracle Metalink's Documentation library for Demantra.

Demantra: Analytical Engine - A deeper look - Part1

Through this post, I would like to share some of findings about how Demantra's analytical engine works. The post is based on Demantra's documents created by Oracle and are available in Oracle Metalink for a detailed study. 

 What is Forecasting

Forecasting empowers one to predict the futuristic tendencies of supply chain, influenced by seasonal and other predictable factors. The result of forecast is a projected curve that has been smoothed to show tendencies and de-emphasize the exceptional variations.

Demantra engine is capable of multidimensional forecasting with mixed modeling techniques. It has been designed to be robust enough for handling large scale installations. It is capable of modeling hundreds of thousands of data sets with various data patterns.

Modeling is performed according to forecast tree, in which each node in the tree is defined by an item-location combination in the Enterprise Data model. Engine tries to generate forecast at lowest level of item-location combination, but in situations where due of data insufficiency's , it is unable to generate a good forecast, then it traverses the Forecast tree to higher level for generation of forecast at an aggregated level. Forecast generated at higher level is split down to lowest level, using a splitting mechanism called “proport”.

Batch verses Simulation

Engine can be executed in two modes, Batch or Simulation.

Batch Run:

• Traverses a large forecast tress, described in database. Each node in tress represents a time based data series that is subjected to forecast.

• Performs model calculation on a large subset of data series (each node of forecast tree)

• Writes the processed data series to a new forecast table in database.

• Executes a post-process procedure which updates new forecast table

Simulation Run:

• Same steps as above are performed but on a selective subset of data, as chosen by user for “what-if” kind of simulation run.

  
  

  Engine Components

  
  

  Engine consists to two components, Engine manager and Engine server. There is one instance of Engine manager and one or more instances of engine server. The engine server scans a portion of the forecast tree according to the traversal rules, and sends the output to the split mechanism. 
  The engine server receives IDs of tasks from Engine manager, which divides the forecast tree into sub-trees (tasks). The engine manager is responsible for the engine run as a whole.  

  
  

  Based on Engine settings done via Engine Administrator application, Engine managers tries to initiate an engine server on list of machines on network having engine registered and server component installed.

  
  

  Reference “Details of Engine Manager & Server”. (source: Oracle Demantra Engine Guide v.5.2.6)

  
  

  Causal Factors

  
  

  Factors which cause the deviation from a trend, are known as Causal Factors. E.g. a sales promotion, due of it’s result you expect sales to rise. On the other hand, a sales promotion by your competitor can impact your sales negatively, which also becomes a causal factor.

  
  

  Causal factors such as promotions, marketing campaigns and production stoppages are essential components when analyzing demand pattern.

  
  

  Global Causal Factors effect all the nodes of forecast tree, seasonal CFs are normally global.

  
  

  Local CFs can be different for each item-location combination.

  
  

  Event is another word for CF, it can be loaded easily with Code, value and intensity information. Event information is not necessarily required to be loaded in future.

  
  

  
  

  ............to be continued.

  
  

ASCP Data Collection: A high level overview

Process of collecting data in proper format from ERP(transactional) instance/schemas to APS(Planning) instance/schema, for easy usage by APS modules like ASCP, GOP, IO, Demantra and others. ERP stores all master data & transactional data, in respective product schemas like INV, BOM, WIP, MRP, PO etc., which is collected to MSC schema for planning applications.

Components of Collection process:
1. Refresh Snapshots: runs always only on the ERP source instance in Distributed environment
2. Planning Data Pull: Pulls data from ERP source schemas to MSC_ST% tables
3. ODS Load: Does data cleansing & manipulation, followed by loading base MSC% tables from MSC_ST%(Staging) tables

For integrated Demantra, further collection of history & related data is required to populate Demantra base tables. The processes for these collections are run from the responsibility "Demand Management System Administrator". The Standard collection option in Demantra responsibility is same as ASCP standard collection. The other collections processes are Demantra specific.

Modes of Collection:

1. Standard: Using this option, one can manually launch collection in three methods, Complete Refresh, Targeted Refresh & NetChange.
2. Continuous: this is an automated collection process, which requires minimal manual intervention and it keeps planning instance data synchronized with ERP source instances. It automatically determines which method of collection should be used.

Few notes to remember:
1. Source ERP instances can be a mixture of releases and can be a legacy instance as well
2. ASCP instance can share instance with one of the ERP instances
3. Collection is required even if APS & ERP instances reside on same instance
4. Supplies against Drop Ship are not collected, as ASCP doesn't plan for drop ship sales

Demantra S&OP(7.2.0.2) integration with EBS 11.5.10 released

Oracle has released another integration patch recently to provide seeded integrated S&OP functionality to it's existing 11.5.10 customer base. This patch builds integration between EBS 11.5.10 and Demantra 7.2.0.2 S&OP. Oracle has already released integration to 7.2 S&OP & Demand Management, with EBS R12 through 12.0.4 release. Also EBS 11.5.10 integration with Demantra DM exists already.

The new release has been named as Demantra 7.2.0.2 ( or 7.2 CU2). More details are available in Metalink note id "470574.1".

ASCP - Unconstrained Plan

Few basic characterstics can be listed as below;
An unconstrained plan:
- doesn't consider manufacturing capacities (material & resources)
- assumes infinite capacity
- results are same as traditional MRP
- simply is an statement of what all resources would be needed to meet the production schedule
- can come handy in long term decision making for resource requirement planning

Oralce's ASCP module can be used for unconstrained planning as well, unconstrained ASCP plans are usually like baby steps towards more complex, holistic, constrained & optimized planning ASCP world.

Unconstrained ASCP plans thus form an integral part of ASCP implementation, as it can be used for getting familiar with application, as well as in verifying the ASCP outcomes. You can compare the unconstrained ASCP plan recommendations with your MRP plan results and thus can validate the basic ASCP setup.

Two important aspects to be focused on while running ASCP unconstrained plan should be:
1. Try to duplicate results of legacy MRP system.
2. Increase familiarity & confidence on ASCP application.

Steps to implement an unconstrained ASCP plan:

1. Create DB link between transaction source(ERP) server and APS(Advanced Planning & Scheduling) server

2. Setup collection program

3. Run collection to copy supply chain model from source instance to APS server

4. Define an ASCP plan and setup plan options.(with no constraints)

5. Launch the plan

VERIFICATION: Unconstrained plan is designed to produce identical results as that of legacy ERP system. This becomes useful in verifying implementation and in building users confidence with the ASCP application.

Oracle Advanced Supply Chain Planning(ASCP)

ASCP module forms the core of Oracle's APS suite, with its holistic global supply & distribution planning functionalities. With ASCP you can plan simultaneously for all your manufacturing plants & distribution houses at different granularity of time in a single plan, which considers the latest demand, forecast, sourcing rules, current inventory and production levels. ASCP offers a variety of plan options and plan types, which can be used to model individual business supply chain planning needs. In general, ASCP implementations start with an initial phase of "unconstrained ASCP plans" usage. In due course of time and with planner's readiness towards understanding the inputs, setups and results, one can move forward with "constrained" ASCP plans (e.g. EDD, ECC & Optimized plans).

Why MRP isn't sufficient?
Becasue:
- It is sequential in nature
- It plans based on unconstrained production, storage & transportation capacity
- It does not optimizes the supply recommendations
- It has no decision support capabilities

Few of major features of ASCP module can be listed as:
- Global Visibility
- Rapid ROI
- Supports Centralized & Decentralized planning
- Supports mixed mode manufacturing
- Holistic Plans for high level planning & Detailed scheduling
- Finite Constraint based Planning(CBP) & Scheduling
- Optimization across multiple Objectives
- Online Replan & Simulation capabilities
- Supports Global Order Promising(GOP)

A good definition for ASCP, found in Oracle documentation:
"Oracle ASCP is a comprehensive, Internet based planning solution that can rapidly and significantly improve supply chain performance. ASCP is based on Oracles' Internet computing architecture, third generation Oracle memory based planning engine technology and proven constraint based planning & optimization technology."

For more details:
Oracle's ASCP offering page link: "http://www.oracle.com/applications/planning/SCMP.html"

How is "Demantra different from ODP" ?

Oracle has left behind ODP and have Demantra as ther future demand planning & forecasting application. Demantra has already found it's place in Oracle's roadmap for Fusion. Demantra had many major differentiators on ODP, that it made Oracle's job of selling Demantra as substitute for ODP, a lot easier. Demantra's beysian mix modeling technique, it's flexible & scalable nature, and support for functions like, S&OP, PTP and TPMO are among few of these differentiators. 

ODP's best fit forecasting method had the capability of selecting the most fit model, for forecast calculation for a data series. It used one of all the available models, which had least residual and was a closest fit to historical demand data. While in Demantra, engine selects multiple good fit models and puts a coefficient to each of their predictions, to calculate the final baseline forecast. So Demantra calculates fit for multiple models to historical demand, and then tries to validate the fit. In the forecasting process, based on residual calculations it also calculates weightages for each of those models and then all of those are combined to form a combined mix estimator model. The Beysian modeling hence uses multiple models, instead of one best fit, which ensures that a better statistical forecast is generated.

Demantra's BPM(Business Process Mapping) capabilities ensures it a berth in Oracle's Fusion and future product roadmap. Demantra's footprint in Trade promotions management & optimization business solutions, along with it's Deduction & Settlement Management modules, makes it a better bundled suite of solutions.