Für das Reportingwerden die Daten aus Raw und Business Vault-dem Core Warehouse-in ein dimensionales Modell übernommen. Während im Core Warehouse der Fokus auf schnellem Laden und dem Aufbau von kompletten Historien liegt, verschiebt sich der Fokus im Data Mart (bzw. Raw oder Information Mart) auf die schnelle Auswertung der relevanten / gewünschten Daten.Je mehr Kennzahlen es werden, desto deutlicher werden Parallelen zwischen diesen Kennzahlen. Wie vermeidet man, dass dieselbe Kennzahl mehrfach ausgerechnetwird? Wie ist der optimale Ablauf für die Erstellung der Kennzahlen im DataMart?
Typische Zielumgebungen
Es gibt viele Reporting Tools am Markt, die alle große Unterschiede in sich tragen. Es gibt die älteren OLAP basierten Produkte wie Cognos, MS Analysis Services oder Microstrategy, die einen mehrdimensionalen Würfel abbilden. Parallel dazu haben sich in den letzten Jahren Werkzeuge wie qlik, tableau und PowerBI durchgesetzt, bei denen der Inhalt des Würfels jeweils in einer großen Datei bereitgestellt wird.
Allen gemeinsam ist: Es werden Zahlen anhand von deskriptiven Attributen gefiltert und aggregiert, auf diesem Ergebnis erfolgen dann weitere Berechnungen wie Quoten, Durchschnitt, etc. Alle diese Tools sind sehr effizient im Aggregieren und Filtern von Werten. Und genau das unterstützt das dimensionale Modell. Eine oder mehrere Zahlen (Kennzahlen) werden über eine Faktentabelle mit den deskriptiven Attributen (Dimensionen) verknüpft. Aus diesem Konstrukt lassen sich dann leicht alle gewünschten Formen des Inputs für das jeweilige Reporting Tool erstellen.
Kennzahlen zerlegen
Das dimensionale Modell bietet die Möglichkeit, jede Dimension und Kennzahl genau einmal festzulegen und dann über mehrere Auswertungen zu verteilen. In den Anforderungen aus dem Fachbereich zu Kennzahlen wird beispielsweise vom ‚Umsatz mit Personen unter 25‘, von ‚% initial erfolgreich produzierten Teilen‘ oder vom ‚Überbestand im Lager‘ gesprochen. Diese Kennzahlen setzen sich aus mehreren Teilen zusammen:
| Umsatz mit Personen unter 25 | Anzahl verkaufter Produkte, Preis pro Produkt bzw. gezahlter Betrag, Rabatte, Alter des Käufers. |
| % initial erfolgreich produzierter Teile | Anzahl erfolgreich produzierter Teile, Anzahl Fehlteile, Anzahl erfolgreich korrigierter Teile |
| Überbestand im Lager | Lagerbestand, aktuelle Aufträge ohne Lieferung, prognostizierte Aufträge bzw. Vergleichswerte aus einer anderen Periode |
Letztlich ist eine Kennzahl also eine Formel aus Kennzahlen und Dimensionen. Das ist eine rekursive Definition. Hier braucht eine weitere Differenzierung der Kennzahlen. Gibt es einen Beginn? Eine Kennzahl, mit der alles anfängt?
Die Basiskennzahl als Ursprung genau einmal festlegen
Wenn man die Kennzahlen nach ihrem Ursprung aufteilt, dann stehen am Anfang der Implementierung solche Kennzahlen, die sich direkt aus einem Satelliten im Core Warehouse ableiten lassen, wie beispielsweise die Anzahl Produkte in der Auftragsposition. Das ist die Basis, die wir aus dem Core Warehouse selektieren. Nicht immer werden diese Basiskennzahlen gebrauchsfertig geliefert. Der tatsächliche gezahlte Betrag als eine Basis für den Umsatz kann von vielen Faktoren abhängen, die vorher zu berücksichtigen sind, wie Reklamationen, Storno, etc.
Wenn die Basiskennzahl zunächst berechnet werden muss, dann ist diese Basiskennzahl im Business Vault auf Einzelfallebene zu ermitteln und zu historisieren. Nur so kann sichergestellt werden, dass diese Kennzahl überall gleich eingesetzt wird. Warum dieser Aufwand? Warum nicht die Kennzahl einfach im Rahmen der Faktentabelle erstellen und so sich den Aufwand der Speicherung und Historisierung sparen?
Das Problem lässt sich am besten an einem Beispiel erklären: Die Versicherung ‚sosecure‘ hat ein intensives Reporting. Zwei wichtige Faktentabellen sind zum einen die Verträge auf der Basiskennzahl des einzelnen Vertrags (Anzahl Verträge). Die andere Faktentabelle hat den einzelnen Schadensfall als Basiskennzahl. Nun kommt es vor, dass bei einem Schadensfall festgestellt wird, der Vertrag war zum Zeitpunkt nicht gültig, z.B. wegen Vertragsverletzung oder nicht erfolgter Zahlungen. Etliche Auswertungen sind dann jeweils auf beiden Faktentabellen möglich. So kann man ‚Anzahl Verträge mit mehr einem Schadensfall‘ in den Vertragsfakten und ‚mehr als ein Schadensfall pro Vertrag‘ in den Schadensfalldaten auswerten.
Hier muss in beiden Fällen dasselbe Ergebnis angezeigt werden, da sonst niemand den Zahlen im Data Warehouse traut. Der einfachste Weg zu einem gemeinsamen Ergebnis ist die Ermittlung dieser Basiskennzahl im Business Vault. Damit ist sichergestellt, dass beide dieselbe Basis haben. So wird eine große Fehlerquelle ausgeschlossen und es gibt keinen redundanten Code für die Ermittlung der Kennzahl. Denn dieser wäre bei einer Änderung dann auch noch an allen auftretenden Stellen zu ändern.
Einige Berechnungen erfolgen besser im Reporting
Die Abspaltung der Basiskennzahl ist jedoch noch nicht ausreichend. Die Berechnung einer Kennzahl kann auch Divisionen enthalten. Diese sollten immer im Reporting Werkzeug berechnet werden. Nehmen wir das Beispiel ‚% initial erfolgreich produzierter Teile‘, diese Kennzahl wird nach Dimensionen wie Material, Maschine, Produktlinie, Werk, etc. ausgewertet. Je nach Auswahl dieser Dimensionen passen sich Zähler und Nenner dieser Prozentberechnung an. Diesen Zahlenraum kann man nicht effizient vorberechnen. Das muss zur Auswertungszeit erfolgen. Diese berechneten Kennzahlen bilden eine eigene Subkategorie von Kennzahlen.
Die Kennzahlen nach Art der Entstehung
Was bleibt nach diesen beiden Abspaltungen noch übrig? Alle anderen Berechnungen auf den Kennzahlen: Addition, Subtraktion und Multiplikation sowie fest vorberechnete Filter wie ‚Personen unter 25‘. Im Prinzip alles, was nicht zur Laufzeit durch den Benutzer ausgewählt werden kann. Oder besser: alles, was danach auf Grund von Dimensionen aggregiert und gefiltert werden kann.
Die Kennzahlen nach der Art ihrer Entstehung hier noch einmal im Überblick:
- Basiskennzahlen – werden aus dem Core Warehouse für die Faktentabellen selektiert. Dies sind Kennzahlen auf unterster Ebene, wie Anzahl eines verkauften Artikels oder ein erfolgreich produziertes Teil (Einzelfertigung) bzw. Anzahl erfolgreich produzierter Teile (Chargenfertigung).
- Abgeleitete Kennzahlen – werden immer auf Basiskennzahlen, anderen abgeleiteten Kennzahlen und Dimensionen berechnet.
- Berechnete Kennzahlen – werden am besten im Frontend-Reporting-Tool berechnet. Entweder weil sie Quoten sind oder weil sie nur berechnet werden können, wenn der Kontext (die Ausprägung der jeweiligen Dimensionen) klar ist.
Für abgeleitete Kennzahlen gibt es immer auch die Möglichkeit der Berechnung im Reporting Tool. Das ist Ermessenssache. Das Hinzufügen einer Altersklasse wie ‚unter 25‘ ist in einem Reporting Werkzeug schnell erledigt. Wenn die Berechnung komplizierter wird, dann sollte man diese aus Gründen des Wartungsaufwands besser nur einmal im Data Mart machen. Genauso ist eine zentrale Berechnung besser, wenn die abgeleitete Kennzahl in vielen verschiedenen Reports verwendet wird. Letztlich ist die genaue Entscheidung über den Umsetzungsort eine Frage von Aufwand und Wartbarkeit.
Die Einteilung nach Entstehungsart ermöglicht die Optimierung der Berechnung
Die Einteilung der Kennzahlen nach ihrer Entstehung erlaubt eine Implementierung mit nur wenig redundantem Code. Änderungen an der Logik sind so nur an einer Stelle zu pflegen.
Die Kennzahlen lassen sich so wiederverwenden und sorgen für gleichbleibende Zahlen in allen Berichten, was die Vertrauenswürdigkeit erhöht.
Die Kriterien der Aufspaltung nach Entstehungsart sind einfach und nachvollziehbar. Das führt zu eindeutigen Regeln in der Architektur und in den Implementierungsrichtlinien, die auch von neuen Mitarbeitern schnell adaptiert werden.
Sie möchten wissen, wo Sie stehen und welche Richtlinien bei Ihnen Sinn ergeben? Füllen Sie einfach unseren Fragebogen aus finden Sie es heraus.