Dieser Beitrag erläutert den KPI-Wechsel bei Navigationsschritten (Drilldown) in der DeltaApp. Ein Wechsel von einer zusammenfassenden Fallkennzahl zu den Detailwerten erfolgt damit innerhalb der App im Navigationsschritt, also ohne Kontextverlust/Change Blindness. Das hier vorgestellte Vorgehen lässt sich technisch auch auf andere Themengebiete übertragen.  

Die DeltaApp verwendet als Datenbasis Datenbanken im DB-Format. DeltaMaster exportiert diese Datenbanken auf Basis von mobilen Berichten. Durch eine nachträgliche Konfiguration der Datenbanken können zusätzliche Logiken implementiert werden.

Im Folgenden wird die Konfiguration einer solchen Datenbank vorgestellt, um einen KPI-Wechsel in Anwendungen der DeltaApp zu erreichen. Grundkenntnisse zur von DeltaMaster exportierten Datenbank werden vorausgesetzt.

Anwendungsbeispiel

Das vorgestellte Beispiel bezieht sich auf eine Anwendung mit physikalischen Messwerten, beispielsweise Wassertemperaturen, welche mit Hilfe von Temperatursensoren gemessen werden. Die Temperatursensoren befinden sich in einer dreistufigen Struktur, bestehend aus Heizzentrale, Haus und Sensor. Eine Heizzentrale versorgt mehrere Häuser, in welchen wiederum mehrere Temperatursensoren installiert sind. Liegt eine gemessene Wassertemperatur außerhalb eines definierten Toleranzbereichs, dann wird ein Alarm gemeldet.

Eine aggregierte Betrachtung von gemessenen Wassertemperaturen besitzt keine Aussagekraft und kann auch durch mögliche Saldierungseffekte keinen Hinweis auf Wassertemperaturen außerhalb des Toleranzbereichs liefern. Jedoch besitzt die aggregierte Anzahl an Alarmen eine hohe Relevanz zur Überwachung der Heizzentralen. Während eines Drilldowns innerhalb der Struktur der Heizzentralen soll ein KPI-Wechsel von der aggregierten Anzahl an Alarmen pro Heizzentrale oder Haus (Fallkennzahl) auf die gemessenen Wassertemperaturen einzelner Sensoren (Detailkennzahl) erfolgen. Zum Editieren der Datenbank wird das Programm SQLite verwendet.

KPI-Wechsel – Allgemein

Ein KPI-Wechsel kann aus einem Wertwechsel, Formatwechsel, sowie einem Wechsel der Farblogik bestehen. Der KPI-Wechsel findet bei Ausführung eines Navigationsschritts in eine als Fallstruktur gekennzeichnete Struktur der Fallkennzahl statt.

Die grundsätzliche Kennzeichnung eines KPI-Wechsels erfolgt in Spalte [T_APPDEF_DashboardKpiStructures].[IsCaseStructure] individuell pro Kennzahl und Struktur. Es sind somit mehrere, auch unterschiedliche Fallstrukturen für eine Kennzahl zulässig.

Für die jeweilige Fallkennzahl und Fallstruktur wird die Spalte [T_APPDEF_DashboardKpiStructures].[StructureTable] ausgelesen, in welcher eine Tabelle oder View mit definierter Spaltenstruktur angegeben werden muss.

Ein KPI-Wechsel kann in zwei verschiedenen Ausprägungen V1 und V2 implementiert werden, auf deren Besonderheiten die nachfolgenden Abschnitte näher eingehen.

KPI-Wechsel V1

Ein Wert von 1 in Spalte [T_APPDEF_DashboardKpiStructures].[IsCaseStructure] definiert den KPI-Wechsel V1. Bei einem KPI-Wechsel V1 werden von der Detailkennzahl nicht der Wert, sondern die Einheit (Formatwechsel) aus Spalte [T_APPDEF_DashboardKpiValues].[Format], sowie die Bereichsinformationen der Kennzahlfärbung aus den Spalten [T_APPDEF_DashboardKpis].[BIColorRangeLow] und [T_APPDEF_DashboardKpis]. [BIColor-RangeHigh] auf die Fallkennzahl angewendet. Die Fall- und Detailkennzahlen können unterschiedlichen Dashboards zugeordnet sein. Hierdurch können die Detailkennzahlen auch einem ausgeblendeten Dashboard zugewiesen werden, um diese nur im Bedarfsfall für einen KPI-Wechsel anzuzeigen.

