Dashboarding als Herausforderung für BI Projekte

Kaum eine moderne Reportinglösung kommt derzeit am Thema „Dashboard“ vorbei. Es ist in und gehört fast schon zum Pflichtprogramm Dashboards im Einsatz zu haben. Sie sind oft interaktiv, schick animiert und bunt. Somit erfüllen sie quasi drei Wünsche auf einmal und erheben damit Anspruch darauf das Reporting-Überraschungsei des 21. Jahrhunderts zu werden.


Vielleicht ist diese kritische Betrachtung überzogen, aber die Erfahrung aus verschiedensten Projekten zeigt, dass nur wenige „Dashboards“ tatsächlich auch Dashboards sind. Grundsätzlich ist es – unabhängig vom Tool, mit dem gearbeitet wird – erst einmal kein Problem ob ein solcher Bericht tatsächlich ein Dashboard ist oder nicht bzw. als solches bezeichnet wird oder nicht, solange er die Bedürfnisse des Anwenders zur vollsten Zufriedenheit erfüllt. Das ändert sich aber dann, wenn die Performance nicht zufriedenstellend ist, die Übersichtlichkeit verloren geht oder die Wartbarkeit aufgrund der Komplexität nicht mehr gewährleistet werden kann.


Aufgrund der Fokussierung der FIVE1 auf Beratungsleistungen rund um SAP Business Intelligence Lösungen konzentriert sich dieser Beitrag zum einen auf das Berichtsdesign von SAP Dashboards 4.0 Berichten, zum anderen soll er aber auch grundsätzlich und toolunabhängig beschreiben wie ein Dashboard an sich aufgebaut und konzeptioniert werden sollte. Der Grund dafür in einem Beitrag beide Themen zu behandeln liegt auf der Hand: Kunden im SAP Umfeld, die planen ein Dashboard zu implementieren, werden dieses derzeit höchstwahrscheinlich mit SAP Dashboards 4.0 realisieren. Und genau an dieser Stelle kommt zusammen was nicht zwangsläufig zusammengehören muss. Denn:


Ein Xcelsius-Bericht muss kein Dashboard sein und ein Dashboard muss nicht mit Xcelsius gebaut werden.


Was ist ein Dashboard?



Hart definiert ist ein Dashboard als Visualisierungsform im Reporting zu verstehen, die

  • die dafür definierten Kennzahlen
  • mit ihren zum Betrachtungszeitpunkt aktuellen Werten
  • in für den jeweiligen Betrachter aggregierter Form
  • auf einem Bildschirm zeigt.



Ein sehr gutes Beispiel aus dem Alltag ist das Cockpit eines Autos. Es zeigt dem Fahrer alle wichtigen Informationen zu seiner Fahrt mit den aktuellen Werten (z.B. Drehzahl) auf einen Blick. Die Frage der Aggregation nach verschiedenen Betrachtern stellt sich in diesem Beispiel nicht. Der Fahrer hat zu jedem Zeitpunkt seiner Fahrt Echtzeitinformationen zu Geschwindigkeit, Motortemperatur, Treibstoffmenge usw. Für das Cockpit sind weitergehende Information nicht relevant. Weitere Analysen wie die Frage warum der Fahrer bei der aktuellen Tankfüllung nur eine Reichweite von 500km hat wo doch die durchschnittliche Distanz, die er zurücklegen kann bei 700km liegt, beantwortet das Auto-Dashboard nicht. Für so geartete Fragestellungen muss der Fahrer den Bordcomputer befragen. Weiterhin werden auch keine monetären Fragen beantwortet. Das heißt, dass aus den Informationen der Armaturentafel nur Indikatoren zur momentanen Leistung des Fahrzeugs gezeigt werden. Ebenfalls denkbare Echtzeitinformationen wie zum Beispiel die Mehrkosten durch erhöhten Spritverbrauch bei 120 km/h statt 100 km/h haben ebenfalls nichts in der Anzeige zu suchen, da sie den Blick für die wesentlichen Fahrtindikatoren stören würden.


Dieses Bild lässt sich mehr oder weniger eins zu eins auch auf BI-Dashboards anwenden. Der kritische Erfolgsfaktor für die Akzeptanz des Dashboards ist somit zu großen Teilen zunächst die Auswahl der Kennzahlen, die abgebildet werden sollen.


Erfolgsfaktor Kennzahlenwahl



