Configuring KPIs for InterSystems Supply Chain Orchestrator

Purposes of KPIs

KPIs are quantifiable measures that gauge a company's performance against a set of targets, objectives, or industry peers. KPIs are widely used in supply chain to help stakeholders understand how the business is doing, and what kind of risks exists across the supply chain. The following screenshot shows some supply chain KPIs: every number on the screen is a KPI.

In Supply Chain Orchestrator™, KPIs serve a second, important role: they can automatically generate issues. This is suitable when the KPI identifies a condition that needs correction.

Configuration Process

To define a KPI, use the following general process:

1. Define KPI logic conceptually, in business terms, with specific conditions. Usually, this is the information you collect from the business users on how they measure the business using this KPI.

2. Map KPI logic to the Supply Chain Orchestrator data model and analytics cube as shown in the KPI configuration example.

   • Does the data model cover the required business entity, or does the corresponding data model object have all the required attributes?

     If not, extend the data model as needed; see the data model documentation for more details.

   • Check to see if the associated cube meets the KPI requirements. For this process, you will use the Business Intelligence Analyzer. (If the Analyzer is not available, make sure that the namespace is analytics-enabled.)

     If a custom attribute is needed for the KPI, you may need to create your own copy of that cube to include that attribute as either a dimension or a measure. Also, if a new object is created for the KPI, a new cube is required for that object. For information on these topics, see Defining Models for Business Intelligence and related training materialOpens in a new tab.

3. Map the KPI specification to KPI definition JSON structure. See the KPI configuration example.

4. Create the KPI definition using the API, and verify the created KPI definition by another API call.

5. Start using the newly created KPI definition in your application through KPI value API or KPI listing API.

KPI Business Logic

When collecting KPI business logic information, consider the following:

• What does the KPI measure? Is the goal to measure the number of transactions, or revenues impacted, or average time for specific tasks? Once the metric is defined, make sure it is represented as a cube measure. Once the cube measure is mapped, there are two possible variations for the measure:

  • Raw data. The KPI value is the exact value as what the cube measure defines, such as count, revenue, average time, and so on.

  • Percentage. The KPI value is a percentage, defined by the ratio of two numbers. In this case, business logic is required for both numerator and denominator. For example, the numerator might be the number of shipments expected to be late, and the denominator might be all shipments in transit.

• What is the primary business entity the KPI is measuring? A KPI can measure late shipped orders based on sales orders, or a KPI can measure late shipped shipment based on supply shipments. Such business entity needs to be mapped to an object in the Supply Chain Orchestrator data model.

• What are the KPI conditions? KPI conditions refer to the business logic which defines the conditions of the interests. For example, the KPI conditions for a late shipment KPI can be: shipments in transit with expected time of arrival later than the requested time of arrival. The tutorial shows how to capture such conditions in technical terms for the KPI definition. A couple of additional considerations:

  • The KPI condition can be empty. In this case, the KPI considers all records. For example, total order revenue may have an empty KPI condition, as it is about the sum of revenues from all orders.

  • In case the KPI measure is of type percentage, two set of conditions are required: one for the numerator, and the other for the denominator.

• How will the KPI data be further processed? You can slice and dice a KPI in different ways; specifically, you can configure the dimensions by which the KPI can be broken down. For example, you may want to see the breakdown of a late shipment KPI by supplier, carrier, and ship-to location. In this case, KPI dimension for supplier, carrier, and ship-to location can be defined. Each KPI dimension must have a corresponding cube dimension, but not all cube dimension need to map to a KPI dimension, i.e. KPI dimension is a subset of cube dimension.

• What are KPI threshold values? Thresholds can be defined to indicate how good or bad the measured aspect is for your business. Thresholds can be used to trigger notifications, or design visuals in the UI (such as green/yellow/red color scheme). Two threshold values are supported for each KPI: watching threshold (from green to yellow), and warning threshold (from yellow to red).

• Other descriptive information about the KPI. You can give each KPI a unique name (used as a key in APIs), a label (displayed name in UI), a description, and a status (active or not).

See the KPI configuration example.

For KPIs intended to capture risks or concerns in your supply chain, you can leverage the KPI definition to automatically generate issues which can then be tracked by the platform. For example, you can use the late delivery KPI to create issues automatically for shipments that meet the condition defined by the late delivery KPI. In such a case, you should consider an additional set of parameters for the KPI definition:

• Issue generating indicator

• Default issue severity level

• Business process name for issue analysis

See Also

• Supply Chain Solution Overview

• Issue Management

• KPI Configuration Example

• API Reference