Ein Wertwechsel kann zusätzlich über eine Fallunterscheidung (CASE-Statement) in Spalte [T_APPDEF_DashboardKpiValues].[Expression] erreicht werden. Ein Beispiel ist im Abschnitt zum Implementierungsbeispiel V1 beschrieben. Für einen solchen Wertwechsel kann es notwendig sein, die Fall- und Detailwerte in einer View nebeneinander zu stellen.

Die verwendete Tabelle oder View in Spalte [T_APPDEF_DashboardKpiStructures].[StructureTable] muss folgende Spaltenstruktur aufweisen:

• [ID]: Mapping mit den Elementen der Fallstruktur
• [SortID]: Sortierreihenfolge für Drilldown nach Elementen anstatt nach Detailkennzahl
• [CorrespondingDashboardID]: DashBoardID der Detailkennzahl
• [CorrespondingKpiID]: KpiID der Detailkennzahl

Durch den nachfolgend vorgestellten KPI-Wechsel V2 wird der KPI-Wechsel V1 obsolet und voraussichtlich in zukünftigen Versionen der DeltaApp nicht mehr unterstützt.

KPI-Wechsel V2

Ein Wert von 2 in Spalte [T_APPDEF_DashboardKpiStructures].[IsCaseStructure] definiert den KPI-Wechsel V2. Bei einem KPI-Wechsel V2 wird für die Wertermittlung der Fallkennzahl anstelle der Einträge aus Spalte [T_APPDEF_DashboardKpiValues].[Column] oder Spalte [T_APPDEF_DashboardKpiValues].[Expression] der hinterlegte Ausdruck aus Spalte [T_APPDEF_DashboardKpiValues].[CaseStructureExpression] verwendet. Zusätzlich wird für die jeweilige Fallkennzahl und die betreffende Strukturebene die Spalte [T_APPDEF_DashboardKpiStructures].[StructureTable] ausgelesen, in welcher eine Tabelle oder View angegeben wird. Die verwendete Tabelle oder View muss folgende Spaltenstruktur aufweisen:

• [ID]: Mapping mit den Elementen der Fallstruktur
• [SortID]: Sortierreihenfolge für Drilldown nach Elementen anstatt nach Detailkennzahl
• [Unit]: Angabe der anzuzeigenden Einheit für Formatwechsel

Die Einheit für den Formatwechsel wird somit nicht wie beim KPI-Wechsel V1 über eine fixe Detailkennzahl definiert, sondern kann dynamisch innerhalb einer View in Spalte [Unit] ermittelt werden.

Abschließend muss in Spalte [T_APPDEF_DashboardKpiValues].[KPISwitchExpression] eine Prüfung definiert werden, ob der KPI-Wechsel tatsächlich durchgeführt wird (Wert 1) oder nicht (Wert 0). Diese Prüfung kann zum Beispiel notwendig sein, damit ein Wechsel der anzuzeigenden Einheit nur dann stattfindet, wenn er auch sinnvoll ist. Wird keine Eintragung in Spalte [T_APPDEF_DashboardKpiValues].[KPISwitchExpression] vorgenommen, dann wird kein KPI-Wechsel durchgeführt.

Ein Wechsel in der Farblogik für den KPI-Wechsel V2 befindet sich zum Zeitpunkt dieses Beitrags in der Entwicklungsphase und wird zu einem späteren Zeitpunkt erläutert werden.

Implementierungsbeispiel V1

