In 3 Schritten zum Dashboard / Schritt 3: Umsetzen in einer konkreten Technologie

Publiziert von

Dashboard-Series-3In 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
2-demo-dashboard-excel-linearis-enterprise 2 Demo-Dashboard EXCEL chartisan Multiples 1 Dashboard Intro - Databox datawall power-bi-device-smartphone-smartwatch

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:

Ausgangssituation Best Practice
Datenquellen sind in der Cloud
  • Cloud-basierte Dashboard-Technologien wie Power BI, Geckoboard, Databox, usw.
Hohe Excel Affinität und bspw. lediglich monatliche Verteilung als PDF
  • Lösung mit Excel 2013/2016 Bordmitteln, ggfs. angereichert mit Visualisierungs-Add-Ins wie Zebra BI und chart-me. Empfehlung: automatische Aktualisierung sicherstellen anstatt monatlicher „Copy & Paste Orgien“
Lösung mit Microsoft Tools im SharePoint Intranet präferiert
  • Excel-basierte Lösungen mit Excel Services (SharePoint 2013) oder Excel Online (SharePoint 2016), hier können auch die Visuals von Zebra BI und chart-me verwendet werden
  • SQL Server basierte Lösungen mit Reporting Services Datazen oder auch m.E. auch mit „normalen“ Reporting Services
  • „Microsoft nahe Drittanbieter“ wie XLCubed u.a. prüfen
Mobile Verteilung steht im Vordergrund
  • Cloud-basierte Dashboard-Technologien wie Power BI, Geckoboard, Databox, usw.
  • SQL Server basierte Lösung mit Reporting Services Datazen
  • (ergänzend können auch excel-basierte Dashboards iVm Power BI mobil verteilt werden, wie in diesem Blogbeitrag gezeigt)
BI Reporting- oder Analyselösung eines Anbieters bereits im Haus
  • Umsetzung mit den Dashboard Tools von SAP, IBM, usw. prüfen
  • Umsetzung mit BI Tools wie QlikView, Tableau, Cubeware Cockpit, Bissantz, usw. prüfen

Vorsicht: mit BI Tools für das Standardreporting ist in der Regel kein Dasbhoarding möglich. Es können – je nach Visualisierungsstärke – Reports erstellt werden, die aussehen wie Dashboards. Es dürfen – natürlich abhängig von den konkreten Anforderungen – nicht die weiteren Eigenschaften für die Aktualisierung und Verteilung fehlen …

 

Nicht alle Empfänger eines Dashboards dürfen die gleichen Daten sehen
  • Lösung mit „Row Level Security“ wird benötigt (bspw. Power BI oder excel-basierte Lösung mit SQL Server Tabular Model / Cube als Datenbasis)

 

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:

dashboard-prozessmodell-1

#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 1×1 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
2-demo-dashboard-excel-linearis-enterprise 2 Demo-Dashboard EXCEL chartisan Multiples 1 Dashboard Intro - Databox datawall power-bi-device-smartphone-smartwatch

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:

Verteilungsmodus Themen zu lösen
Device „Datawall / TV“
  • Bietet der Dashboard-Anbieter einen Full-Screen Mode?
  • Ist die automatische Datenaktualisierung („always on„) gewährleistet?
  • Braucht es Möglichkeiten zur Interaktion (dynamische Filterung, Notiz-/Diskussionsfunktion)?
  • Braucht es eine Alert-Funktion (Benachrichtigung beim Überschreiten bestimmter Schwellenwerte)?
Device“Desktop / Tablet“
  • Wird das Dashboard wie ein „normaler Bericht“ vom Benutzer aufgerufen („on demand„) oder bleibt das Dashboard am Bildschirm immer geöffnet („always on„)?
  • Wie erhalten die Empfänger Zugang? Via Browser, über Excel oder muß ein eigenes Client-Programm verteilt und installiert werden?
  • Braucht es Möglichkeiten zur Interaktion (dynamische Filterung, Notiz-/Diskussionsfunktion)?
Device „Smartphone“ und „Smartwatch“
  • Bietet der Dashboard-Anbieter eine mobile App, die zum Betriebssystem der Smartphones im Unternehmen paßt?
  • Lassen sich die Inhalte des Dashboards für die Darstellung am Smartphone responsive darstellen?
  • Braucht es Möglichkeiten zur mobilen Analyse? Auch eine Notiz- und Diskussionfunktion?
  • Braucht es eine Alert-Funktion (Benachrichtigung beim Überschreiten bestimmter Schwellenwerte)?

Ausdehnung auf Smartwatch:

  • Bietet der Dashboard-Anbieter eine entsprechende Smartwatch-App?
  • Lassen sich die Inhalte des Dashboards für die Darstellung auf der Smartwatch reduzieren?
Device „PDF / Ausdruck“
  • Wie erfolgt die Verteilung: PDF per Mail oder per SharePoint/Intranet? Wer erstellt Ausdrucke?
  • Wie erfolgt die Versionierung bzw. wie wird der Zugriff auf die historischen Dashboard-Dateien übersichtlich organisiert?
Sollen/dürfen alle Empfänger alle Zahlen im Dashboard sehen?
  • Wie wird das Dashboard für die Empfängergruppen personalisiert? (hier ein Blogbeitrag iZm Power BI)
  • Bietet das Datenmodell „Row Level Security“ zur dynamischen Filterung des Dashboards abhängig vom angemeldeten Benutzer?
  • Wie ist diese Funktionalität bei sehr großen Userzahlen praktisch zu handhaben?
Große Anzahl Empfänger (> 100)
  • Ist das Dashboard-Tool (performance-)technisch in der Lage, eine große Anzahl von Empfängern zu versorgen?
  • Kann das Dashboard ohne Schulung und intuitiv von jedem nicht nur verwendet sondern auch verstanden werden?
  • Welche Lizenz-/Mietkosten fallen pro Nutzer an?
  • Ist die Wartung der User Accounts automatisiert möglich (Sync mit Active Directory, usw.)

 

#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):
    Dashboard Datenquellen - Power BI AppSources
  • 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.)
    PPV Datenmodell
  • 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:

dashboard-prozessmodell-2

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.

Ihre Dashboard-Themen besprechen ...

Robert Lochner

Robert Lochner ist seit 2001 als Unternehmer tätig und Gründer der Linearis. Seit seinem Betriebswirtschaftsstudium an der WU Wien ist er als Unternehmer in der BI Branche tätig, ist Trainer für Excel BI und Power BI und unterstützt Unternehmen bei der digitalen Transformation ihrer Business Intelligence Prozesse. Er ist Autor des Linearis Blogs und mehrerer fachlicher Publikationen.

Weitere Beiträge

Kategorien: Dashboarding, Excel als BI Frontend, Power BI im Team nutzen