Oracle Demantra Implementation Guide Supplement

Skip Headers

Contents

Forecast Modes

The Analytical Engine can run in three modes: batch, simulation, or subset forecast.

Note: The Analytical Engine can run in only one mode at a time.

In batch mode, the Analytical Engine considers all the item-location combinations and generates a forecast for all of them (with a few exceptions, noted in the next chapter). In a typical implementation, the engine automatically runs in batch mode regularly. Batch mode should be run separately of data load, typically after new data is imported.
In simulation mode, the Analytical Engine considers only a subset of the combinations. In this mode, the engine (called the Simulation Engine) waits for simulation requests and then processes them.

In simulation mode, a user runs a worksheet and submits a simulation request for some or all of the combinations in it. The simulation request is processed in the background but generally fairly soon. When the simulation is done, Demantra alerts the user, who can then accept or reject the results.

In this mode, the user is usually performing a "what if" analysis, which refers to making some changes within the worksheet and then performing the simulation to see whether those changes have the desired effect. This process can be repeated until the optimum results are achieved.

It is also possible to run simulations programmatically from within a workflow.
In Subset Forecasting mode, the main differences are as follows:

The column into which the engine will write into will be based on the Parent Batch profile associated with this profile; it will not receive its own set of columns and forecast versions.

When engine is run using a subset type engine forecast, the existing (latest) forecast column for the parent profile will be used. No new engine version will be generated; when completed the engine will still appear the same column as latest version.

For more information about forecast modes, refer to Comparing Forecast Modes in the Demantra Implementation Guide. For information about the subset forecasting mode, see the section Subset Forecasting Mode Characteristics later in this document.

Subset Forecasting Mode Characteristics

Subset forecasting incorporates elements of both batch and simulation engines. As in simulation engine, it will process a subset of total data, but as in batch, it will execute without the context of a worksheet and can leverage distributed processing.

In subset mode, engine logs will specify engine is running using subset profile. Engine will note what parent profile the subset profile is associated with as well as display any filter applied to the run.

For example, instead of stating "Running in Batch mode", the log file will state "Running in Subset mode based on Parent Profile XXXX" and "Filter YYYY is applied to engine population."

Important: It is strongly recommended the population which the engine runs on will be filtered using PopulationExtraFilter. For more information, refer to description in "Analytical Engine Parameters".

Important: When running engine in subset mode, it is strongly recommended parameter RunInsertUnits be set as "run nothing", as this should typically be executed during batch runs. If no full batch run is planned, this parameter can be set to active (1 or 3).

Example:

System has 100 active combinations
Engine last executed in batch mode using batch engine profile.
Batch profile has two forecast versions, Fore_4 column holds currently active version and Fore_2 holds an older archive version of forecast.
When engine is run again using the batch profile, the oldest available column will be used to store newly generated forecast. Any other forecast column will serve as an archive of newly generated forecast. The forecast will be written to Fore_2 column for all 100 combinations and Fore_4 column will be left alone. Fore_2 now holds the active version and Fore_4 holds the older archive.
A Subset engine profile is created with name NewProds and is associated with parent profile batch.
Profile NewProds is configured to execute on only 10 combinations.
When engine is executed using NewProds profile, forecast will be regenerated for the filtered 10 combinations and forecast will be rewritten to Fore_2 column. Forecast for 90 combinations filtered out will not be modified.

Engine Profiles

Forecast Non-Unit Maintenance Plan (UMP) Work Orders

This engine profile supports forecasting of work orders not associated with standard maintenance activity and service requests. The work order projection can be used as an input for processes outside this application generating future visits not linked to standard maintenance activity.

Forecast tree for new profile will be set as follows:


Level	Item Level	Location Level
1	Lowest Item Level	Lowest Location Level
2	Asset Group	Lowest Location Level
3	Highest Fictive Level	Highest Fictive Level

Engine Parameters

The following parameters differentiate this profile from other profiles:

Min_fore_level=1
Max_fore_level=2
Parameter 'PopulationExtraFilter' will be configured to filter out only work orders associated with non-Unit Maintenance Plan (UMP) visits. The parameter should be set to a filter on the Visit Type level to only include the members which represent non-maintenance activity.

Refer to Engine Parameters in the Demantra Implementation Guide for details about PopulationExtraFilter.

To create an engine profile:

When you create an engine profile, it is associated with a specific init_params table. It must not be the same table used by the other engine profiles. To check which init_params tables are in use, you can use the sql command select * from engine_profiles;

Navigate to System Parameters.

Business Modeler > Parameters > System Parameters.

The System Parameters window appears.
Select the Engine tab.

The existing engine profiles are displayed in the Engine Profile drop-down menu.
Click New.

The Create Engine Profile dialog box appears.
Select the engine profile you would like to use as a base for your new profile, if desired.
In the Profile Name field, enter the name of the engine profile.
In the Init Params Table Name, enter the init params table to be associated with this engine profile.
In the Profile Type field, select the appropriate profile type: Batch, Simulation Engine, or Subset Forecasting.
If you have selected Simulation Engine or Subset Forecasting as the Profile Type, use the Select Parent batch Profile list to assign the appropriate parent profile.

Note: When choosing a Subset Forecasting profile it is recommended the same profile be chosen as profile it is based on and parent profile. If base and parent profiles are not the same, all parameters of newly created profile need to be reviewed to ensure settings are valid and match configuration of parent profile. For more information, refer to Subset Forecasting Mode Characteristics.
Click OK.

The engine profile is saved.

Causal Factor Testing (Envelope Function)

For some of the engine models (CMREGR, ELOG, LOG, MRIDGE, and REGR), Demantra can choose random sets of causal factors, which it then tests. Demantra can then either use the set of causal factors that gives the best result or use a mix of causal factors.

This operation is known as the envelope function, because it is performed as an envelope around the main engine flow. This operation is controlled by the UseEnvelope parameter, which can be set to equal any of the following:

0 -Do not use the envelope function.
1 - Use the envelope function on five groups of causal factors: base plus direct and the four switching groups.
2 - Use the envelope function on the causal factor groups defined in Estimation_groups table.
3 - cycles individual influence groups in and out as part of causal factor envelope analysis process.

Note: A value of '3' is only relevant if at least one active promotional causal factor is set to ‘Has only indirect effects’ or ‘Has both direct and indirect effects'. For more information, see Influence Group Handling and Filtering.

Additional parameters further control the behavior for specific engine models:

IGLIndirectLimit specifies the number of influence groups to use when generating cannibalization and halo effects. The top influence groups are chosen based on group volume.

Note: This parameter is only relevant if at least one active promotional causal factor is set to ‘Has only indirect effects’ or ‘Has both direct and indirect effects’.
ENVELOPE_RESET_SEED specifies whether to reset the randomization seed for the envelope function, which evaluates different sets of causal factors for different engine models.
ENVELOPE_CHAIN_LENGTH specifies the number of variations of causal factors to try, for each model.
BestOrMix specifies whether to use the best set of causal factors (1) or to use a mix of the causal factors (0). The default is 0.

Influence Group Handling and Filtering

Several parameters control how the Analytical Engine handles influence groups during the evaluation of cannibalization and halo effects. This helps reduce amount of extraneous information encountered by the engine in large influence ranges, and helps limit indirect effects to substantial demand volumes. For example, you can limit the amount of cannibalization generated from the top ten brands.

The IGLIndirectLimit parameter limits the number of influence groups used when generating cannibalization and halo effects.

Note: The IGLIndirectLimit parameter is only relevant if at least one active promotional causal factor is set to ‘Has only indirect effects’ or ‘Has both direct and indirect effects’. UseEnvelope and IGLIndirectLimit parameters will often be used together during a PTP engine run when indirect effects are enabled.

To enable influence group handling:

From the Business Modeler, select the Parameters menu and then click System Parameters.
Click the Engine tab.
On the General subtab, set the UseEnvelope parameter to 3.
Click the Save button.

To configure influence group filtering:

Depending on your implementation's base time unit, open the appropriate InitParams XML file in a text editor.
- For daily time definitions, modify InitParams0Daily.xml.
- For weekly time definitions, modify InitParams0Weekly.xml.
- For monthly time definitions, modify InitParams0Monthly.xml.
Update the value of the IGLIndirectLimit parameter so that the Argument value is the maximum number of indirect influence groups to be analyzed for each node. The value can be '0' (zero) or any positive integer. A value of zero disables the filter. A positive integer allows the highest volume influence groups to participate in halo and cannibalization. Oracle recommends a value between 5 and 10.
Save the file.