Im Implementierungsbeispiel des KPI-Wechsels V1 ist die Fallkennzahl die Anzahl an Alarmen (KpiID 20 – [Messungen]) und die Detailkennzahl sind die einzelnen Messwerte (KpiID 25 – [Messwert]). Über einen Wertwechsel sollen bei einem Drilldown in die Fallstruktur, Sensor anstelle der Anzahl an Alarmen die einzelnen Messwerte gezeigt werden. Dies wird über den Ausdruck in Spalte [T_APPDEF_DashboardKpiValues].[Expression] umgesetzt (Abbildung 1). Hierbei werden die einzelnen Messwerte der Temperatursensoren nur dann angezeigt, wenn die Anzahl an Alarmen 1 beträgt. Hierdurch wird eine Aggregation von Messwerten für die Strukturen Heizzentrale und Haus vermieden.

Abbildung 1: KPI-Wechsel V1 – T_APPDEF_DashboardKpiValues für die Fallkennzahl

Durch einen Formatwechsel wird bei einem Drilldown in die Struktur Sensor für die Messwerte, die Anzeige der Einheit °C umgesetzt. Für die Strukturen Heizzentrale und Haus wird keine Einheit verwendet. Spalte [T_APPDEF_DashboardKpiValues].[Format] enthält für die Fallkennzahl keinen Eintrag und für die Detailkennzahl die Zeichenfolge °C (Abbildungen 1 und 2).

Abbildung 2: KPI-Wechsel V1 – T_APPDEF_DashboardKpiValues für die Detailkennzahl

Spalte [T_APPDEF_DashboardKpiStructures].[IsCaseStructure] enthält für die Fallkennzahl und Strukturebene Sensor den Wert 1 (Abbildung 3). Spalte [T_APPDEF_DashboardKpiStructures].[StructureTable] enthält den Namen der zu verwendenden View [V_S_Sensor_Heizzentrale] (Abbildung 3).

Abbildung 3: KPI-Wechsel V1 – T_APPDEF_DashboardKpiStructures

Die nachfolgende View [V_S_Sensor_Heizzentrale] bezieht die Spalten [ID] und [SortID] aus der Strukturtabelle [T_S_1_20_Sensor], welche die Elemente der Struktur Sensor für die Fallkennzahl enthält. In den Spalten [CorrespondingDashboardID] und [CorrespondingKpiID] wird auf die Detailkennzahl verwiesen.

CREATE VIEW [V_S_Sensor_Heizzentrale] AS

SELECT DISTINCT
	[ID]		AS [ID],
	[SortID]		AS [SortID],
	2		AS [CorrespondingDashboardID],
	25		AS [CorrespondingKpiID]

FROM
	[T_S_1_20_Sensor]
;

Bei einem Drilldown von einem Haus in die zugehörigen Sensoren werden nun nicht wie für Heizzentralen und Häuser die Anzahl an Alarmen angezeigt, sondern die einzelnen Messwerte (Wertwechsel) mit Einheit °C (Formatwechsel) (Abbildung 4).

Abbildung 4: KPI-Wechsel V1 – korrekter Wertwechsel und Formatwechsel in der DeltaApp

Werden nach einem Drilldown von einer Heizzentrale jedoch nicht die Häuser gewählt, sondern über ein laterales Wischen direkt die Sensoren, entsteht ein ungewünschter Formatwechsel mit Anzeige der Einheit °C für die Anzahl an Alarmen (Abbildung 5). Die Ursache hierfür ist, dass in den einzelnen Häusern die Sensoren identisch benannt wurden und hierdurch aufgrund der Aggregation von gleichnamigen Sensoren die Anzahl an Alarmen größer 1 beträgt. Zur Behebung dieser falschen Anzeige wird der KPI-Wechsel V2 benötigt.

Abbildung 5: KPI-Wechsel V1 – ungewünschter Formatwechsel in der DeltaApp

Ein weiteres nicht optimales Verhalten eines KPI-Wechsels V1 ist die Durchführung des Wertwechsels für nur einige, aber nicht alle Elemente einer Struktur. Würde beispielsweise in Haus 3 nur ein Temperatursensor eine Alarmmeldung erzeugen, so würde bei obiger Implementierung in Abbildung 4 in der Struktur Haus für Haus 3 bereits der entsprechende Messwert angezeigt werden, während für Haus 4 die Anzahl an Alarmen angezeigt würde. Solch ein Verhalten kann ebenfalls durch den KPI-Wechsel V2 ausgeschlossen werden.

