This article is also available in English
TL;DR
- Kernproblem: Datenplattformen scheitern nicht an der Technik, sondern daran, dass Mitarbeitenden die Kompetenz fehlt, mit Daten sinnvoll zu arbeiten.
- Kreislauf: Datenzugang und Datenkompetenz verstärken sich gegenseitig – Zugang weckt Neugier, Kompetenz steigert Nutzung und Nutzung erzeugt neue Daten.
- Motivation: Der individuelle Nutzen überzeugt mehr als Unternehmensziele – Führungskräfte müssen Datenarbeit vorleben, nicht nur einfordern.
- Lernsystem: Enabling-Teams, Communities of Practice und eine menschenzentrierte Plattform machen aus einem Technikprojekt einen sozialen Lernprozess.
- KI-Realitätscheck: Gerade weil KI-Antworten überzeugend klingen, ist Datenkompetenz die Voraussetzung, um Fehler zu erkennen.
Das Wechselspiel von Data Literacy und Data Access
Es gibt einige Definitionen von Data Literacy (Datenkompetenz). Mir gefällt die Definition von Jordan Morrow in seinem Buch Be Data Literate sehr gut. Ich habe versucht, sie sinngemäß ins Deutsche zu übersetzen:
Data Literacy ist die Fähigkeit, Daten zu lesen, mit ihnen zu arbeiten, sie zu analysieren und mit ihnen zu kommunizieren. (Morrow, 2024, S. 36, eigene Übersetzung)
Morrow schreibt außerdem, dass nicht alle Menschen Data Scientists werden müssen, aber die genannten Fähigkeiten im Grunde haben sollten, um sich in der Welt behaupten zu können. Ohne Zugang zu den Daten bleiben solche Lernbemühungen in meinen Augen leider weitestgehend theoretisch. Durch föderierte und datenproduktorientierte Datenarchitekturen wie Data Mesh kann dieses Problem gelindert werden, denn Unternehmen, die solche Konzepte umsetzen, sollten, wo rechtlich möglich, auch Zugriff auf alle Daten im Unternehmen ermöglichen. Eine solche offene Datenverfügbarkeit führt jedoch ohne Datenkompetenz zu Chaos, denn ohne die Kompetenz, Daten zu verstehen und Tools zu benutzen, ist die Wahrscheinlichkeit von Fehlinterpretationen sehr hoch. Gemeinsam bilden Datenverfügbarkeit und Data Literacy aber einen symbiotischen Kreislauf:
Wenn wir die Möglichkeit erhalten, auf für uns relevante Daten zuzugreifen (Data Access), kann sich Neugier entwickeln (Curiosity). Diese Neugier schafft die Grundlage für eine Lernmotivation (Learning), die zu neuen Kompetenzen bei der Arbeit mit Daten führt. Diese Data Literacy hat den gewünschten Effekt: Die Plattform wird genutzt (Platform Usage), was wiederum zu einer größeren Vielfalt von Daten (Data Variety) auf der Plattform führt. Dadurch werden weitere Daten verfügbar, die wiederum für andere von Interesse sein können, und der Kreislauf geht weiter.
Eine gut gestaltete Datenplattform verstärkt diesen Zyklus: Sie macht Daten zugänglich und unterstützt die Nutzer:innen dabei, verantwortungsvoll mit ihnen umzugehen. Architekturen, die die Verantwortung für Daten auf die Teams verteilen, die diese am besten kennen, können diese Grundlage bieten. Ich verstehe darunter Architekturen, bei denen nicht ein zentrales Datenteam alle Daten verwaltet und bereitstellt, sondern die fachlichen Domänen selbst als eigenverantwortliche Eigentümer:innen ihrer Datenprodukte auftreten. Ein Datenprodukt ist dabei mehr als ein Datensatz: Es ist ein klar definiertes, dokumentiertes und verlässlich gepflegtes Datenangebot, das gezielt für die Nutzung durch andere entwickelt wurde. Wenn ich in diesem Artikel von datenproduktorientierten Architekturen spreche, dann meine ich damit nicht unbedingt ein vollständig ausgereiftes Data Mesh nach Zhamak Dehghani. Ich beschreibe ein Spektrum von ersten Schritten in Richtung dezentraler Datenverantwortung bis hin zur vollständigen Umsetzung der vier Prinzipien. Der Kern bleibt jedoch bestehen: Datenverantwortung gehört in die Teams, die die Daten kennen.
Durch den anhaltend rasanten Aufstieg von Large Language Models wird dieser Kreislauf noch relevanter, da der Wert dieser Technologien von der Qualität der zugrunde liegenden Daten abhängt. Unternehmen, die über keine belastbaren, gut strukturierten und zugänglichen Daten verfügen, werden auch aus KI-Initiativen nur wenig Nutzen ziehen können. Data Literacy und eine solide Datenarchitektur sind somit nicht nur Voraussetzung für datengetriebene Entscheidungen, sondern auch Grundlage für den sinnvollen Einsatz von KI.
Doch wie können wir erreichen, dass unsere Mitarbeitenden die relevanten Tools tatsächlich nutzen und verstehen, wie sie diese richtig einsetzen, um Daten korrekt zu interpretieren? Die Antwort darauf ist einfach, die Umsetzung dessen aber das Gegenteil: Organisationen benötigen data-literate Mitarbeitende.
„Was habe ich davon?”: Interesse an Data Literacy schaffen
Die Motivation, mit Daten arbeiten zu wollen, ergibt sich nicht immer von allein. Im Buch Humanizing Data Strategy beschreibt Tiankai Feng (2024) mehrere spannende Möglichkeiten, wie Datenstrategien nachhaltig umgesetzt werden können. Hervorheben möchte ich jedoch einen bestimmten Punkt: Der individuelle Nutzen ist für Mitarbeitende mindestens genauso motivierend wie der Nutzen für die Organisation. Menschen nutzen Daten, wenn diese ihren Arbeitsalltag erleichtern. Wenn die angebotenen Tools beherrscht werden, können Arbeitsabläufe automatisiert und somit erleichtert werden. Wenn Teams ihre Produktivität und Innovationskraft steigern können, hilft ihnen das nicht nur in ihrem persönlichen Erfolg und ihrer Entwicklung, sondern auch der gesamten Organisation (Feng, 2024).
Führungskräfte haben eine besondere Vorbildfunktion, indem sie die Arbeit mit Daten vorleben und Anreize schaffen, sich darauf einzulassen. Das bedeutet, dass sie die Arbeit mit Daten nicht nur selbst erledigen, sondern auch den Mitarbeiterinnen und Mitarbeitern einen Anreiz bieten, es ihnen gleichzutun. Dabei ist entscheidend, dass nicht nur mit Daten kommuniziert wird, sondern auch über Daten sowie die Erfolge, die durch deren Nutzung erzielt wurden. Beispiele hierfür sind die Veröffentlichung erfolgreich umgesetzter Datenprojekte oder die Anwendung von Gamification bei der Gestaltung von Lernpfaden.
Enabling-Team & Community of Practice
Der Aufbau von Datenkompetenz wird durch soziale Strukturen unterstützt. Einerseits kann er durch sogenannte Enabling-Teams vorangetrieben werden. Diese Teamform wird in Kapitel 5 von Team Topologies ausführlich beschrieben (Skelton & Pais, 2019). Dieses Team arbeitet eng mit den Domänenteams zusammen, coacht, begleitet und unterstützt den praktischen Aufbau von Datenprodukten durch Workshops, Self-Service-Angebote oder durch die aktive Förderung der Zusammenarbeit zwischen den Teams, die Daten austauschen. Die Erfolge eines Enabling-Teams sind fast immer indirekt, weshalb eine klare Unterstützung durch Führungskräfte nötig ist. Diese müssen Zeit zum Lernen schützen und Zusammenarbeit belohnen (Skelton & Pais, 2019).
Eine Community of Practice zum Thema Daten hält den Lernprozess lebendig. Sie verbindet alle, die mit Daten arbeiten, ermöglicht den Austausch positiver wie negativer Erfahrungen, schafft Wissen, beispielsweise über Datenqualität, und etabliert gemeinsame Standards. Damit ergänzt sie das Enabling-Team: Das Enabling-Team schafft gezielt neue Fähigkeiten, während die Community dafür sorgt, dass dieses Wissen breit verankert und die kognitive Last reduziert wird, indem sie relevante Inhalte für die Organisation vorfiltert. Gemeinsam machen sie Lernen zu einem kontinuierlichen, sozialen Prozess.
Die Einführung einer datenproduktorientierten Architektur ist kein reiner Projektplan, sondern die Etablierung eines Lernsystems. Um unseren Mitarbeitenden angemessene Lernpfade, Lernhilfen und Aufgaben bereitstellen zu können, müssen wir sie sehr gut kennen und nach Kompetenzniveau und Interessensgebieten gruppieren. Enabling-Teams können Wissenslücken erkennen. Eine gute Community fördert funktionierende Arbeitsweisen zutage und bietet ein Diskussionsforum für kontroverse Themen. Diese Feedbackschleifen halten den Prozess der Transformation zu einer datengetriebenen Organisation am Laufen und machen die Datenplattform zu einem lebendigen System.
Die Plattform als Katalysator
Neben den sozialen Strukturen ist die Umsetzung der technischen Plattform eine tragende Säule, um eine datenproduktorientierte Architektur erfolgreich auszurollen. Die Plattform sollte zur Teilnahme einladen und nicht abschrecken. Das heißt, bei der Auswahl oder dem Bau von Tools müssen die Nutzer:innen im Mittelpunkt stehen. Wir nutzen so etwa für Deployments von Datenprodukten Tools wie Terraform, die Software-Engineers bereits kennen. Für fachliche Nutzer:innen binden wir Datenquellen an bekannte Programme wie Microsoft Excel oder Google Sheets an.
Nicht immer ist das bekannte Tooling ausreichend, um kompetenten Nutzer:innen alle Möglichkeiten zu bieten, die Daten voll auszunutzen. So möchten Nutzer:innen mit einem gewissen Reifegrad für die Datenauswertung beispielsweise auch BI-Tools wie Microsoft Power BI oder Tableau nutzen. Bei Tools im Bereich Software- und Data-Engineering reicht die grundsätzliche Kenntnis eines Tools oft nicht aus, um es in der konkreten Umgebung ohne nerviges Try-and-Error umsetzen zu können. Hier müssen klare Dokumentationen, einfache Onboarding-Prozesse, sinnvolle Defaults und automatisierte Qualitätschecks Teil des Designs sein.
Wenn Werkzeuge nicht bekannt sind, sollten sie in vertretbarer Zeit erlernbar sein, denn sonst wird die falsche Botschaft vermittelt. Wichtig ist, die Arbeit mit Daten zu verinnerlichen. Programme und Softwarebibliotheken sind dabei primär als Vehikel zu verstehen. Das soll nicht heißen, dass die Einführung einer neuen Technologie nicht als Motivation dienen kann. Vor allem technikaffine Mitarbeitende werden damit angesprochen. Eine technisch brillante, aber kognitiv überfordernde Plattform wird von den Nutzern jedoch meistens nicht akzeptiert.
Erfolg messbar machen
Wir können die Akzeptanz unserer Plattform nicht erzwingen. Da nicht jede Organisation gleich ist, gibt es bei der Erstellung von Lernpfaden und bei der Toolauswahl keine Universallösung. Wir können jedoch unsere eigene Datenkompetenz unter Beweis stellen, indem wir den Verlauf des Rollouts beobachten und analysieren, um an den richtigen Stellen nachzujustieren.
Zu den entsprechenden Metriken zählen beispielsweise:
Kompetenzaufbau – Entwickeln Menschen tatsächlich neue Fähigkeiten?
Die Teilnahme an Workshops zeigt das Interesse und dass unsere Maßnahmen angenommen werden.
Die Quantität der eigenständig gelieferten Datenprodukte aus Domänenteams zeigt, dass das Gelernte auch angewendet wird.
Regelmäßige Umfragen zum Datenvertrauen geben Aufschluss darüber, ob Mitarbeitende sich sicher genug fühlen, Daten in ihren Entscheidungen zu nutzen.
Kulturelle Signale – schwer zu messen, aber besonders aussagekräftig
Wenn Datenprodukte über Domänengrenzen hinweg wiederverwendet werden, entsteht echte Zusammenarbeit.
Weniger Ad-hoc-Anfragen an das zentrale Datenteam zeigen, dass Teams zunehmend selbstständig arbeiten können.
Interne sowie externe Talks oder Blogposts von Mitarbeitenden zum Thema Datennutzung signalisieren, dass eine Datenkultur nicht nur gelebt, sondern auch aktiv weitergegeben wird.
Plattformnutzung – kommt die Plattform im Arbeitsalltag an?
Die Zahl aktiver Nutzer:innen und veröffentlichter oder wiederverwendeter Datenprodukte gibt an, ob das System wächst oder stagniert.
Die Zeit bis zum Datenzugriff ist dabei besonders wichtig: Ist sie zu lang, bricht der Kreislauf aus Neugier und Lernen bereits am Anfang ab.
Plattform-Usability – für echte Menschen mit echten Aufgaben nützlich?
Welche Features werden bevorzugt genutzt, welche gemieden?
Wo brechen Nutzer:innen Interaktionspfade ab?
Werden Datenprodukte gefunden und dann auch wirklich genutzt?
Wir sollten diese Metriken nicht nutzen, um uns nach außen hin gut zu verkaufen oder unseren Projekterfolg zu beschönigen. Sie sind Spiegel, die zeigen, ob Menschen lernen, zusammenarbeiten und dem System vertrauen. Und um genau das zu erreichen, müssen wir die Kennzahlen auswerten, unser Vorgehen entsprechend ausrichten und bei Bedarf nachjustieren.
Der Elefant im Raum: Data Literacy & AI
Kaum ein Thema dominiert derzeit die Diskussionen in Unternehmen so sehr wie künstliche Intelligenz. KI-Werkzeuge werden zunehmend direkt an Unternehmensdaten angebunden. Das Versprechen: Man stellt einfach eine Frage und erhält sofort eine Antwort. „Talk to your data“ ist keine Zukunftsvision mehr und die Möglichkeiten sind beeindruckend: Zusammenhänge, für deren Analyse früher tiefgehende Fachkenntnisse und viel Zeit nötig waren, lassen sich heute in wenigen Minuten erkunden. Dadurch sinkt die Einstiegshürde enorm und der Kreislauf aus Datenzugang, Neugier und Kompetenz kann erheblich beschleunigt werden.
Diese Chance bringt jedoch auch eine neue Verantwortung mit sich. Large Language Models halluzinieren, das heißt, sie liefern selbstsicher klingende Antworten, die sachlich falsch sein können. Wer die zugrundeliegenden Daten nicht kennt und über keine Grundkompetenz im Umgang mit ihnen verfügt, wird solche Fehler nicht erkennen. Data Literacy ist somit keine Alternative zu KI-Werkzeugen, sondern eine Voraussetzung. Data Literacy befähigt Menschen, Antworten zu hinterfragen, einzuordnen und verantwortungsvoll darauf zu handeln.
Ich sehe Chatbots und ähnliche Werkzeuge als weitere Tools in unserem Ökosystem, denen gezielt Daten zur Verfügung gestellt werden sollten, genauso wie Excel oder Power BI. Der Unterschied ist, dass Fehler hier schwerer zu erkennen sind, da die Ausgabe wie eine sichere Aussage wirkt und nicht wie eine Formel, deren Berechnung nachvollziehbar ist. Data Literacy bedeutet in diesem Kontext, fähig zu sein, Fehler und sonstige Unstimmigkeiten zu erkennen.
Literaturverzeichnis
Morrow, J. (2024). Be Data Literate: The data literacy skills everyone needs to succeed (2. Aufl.). Kogan Page
Feng T. (2024). Humanizing Data Strategy: Leading Data with the Head and the Heart. Technics Publications
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press