3/3+180 XP

Ein Data-Literacy-Programm aufbauen

# Ein Data-Literacy-Programm aufbauen

2018 hatte Airbnb ein Problem, um das die meisten CDOs sie beneiden würden: zu viel Data-Begeisterung. Analysten wurden mit Ad-hoc-Anfragen überschwemmt, Business-Teams bauten widersprüchliche Metriken, und dieselbe Frage, „wie viele aktive Nutzer haben wir?“, ergab vier verschiedene Antworten, je nachdem, wen man fragte. Ihre Antwort darauf, die „Data University“, wird heute in jedem Literacy-Deck auf dem Konferenzzirkus zitiert. Was diese Decks aber weglassen: Airbnb hat nicht damit angefangen, SQL zu unterrichten. Sie haben damit angefangen, festzustellen, dass sich ihre Leute nicht auf Definitionen einigen konnten, ein Experimentergebnis nicht interpretieren konnten und nicht wussten, welcher der vier „Active User“-Zahlen sie trauen sollten. Das Training war das *Letzte*, was sie gebaut haben, nicht das Erste.

Genau diese Umkehrung ist die ganze Lektion. Die meisten Data-Literacy-Programme scheitern, weil sie mit dem Curriculum beginnen: eine LinkedIn-Learning-Lizenz, ein Lunch-and-Learn zu Dashboards, ein Pflichtkurs, den alle durchklicken und bis Donnerstag vergessen haben. Dass Datenkultur das Ziel ist, wissen Sie bereits. In dieser Lektion geht es um den Mechanismus: wie man ein Literacy-Programm baut, das ein bestimmtes Verhalten in einer bestimmten Rolle verändert, an eine Entscheidung gekoppelt ist, die jemand tatsächlich trifft, und so instrumentiert ist, dass Sie die Wirkung belegen können.

Bei Entscheidungen anfangen, nicht bei Kompetenzen

Der kompetenzgetriebene Ansatz ist verführerisch, weil er ordentlich aussieht. Sie listen die Skills auf: ein Chart lesen, statistische Signifikanz verstehen, eine Query schreiben, vergeben Proficiency-Level und mappen Trainings darauf. Das ergibt eine schöne Matrix und fast keine Verhaltensänderung, weil es eine Frage beantwortet, die im Business niemand stellt. Ein regionaler Sales-VP wacht nicht mit dem Wunsch auf, „seine Data Proficiency zu verbessern“. Er wacht mit dem Wunsch auf, seine Zahl zu erreichen.

Drehen Sie es um. Beginnen Sie mit einem Decision Inventory: den zehn bis fünfzehn wiederkehrenden Entscheidungen in einer Funktion, die datenbasiert sein sollten, es aber nicht sind oder schlecht sind. Dann arbeiten Sie zurück zur Literacy-Lücke, die eine bessere Entscheidung blockiert.

Nehmen Sie ein Merchandising-Team, das wöchentlich Bestände nachordert. Die Entscheidung ist konkret, hochfrequent und teuer, wenn sie falsch ausfällt. Wenn Sie das Team interviewen, stellen Sie fest: Die eigentliche Lücke ist nicht, dass sie kein Dashboard lesen können, sondern dass sie dem Demand Forecast nicht trauen, ihn also mit Bauchgefühl überschreiben und dieselben SKUs kaufen wie immer. Die Literacy-Lücke ist hier *nicht* „wie man Tableau benutzt“. Sie lautet: „wie man das Konfidenzintervall eines Forecasts interpretiert und weiß, wann man ihm traut und wann man ihn überschreibt“. Das ist ein lehrbarer, an eine Entscheidung gekoppelter Skill. Der Tableau-Kurs hätte ihn komplett verfehlt.

Das ist das zentrale Reframing: Literacy ist kein Wissen im Kopf einer Person; es ist die Fähigkeit, in dem Moment, in dem eine Entscheidung fällt, eine bessere Entscheidung zu treffen. Ihre Analyseeinheit ist die Entscheidung, nicht die Person und nicht der Skill.

Bauen Sie das Inventory über strukturierte Interviews mit den Funktionsverantwortlichen. Stellen Sie pro wiederkehrender Entscheidung drei Fragen:

Welche Daten nutzen Sie *aktuell* für diese Entscheidung, und worauf verlassen Sie sich tatsächlich stattdessen?
Wo brennen Sie sich die Finger, welche Entscheidungen gehen schief und warum?
Wenn Sie eine Zahl oder eine Sicht hätten, der Sie trauen, welche wäre das?

