Projektmanagement
Kennzahlendefinitionen als zentrales Arbeitsinstrument im BI-Projekt
Jon Cajacob |
Kennzahlen sind der Kern jeder BI-Lösung und sollten von Anfang an und laufend klar definiert werden. Dazu bietet sich eine simple Liste mit Kennzahlendefinitionen an, welche laufend aktualisiert wird im Projekt. Dies soll ein zentrales Arbeitsinstrument für das ganze Team sein.
Einleitung
Der Zweck einer Business Intelligence (BI) Lösung ist letztendlich das Beantworten von geschäftlichen Fragestellungen und damit die Unterstützung der informationsbasierten Entscheidungsfindung im Unternehmen. Dabei stehen Kennzahlen und deren mehrdimensionale Auswertung immer im Mittelpunkt. Es macht deshalb Sinn, relevante Kennzahlen frühzeitig – wenn nicht sogar ganz am Anfang eines BI-Projekts – beginnen aufzulisten und klar zu definieren.
Diese Auflistung von Definitionen soll dann im Verlauf des (agilen) Projekts ständig aktualisiert und an neue Erkenntnisse angepasst werden.
Analytische Fragestellungen als Ausgangspunkt
Welche Kennzahlen überhaupt in einem BI-Tool ausgewertet werden können hängt von den analytischen Fragen ab, welche beantwortet werden sollen.
Beispiele
- Was sind unsere Top 10 umsatzstärksten Produkte?
- Ist die Deckungsbeitragsmarge besser oder schlechter als im gleichen Zeitraum des Vorjahres?
- Welche Vertriebsregion hat sich im Auftragsvolumen am stärksten entwickelt in den letzten 6 Monaten?
Aus den Fragenstellungen können wir sofort die notwendigen Kennzahlen und auch deren Dimensionalität ableiten.
Template Kennzahlendefinitionen
Die Kennzahlendefinitionen soll ein Arbeitsinstrument sein und während des BI-Projekts (und in der Weiterentwicklung darüber hinaus) als zentrales Werkzeug aktiv geführt und ständig an neue Informationen, Anforderungen und Erkenntnissen angepasst werden.
Es empfiehlt sich die Definitionen in einer simplen Excel-Liste zu führen und im Team sowie für weitere Stakeholder transparent zu machen.
Viele Merkmale der Definitionen sind natürlich optional und sollten nur sofern sinnvoll geführt werden.
Merkmale der Kennzahlendefinition
| Merkmal | Beschreibung | Beispiel |
|---|---|---|
| Bezeichnung Kennzahl | Möglichst kurz, selbsterklärend und strukturiert | Umsatz Ist |
| Analytische Fragestellung | Welche Fragen sollen mit der KPI beantwortet (und Entscheidungen unterstützt) werden? | Was ist der Umsatz über die Zeit, nach Kunden und Produkte? |
| Kategorie / Gruppierung | Nur wenn sinnvoll: Gruppierung von Kennzahlen für die bessere Übersicht | Vertriebskennzahlen |
| Quelle | Quellsystem, Tabelle, Spalte | SQL ABC, factFIBU, [Betrag] |
| Formel | Beschreibung der Berechnung. Kann mit mathematischer Notation sein oder sogar DAX, muss aber nicht | Summe von [Betrag] oder SUM([Betrag]) |
| Filterung / Einschränkung | Viele Kennzahlen müssen korrekt vorgefiltert werden, d.h. die zugrundeliegende Faktentabelle muss anhand verschiedener Merkmale eingeschränkt werden, bevor z.B. eine Summe gebildet werden muss | dimKonto[KontoID] startet mit 4* |
| Format | Das Format ist meistens selbsterklärend aus der Definition. Aber möglicherweise kann die genaue Definition des Formats wichtig sein | Ganze Zahl und Tausendertrennzeichen CHF |
| Dimensionen | Anhand welcher Dimensionen soll die Kennzahl ausgewertet und gefiltert werden? (Gibt es Dimensionen im Datenmodell, anhand welcher die Kennzahl nicht analysiert werden kann?) | Datum Kunden Produkte |
| Drillhierarchien(Aggregations- und Detailstufen) | Auf welchen Aggregationsstufen und bis auf welche Detailstufe soll die Kennzahl analysiert werden können? Reicht z.B. die Umsatzsumme auf Stufe Kalenderwoche oder braucht es auch den Kalendertag? | Region → Kunde → Produktkategorie |
| Variationen | Oftmals sind Variationen derselben Kennzahl notwendig, wie z.B. der Vorjahreswert für die Darstellung eines Vergleichs Ändert sich die grundlegende Kennzahlendefinition nicht, macht es auch keinen Sinn diese Variationen separat aufzuführen | Umsatz VJ Δ Umsatz Ist vs VJ Δ% Umsatz Ist vs VJ |
| Abhängigkeiten | Kennzahlen bauen vielmals aufeinander auf. Vielleicht sogar in einem umfassend definierten Kennzahlenbaum. Es kann Sinn machen, diese Abhängigkeiten hier festzuhalten | Basis für Berechnung Deckungsbeitrag (I) |
Schlusswort
Umfassende Projektdokumentationen oder detaillierte Anforderungslisten sind aufwendig und bringen nur selten einen vernünftigen Gegenwert. Insbesondere in agil geführten BI-Projekten, wo am Anfang oftmals noch nicht klar ist, wo die Reise eigentlich im Detail hingehen soll.
Gerade mit Power BI sind die meisten Aspekte der Lösung (mit wenigen Ausnahmen) sowieso direkt im Tool «dokumentiert». Ich kann jederzeit in Power Query nachvollziehen, wie die Rohdaten Schritt für Schritt in die gewünschte Form transformiert werden. Ist ein Element besonders komplex, z.B. eine DAX-Formel, kann ich direkt innerhalb dieses Elements eine kurze Beschreibung anfügen.
Die Definition der Kennzahlen aber ist vermutlich neben den analytischen Fragestellungen der zentralste Aspekt einer BI-Lösung, da daraus praktisch alles andere abgeleitet werden kann. Welche Dimensionen (Stammdaten) benötigen wir? Welche Fakten (Bewegungsdaten) benötigen wir auf welcher Detailstufe? Welche Kennzahlen sollen im Bericht entlang welcher Drillstufen dargestellt werden? Welche Filter hat der User auf der Berichtsseite zur Interaktion zur Verfügung?
Die klare, gemeinsame Definition der Kennzahlen lohnt sich deshalb definitiv und es ist ein Projektinstrument mit einem erfahrungsgemäss sehr guten Kosten-Nutzen-Verhältnis.
