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.