Die Lücke zwischen „Daten, die Sie nutzen sollten“ und „worauf Sie sich stattdessen verlassen“ ist Ihr Curriculum. Sie ist so gut wie nie generisch. Sie lautet: „Unsere Finance Manager wissen nicht, dass unsere Umsatzmetrik Rückerstattungen ausschließt“ oder „unsere Marketer halten einen Lift von 2 % für echt, obwohl der Test nicht die Power hatte, ihn zu erkennen“.

Nach Rolle segmentieren, dann nach Datenbeziehung

Sobald Sie die Entscheidungen haben, widerstehen Sie dem Impuls, ein einziges Programm zu bauen. Der häufigste Designfehler nach „Curriculum first“ ist „one size fits all“. Eine Führungskraft, die eine Kapitalallokation von 40 Mio. $ freigibt, und ein Supply-Chain-Analyst, der ein Reorder-Modell tunt, brauchen radikal unterschiedliche Literacy. Sie gleich zu behandeln verschwendet die Zeit der Führungskraft und bleibt hinter dem Bedarf des Analysten zurück.

Segmentieren Sie die Organisation nach ihrer Beziehung zu Daten, nicht nach Seniorität. Ein brauchbares Vier-Stufen-Modell:

Data Consumers lesen Daten, die andere produzieren, und handeln darauf. Hier lebt der größte Teil der Organisation: der Sales-VP, der Marketing Manager, die Filialleitung. Ihr Literacy-Ziel ist *Interpretation und Skepsis*: ein Chart korrekt lesen, wissen, was eine Metrik ausschließt, eine irreführende Achse erkennen, „im Vergleich zu was?“ fragen. Sie brauchen kein SQL. Es ihnen beizubringen ist eine Vanity Metric.

Data Explorers bedienen sich selbst. Sie bauen ihre eigenen Dashboards, schneiden Daten, setzen ihre eigenen Filter. Ihre Lücke ist meist *Methodik*: Sie können Daten ziehen, leiten daraus aber falsche Schlüsse ab. Korrelation vs. Kausalität, Stichprobengröße, Kohortenlogik, der Unterschied zwischen einer Rate und einem absoluten Wert.

Data Producers erstellen die Assets, auf die sich andere verlassen: Analysten, Data Scientists, Engineers. Ihre Literacy-Lücke ist selten technisch; sie liegt in *Kommunikation und Governance*. Sie können das Modell bauen, aber die Unsicherheit einem nicht-technischen VP nicht erklären, oder sie erzeugen eine fünfte „Active Users“-Metrik, weil sie vorher nicht in den Semantic Layer geschaut haben.

Data Leaders allokieren Ressourcen und setzen die Richtung auf Basis von Daten. Ihr Ziel ist *die richtigen Fragen stellen und den falschen Antworten widerstehen*: erkennen, wann die ROI-Behauptung eines Anbieters unfalsifizierbar ist, wann eine Korrelation als Kausalität verkauft wird, wann man einen kontrollierten Test verlangen sollte, bevor Budget committet wird.

Mappen Sie jede wiederkehrende Entscheidung auf die Stufe, die sie verantwortet. Jetzt hat Ihr Curriculum ein *Was* (die Entscheidung) und ein *Wer* (die Stufe), und Sie können eine dazu passende Intervention designen. Die Führungskraft bekommt eine 90-minütige Working Session zur Interpretation von Experimentergebnissen, mit ihren eigenen letzten drei gescheiterten Initiativen als Fällen. Der Analyst bekommt einen Hands-on-Workshop zum Semantic Layer und dazu, wie man Konfidenzintervalle kommuniziert. Dasselbe Programm, bewusst unterschiedliche Dosierung.

How Airbnb Democratizes Data with Data University

Watch on YouTube

Interventionen designen, die am Workflow kleben

Hier die unangenehme Wahrheit über Trainings: Die Vergessenskurve ist brutal. Ein Standalone-Kurs verliert den größten Teil seines Werts innerhalb von Wochen, wenn der Lernende ihn nicht sofort anwendet. Das Designprinzip mit der höchsten Hebelwirkung lautet deshalb: Verankern Sie die Literacy im Workflow, in dem die Entscheidung fällt, nicht in einem Klassenraum Wochen vorher.

Drei Taktiken, in aufsteigender Haltbarkeit:

