Teil 2: Datengetriebene Unternehmenssteuerung: Fachliche Anforderungen und Struktur
Welche fachlichen Fragen möchten wir durch eine stabile Datenbasis beantworten? Und wer benötigt die Antwort auf die Fragen? Wie man von der Idee der Datennutzung zu einer fachlichen Strukturierung einer Datenbasis kommt, ist Inhalt dieses Artikels.
Die Rückendeckung der Geschäftsführung
Im vorangegangenen Artikel wurden verschiedene Auslöser für die Planung eines automatisierten Unternehmensreportings genannt und Erwartungen, die uns bei unserem eigenen Datenprojekt aber auch in Kundenprojekten immer wieder begegnen. Diese können entweder aus dem Kreise der Mitarbeiter kommen, z.B. denen, die regelmäßig viel Zeit für Reporting an die Geschäftsleitung verwenden. Oder aus dem Management direkt, z.B. weil zu jeder Zeit die aktuellen Zahlen zur Verfügung stehen sollen.
Die notwendigen Regelungen zum Aufbau einer Datenbasis und dessen Nutzung im Unternehmen erfordern mindestens die Mitwirkung des Managements, besser noch das aktive Vorantreiben der notwendigen Tätigkeiten. Gerade im Bereich der Data Governance sind strategische Entscheidungen zu treffen, die in die gesamte Unternehmensstrategie eingebettet sein müssen und die nicht selten mit anderen Prozessen oder Zielen in Konflikt stehen. Zudem ist der Aufwand personeller und finanzieller Art nicht unerheblich, sodass auch seitens Budget Rückendeckung notwendig ist.
Was wollen wir wissen? Anforderungen erheben und die richtigen Fragen stellen
Die Sammlung der Anforderungen kann von verschiedenen Seiten begonnen werden: Top Down oder Bottom Up.
Wenn man nun den Top-Down Ansatz mit den Use Cases betrachtet, so kann man im Fall schon vorhandener, manuell erstellter Berichte von diesen Fragestellungen ausgehen und die Anforderungssammlung vom Nutzer her bzw. aus fachlicher Sichtweise beginnen.
Auch bei bewährten Berichten ist es sinnvoll, sich Gedanken zu jeder Fragestellung zu machen und unabhängig von Tools und Darstellung die Anforderungen zu strukturieren. Ein Bericht kann mehrere Use Cases enthalten, nicht zuletzt bei einem zusammenfassenden Überblick über alle KPIs auf höchster Aggregationsstufe.
Für alle Use Cases sollten mindestens folgende Fragen beantwortet werden:
|
In unserem internen Datenprojekt Datenhub wurden bestehende, manuelle Berichte als Absprungpunkt genommen und zunächst die Frage bearbeitet, wie erfolgreich die Projekte finanziell sind. Nachdem für uns als Dienstleister die Projekte das produzierte Gut sind, ist das eine sehr zentrale Fragestellung für viele weitere Analysen. Zunächst wurde begonnen, abgeschlossene Projekte zu analysieren und die KPIs Projektertrag, Rendite, interne und externe Kosten auszuweisen. Zu späteren Zeitpunkten kamen weitere KPIs hinzu, die auch auf laufende Projekte mit linearer Fortschreibung angewandt wurden. Mit zunehmender Kenntnis der Einflüsse und Indikatoren bildeten sich zudem darauf aufbauende KPIs aus, die den Erfolg des Projektgeschehens in der Firma abbilden.
Abbildung 1: Datenstrategie Top Down oder Bottom up; Quelle: eigene Darstellung: https://blog.doubleslash.de/mit-predictive-maintenance-den-business-value-maximieren/
Von der Fragestellung zum Datenangebot
In den Use Cases/Fragestellungen ist oftmals schon klar, welche Datenquellen für die Beantwortung in Frage kommen. Gerade in größeren Unternehmen kommt es aber immer wieder vor, dass ein potentieller Datentopf aufwändig gesucht werden muss und eine Anbindung durch zahlreiche Prozesse langwierig ist. Die vorbereitenden Maßnahmen sind nicht selten mit erheblichen Aufwänden verbunden, bevor überhaupt der erste Datenabzug eingesehen werden kann. Sehr viel Aufwand kann bei der Datenvorbereitung gespart werden, die Quellen gegebenenfalls mit wenig Anpassung für mehrere Use Cases bereitstellen kann.
In unserem Fall basiert die initiale Fragestellung nach dem finanziellen Erfolg der Projekte auf Daten aus zwei Systemen: den vertraglich vereinbarten Preisen und Rahmenbedingungen, wie z.B. die Laufzeit mit dem Kunden auf der einen Seite und den Stundenbuchungen der Projektmitarbeiter und weiteren Ausgaben im Rahmen des Projekts auf der anderen Seite. Dadurch waren an dieser Stelle schon zwei Systeme involviert, deren Daten in Zusammenhang gebracht werden mussten. Die beiden Systeme wurden nicht zur gleichen Zeit eingeführt und hatten deshalb unterschiedliche Zeitspannen historischer Daten. Der Aufwand, Altdaten aus dem zuvor abgelösten System zu überführen, überstieg den Nutzen bei weitem und wurde deshalb explizit ausgeschlossen. Die historischen Daten reichen so weit zurück wie das jüngere beider Systeme im Unternehmen eingeführt wurde.
Zu den für und von uns entwickelten Fragestellungen wurden auch weltweit standardisierte KPIs genutzt, die nicht eigens definiert werden mussten und zum Teil für ein externes Reporting in vergleichbarer Form gebraucht werden wie z.B. Eigenkapitalquote oder EBIT (Earnings before interests and tax).
Als Stakeholder des initialen Use Cases zum Projekterfolg wurde der Führungskreis und die Teamleiter gesehen. Dort waren die Berechtigungen nicht weiter unterteilt. Es wurde aber zu Beginn des Datenprojektes festgelegt, dass keine mitarbeiterbezogenen Daten ausgewertet werden.
Vom Datenangebot her betrachtet hatten wir mindestens diese zwei Systeme mit mehreren Datensätzen. Würde man von dieser anwenderbezogenen Sichtweise ausgehen, beginnt man mit der Prüfung von technischer und fachlicher Qualität und stellt sich die Frage, zu welchen fachlichen Fragestellungen sich die Daten bereitstellen oder verbinden lassen. Wenn es das wesentliche Ziel ist, dass viele Anwender im Selfservice bereitgestellte Datenquellen nutzen, ist dieser Blickwinkel nicht zu vernachlässigen.
Oft ist der Top Down Ansatz vorherrschend, weil es dann Stakeholder gibt, die Fragen beantworten müssen und deshalb Antworten in Daten suchen und diese einfordern. Zudem ist der fachliche Qualitätsanspruch im Fokus des Stakeholders.
Fazit
Entscheidend für das Gelingen eines Datenprojektes ist die Rückendeckung der Geschäftsführung. In unserem Datenprojekt gab es zunächst Anforderungen für bestehende Berichte und alles weitere entwickelte sich nach den ersten Erfahrungen. Wenn für jeden Bericht die Fragen zu Use Cases und Stakeholder geklärt werden, hat das den Vorteil, dass durch die Strukturierung gegebenenfalls Fragestellungen zusammengefasst und damit Aufwände durch Redundanz reduziert werden können. Für die richtigen Fragestellungen kann man entweder top down oder bottom up vorgehen.
Nicht selten wird die dargestellte Strukturierung erst nach schon begonnener Nutzung der Daten vorgenommen – wenn mittels Konsolidierung (wieder) fachliche Struktur in die wachsende Zahl von Datenquellen gebracht werden muss. Eine Struktur kann aus verschiedenen Gründen durchaus Änderungen erfahren, muss aber konsequent für die gesamte Datenbasis gelten, um für verlässliche Qualität und Nachvollziehbarkeit zu sorgen. Für eher unbeliebte aber notwendige Prozesse der Data Governance ist es unabdingbar, sich zu Use Cases und deren Stakeholdern und möglichen Berechtigungen Gedanken zu machen.
