In dieser Blogserie In 3 Schritten zum Dashboard sehen wir uns an, wie wir strukturiert und effektiv zu einem robusten und praxistauglichen Dashboard kommen.

Im abschließenden Schritt 3 geht es jetzt um die Umsetzung von Dashboards in einer konkreten Technologie. Dieser Beitrag strukturiert den Umsetzungsprozess und verwendet für die tatsächliche Umsetzung beispielhaft die Technologien Excel und Power BI, beide mit dem Datenmodell in Power Pivot bzw. SQL Server Tabular Model.

1. Grundsatzentscheidungen

Nach der Konzeption in fachlicher, visueller und technischer Hinsicht (siehe Teil 2 dieser Blogserie) sind jetzt die entsprechenden Grundsatzentscheidungen zu treffen.

Fachliche Grundsatzentscheidungen

Die Entscheidung, welches Thema auf dem Dashboard behandelt werden soll. Wir empfehlen davon auszugehen, daß es mittelfristig mehrere oder sogar viele Themen-Dashboards im Unternehmen geben wird. Der Fokus für das erste Dashboard sollte daher eng gesetzt werden, es sollte nicht gleich zu Beginn ein "Unternehmens-Dashboard" entwerfen werden ...

Visuelle Grundsatzentscheidungen

Es ist die erste Grundsatzentscheidung zu treffen, um welchen Typ Dashboard es sich grundsätzlich handeln soll (das hat auch tw etwas mit der Technologie zu tun, hier aber erst mal aus visueller Sicht). Wir haben in Teil 2 dieser Blogserie beispielhaft 4 Dashboard-Typen definiert:

Typ #1: Grafiktabellen	Typ #2: Multiples	Typ #3: Datawall	Typ #4: Mobil & Touch

Weiters ist die Grundsatzentscheidung zu treffen, ob ein Notations- und Visualisierungskonzept angewendet bzw. auch entwickelt werden soll. Damit Dashboards nicht "gelesen und studiert" sondern auf einen Blick oder im Vorbeigehen aufgenommen werden können, empfehlen wir ein firmenspezifisches Notations- und Visualisierungskonzept auf Basis des IBCS® Framework.

Technologische Grundsatzentscheidungen

Die Entscheidung für eine konkrete Technologie ist natürlich sehr weitreichend und damit auch schwierig. Unseres Wissens nach gibt es derzeit kein Dashboarding-Tool, das alle Ansprüche am besten erfüllen kann, insofern gibt es hier - wie so oft - keinen "Königsweg". Aufbauend auf den technischen Fragestellungen am Ende von Teil 2 dieser Blogserie hier einige Best Practices, diese können aber einen fundierten Software-Auswahlprozess nicht ersetzen:

2. Implementierung

Gerade im Dashboarding macht fast ausschließlich ein agiler Projektansatz gegenüber einer Implementierung nach Spezifikation Sinn, da sich die Anforderungen nach dem Motto "Beim Essen kommt der Appetit" rasant weiterentwickeln. Wir empfehlen, mit einem Rapid Deployment - also mit wenigen Kennzahlen/Visuals - zu starten und dann kontinuierlich auszubauen. Hier unser empfohlenes Vorgehensmodell:

#1 Dashboard entwerfen und Anordnen der Visuals

Darüber haben wir schon viel in Teil 1 und Teil 2 dieser Blogserie gesehen, dazu das Fundament aus der vorangehenden Blogserie 1x1 der Visualisierung. An dieser Stelle daher nur die Wiederholung der in Teil 2 dieser Blogserie beispielhaft definierten 4 Dashboard-Typen:

Typ #1: Grafiktabellen	Typ #2: Multiples	Typ #3: Datawall	Typ #4: Mobil & Touch

Best Practice Empfehlungen:

• Bei jedem Visual muß klar sein, welcher Zeitraum und welche Organisationseinheit(en) gezeigt wird (v.a. wenn vom Gesamt-Dashboard abweichend)
• Jedes Dashboard braucht eine verlässliche Datenstandsanzeige (also ein Datum mit Uhrzeit, wann die Daten zuletzt aktualisiert wurden, ggfs. getrennt nach Datenquelle)

#2 Dashboard Verteilungsmodus umsetzen

Wie bereits mehrfach in dieser Blogserie angemerkt, hängen die Möglichkeiten zur Verteilung eines Dashboards massiv von der gewählten Technologie und dem vorgelagerten Datenmodell ab. Hier die wichtigsten Implementierungsthemen - natürlich ohne Anspruch auf Vollständigkeit - nochmals zusammengefaßt:

#3 Datenquellen identifizieren

Die Frage, welche Metrik die IST-, Vorjahres- und Zielwerte aus welchem System geliefert bekommt, ist häufig eine schwierige und ist oft mit technischen und organisatorischen Stolpersteinen versehen. Hier unsere Best Practice Empfehlungen:

• Liefern SaaS-Systeme aus der Cloud die Daten für das Dashboard, dann  sollte zuerst geprüft werden, welche Anbieter fertige Integrationen für diese Datenquelle haben. Selbst wenn das Dashboard des Anbieters nicht eingesetzt wird, kann aus diesen Integrationen sehr viel nützliches Know-How bezogen werden. Hier ein Auszug aus den sogenannten AppSources in Power BI (aktuell sind rund 50 Integrationen verfügbar, viele im Bereich Marketing, Microsoft Dynamics AX/NAV/CRM und Azure):
  