In diesem Zusammenhang kommt ein zweites Trendthema ins Spiel – die KPIs. In vielen Fällen wird der Begriff Key Performance Inidicator (oder kurz KPI) mittlerweile synonym zum Wort Kennzahl verwendet. Um es vorwegzunehmen ist das einer der Gründe, warum Dashboardprojekte scheitern können, da zum einen alle Kennzahlen auf eine Stufe gestellt werden („Key“) und zum anderen unterstellt wird, dass es sich bei allen Kennzahlen um Performance-Indikatoren handelt, was dazu führt, dass Kennzahlen im Dashboard landen, die dort nichts zu suchen haben.


Wie schon aus dem Autobeispiel hervorgeht gibt es neben den Performanceindikatoren auch eine zweite Kategorie, in die sich Kennzahlen einteilen lassen – die Ergebnisindikatoren oder auch Result Indicators. Beide Kategorien lassen sich nochmals unterteilen in „Key“ und Standardindikator. Zum besseren Verständnis empfehle ich an dieser Stelle das Buch Key Performance Indicators (KPI): Developing, Implementing, and Using Winning KPIs von David Parmenter (ISBN: 0470545151).


Eine grobe Unterscheidung folgt in nachstehender Tabelle:





Das Thema Kennzahlen werde ich in einem späteren Beitrag genauer behandeln. An dieser Stelle ist es zunächst ausreichend die Kennzahlen zu differenzieren und bei der Auswahl der Kennzahlen für das Dashboard Ergebniskennzahlen außen vor zu lassen. Wichtig ist im ersten Schritt also nur die Differenzierung von Kennzahlen in Performance- und Ergebniskennzahlen, wobei Performanceindikatoren klassischerweise sowohl non-monetär als auch mindestens täglich verfügbar sind und die Verantwortlichkeit über die gesamte Hierarchie heruntergebrochen werden kann.


Neben der Wahl der richtigen Kennzahlen sollte auch das Design des Dashboards in der Konzeptionsphase bereits durchdacht werden. Zu viele verschiedene Designelemente machen das Dashboard schnell unübersichtlich. Ziel des Dashboards muss es sein, dass der Anwender auf einen Blick erkennen kann, wie die aktuelle Situation sich darstellt. Daher sollte darauf geachtet werden, dass nicht nur die Anzahl der Designelement-Varianten sondern auch die Anzahl der Designelemente an sich nicht zu groß wird. Ich empfehle an dieser Stelle eine Anzahl von maximal 9 Elementen auf einem Dashboard, da somit eine gute Lesbarkeit auch auf kleineren Bildschirmen und Ausdrucken gewährleistet werden kann. Natürlich ist es möglich Kennzahlen, die in einem kausalen Zusammenhang stehen in einem Element zusammen abzubilden, wenn dadurch ein informatorischer Mehrwert für den Anwender entsteht.


Ein weiterer Vorteil, der sich durch die Verwendung richtiger Performance Indikatoren als Kennzahlen für das Dashboard ergibt, ist die Möglichkeit ein Dashboard für das ganze Unternehmen – sprich für alle Ebenen der Hierarchie – zu entwickeln. So sieht jeder Anwender die aktuellen Werte der Kennzahlen auf seiner Ebene. Auch bereichsspezifische Kennzahlen lassen sich so in das Dashboard integrieren ohne das ein zweiter Bericht erstellt (und natürlich später auch gewartet) werden muss.


Dashboarding mit SAP BusinessObjects 4.0



Projiziert man den beschriebenen Ansatz nun auf das Set der BI Tools von SAP BusinessObjects 4.0 kann man daran zweifeln, dass SAP Dashboards 4.0 das richtige Tool für die Erstellung von Dashboards ist. Um beim Autobeispiel von vorhin zu bleiben, gibt es natürlich die passenden Visualisierungselemente inklusive deren Animation. Im Gegensatz zum Auto fehlt es aber an einer entscheidenden Stelle: Den Echtzeitinformationen.


Da diese meist maximal „nur“ tagesaktuell verfügbar sind, ist die Konsequenz, dass das Dashboard an sich ein statisches Informationsinstrument ist. SAP Dashboards ist aufgrund der eingesetzten Flashtechnologie aber eher darauf ausgerichtet dynamische bzw. interaktive Berichte zu erstellen. Daher eignet sich für ein unternehmensweites Dashboard Crystal Reports deutlich besser als Tool. Insbesondere bei Unternehmen, die neben den unternehmensweiten z.B. auch Abteilungskennzahlen verwenden, ist es mit Crystal Reports einfacher auf Abteilungsbedürfnisse einzugehen als bei SAP Dashboards, da die Formatierungs- und Anzeigeoptionen größer sind. Auch das zeitaufwendige Flashrendering von SAP Dashboards entfällt.


