Introduction to Scenario Analysis

About the Scenario Analysis Module

The scenario analysis module enables your solution to resolve supply chain problems (and to perform other analyses, if wanted). This module defines scenario analysis as a set of specific, standard processing phases. Instead of needing to define the analysis process from end to end, you need only to create a template and a set of reusable helper functions to be called in each of these phases.

Each template is appropriate for a specific use case. For example, you would create a different template for an out-of-stock event than you would for a capacity shortage.

Each template also requires input data describing the particular issue. As an example, for an out-of-stock event, the input data includes the identifier of the product that is out of stock, the number of units, and the identifier of the location where the shortfall is.

The scenario analysis module provides an API for starting, obtaining status of, and resolving analysis runs, as well as managing templates.

How Your Solution Uses a Template

Your solution code uses a template roughly as follows:

1. Your solution code detects one or more issues that requires scenario analysis. For example, after consolidating inventory records, your code might notice multiple records that indicate out-of-stock events, each for a specific product at a specific location.

   Each out-of-stock event is a separate issue to examine and address.

2. For each such issue, your code should then obtain the appropriate input data, determine the correct template to use, and call the scenario analysis API to start a scenario analsys run.

   The scenario analysis module then asynchronously generates and evaluates possiblities, choosing one as the recommendation.

3. Your code periodically calls the scenario analysis API to see if analysis is complete. When analysis is complete, your solution code retrieves the recommendation, as well as full details about the possiblities and their impacts.

   Typically you use the scenario analysis module to determine the best solution to an issue. In such cases, your solution code would continue with the next two steps. In other cases, you may simply want to determine how something might impact the supply chain; in such a case, your code would not need the next two steps.

4. Your code then presents the remaining possiblities and the recommendation to a user, who chooses the course of action, selecting an answer in a user interface.

5. Your code then uses the scenario analysis API to resolve the scenario, which uses logic in the template to call third-party systems (to place an order, for example). The scenario analysis module also removes all temporary data related to the current scenario run.

Processing Stages

A scenario analysis template contains a set of specific, standard processing phases, as follows:

1. Transformation. This phase identifies possible changes that could occur and represents each possibility in a temporary snapshot of data.

   A snapshot represents the state of the supply chain as it would be, if the user chose this specific possibility. Each snapshot is created by applying a transformation to the data. For example, if one possibility is to transfer 100 units of a product from a specific warehouse, the snaphot is created by subtracting 100 units of that product from that warehouse. The transformation can affect data in multiple tables, whatever is needed to represent the possible choice.

   The template defines the logic needed to identify where changes could occur, as well as logic for creating the snapshots.

   This phase generates a set of possiblities, each with its own snapshot, isolated from the other possiblities and from all the other tables. The snapshots are used by the remaining phases of analysis.

2. Validation. This phase validates each snapshot and discards any that are not valid.

   For this phase, the template defines one or more validation functions to use.

3. Impact. This phase runs one or more impact rules, each of which computes an impact, such as time or cost. These rules examine each snapshot.

   This phase generates an impact report, so that each impact is known for each possibility.

4. Recommendation. This phase examines each pair of snapshots. For the pair of snapshots, the system calls the recommendation rule to determine which snapshot (of that pair) is considered better. After examining all the pairs, the system recommends the best snapshot that it found.

How Values Are Passed Between Template Parts

It is useful to start with a basic understanding of how the scenario analysis module receives input data and passes it between parts of a template.

1. First, when your solution code calls the scenario analysis API, that request must contain two elements:

   • A context object that contains information needed to analyze the issue. This is a JSON array that contains the specific parameters required by the template. Your solution code must determine what values to package and put into this object.

   • The name of the template to use. (Each template is applicable only in certain situations, so your solution code must determine that as well.)

2. Within a template, you list the parameters to provide as input for the helper functions. In most cases, you do this by providing an array of parameter names, which match names of parameters provided by the context object.

Also, in some places, the scenario analysis module passes additional arguments for your code to use; one of these arguments includes a copy of the context object. There is also a method you can call to add to the context object.

For any BPL business process that you define, when you use the required message request class, the scenario analysis module automatically includes all the context parameters in that message. Your BPL can then access the values.

Similarly for the recommendation business rule, when you use the required context superclass class, the scenario analysis module automatically populates it with the impact values from the scenarios it is comparing. Your business rule can then access the values.

How Temporary Data Is Isolated

The scenario analysis module is designed so that it is possible to see the results of transforming data without touching the actual supply chain tables. This works as follows:

• Each possibility has a temporary copy of the applicable data—a snapshot, as noted above, located in a generated internal table.

• Your helper functions work only with the snapshot.

  Specifically, within your Python or ObjectScript functions, rather than executing SQL directly, you use an interface that converts your SQL into the equivalent that queries the snapshot-specific copy.

  Similarly, when you create an SQL function, the scenario analysis module converts your SQL into the snapshot-specific equivalent.

• Invalid snapshots are automatically removed when it is appropriate to do so.

• When scenario analysis is resolved (with a selection made), all temporary data is automatically removed.

This system enables all the possibilities to be isolated from each other and from the rest of your Supply Chain Orchestrator solution.

See Also

• Defining a Template

• Introduction to the Scenario Analysis API