Die Datenplattform-Initiative hat leider nicht den gewünschten Erfolg gebracht.
Die harte Wahrheit ist: Die meisten Unternehmen verbrennen Millionen in Datenprojekten und landen am Ende doch nur bei ETL, Dashboards und PowerPoint-Charts. Warum? Bei Projekten von DAX-Unternehmen bis zum Mittelstand habe ich im Laufe der Jahre immer die gleichen Fehler beobachtet.
1. Ohne eine klare Datenstrategie entsteht nur Chaos.
Stellen wir uns vor, ein Haus würde ohne Bauplan errichtet werden. Jeder Handwerker würde nach eigenem Ermessen handeln. Das Ergebnis wäre eine Konstruktion mit einem Dach über dem Keller, einer Toilette im Wohnzimmer und einer Treppe, die ins Nichts führt. Genau so stellt sich die Datenlandschaft in den meisten Unternehmen dar. Jedes Team baut sein eigenes Silo, jeder Abteilungsleiter hat seine eigene „Wahrheit“ – und am Ende passt nichts zusammen. Letztlich manifestiert sich ein Zustand der Diskrepanz.
Eine Datenstrategie sollte nicht als 100-seitiges PDF verstanden werden, das in einer Schublade verstaubt. Sie agiert vielmehr wie ein Kompass, der die Prioritäten bestimmt. Ohne sie besteht die Gefahr, sich in endlosen Diskussionen über Tools, Technologien und „Best Practices“ zu verlieren, die von den meisten gar nicht verstanden werden. Es steht nicht zur Debatte, ob eine Strategie benötigt wird, sondern wie schnell sie erstellt werden kann – vor dem Hintergrund, dass das nächste Team sein eigenes Excel-Universum konstruiert.
2. Entweder Data Governance automatisieren – oder aufgeben.
Zu den Herausforderungen zählen unter anderem Excel-Listen, manuelle Freigabeprozesse und endlose E-Mail-Ketten. Wenn die Governance in diesem Fall nur Manuell erfolgt, ist die Skalierung nicht möglich. Sowohl für die betreffende Person als auch für alle anderen stellt die Integration einer neuen Datenquelle, die Erstellung eines neuen Dashboards oder die Aufnahme eines neuen Nutzers eine Herausforderung dar.
Automatisierung darf nicht als Luxus betrachtet werden, sondern ist eine Überlebensstrategie, um klare Richtlinien in Form von Code zu etablieren. Essenziell ist, dass sämtliche Prozesse automatisiert, transparent und für alle Beteiligten nachvollziehbar gestaltet werden. Andernfalls besteht die Gefahr, dass die manuelle Kontrolle als einzige Möglichkeit der Steuerung wahrgenommen wird.
3. Self-Service ist nicht optional, sondern Pflicht.
Es wird die Hypothese aufgestellt, dass für jede E-Mail ein IT-Ticket erstellt werden sollte. Daten stellen demnach kein exklusives Wissen dar, das nur einer elitären Gruppe von Experten vorbehalten wäre.
Die Verwendung des Begriffs „Self-Service” impliziert nicht zwangsläufig, dass alle Akteure SQL-Experten sind. Durch die Schaffung von Instrumentarien und Abläufen sollen Nicht-Techniker die Fähigkeit erhalten, autonome Problemlösungen zu erarbeiten. Dies erfolgt ohne die Notwendigkeit einer überlasteten Datenabteilung. Wenn die Datenabteilung diese Fähigkeit nicht erbringt, wird sie immer der Flaschenhals sein, der Innovation bremst.
4. Open Source und SQL schlagen proprietäre Blackboxes.
Komplexität ist kein Feature. Sie ist ein Fehler. Und doch stürzen sich viele Unternehmen gerne in teure, proprietäre Blackboxes, die niemand versteht und die am Ende nur den Anbieter reich machen. Warum? Weil „Enterprise“-Lösungen oft mit dem Versprechen verkauft werden, dass sie „alles können“. Diese Aussage ist mit einem gewissen Grad an Vorsicht zu genießen, denn es besteht die Option, dass die betreffenden Aufgaben auch mit Open Source und einer gewissen SQL-Kenntnis bewältigt werden können.
Technologie muss verständlich, portabel und kosteneffizient sein. Punkt. Wenn man sich in eine Lösung binded, die einen an einen Anbieter kettet, stellt man irgendwann fest, dass man nicht mehr Herr der eigenen Daten ist. Und dann ist es zu spät.
5. Infrastruktur muss versioniert werden.
Die Implementierung von Infrastructure-as-Code ist eine wesentliche Maßnahme, um die Stabilität der Plattform zu gewährleisten, Komplexität zu meistern und den Wartungsaufwand zu optimieren. Werden die Infrastrukturen nicht versioniert, dokumentiert und automatisiert, führt dies in der Regel zu einer unübersichtlichen Situation, die durch manuelle Änderungen, nicht dokumentierte Workarounds und die Konfiguration.
IaC ist keine optionale Zusatzfunktion, sondern ein essenzieller Bestandteil der Server-Konfiguration. Es bildet die Basis für alle nachfolgenden Aspekte. Wenn die aktuelle Erscheinungsform der Plattform nicht bekannt ist, ist es unmöglich, zukünftige Entwicklungen zu antizipieren. Wenn das Aufsetzen nicht reproduzierbar durchgeführt werden kann, ist eine Skalierung nicht realisierbar.
6. Kein Betrieb ohne Monitoring.
Pipelines und Machine-Learning-Modelle, die keiner Überwachung unterliegen, sind mit Fahrzeugen ohne Tacho vergleichbar. Es ist unklar, wann es zu einem Crash kommt und aus welchen Gründen. Es ist offensichtlich, dass die Messung von Variablen eine Basis schafft, die es ermöglicht, Abweichungen von Erwartungswerten zu identifizieren. Es ist davon auszugehen, dass das Vorhaben nicht von Erfolg gekrönt sein wird.
Monitoring ist kein Overhead. Die vorliegende Option ist die einzige Möglichkeit, Probleme zu identifizieren, bevor sie sich zu Katastrophen entwickeln. Die mangelnde Kenntnis über die Laufzeit der Pipelines sowie über die Häufigkeit und die Ursachen ihres Scheiterns sind charakteristische Merkmale eines unprofessionellen Umgangs mit Datenplattformen.
7. Dashboards allein schaffen noch keinen Mehrwert.
100 Dashboards, sie werden allerdings nicht genutzt. Datenprodukte müssen zwingend businessrelevant sein.
Sie müssen einen klar definierten Zweck erfüllen. Es ist von entscheidender Bedeutung, dass Sie sich nicht nur auf die Darstellung von Zahlen konzentrieren, sondern auch die Lösung von Problemen in den Mittelpunkt rücken. Wenn das Dashboard nicht dazu geeignet ist, Entscheidungen zu erleichtern, erfüllt es lediglich eine dekorative Funktion. Es besteht keinerlei Bedarf dafür.