self_service_bi

SELF-SERVICE BI OHNE DATA WAREHOUSE?

Alle reden seit Jahren von Self-Service BI – Tools wie Tableau, Power BI etc. versetzen auch Fachanwender in die Lage, ohne großen Aufwand und technisches Knowhow ihre Daten zu analysieren und visualisieren.
Doch bei allem berechtigten Jubel erkennen auch immer mehr Unternehmen, dass es eben nicht reicht, einen großen Datentopf hinzustellen, aus dem sich jeder bedienen kann. Dies führt gerade bei mehreren Quellsystemen zwangsläufig zu Frustrationen, weil die Daten eben nicht so sauber und leicht verständlich sind, wie oft proklamiert wird. Außerdem konterkariert es das Ziel, einen „single point of truth“ zu etablieren. Im schlimmsten Fall hat jeder Benutzer eine andere persönliche Wahrheit vor sich…

In der Praxis führt das nun oft dazu, dass nur Fachanwender, oft aus dem Controlling, mit SQL-Abfragen in Microsoft Access oder sogar mit VBA-Makros eigene Zugriffsroutinen auf Daten implementieren, die aber für alle anderen schwer verständlich und daher kaum wartbar sind.
Muss man nun doch die IT einschalten und ein teures und langwieriges Data-Warehouse-Projekt in die Wege leiten – mit vielen externen Beratern und entsprechendem Aufwand an Abstimmung und Ressourceneinsatz? Wie soll man damit agil sein und sich schnell an die zwangsläufigen Änderungen im Business anpassen können?
Zwischen Extremen findet man oft einen guten Mittelweg – und hier kommen wir zum Thema Self Service ETL. ETL steht für Extrahieren, Transformieren und Laden – d.h. für die Kernaufgaben, die nötig sind, um saubere und konsistente Daten für die weitere Verwendung zu gewinnen.

WELCHE ARCHITEKTUR IST NÖTIG?

Wer Self-Service BI erfolgreich verbreiten will, sollte seinen Fachanwendern saubere, integrierte und historisierte Daten in einem leicht verständlichen Tabellenschema („Stern“) zur Verfügung stellen, damit die Analysewerkzeuge wie Power BI, Tableau, Qlik und viele mehr effektiv arbeiten können. Aus der täglichen Arbeit wissen viele Fachanwender, welche Quelldaten wirklich wichtig sind, bis hin zu Tabellennamen und Fehlerkorrekturen im Quellsystem. Wenn sie das richtige Werkzeug bekommen, und wenn man ihnen klar vermittelt, wie die Tabellen im Zielsystem „Data Warehouse“ aussehen sollen, können sie das entscheidende „missing link“ in einem solchen Projekt sein.