Datenstrategie eines Unternehmens

[22.11.2022]

Oft stellen sich in einem Unternehmen die Fragen: „Können wir diesen Bericht automatisieren?“ oder „Können wir diesen Bericht erweitern und auch nach Dimension-X gruppiert ausgeben?“.  In diesem Artikel gehen wir darauf ein, wie man mit solchen Fragestellungen umgehen kann und warum es gerade hier seitens Unternehmens wichtig ist, eine vordefinierte Datenstrategie zu haben.

1. Drei provozierende mögliche Folgereaktionen:

a) Niemand nimmt sich der Fragestellung an und der Report wird bei Bedarf manuell erzeugt.

b) Ein Verantwortlicher nimmt sich der Fragestellung an, daraufhin wird ein Report definiert und über
     ein Medium bereitgestellt, z.B. via E-Mail.

c) Eine View (vordefinierte SQL-Abfrage die beim Aufrufen ausgeführt wird) wird entwickelt,
     bereitgestellt und kann z.B. in Excel von wissenden Personen genutzt werden.

Je nach Unternehmen kann es sein, dass diese Lösungen die betroffenen Stakeholder zufriedenstellen. Problematisch wird es, wenn:

• Nicht jedem bekannt ist, wo welcher Bericht gefunden werden kann
• Berichte frei zugänglich sind und sensible Daten nicht geschützt sind
• Berichte nicht frei zugänglich sind und somit der Zugriff für die Verantwortlichen nicht möglich ist
• Nicht verständlich ist, wie die Daten erhoben wurden, auf denen der Bericht aufbaut.
• Weitere Reports erwünscht sind, die allerdings auf einer anderen Datenbasis beruhen und
• somit andere (und ggfs. widersprechende) „Antworten“ liefern könnten als der bisherige Bericht

2. Warum eine Datenstrategie notwendig ist

Um obige Fallstricke zu vermeiden, sollte vorerst eine Datenstrategie definiert und implementiert werden. Das Ziel einer Datenstrategie ist es, Unternehmensdaten zu strukturieren und auf deren Basis datengetriebene Entscheidungen zu fällen. Je nachdem, wie weit man den Begriff fasst, inkludiert dies unter anderem auch das Hinterfragen, Überarbeiten und Optimieren von Prozessen. In diesem Blogpost geht es allerdings nur um die Datenstrategie für eine bestehende Datenlandschaft und wie man hieraus Erkenntnisse gewinnt und das ganze skalierbar aufsetzt.

Konkret könnte das bedeuten, dass ein Kunde Transparenz im Bereich Verkauf und Auftragseingang haben möchte. Dafür muss geklärt werden, welche Daten dafür nötig sind und in welchen Quellsystemen diese vorhanden sind.

Da eine einzelne Zahl, wie bspw. 10Mio EUR Umsatz pro Jahr nur eine bedingte Aussagekraft hat, ist es nötig „Reporting Dimensionen“ mit einzubeziehen. Eine Dimension lässt sich leicht identifizieren, wenn man fragen kann: „Nach was will ich meine/n Umsatz/Auftragseingang/Rohmarge/.. reporten?“. Hierbei kann es sich um Zeitdimensionen, Kundendimensionen und Artikeldimensionen wie z.B. Artikelbezeichnung und Artikelgruppe handeln. Natürlich hat jede Branche und jeder Reporting-Bereich eigene Dimensionen, die unterschiedlich erhoben und definiert werden müssen. Ein gutes Beispiel sind „einmalige Umsätze vs. wiederkehrende Umsätze“ (typisch für SaaS basierte Unternehmen, engl: Software as a Service). Diese haben andere Reportinganforderungen und typischerweise auch andere „Reporting Dimensionen“, wie traditionelle one-off Unternehmen.

3. Datenquellen analysieren und synchronisieren

Sind alle Quellen definiert, müssen diese in ein Data Warehouse (DWH) integriert werden. Die Datenquellen sollten so synchronisiert werden, dass alle Datenquellen zur gleichen Zeit, z.B. stündlich/täglich/.. in das DWH geladen werden. Hier bestimmt die „langsamste“ Quelle die Frequenz gleicher Daten. Geht man z.B. von einem Unternehmen aus, welches direkten und indirekten Umsatz generiert, also z.B. über externe Vertriebler, so könnten die Auftragseingangsdaten wie folgt gepflegt werden:

• Daten der eigenen Vertriebler täglich im ERP-System
• Versand der Daten der externen Vertriebler einmal pro Woche in Excel

Das heißt, das DWH sollte wöchentlich - nach Erhalt der Excel Datei - aktualisiert werden. Natürlich kann man das DWH auch täglich aktualisieren, dies ist eine Designentscheidung, die von den Stakeholdern getroffen werden muss und subsequent im Reportdesign berücksichtigt wird.

4. Shit in, shit out

Sind alle Quellen integriert, so müssen diese überprüft und bereinigt werden. Da die Datenqualität verschiedener Quellen stark variieren kann, ist generell anzunehmen, dass Datenbank-basierte Quellen eine höhere Datenqualität aufweisen (Excel vs Datenbank). So müssen beispielsweise Eingabe-basierte Fehler korrigiert werden, z.B. kann der gleiche Kunde zwei mal existieren, einmal mit Schreibfehler und einmal ohne. Im besten Fall werden diese Stammdatenfehler durch das finale Reporting transparent und werden subsequent im Quellsystem behoben. Alternativ können natürlich auch Daten systematisch im DWH bereinigt werden. Die Sinnhaftigkeit von solch einer Bereinigung ist auf einer case to case Basis abzuwägen.

Sind die Daten bereinigt, so können Aggregationen gebildet werden, die nicht im Quellsystem vorhanden sind. Ländernamen können beispielweise in Regionen aggregiert werden und Kundennamen können nach Fakturierungsland in Fakturierungsregionen aggregiert werden. Wichtig ist hierbei nur, dass diese Aggregationen algorithmisch definierbar und robust gegenüber neuen Daten sind, d.h. dass auch bei neuen Datensätzen die Aggregierungslogik automatisch einsetzbar ist.

Generell ist jedes Reporting nur so gut, wie die Daten, die reported werden. Sind falsche Daten im Quellsystem, werden falsche Daten im Report angezeigt oder in der Datenbereinigung abgefangen. Auch hier muss auf einer case to case Basis abgewogen werden, wie mit „falschen“ Daten umzugehen ist.

5. Zeitplan: As soon as possible

Zurück zu der initialen, provozierenden Fragestellung am Anfang dieses Blogposts. Wann sollte eine Datenstrategie definiert werden? Im besten Fall, bevor das DWH aufgesetzt wird und somit auch, bevor ein DWH basiertes Reporting eingeführt wird. Da dies für eine Vielzahl von Stakeholdern relevant sein wird, sollte man frühzeitig mit dem Aufsetzen einer Datenstrategie beginnen und das ganze vollumfänglich planen, um nicht zum Schluss einen „Datenflickenteppich“ vorzufinden.

Außerdem ist es sinnvoll, eine Datenstrategie schrittweise zu implementieren, d.h. Bereich für Bereich folgende Schritte zu durchlaufen: Datenquellen ins DWH integrieren, diese zu validieren und final zu reporten. Abschließend sollten einhergehend mit dem Reporting Prozesse definiert werden, die die Datenqualität kontinuierlich verbessern und subsequent das Reporting stärken. Wann? Am besten gestern.