1. Guidance am Point of Decision. Bringen Sie die Interpretation *ins* Tool. Ein Dashboard, das eine Metrik zeigt, sollte auch ihre Definition beim Hover, ihre Datenaktualität und ein Konfidenzband zeigen, damit der Consumer sie jedes Mal korrekt liest, wenn er sie benutzt, und nicht einmal in einem Kurs. Hier verdient sich ein Semantic Layer seine Existenz: Er macht die „korrekte“ Definition zur *einzigen* verfügbaren Definition.

yaml

# Semantic layer metric definition — die Literacy steckt in der Config
metric: active_users
  label: "Active Users (28-day)"
  description: "Distinct users with >=1 qualifying session in trailing 28 days.
                EXCLUDES internal test accounts and bot traffic."
  owner: growth-analytics
  gotcha: "Not comparable to 'MAU' in the 2021 board deck (different window)."

Dieses gotcha-Feld leistet mehr Literacy-Arbeit als jedes Foliendeck, weil es genau in dem Moment erscheint, in dem jemand die Zahl falsch verwenden könnte.

2. Kohorten, die an Entscheidungen hängen. Statt Kurse mit offener Anmeldung fahren Sie Kohorten, die um eine gemeinsame, laufende Entscheidung organisiert sind. Das Merchandising-Team lernt Forecast-Interpretation, *während* es den Einkauf für das nächste Quartal plant, mit dem echten Forecast. Das Gelernte hat unmittelbare Konsequenzen, und das ist der einzige verlässliche Weg, es in bleibendes Verhalten zu überführen. Die Kohorte schafft außerdem Peer Accountability: Die Norm verschiebt sich, weil sich alle gemeinsam verschieben.

3. Data Champions in den Funktionen. Airbnb, Bloomberg und andere sind auf dieselbe Struktur gekommen: ein verteiltes Netzwerk von „Champions“, keine Vollzeit-Analysten, sondern respektierte Operator in jeder Funktion, die ein tieferes Training bekommen und zur lokalen First Line of Support werden. Das löst das Skalierungsproblem (ein zentrales Datenteam kann nicht jede Frage beantworten) und das Vertrauensproblem (Menschen nehmen Datenratschläge eher von einem Peer an als von einer zentralen Funktion, die sie als bürokratisch wahrnehmen). Budgetieren Sie ihre Zeit explizit; eine Champion-Rolle, die rein „zusätzlich zum Tagesjob“ läuft, stirbt leise.

Ein Wort zum Urteilsvermögen: Das Champion-Modell scheitert, wenn Sie Champions nach technischem Können statt nach Einfluss auswählen. Sie wollen die Person, zu der andere schon heute mit Fragen gehen, und dann bilden Sie *diese* weiter. Den stillen SQL-Experten zu nehmen, den niemand fragt, ist ein häufiger und vermeidbarer Fehler.

Wissenscheck

1. Was ist laut Lektion der Hauptgrund, warum die meisten Data-Literacy-Programme scheitern?

2. Die Lektion argumentiert, man solle ein Literacy-Programm mit einem „Decision Inventory“ statt mit einer Kompetenzmatrix beginnen. Was ist der Hauptvorteil dieser Umkehrung?

3. Im Beispiel des Merchandising-Teams wurde die eigentliche Literacy-Lücke als welche der folgenden identifiziert?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die das Argument der Lektion zum Design eines Data-Literacy-Programms korrekt wiedergeben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie anhand des Airbnb-Beispiels ALLE Lehren, die der Text aus der Geschichte der „Data University“ zieht.

Wählen Sie alle richtigen Antworten aus.

Verhaltensänderung messen, nicht Teilnahme

Wenn Sie Ihrem Board Completion Rates berichten, bekommen Sie Completion. Literacy bekommen Sie nicht. Die Messebene trennt ein echtes Programm von Theater, und sie ist der Teil, den die meisten CDOs überspringen, weil er wirklich schwer ist.

Messen Sie auf drei Ebenen, und seien Sie ehrlich: Jede wird schwieriger und wertvoller, je weiter Sie nach unten gehen.

Activity Metrics (einfach, schwach): Anmeldungen, Abschlüsse, Workshop-Teilnahme. Erfassen Sie das nur zur operativen Hygiene. Präsentieren Sie es niemals als Impact. Es sagt Ihnen, dass das Programm läuft, nicht dass es wirkt.

