Interview mit Lars Schubert, Geschäftsführer graphomate GmbH
Dashboards bieten großen geschäftlichen Nutzen, vorausgesetzt sie werden richtig eingesetzt. Sorgfältige Planung und Erfahrung, wie sich Nutzer verhalten, sind jedoch erforderlich, um das Beste aus ihnen herauszuholen.
Lars Schubert, Geschäftsführer der graphomate GmbH, hat sich der Visualisierung von Informationen verschrieben.
Im Interview verrät er, wie Unternehmen ihre Investitionen in Dashboards optimal nutzen können. Während sie Dashboards entwickeln, sollten sich die Mitarbeiter auf die Ziele fokussieren, um sicherzustellen, dass sich Dashboards auch auszahlen.
Infocient: Herr Schubert, was ist der größte Fehler, den Sie bei der Entwicklung von Dashboards in Unternehmen beobachten?
Lars Schubert: Schön, dass Sie direkt den Entwicklungsprozess eines Dashboards als Gesamtes und nicht nur die Frage des Information Designs ansprechen. Ich werde gerne gefragt: „Welches Chart empfehlen Sie für die Darstellung dieser Daten?“ Das sollte aber zunächst nicht im Vordergrund stehen.
Für die meisten Berichtsempfänger ist ein Dashboard zunächst einmal recht abstrakt: Man erhält Informationen visuell aufbereitet und kann ohne großen Lernaufwand in seinem Datenraum filtern und entsprechend definierter Navigationspfade vom Allgemeinen in Detaildaten springen, um relevante Fragestellungen zu beantworten und Entscheidungen zu unterstützen.
Das klingt zunächst einmal sehr einfach, aber irgendetwas scheint schief zu laufen: Immer wieder hört man von Dashboards, deren Akzeptanz und Nutzungshäufigkeit zu wünschen übrig lässt.
Wenn Sie mich nach dem größten Fehler bei der Dashboardentwicklung fragen, gibt es für mich nur eine Antwort: Ein bestehendes Excel-Reporting – verteilt auf mehreren Tabellenblättern – als Basis für ein Dashboard zu nutzen.
Ein Dashboard ist kein Excelbericht im Web. Ein Dashboard bietet so viel mehr an Interaktionsmöglichkeiten und folgt anderen Visualisierungsregeln als ein Excel-Bericht. Diese sollten unbedingt beim Design des Dashboards beachtet werden.
Dennoch erlebe ich diesen Ansatz immer wieder: Der IT wird ein Excelfile übergeben, dass sich in den letzten Jahren mit viel manuellem Aufwand als Standardberichtswesen etabliert hat. Man möge dies doch bitte als Dashboard umsetzen, so dass der manuelle monatliche Erstellungsaufwand entfällt.
„Ein Dashboard ist kein Excelbericht im Web.“
Infocient: Wie kann die Einführung und die Akzeptanz eines neu entwickelten Dashboards vorangetrieben werden?
Lars Schubert: Wesentlich ist für mich Zusammenarbeit zwischen IT und Empfängern des Dashboards – also der Fachbereiche. Klingt nach altem Hut, ist leider in der Praxis immer noch ein Thema. Wie oft habe ich auf die Frage: „Was möchten Sie in Ihrem Dashboard sehen?“ die Antwort: „Alles!“ oder gerne auch „So wie immer, wie unser Excel-Bericht eben“ gehört.
Natürlich ist es sinnvoll, die Inhalte des bestehenden (Excel-)Reportings zu kennen und diese mit in das Dashboard-Design einzubeziehen. Ja, die IT muss sich mit den fachlichen Konzepten der Fachbereiche auseinandersetzen und auch an Ihrer Wahrnehmung arbeiten, als Bremse im Reportingsprozess wahrgenommen zu werden.
Aber gleichzeitig gilt es auch, dass man sich im Fachbereich mit Data Warehouse-Konzepten beschäftigt, die über SVerweis-Funktionen in Excel hinaus gehen. Ohne ein einheitliches Verständnis und eine gemeinsame Herangehensweise ist erfolgreiches Dashboarding unmöglich.
Ich bin deshalb auch ein großer Verfechter sogenannter Business intelligence Competence Center (BICC), in denen IT- und Fachbereichsmitarbeiter zusammenarbeiten. Im Rahmen eines Dashboard-Projekts gilt es in gemeinsamen Workshops sowohl die technischen Möglichkeiten zu zeigen, als auch die fachlichen Anforderungen heraus zu arbeiten. Kein einfaches Unterfangen, denn wer gibt schon gern seine Entscheidungsmechanismen preis.
Ich sehe die Entwicklung eines Dashboards als iterativen Prozess: Man beginnt mit einer übersichtlichen Anwendung, hat aber das große Ganze im Blick. Ein Entscheider ist glücklich, wenn er nach sechs Wochen ein erstes – wenn auch noch nicht umfassendes – Dashboard erhält, das ihn schon bei einigen Entscheidungsfragen bedarfsgerecht unterstützt.
Hierbei hat es sich als sehr hilfreich erwiesen, vorab ein Notationshandbuch zur Standardisierung von Dashboard-Elementen zu formulieren. So ist sicher gestellt, dass die weiteren Entwicklungsschritte eines Dashboards konsistent sind und das Berichtswesen in einem Unternehmen vereinheitlich wird.
„Ohne ein einheitliches Verständnis und eine gemeinsame Herangehensweise ist erfolgreiches Dashboarding unmöglich.“
Infocient: Wie groß sollte die Detailtiefe eines Dashboards sein? Sollte man viele freie Elemente zur Wahl anbieten oder die Anwender lieber streng führen?
Lars Schubert: Das Angebot vieler freier Elemente widerspricht dem Konzept einer geführten Navigation eines Dashboards. Da bewegen wir uns mehr im Analytics/Self-Service-Umfeld.
Dashboards sind in Ihrem visuellen Erscheinungsbild starr: Man stelle sich eine Reporting-Hülle vor, die regelmäßig mit Daten zu füllen gilt. Dabei kann die Detailtiefe durchaus bis auf Belegebene gehen: Nur eben nicht in einer ersten Sicht, sondern nach etlichen Filterschritten, so dass nur noch relevante Details angezeigt werden. Ben Shneidermann hat diesen Aspekt mit seinem visual-seeking Mantra auf den Punkt gebracht:
„Overview first, zoom and filter, then details-on-demand“.
Infocient: Wie viel Aufwand sollten Unternehmen in die perfekte Optik von Dashboards stecken im Vergleich zu anderen Komponenten?
Lars Schubert: Schwierige Frage! Die aussagekräftigsten Visualisierungen bringen nichts, wenn die Datenbasis falsch ist. Es gilt immer: „shit-in, shit-out“. Dennoch ist die Frage des Erscheinungsbildes eines Dashboards für den Erfolg und die Akzeptanz ebenfalls von sehr hoher Bedeutung. Bei einem Greenfield-Ansatz zum Aufbau eines Dashboards würde ich die 80:20 Regel für die Aufteilung zwischen Backend- und Frontend-Aufwänden anwenden. Bei bestehender Datenbasis kann sich dieses Verhältnis auch zugunsten der perfekten Optik umkehren. Der Projektaufwand dürfte aber auch entsprechend geringer sein.
„Die Frage des Erscheinungsbildes eines Dashboards ist für den Erfolg und die Akzeptanz von sehr hoher Bedeutung.“
Abb. 1: Screenshot des Dashboards der Lufthansa Technik AG
Infocient: Können Sie vielleicht ein Beispiel eines gelungenen Projektes kurz skizzieren?
Schubert: Wir sind als Anbieter von Standard-Softwarekomponenten nur recht selten direkt im Entwicklungsprozess eines Dashboards involviert. Ich nenne allerdings immer gern ein Reporting-Projekt der Lufthansa Technik AG als Referenz, das sehr erfolgreich war und auch auf den DSAG Technologietagen 2016 vorgestellt wurde. Wir haben gemeinsam eine kurze Referenzstory verfasst, die Sie hier finden: Visualisierungen sorgen für Ordnung im Reporting
Besonders gefreut hat mich, dass mich der Projektverantwortliche nach dem Go-live anrief und mir sagte, dass er nach 15 Jahren als BI-Projektleiter das erste Mal ein rundum positives Feedback aus den Fachbereichen zu dem umgesetzten Dashboard erhalten habe. Das Thema Visualisierung von Informationen ist für Endanwender wohl tatsächlich ein wichtiger Bestandteil einer BI-Lösung.
Infocient: Ganz herzlichen Dank für dieses informative Gespräch.
Lars Schubert ist Geschäftsführer der graphomate GmbH aus Kiel und Partner von Infocient Consulting GmbH.
Kontakt: info@graphomate.com