• Wird keine real-time Funktionalität im Dashboard benötigt, dann sollte das Dashboard nicht direkt auf die operativen Vorsyteme greifen sondern auf eine relationale Datenschicht. Damit kann die (oft erst mittelfristig steigende) Komplexität der Datentransformationen bzw. die notwendige Homogenisierung der Daten aus den verschiedenen Quellsystemen strukturiert und technisch robust umgesetzt werden. Weiters kann hier auch die Analysefähigkeit bis auf den Einzeldatensatz sowie der Konnex zum Standardreporting einfacher sichergestellt werden.
• Ist der Aufbau von soliden Datenstrukturen nicht gleich möglich bzw. muß der Nutzen eines Dashboards erst evaluiert werden, dann starten Sie mit strukturierten Excel- oder CSV-Datenlisten, die manuell aktualisiert werden. Diese Excel-/CSV-Dateien werden in das Datenmodell des Dashboards als Datenquelle eingebunden und können im Rahmen der agilen Projektimplementierung schrittweise durch die Anbindung an die relationale Datenschicht oder an das Vorsystem ersetzt werden (ohne das Datenmodell oder das Dashboard später umbauen zu müssen).

#4 Analytisches Datenmodell: Sicherstellen der Aktualisierung, der Analysefähigkeit und der (selektiven) Verteilung des Dashboards

Hier ist in Umsetzungsprojekten häufig zuerst die Frage zu klären, warum nicht direkt mit den Dashboard-Visuals auf die Datenquellen zugegriffen werden kann (wie das etwa bei den Power BI AppSources scheinbar der Fall ist), wozu also ein Datenmodell für ein Dashboard benötigt wird. Hierzu möchten wir folgendes postulieren:

Jede Dashboard-Anwendung hat auch ein analytisches Datenmodell, es kann jedoch für den Anwender unsichtbar sein und der Funktionsumfang kann stark variieren. Das Datenmodell macht ein Dashboard zu einer dynamischen Anwendung und erhöht damit den Nutzen für den Information Worker. 

Ein analytisches Datenmodells kann - je nach verwendeter Technologie - folgende Aufgaben im Dashboarding erfüllen:

1. Automatische Aktualisierung der Daten aus den Quellsystemen und Anwendung der Standardfilter/Rollierungen
2. Puffern der Daten aus den Vorsystemen (Intervall-Aktualisierung) oder bewerkstelligen einer sogenannten Direct Query Verbindung (Real-time-Aktualisierung)
3. Multidimensionale Berechnung von Kennzahlen (Counts und Ratios, Rangermittlung, ABC-Segmentierungen, Year-to-Date/Rolling-12-month, usw., IST-PLAN-Abweichungen, usw.)
4. Benutzerspezifische Datenfilter für die Verteilung des Dashboards, wenn nämlich nicht alle Empfänger des Dashboards alle Daten sehen dürfen bzw. nur ihre (Abteilungs-)Daten sehen sollen ("Row Level Security")
5. Verknüpfen von Fakten- und Dimensionstabellen zum analysefähigen Datenmodell (interaktives Filtern der Dashboard-Datenbestände in zeitlicher Hinsicht, auf Abteilungen, Mitarbeiter, Produkte, usw.)
6. Analysefähigkeit bis auf den Einzeldatensatz sowie Konnex zum Standardreporting im Unternehmen

Das analytische Datenmodell kann ...

• in die Dashboard-Anwendung integriert sein (Geckoboard, Databox, Tableau, Qlik, usw.), oder
• als eigene modular einsetzbare Anwendung ausgeprägt sein (Power Query, Power Pivot / Power BI Desktop / SQL Server Tabular Model, SQL Server Cubes, usw.)
  
• aus einem Formelwerk in Excel bestehen (wenig empfehlenswert aber weit verbreitet ...)

3. Laufender Betrieb und Ausbau

Ein Dashboard sollte nicht als fertig betrachtet werden sondern kontinuierlich an die aktuellen Entwicklungen des Unternehmens, des Geschäftsmodells, der Branche und dem Unternehmensumfeld angepaßt werden. Auch deshalb macht die agile Projektmethode im Dashboarding besonders viel Sinn, es sollten nicht zu viele Ressourcen in eine perfekte Erstumsetzung investiert werden sondern sondern die laufenden Erfahrungen der Empfänger in die Weiterentwicklung integriert werden:

Nützlichen Content zur Dashboard-Implementierung gibt`s auch bei Geckoboard (hier).

Weiterführende Unterstützung

Gerne unterstützen wir Sie bei der Klärung Ihrer konzeptionellen Fragen, bei der Technologieentscheidung und bei der Umsetzung Ihres Dashboards / Ihrer Dashboards. Jede Form der Unterstützung ist möglich, von der kostenlosen telefonischen Erstberatung über Trainings und Coachings bis zum schlüsselfertigen Dashboard-Projekt - ganz nach Ihren Vorstellungen.

[contact-form-7 id="43392" title="Formular Dashboard-Themen besprechen"]