Wie ich über Business Value in Data denke
Datenprojekte scheitern selten an der Technologie. Sie scheitern, weil der Nutzen zu spät, in der falschen Form oder zu hohem Aufwand entsteht.
Ich arbeite seit dem Jahr 2000 im Bereich Data Warehousing. In dieser Zeit habe ich Technologien kommen und gehen sehen, Architekturen aufsteigen und fallen – und viele „nächste große Dinge" still wieder verschwinden sehen. Was sich nicht verändert hat, ist die Frage, die immer wieder gestellt wird:
Wie schöpfen wir Wert aus Daten?
Nicht theoretischen Wert. Nicht etwas, das wir für „Phase drei" versprechen. Echten Wert, der einem Unternehmen hilft, bessere Entscheidungen zu treffen, mehr Umsatz zu erzielen oder Kosten zu senken.
Je länger ich in diesem Bereich arbeite, desto mehr wird mir klar: Die Antwort ist viel einfacher, als die meisten Datendiskussionen vermuten lassen.
Warum wir uns überhaupt mit Daten beschäftigen
Wir verwalten Daten nicht, weil es interessant ist. Wir bauen Plattformen nicht, weil es Spaß macht. Wir tun es, weil Daten dem Unternehmen nützen sollen.
In der Praxis zeigt sich dieser Nutzen fast immer auf genau zwei Arten:
- Umsatz steigern
- Kosten senken
Natürlich gibt es Ausnahmen. Regulatorisches Reporting ist ein gutes Beispiel. Niemand brennt darauf, einen DSGVO-Bericht zu erstellen – aber wir tun es, weil wir müssen. Dennoch ist Business Value bei den meisten Initiativen der eigentliche Treiber.
Wann immer ich mir ein Datenprojekt anschaue, beginne ich immer mit einer einzigen Frage: Welches Business-Ziel soll dieses Projekt unterstützen?
Was Daten wirklich wertvoll macht
Im Laufe der Jahre habe ich festgestellt: Wert entsteht nicht durch Komplexität oder Raffinesse. Er entsteht durch einige sehr praktische Dinge.
Meiner Erfahrung nach erzeugen Daten dann Wert, wenn:
- Sie früh ankommen: Wertvolle Erkenntnisse wirken wie ein Zinseszins. Jeder Monat Verzögerung mindert still und leise das mögliche Potenzial.
- Sie effizient geliefert werden: Selbst großartige Ideen verlieren an Wert, wenn ihre Umsetzung zu lange dauert oder zu viel Aufwand erfordert.
- Sie die richtigen Fragen beantworten: Geschäftsprioritäten ändern sich ständig – Quartalsabschlüsse, Strategiewechsel, neue Regularien. Data Teams müssen reagieren können, ohne von vorne anzufangen.
Zusammengefasst läuft es auf Folgendes hinaus: Wert entsteht, indem die richtigen Dinge früh und ohne verschwendeten Aufwand geliefert werden.
Warum „Agilität" nicht der Kern der Sache ist
Über Agilität in Datenprojekten wird viel gesprochen. Ich habe aber aufgehört, dieses Wort gegenüber Business-Stakeholdern zu verwenden. Nicht weil Agilität unwichtig wäre – sondern weil das Wort außerhalb der IT wenig bedeutet.
Was hingegen jeder versteht, ist Verzögerung.
Wenn eine wichtige Erkenntnis zu spät eintrifft, ist auch die darauf basierte Entscheidung zu spät. Und diese Verzögerung hat ihren Preis. Manchmal entgangener Umsatz. Manchmal unnötige Ausgaben. Manchmal einfach verpasste Chancen.
So denke ich über Agilität: Es geht schlicht darum, die Kosten von Verzögerung zu reduzieren. Automatisierung, Tools und Frameworks sind nur relevant, wenn sie uns dabei helfen.
Warum große „perfekte" Lösungen selten überleben
Am Anfang meiner Karriere haben wir monatelang unternehmensweite Datenmodelle entworfen. Sie waren beeindruckend – und oft irrelevant, sobald sie in Betrieb gingen. Das Business bewegt sich schneller als Designdokumente. Deshalb glaube ich nicht mehr an große, vorab definierte Lösungen. Ich glaube an:
-
Klein anfangen
-
Schnell etwas Nützliches liefern
-
Kontinuierlich anpassen, wenn sich Anforderungen ändern
Eine leicht unvollkommene Lösung, die heute nützlich ist, schlägt eine perfekte, die zu spät kommt.
Der Teil, den alle gerne überspringen möchten
Viele Teams versuchen, die unordentliche Mitte der Datenarbeit zu umgehen – Integration, Historie, gemeinsame Definitionen – in der Hoffnung, dass sich das irgendwie von selbst löst. Das passiert selten. Ich habe gesehen, was passiert, wenn jeder Schlüsselbegriffe auf eigene Faust definiert. Selbst wenn jede Definition für sich genommen sinnvoll ist, entsteht daraus Verwirrung, Nacharbeit und endlose Diskussionen. Egal welche Architektur gewählt wird: Data Lake, Data Mesh, zentralisiert oder dezentralisiert. Man braucht dennoch:
-
Gemeinsame Definitionen
-
Konsistente Logik
-
Eine Stelle, an der Daten integriert und verstanden werden
Diese Mittelschicht ist unvermeidbar.
Wenn Data Teams zu Softwareunternehmen werden
Ein weiteres Muster, das ich häufig sehe, beginnt mit guten Absichten. Unternehmen wollen Flexibilität und stellen deshalb einen Stack aus Open-Source-Tools zusammen und bauen ihre eigene Plattform.
Was sie dabei oft nicht bemerken: Sie haben sich gerade einen Zweitjob genommen.
Plötzlich liefert das Data Team nicht nur Erkenntnisse. Es wartet auch Frameworks, aktualisiert Tools, dokumentiert individuelle Lösungen und schult neue Kolleginnen und Kollegen in einem Setup ein, das nur in diesem Unternehmen existiert.
Ich stelle hier gerne eine einfache Frage: Wenn Data Management so komplex ist wie ERP – würden Sie Ihr eigenes ERP-System bauen?
Die meisten Unternehmen würden das nicht tun – und das aus guten Gründen. Dieselbe Logik sollte für Datenplattformen gelten.
Warum Automatisierung meine Perspektive verändert hat
Automatisierung beseitigt nicht alle Komplexität, aber sie eliminiert einen Großteil der repetitiven, wenig wertschöpfenden Arbeit. Gut eingesetzt hilft sie Teams dabei:
-
Wert früher zu liefern
-
Sich schneller an veränderte Prioritäten anzupassen
-
Langfristige Wartungsaufwände und Risiken zu reduzieren
Und vor allem: Sie gibt Menschen die Freiheit, sich auf das Verstehen des Business zu konzentrieren – statt auf das Reparieren von Infrastruktur.
Was ich nach all diesen Jahren gelernt habe
Wenn ich eines mitgeben könnte, dann das:
Datenprojekte scheitern nicht, weil Menschen inkompetent sind. Sie scheitern, weil der Wert zu spät ankommt, in der falschen Form, oder zu hohem Aufwand.
Wenn wir nah am Business bleiben, die Dinge einfach halten, früh liefern und automatisieren, was keine menschliche Kreativität erfordert, kann Daten endlich das leisten, wofür es immer gedacht war – Menschen helfen, bessere Entscheidungen zu treffen.
Und darum geht es bei dieser Arbeit letztlich.