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".