Des Weiteren könnten die Detailwerte unterschiedliche Einheiten besitzen, und nicht wie im Beispiel allgemeingültig die Einheit °C. Hierfür wird im Formatwechsel die dynamische Ermittlung der Einheit innerhalb einer View des KPI-Wechsels V2 benötigt, welche nicht pro Fallstruktur eine fixe Detailkennzahl zur Durchführung eines Formatwechsels erwartet.

Implementierungsbeispiel V2

Im Implementierungsbeispiel des KPI-Wechsels V2 ist die Fallkennzahl erneut die Anzahl an Alarmen (KpiID 20 – [Messungen]). Spalte [T_APPDEF_DashboardKpiStructures].[IsCaseStructure] enthält für die Fallkennzahl und Struktur Sensor den Wert 2 zur Kennzeichnung eines KPI-Wechsels V2 (Abbildung 6). Spalte [T_APPDEF_DashboardKpiStructures].[StructureTable] enthält den Namen der zu verwendenden View [V_S_Sensor_Heizzentrale] (Abbildung 6).

Abbildung 6: KPI-Wechsel V2 – T_APPDEF_DashboardKpiStructures für die Fallkennzahl

Der Wertwechsel soll identisch zum KPI-Wechsel V1 erfolgen. In Spalte [T_APPDEF_DashboardKpiValues].[Expression] ist die Fallkennzahl Anzahl an Alarmen ([Messungen]) definiert, während in Spalte [T_APPDEF_DashboardKpiValues].[CaseStructureExpression] die beim Drilldown zu verwendende Detailkennzahl ([Messungen]) aufgeführt wird (Abbildung 7).

Der Formatwechsel soll ebenfalls identisch zum KPI-Wechsel V1 erfolgen. Hierfür ist Spalte [T_APPDEF_DashboardKpiValues].[Format] für die Fallkennzahl leer. Für die Struktur Sensor wird die anzuzeigende Einheit der Detailkennzahl aus Spalte [Unit] in View [V_S_Sensor_Heizzentrale] gelesen (Abbildung 7).

In Spalte [T_APPDEF_DashboardKpiValues].[KPISwitchExpression] ist die abschließende Prüfung definiert, ob der KPI-Wechsel V2 durchgeführt wird. Dies ist der Fall, wenn die Anzahl an Alarmen 1 beträgt (Abbildung 7). Dies entspricht der Anzeige eines einzelnen nicht aggregierten Messwerts.

Abbildung 7: KPI-Wechsel V2 – T_APPDEF_DashboardKpiValues für die Fallkennzahl

Die nachfolgende View [V_S_Sensor_Heizzentrale] unterscheidet sich in ihrer Struktur vom KPI-Wechsel V1. Zwar bezieht die View weiterhin die Spalten [ID] und [SortID] aus der Strukturtabelle [T_S_1_20_Sensor], welche die Elemente der Struktur Sensor für die Fallkennzahl enthält. Jedoch enthält die View nun nur noch eine weitere Spalte [Unit], in welcher die anzuzeigende Einheit °C der Detailkennzahl angegeben ist. Spalte [Unit] könnte auch eine dynamische Ermittlung der Einheit, beispielweise aus einer weiteren Hilfstabelle, aus dem Namen des Sensors oder einer Fallunterscheidung (CASE-Statement), enthalten.

CREATE VIEW [V_S_Sensor_Heizzentrale] AS

SELECT DISTINCT
	[ID]		AS [ID],
	[SortID]		AS [SortID],
	'°C'		AS [Unit]

FROM
	[T_S_1_20_Sensor]
;

Das Verhalten während eines Drilldowns von einem Haus in die zugehörigen Sensoren entspricht dem des KPI-Wechsels V1 (Abbildung 4).

Anders als beim KPI-Wechsel V1 wird nun nach einem Drilldown in eine Heizzentrale und einem anschließenden lateralen Wischen in die Struktur Sensor für die aggregierte Anzahl an Alarmen nicht länger die Einheit °C angezeigt (Abbildung 8).

Abbildung 8: KPI-Wechsel V2 – korrektes Verhalten ohne ungewünschten Formatwechsel in der DeltaApp