Calculating useful KPIs#

In this section, useful ways to define and calculate KPIs variables for later analysis are introduced. First derivation of a Solution
In many use cases, a KPI will be the date of the first derivation of a solution. How long did it take for the knowledge base to recognize and derive that a problem, e.g. in a machine or patient, has occurred. To calculate this, the following arrangement of formulas can be used as a template:

%%Variable KPI_Date = firstChange(filter(Solution[], established))

After execution, the history of a solution is filtered for the entries where the Solution was established. In combination with the function firstChange, the date of entry will be selected, where the solution was first set to established.

Last derivation of a solution
The last derivation of a solution can be calculated analogous to the calculation of the first derivation:

%%Variable KPI_Date = latestChange(filter(Solution[], established))

Minimum or maximum of a variable
A frequently needed KPI is the minimum or maximum of a variable during the execution of a case. The calculation can here be done simply with the following formula:

%%Variable KPI_Num = min(QuestionNum[]) %%Variable KPI_Num = max(QuestionNum[])

Counting occurrences
A use case for a KPI could be the number of times, a solution was established or a variable was, for example, over a certain threshold. To calculate this, the following arrangement of formulas can be used as a template:

%%Variable KPI_Num = count(filter(QuestionNum[], '>', 25))

The KPI variable KPI_Num will contain the amount of history entries of the variable QuestionNum, that are greater than 25.

Limitations#

In some cases or for certain KPIs, changing the original knowledge base cannot be avoided to effectively perform an analysis. For example, it may not be possible to count how many times a certain edge or loop in a flowchart was cycled, if the loop does not contain a note performing an action in each pass. To count the cycles, such a note has to be added. This can only be done in the original knowledge base and not in the one extended using the KPI page.
If the integrity of the knowledge base is important, we suggest to clone the wiki content of the knowledge base and to perform the KPI analysis in the clone.

Specifying the KPI Markup#

After all KPIs are defined and calculated, the actual %%KPIAnalysis markup needs to be added to KPI page. In the markup, the different KPIs to be analyzed and also the cases to be executed have to be specified. The KPIs will be evaluated for every knowledge base that compiles the package the KPI markup is part of.
To add a particular KPI, the annotation @column can be used, defining a column in the excel analysis result file. Any question or solution in the knowledge base can be set as a KPI. The added KPIs will be displayed as the columns in the resulting excel table (see section KPI Result).
To add cases, the annotation @case can be used. All cases or test cases defined in the knowledge base can be set. Auto completion will help to use the right name/identifier for the case. Additionally, a regular expression can be used to define all cases that should be included in the result.
By default, all purging is disabled for KPI analysis. This may lead to high memory consumption if analyzing huge cases with very frequent value changes. To avoid this, purging can be enabled by using the annotation @purge, which can be set to enabled or disabled.

Example for a KPI wiki page#

The following example displays the source code of a complete KPI wiki page.

Plain KPI Configuration#

Instead of defining a new knowledge base for the KPI, the markup could also allow to define and calculate the KPIs in a similar way as they are otherwise defined in the and calculated in the