Management von Datenprojekten oder "how to build a dashboard"

[20.09.2022]

Nach dem Artikel Excel vs. Datenbanken geht es in diesem Post über das Management von Datenprojekten.

 

Datenprojekte sind vielfältig und meist hoch individuell. Trotzdem kann man vogelperspektivisch einen Überblick darüber geben, was sich dahinter verbirgt, welche Stolpersteine auftreten können und wie wir das ganze bei base camp strukturieren.

 

1. Stakeholder Management und Planung

Neue Projekte entstehen nicht einfach so, meist kommt der Wunsch für ein Datenprojekt beziehungsweise die Resultate dessen, von einem oder mehreren Stakeholdern. Dies kann eine Person oder eine ganze Abteilung sein. Daher muss initial geklärt werden, welche Erwartungen existieren. Typischerweise äußern sich diese in Form eines finalen Produkts (Dashboard, Reporting) oder dem Wunsch nach Automatisierung von Prozessen (Arbeitsreduktion).

Im Folgenden gehen wir davon aus, dass der oder die Stakeholder sich einen automatisierten Cash Bericht wünschen, der die Liquidität der kommenden Wochen voraussagt (Task).

Dieser Bericht soll auf einem Set von Annahmen basieren (1) und für bestimmte Personen bereitgestellt werden (2) und zudem jeden Montag um 8:00 Uhr verfügbar sein (3).

Gibt es bereits eine manuelle oder veraltete Version eines solchen Berichtes, so kann man diesen als Grundlage nehmen, um besser verstehen zu können, welche Vorstellungen die Stakeholder an das finale Produkt haben (4).

Meist ist der Initiator des Projekts nicht unbedingt der Projektverantwortliche. Es wäre also noch zu klären, wer das Thema auf Kundenseite fachlich vertritt (5) und der interne Ansprechpartner bei Rückfragen ist.

 

2. Assessment - Status quo Projekt (Task)

Im Folgenden werden nun die oben numerisch erwähnten Punkte aufgearbeitet; teilweise anhand von bereitgestellten Informationen oder im Gespräch mit den respektiven Stakeholdern. Speziell die Punkte 1 und 4, das Set von Annahmen auf dem der Cash Bericht aufgebaut wird und wie der Forecast definiert werden soll, kann sehr komplex werden und ggfs. mehrere Termine in Anspruch nehmen.

 

3. Quellsysteme

Parallel zum Assessment schauen wir uns direkt die verfügbaren Daten an. Das heißt, sowohl im Software Frontend z.B. in der Benutzeroberfläche von SAP, Salesforce oder ähnlichen Anwendungen als auch im Backend, also auf den Datenbanken der genannten Applikationen. Hier fließt bereits einiges an technischem Know-how mit ein, in das wir hier aber nicht weiter eingehen werden (Stichwort: Daten Anbindung).

 

4. Assessment – Status quo data quality

Nachdem die Daten im Backend gesichtet sind, werden diese hinsichtlich verschiedener Kriterien, wie bspw. Vollständigkeit und Korrektheit evaluiert. Anschließend wird für die Validierung der Daten eine Überleitung zu den Auswertungen des IST-Systems durchgeführt (Abgleich mit bestehenden Auswertungen/Reports).

 

5. Infrastruktur des Data Warehouse (DWH) & Datenflüsse

Im Folgenden sehen wir den Datenfluss eines simplifizierten und generischen Projekts. Auf der linken Seite existieren diverse exemplarische Quellen, die angebunden und in das Data Warenhause (DWH) geladen werden. 

Die Pfeile von den Quellsystemen zum DWH beschreiben die drei Prozesse: Extraktion, Transformation und Beladung (engl.: Extraction, Transformation, Loading: ETL) des DWH. ETL Prozesse sind Kernbestandteil jedes Datenprojekts, in welche wir hier aus Komplexitätsgründen nicht weiter eingehen.

Um auf das Liquidität Reporting zurückzukommen: Sind nun alle Daten im ETL-Prozess angebunden, gesäubert und für das Reporting aufbereitet, können diese im Reporting Tool visualisiert und veröffentlicht werden. Wir nutzen dafür gerne PowerBI, da dies als Microsoft Produkt leicht von unseren Kunden administriert werden kann (Stichwort: Produktkosten und Einbindung in die Softwarelandschaft des Kunden).

 

6. Automatisierung & Freigabe

Sind alle ETL Prozesse implementiert und validiert, so kann man diese automatisieren, das heißt nach bestimmten Mustern auslösen. In unserem Fall wäre die Bedingung, wie in Punkt 3 erwähnt, dass der Report montags um 8:00 Uhr zur Verfügung stehen muss. Daher würden wir den ETL Prozess so einstellen, dass er montags mit genug Vorlaufzeit bspw. um 5:00 Uhr morgens, ausgeführt wird.

Durch das Ausführen außerhalb der Arbeitszeiten reduziert sich außerdem die Last auf dem Live-System und die Daten stehen anschließend zur Verfügung und können - ebenfalls automatisiert - in das Reporting Tool geladen werden.

Abschließend wird das Reporting dem Kunden bzw. den in Punkt 2 definierten Verantwortlichen freigegeben. Nach einer initialen „trial“ Period in welcher noch Änderungen vorgenommen werden können, wird der Report schließlich ausgerollt und final veröffentlicht.

 

7. Fazit

Datengetriebene Projekte sind sehr komplex, da viele Stakeholder beteiligt sind. Zusätzlich stellt die Vielzahl an möglichen Software- und Technologieprodukten eine weitere Herausforderung dar, da diese automatisiert miteinander harmonieren sollen. Die obigen Punkte beschreiben simplifiziert die nötigen Prozessschritte vom Design bis zur Implementierung, natürlich zum Zwecke der fachfremden Darstellung, stark vereinfacht. Haben Sie Fragen zu speziellen Datenprojekten oder zu den einzelnen Schritten, setzen Sie sich gerne mit uns in Verbindung.

Autor Maximilian Löffel