Sicherlich kann man darüber diskutieren, ob ein Schieberegler als „Gaspedal“ interpretiert werden kann, der Auswirkungen auf die Daten im Dashboard aufgrund von Manipulation beeinflusst. Allerdings würde ich dem nur zustimmen, wenn die manipulierten Daten auch tatsächlich zurückgeschrieben werden.


Eine weitere Möglichkeit Dashboards mit SAP BusinessObjects 4.0 darzustellen sind die Desktop Widgets von Web Intelligence. So kann der Anwender auf seinem Desktop einzelne Kennzahlen abbilden und bekommt direkt morgens nach dem Starten des Rechners ein Update seiner Zahlen.


SAP Dashboards 4.0 Berichte



Der beschriebene Ansatz ein Dashboard zu definieren ist für die heutige Reportingrealität sicher zu hart gefasst. Zum einen liegt das am Mangel von Echtzeitinformationen zum anderen ist gerade SAP Dashboards dafür ausgelegt mit Reglern und Drop-down Feldern die Anzeige in gewissen Maße zu beeinflussen.


Dennoch sollten die definierten Anforderungen an ein Dashboard generell auch für das Design von SAP Dashboards Berichten gelten. Es ist natürlich verführerisch die gesamte Vielfalt an Anzeige- und Manipulationselementen in einem Bericht zu verbauen. Auch ist es möglich über die selektive Anzeige viele Szenarien abzubilden (wenn Zustand 1 dann Grafik 1, wenn Zustand 2 dann Grafik 2, usw.). Allerdings sollte es immer im Bewusstsein des Entwicklers sein, dass zum einen jedes Element gerendert werden muss und damit die initiale Ladezeit erhöht und zum anderen immer berücksichtigt werden sollte, dass diese Berichte nicht zu Analysezwecken designt werden, sondern eine hochaggregierte Sicht auf die Daten bieten, um in Analyseberichten Ansatzpunkte für die Detailanalyse zu haben. Eine Möglichkeit den direkten Absprung in die Detailanalyse anzubieten, ist der parametrisierte Aufruf eines Web Intelligence Berichts über die integrierte OpenDocument Schnittstelle.


Es sollte auch darauf geachtet werden, dass nicht zu viele Datenabfragen gleichzeitig laufen. Idealerweise formuliert man beim Berichtsdesign Ladebedingungen für jede Query, so dass Zahlen nur dann geladen werden wenn sie gebraucht werden. Vorteilhaft für die Laufzeit der Queries ist natürlich auch eine Datenquelle, die auf das wesentliche bereits eingeschränkt ist. Soll heißen, dass es durchaus Sinn macht für den Bericht einen separaten Datenprovider aufzubauen, der die Daten in der benötigten Granularität vorhält.


Ein weiterer Fokus bei der Berichtserstellung ist die optische Übersichtlichkeit. Die große Auswahl an Visualisierungselementen lädt dazu ein viele davon zu verwenden. Ergebnis ist in vielen Fällen ein unruhig und verspielt wirkender Bericht. Der Einsatz gleichartiger Grafiken verhindert das und eine symmetrische Ausrichtung verstärkt die Berichtsharmonie.


Entscheidet man sich dazu Manipulationselemente wie den Schieberegler zu verwenden, sollte man darauf achten, dass die Intuitivität dabei nicht verloren geht. Trotz Interaktion sollte der Anwender den Bericht ohne Erklärung verstehen und verwenden können.


Zusammenfassung



Aufgrund mangelnder Echtzeitinformationen ist ein Dashboard im enger definierten Rahmen heutzutage kaum realisierbar, allerdings sollten die dafür aufgestellten Regeln und Grundsätze auch für dashboard-ähnliche Berichte, die im SAP BO Umfeld derzeit mit SAP Dashboards erstellt werden gelten.

  • Auswahl der relevanten Kennzahlen
  • Intuitive Berichtsoberfläche
  • So wenig Visualisierungselemente wie möglich, so viele wie nötig
  • Darstellung der Daten in hochaggregierter Form
  • Schlankes Datenmodell und intelligente Ladelogik
  • Auslagerung von Detailanalysen (z.B. in Richtung Web Intelligence
Getagged mit: , , , ,
0 Kommentar auf “Dashboarding als Herausforderung für BI Projekte
1 Pings/Trackbacks für "Dashboarding als Herausforderung für BI Projekte"

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*