Welcome to Performance Dashboard Help!
The Performance Dashboard consists of a set of tools and a runtime framework for calculating and storing KPIs in the DELMIA Apriso system.
“KPI” stands for Key Performance Indicator, which is defined as a human or machine process, operation, task, or other performance-related item that can be measured and that is used to monitor and control performance. KPIs help an organization define and measure their progress against metrics and towards goals.
An example of a KPI is “Quality,” which is the percentage of material produced at a machine that is good. This can be expressed in the following equation:
QUALITY = Quantity Good / Total Quantity Produced * 100
Quantity Good and Total Quantity Produced will need to be calculated before the KPI can be assigned a value. In DELMIA Apriso nomenclature, these are referred to as KPI Terms.
To define KPI Terms and KPIs as well as to manage and control their use during runtime, DELMIA Apriso includes a configuration tool and a framework of core runtime components that are referred to as the Metric Panel/Analytics Administration Tool & Engine. DELMIA Apriso also includes numerous KPIs and underlying KPI Terms that span all operational areas of a plant or warehouse including inbound/outbound logistics, material control, quality, maintenance, and manufacturing. The KPIs are based on industry best practices and are packaged into three major areas called Metric Panels. The Metric Panels and KPIs supported in DELMIA Apriso are as follows:
Metric Panel | KPIs |
Lean/Six-Sigma |
Availability |
Material & Logistics Execution |
Not OTIF Not In Spec |
Cost |
Standard Rate Variance |
The configuration tool, runtime engine, KPIs, and KPI Terms can also be referred to collectively as Performance Dashboard (abbreviated as “PD” or “DELMIA Apriso PD”).
To simplify the definition of KPIs and improve the availability of KPI data in real-time, the PD engine extracts, transforms, and in some cases aggregates data from the various DELMIA Apriso operational database tables and caches them using two fact tables. The cached data is referred to as facts, and there are four types of facts:
Facts are atomic data elements that are used by PD to directly calculate KPI Terms and KPIs. For example, if a machine is producing work for multiple work orders for multiple products over various days, getting the production information requires a number of queries that access multiple tables. Fact KPIs run the calculation and store the information in one table and, in some cases, one record. The facts and fact tables also serve a useful purpose in the area of analytics, data warehousing, and data mining purposes.
To summarize, KPIs are numerical values that are based on a mathematical equation of KPI Terms, which in turn calculate values based on production or logistics fact tables that cache information for performance and usability purposes. The elements that comprise KPIs and KPI Terms are as follows:
This contains the KPI expression or the formula made up of KPI Terms. A KPI also has a From Term and a To Term. A KPI is linked to the KPI_CONTEXT table and is stored in the KPI_VALUE table. To calculate a KPI, the KPI must be supplied with a CONTEXT_QUERY.
These are what make up a KPI. All KPI Terms must be calculated and return values before a KPI can be calculated. The KPI must return a single value that is of the DateTime or Decimal type. Terms are usually calculated from a FACT Table. A term can be any of the following:
This is the KPI Term used to calculate the point at which the KPI Terms are required to be calculated. This could be the start of a shift, the start of a month, etc. This term must return a single date.
This is the KPI Term used to calculate the point to which the KPI Terms are required to be calculated. This could be the end of a shift, the end of a month, etc. This term must return a single date.
This is the SQL query that is supplied when calculating a KPI. This query returns rows of information. The KPI is calculated and stored for each row in the context.
Tolerances are applied to the calculated KPI values and are persisted in the KPI_VALUE and KPI_VALUE_HISTORY tables.
Tolerances are applied by first checking for any tolerances for the key combination of the KPI value record.
If tolerances are not defined for the specific entity, then the default tolerance for the KPI is used.
Clients are used in the DELMIA Apriso environment to address for these two reasons:
Data can be sent from other DELMIA Apriso systems via XML Manager; therefore, data can exist in a system that is required to be sent to another system or was sent from another system. This is valid in the KPI calculation results.
A “stamp” is applied to the records that the system generated when there exists many systems in the CLIENT table. This is done by a single record in the CLIENT table that has its Master flag set to True.
This is an example scenario for a company called ABC:
In the main plant corporate office, decisions are made, processes are defined, and performance analysis takes place. This performance is monitored not only at the main plant but at the three child plants.
This structure will be reflected in the client table as follows (from the main plant) system:
Client Name |
Master Y/N |
Main Plant |
Y |
Plant 1 |
N |
Plant 2 |
N |
Plant 3 |
N |
Because this is the client table of the main plant, its master flag is set to true.
Alternatively, for plant 2 the following client structure is found:
Client Name |
Master Y/N |
Main Plant |
N |
Plant 1 |
N |
Plant 2 |
Y |
Plant 3 |
N |
One of the most important metrics that ABC requires is the amount of stock produced at each plant. This is then added as a KPI in the main plant using the PD Administration screen. When any KPI administration record is created, it is assigned the client name that is flagged as “master.” For example, the following record is in the KPI table:
KPI Name |
Client |
Quantity |
MAIN PLANT |
After this has been tested, the KPI is sent to the other plants using the Data Extractor Business Component (for details, please see the COE Data Replication Using Data Extractor Business Component Technical Guide). When sending the KPI data, the client is sent as well so that this reflects the source of the data. For example, the KPI records in plant 2 will look like this:
KPI Name |
Client |
Quantity |
MAIN PLANT |
KPI Plant2 – Attendance |
Plant 2 |
TestKPI |
Plant 2 |
When KPI results are generated, all of the records generated are assigned the master client name.
So in the above scenario, plant 2 has run the Quantity KPI at the end of the week. The result will be stored in the KPI value table as follows:
KPI Name |
Value |
Date |
Client |
Quantity |
1200 |
10/06/2005 |
Plant 2 |
These results are then sent to the main plant for analysis, again using the Data Extractor Business Component. This is then reflected in the main plant’s system for all of the plants so that analysis can be performed by all items:
KPI Name |
Value |
Date |
Client |
Quantity |
1200 |
10/06/2005 |
Plant 2 |
Quantity |
1690 |
10/06/2005 |
Plant 1 |
Quantity |
703 |
10/06/2005 |
Plant 3 |
Quantity |
3400 |
10/06/2005 |
Main Plant |
From these results it becomes easier to view the results (that plant 3 is not producing) from using tolerances (see Tolerance) and the client name.
Help version: DELMIA Apriso 2021 | 3DS Support
Copyright Dassault Systèmes 2001-2020