Adoption Metrics (mittel): Nutzen Menschen Daten tatsächlich anders? Query-Volumen auf governed Sources im Vergleich zu Schatten-Spreadsheets. Zahl der Entscheidungen, die über den Semantic Layer laufen. Rückgang widersprüchlicher Metrikdefinitionen. Self-Service-Dashboard-Nutzung durch Consumer, die früher Tickets geschrieben haben. Das sind Proxys für Verhalten, und sie sind instrumentierbar, die Logs haben Sie schon.

Outcome Metrics (schwer, stark): Sind die Entscheidungen besser geworden? Das setzt voraus, dass Sie die Entscheidungen vorab definiert haben, weshalb sich das Decision Inventory ein zweites Mal auszahlt. Für das Merchandising-Beispiel: Sind die Override-Raten beim Forecast gesunken, und sind Stockouts oder Overstock in Folge zurückgegangen? Für das Marketing-Team: Ist der Budgetanteil gestiegen, der erst *nach* einem sauber gepowerten Test committet wurde? Für Führungskräfte: Ist der Anteil der Initiativen mit definierter Erfolgsmetrik und Kill-Kriterium gestiegen?

Designen Sie eine kleine Zahl dieser Outcome-Maße als Vorher/Nachher- oder Treated/Untreated-Vergleiche. Fahren Sie das Kohortenprogramm zuerst in zwei von fünf Regionen, halten Sie drei als Kontrolle und vergleichen Sie die Entscheidungsqualität. Das ist nicht Rigor um des Rigors willen, es ist Ihre Verteidigung, wenn Finance fragt, warum das Literacy-Programm das Budget des nächsten Jahres verdient. „Regionen, die die Merchandising-Kohorte durchlaufen haben, haben Overstock-Abschreibungen gegenüber der Kontrolle um 11 % gesenkt“ ist ein Satz, der Budgets verlängert. „Wir haben 4.000 Leute geschult“ ist es nicht.

Eine Warnung zur Messung: Attribution ist umstritten. Business Outcomes haben viele Ursachen, und ein kluger CFO wird sagen, dass Ihr Literacy-Programm nicht die ganzen 11 % für sich beanspruchen kann. Er hat recht. Rahmen Sie es als Beitrag, registrieren Sie Ihren Vergleich vorab, bevor Sie starten, und wählen Sie Entscheidungen, bei denen die Kausalkette kurz genug ist, um sie zu verteidigen. Behaupten Sie nicht zu viel; eine bescheidene, glaubwürdige Zahl ist besser als eine aufgeblasene, die Sie zurückziehen müssen.

Key Takeaways

Bauen Sie das Decision Inventory vor dem Curriculum. Interviewen Sie Funktionsverantwortliche, um die zehn bis fünfzehn wiederkehrenden Entscheidungen zu finden, bei denen die Lücke zwischen „Daten, die sie nutzen sollten“ und „worauf sie sich stattdessen verlassen“ den echten, konkreten Literacy-Bedarf offenlegt. Das Curriculum fällt aus den Lücken, nicht aus einem Kompetenzframework.

Segmentieren Sie nach Beziehung zu Daten, nicht nach Seniorität. Consumers brauchen Interpretation und Skepsis; Explorers brauchen Methodik; Producers brauchen Kommunikation und Governance; Leaders müssen harte Fragen stellen. Consumers SQL beizubringen ist eine Vanity Metric, dosieren Sie angemessen.

Verankern Sie Literacy im Workflow, nicht im Klassenraum. Guidance am Point of Decision (Definitionen und Gotchas im Semantic Layer), an laufenden Entscheidungen lernende Kohorten und Champions mit Einfluss schlagen jeden Standalone-Kurs, weil sie die Vergessenskurve aushebeln.

Berichten Sie Adoption und Outcomes, nie Completion. Instrumentieren Sie das Query-Volumen auf governed Sources und die Zahl widersprüchlicher Definitionen (Adoption) und setzen Sie Vorher/Nachher- oder Treated/Control-Vergleiche zu den inventarisierten Entscheidungen auf (Outcomes). Registrieren Sie den Vergleich vorab und beanspruchen Sie einen Beitrag, nicht den ganzen Effekt.

Wählen Sie Champions nach Einfluss und bilden Sie sie dann weiter, nicht umgekehrt. Die Person, zu der Ihr Team schon heute mit Fragen kommt, ist zehn stille Experten wert. Finanzieren Sie ihre Zeit explizit, sonst stirbt die Rolle leise.