Data Governance #16 – Die üblichen Verdächtigen – Du kannst deinen eigenen Daten nicht trauen.

Ambiguität als unterschätztes Kernproblem in der Data Governance

Keyser Söze und das Problem der unbestrittenen Definition

Am Ende von Die üblichen Verdächtigen (The Usual Suspects) lösen sich alle Gewissheiten auf. Der Ermittler Kujan glaubt, er habe die Wahrheit herausgearbeitet und dass er das mühsam rekonstruierte Bild eines komplexen Verbrechens gelöst hat. Dann sieht er die Pinnwand hinter sich. Er begreift: Roger Verbal Kint, der Hauptverdächtige, hat jedes Detail seiner Geschichte aus Notizen, Firmenlogos und Zeitungsausschnitten zusammengesetzt, die direkt vor ihm lagen (bzw. hinter dem Ermittler zu sehen waren). Niemand hat die Grundannahmen hinterfragt. Alle haben der Erzählung vertraut, weil sie in sich stimmig war.

„The greatest trick the devil ever pulled was convincing the world he didn't exist.” (Zitat aus dem Film)

Ersetzen Sie Kujan durch ein Management-Board. Ersetzen Sie Kint durch eine gut gemeinte, aber nie hinterfragte KPI-Definition. Ersetzen Sie die Pinnwand durch das Data Warehouse. Und ersetzen Sie Keyser Söze durch das, was in datengetriebenen Organisationen tatsächlich die größte unsichtbare Bedrohung ist: die Ambiguität, die Mehrdeutigkeit von Daten.

Das Gefährlichste an Ambiguität ist nicht, dass sie existiert. Das Gefährlichste ist, dass niemand sie bemerkt, bis es zu spät ist.

Das Problem: Wenn Daten keine gemeinsame Sprache sprechen.

Ambiguität (Mehrdeutigkeit) bezeichnet im Kontext organisationaler Daten den Zustand, in dem ein und dasselbe Datum, derselbe Begriff oder dieselbe Kennzahl von verschiedenen Personen, Systemen oder Prozessen unterschiedlich interpretiert wird, ohne dass diese Unterschiede explizit gemacht, dokumentiert oder bewusst gesteuert werden.

Es klingt trivial. Ist es aber nicht! Eine Organisation, die glaubt, sie habe ein Datenproblem, hat in Wirklichkeit häufig ein Bedeutungsproblem.

Daten sind keine objektiven Fakten.

Eine der hartnäckigsten Fehlannahmen in datengetriebenen Organisationen lautet: Daten seien objektiv. Sie seien die Rohmasse der Realität, neutral, präzise, verlässlich. Tatsächlich aber sind Daten kontextabhängige Konstruktionen. Sie entstehen durch Entscheidungen: Welche Ereignisse werden erfasst? Zu welchem Zeitpunkt? Mit welcher Granularität? Nach welcher Logik wird aggregiert? Wer hat diese Entscheidungen getroffen? Und warum?

Die „sakila”-Datenbank unserer fiktiven Blockbuster Bytes AG enthält eine Tabelle „rental”. Darin steht, wann ein Film ausgeliehen wurde. Klingt eindeutig? Ist es nicht. Zählt eine Ausleihe zum Zeitpunkt der Buchung oder des Abholens? Zählt sie zum Zeitraum des Verleihs oder zum Monat der Rückgabe? Wird eine Verlängerung als neue Ausleihe gewertet oder als Fortsetzung? Je nachdem, wer fragt und welches System antwortet, entstehen unterschiedliche Zahlen, alle korrekt aus ihrer jeweiligen Perspektive, keine davon allgemeingültig.

Wie bei Verbal Kints Geschichte: Alles ist stimmig, alles ist belegbar, alles ist, aus der richtigen Perspektive, wahr. Und genau deshalb wird es nicht hinterfragt. 

Ambiguität entsteht systemisch, nicht durch Fehler.

Der entscheidende Punkt: Ambiguität ist kein Symptom von Nachlässigkeit oder Inkompetenz. Sie ist das natürliche Ergebnis komplexer Organisationen. Jede Abteilung hat ihre eigene Sprache, ihre eigenen Anforderungen, ihre eigene Geschichte. Der Vertrieb optimiert auf gebuchte Aufträge, Finance auf fakturierte Umsätze, Operations auf ausgelieferte Einheiten – und alle drei nennen es Umsatz.

Diese Divergenz ist nicht böswillig. Sie ist funktional entstanden und oft sogar rational begründet. Das macht sie umso schwieriger zu erkennen – und umso gefährlicher, wenn sie unbemerkt bleibt. 

Die Anatomie der Mehrdeutigkeit – wo Keyser Söze lebt

Um Ambiguität zu steuern, muss man ihre Quellen kennen. Sie entstehen auf mehreren Ebenen gleichzeitig und verstärken sich gegenseitig.

Silodenken und dezentrale Datenverantwortung

In vielen Organisationen werden Daten dort erzeugt, wo Geschäftsprozesse stattfinden: im CRM, im ERP, in Spezialanwendungen, in Excel-Tabellen. Jedes System ist für seinen Zweck optimiert. Eine zentrale Hoheit über gemeinsame Begriffe existiert nicht, weil niemand sie jemals für notwendig gehalten hat. Solange jeder Bereich in seinen eigenen Grenzen operiert, funktioniert das. Sobald aber bereichsübergreifende Berichte entstehen, prallen die Deutungsrahmen aufeinander.

Unterschiedliche fachliche Perspektiven

Finance definiert Kunde als juristische Person mit aktivem Vertrag. Der Vertrieb definiert Kunde als jeden, der jemals eine Anfrage gestellt hat. Das CRM kennt Kontakte, Accounts und Opportunities. Welche Zahl erscheint im Quartalsbericht, wenn das Management fragt: Wie viele Kunden haben wir? Die Antwort hängt davon ab, wer gefragt wurde. Und meistens fragt niemand nach der Definition.

Fehlende semantische Standards

Ein Business-Glossar, eine verbindliche, organisationsweite Definition zentraler Datenbegriffe, gehört in vielen Unternehmen noch zu den Desideraten. Selbst wenn es existiert, ist es oft veraltet, nicht durchgesetzt oder nicht mit den tatsächlichen Datensystemen verknüpft. Begriffe wie aktiver Kunde, Nettoumsatz oder Marge werden in jedem Meeting neu verhandelt, ohne dass irgendjemand dies als Problem benennt. Das kostet Zeit und Nerven.

Historisch gewachsene IT-Landschaften

Jedes neue System bringt seine eigene Datenlogik mit. Was als customer_id in System A gespeichert wird, heißt in System B KundNr und in System C PartyID und meint dennoch nicht dasselbe. Integrationslogiken, die im Laufe der Jahre entstanden sind, haben diese Unterschiede überbrückt, aber nicht aufgelöst. Sie haben sie versteckt. Genau wie Verbal Kints Geschichte: Die Naht ist unsichtbar, weil niemand danach sucht.

Unklare Rollen und fehlende Verantwortung

Wo niemand explizit für die Definition eines Datenbegriffs verantwortlich ist, bleibt die Definition implizit. Und implizite Definitionen sind instabil. Sie verändern sich mit Systemmigrationen, mit Personalwechseln, mit neuen regulatorischen Anforderungen, ohne dass irgendjemand dies bewusst wahrnimmt oder dokumentiert. Keyser Söze existiert. Nur niemand weiß, wer er ist.

Mangelnde Dokumentation von Transformationen

Daten durchlaufen auf dem Weg vom Quellsystem zum Dashboard zahlreiche Transformationen (Data Lineage). Jede Transformation ist eine potenzielle Quelle von Bedeutungsverschiebung. Wenn diese Transformationen nicht dokumentiert sind, wenn Data Lineage fehlt, dann ist der Weg vom Rohdatum zur Management-KPI eine Black Box. Und Black Boxes erzeugen Misstrauen. Zu Recht!

Warum klassische IT-Maßnahmen das Problem nicht lösen

Der Reflex vieler Organisationen auf Datenprobleme ist technischer Natur: ein neues Data Warehouse, eine bessere ETL-Pipeline, ein einheitlicheres Datenmodell. Diese Maßnahmen sind oft notwendig bzw. sinnvoll, aber nicht hinreichend. Ambiguität ist kein technisches Problem. Sie ist ein semantisches, organisatorisches und kulturelles Problem. Ein noch so perfekt normalisiertes Datenmodell löst keine semantischen Konflikte, wenn die beteiligten Fachbereiche sich über die Bedeutung eines Begriffs nicht einig sind. Man kann Kujan eine bessere Pinnwand geben, er wird immer noch der falschen Geschichte glauben, solange er die richtigen Fragen nicht stellt.

Konsequenzen – was passiert, wenn niemand die Fragen stellt?

Die Auswirkungen unkontrollierter Ambiguität sind nicht abstrakt. Sie zeigen sich tagtäglich in Besprechungsräumen, in Prüfungsverfahren und in Entscheidungsprozessen. 

Widersprüchliche Reports und endlose KPI-Diskussionen

Das Management-Board sieht zwei Berichte über denselben Sachverhalt mit unterschiedlichen Zahlen. Die erste Hälfte des Meetings geht für die Klärung der Datenbasis drauf. Entscheidungen werden vertagt. Das Vertrauen in Analytics sinkt.

In unserer Blockbuster Bytes AG: Finance meldet sinkende Verleiherlöse – während Operations steigende Ausleihzahlen meldet. Beide haben Recht. Beide messen Unterschiedliches. Niemand hat dies vorher explizit gemacht. Die Geschichte klingt stimmig – bis jemand auf die Pinnwand schaut. 

Vertrauensverlust in Daten

Daten verlieren ihren strategischen Wert, wenn die Organisation ihnen nicht vertraut. Und Vertrauen entsteht nicht durch technische Qualität allein, sondern durch semantische Klarheit: Ich muss verstehen, was die Zahl bedeutet, bevor ich ihr vertrauen kann. Organisationen, die dieses Vertrauen verloren haben, treffen Entscheidungen zunehmend auf Basis von Bauchgefühl und politischem Gewicht statt auf Basis von Evidenz. 

Compliance-Risiken

Regulatorische Berichterstattung – ob DSGVO, DORA, ESG-Reporting oder Bankenaufsicht – setzt voraus, dass Begriffe eindeutig definiert und konsistent verwendet werden. Ambiguität in regulatorisch relevanten Daten ist kein akademisches Problem: Sie kann zu falschen Meldungen, Bußgeldern und Reputationsschaden führen. 

Ineffiziente Abstimmungsprozesse

Wenn jede Entscheidung, die auf Daten basiert, zunächst eine Debatte über die Datenbasis erfordert, ist das ein erheblicher Kostenfaktor. Nicht sichtbar in der Bilanz, aber sehr spürbar in der Geschwindigkeit und Qualität der Entscheidungsfindung. 

Lösungsansätze – den echten Keyser Söze identifizieren.

Eine wichtige Vorbemerkung: Das Ziel ist nicht die vollständige Eliminierung von Ambiguität. Das wäre weder möglich noch sinnvoll. Unterschiedliche Perspektiven auf Daten sind in einer differenzierten Organisation nicht nur unvermeidlich, sondern auch wertvoll. Das Ziel ist ihre bewusste Steuerung, Transparenz darüber, was ein Begriff bedeutet, wer ihn definiert hat, in welchem Kontext er gilt und wo seine Grenzen liegen. Oder, um im Bild zu bleiben: Es geht nicht darum, Keyser Söze zu eliminieren. Es geht darum, ihn sichtbar zu machen. 

Business Glossar: Die verbindliche Sprache der Organisation

Der erste und grundlegendste Schritt ist die Einführung eines Business-Glossars, einer dokumentierten, verbindlichen und durchgesetzten Sammlung zentraler Datenbegriffe mit ihren Definitionen, Verantwortlichen und Gültigkeitsbereichen. Ein Business-Glossar ist kein IT-Artefakt. Es ist ein Managementinstrument. Es entsteht nicht im stillen Kämmerlein der IT, sondern in expliziten Abstimmungsprozessen zwischen Fachbereichen. In OpenMetadata, unserem Werkzeug der Wahl in dieser Blogserie, lassen sich Glossareinträge direkt mit den entsprechenden Datentabellen und -spalten verknüpfen. So wird die Definition nicht nur dokumentiert, sondern im Kontext der Daten sichtbar und damit prüfbar. 

Data Domains und klare Rollenmodelle

Wie in den ersten Episoden dieser Serie beschrieben, sind Data Domains und klare Rollenmodelle, Data Owner, Data Steward, Data Custodian, die organisatorische Grundlage für semantische Klarheit. Wenn für jeden Datenbegriff eine Person verantwortlich ist, wird Ambiguität nicht unsichtbar diskutiert, sondern explizit adressiert. Der Data Owner der Domain Customer bei der Blockbuster Bytes AG legt fest, was als Kunde gilt. Diese Entscheidung ist dokumentiert, kommuniziert und bindend. 

Data Lineage: Den Weg des Bedeutungswandels sichtbar machen

Ambiguität entsteht nicht nur in der Definition, sondern, wie bereits erwähnt, auch in der Transformation. Eine Zahl, die das Quellsystem als Anzahl Transaktionen speichert, kann im Data Warehouse zu Anzahl Bestellungen und im Dashboard zu Anzahl Kunden werden, je nachdem, wie die Aggregationslogik gestaltet ist. Data Lineage macht diesen Weg sichtbar. Sie erlaubt es, an jedem Punkt der Datenpipeline zu fragen: Was meint diese Zahl hier und was meinte sie am Ursprung? Sie ist die Kamera, die zeigt, wie die Geschichte zusammengesetzt wurde.  

KPI Definition Workshops

Technische Maßnahmen allein reichen nicht. Ambiguität ist ein kommunikatives Problem, das kommunikative Lösungen erfordert. Strukturierte KPI Definition Workshops, in denen Fachbereiche gemeinsam und moderiert ihre zentralen Begriffe klären, sind häufig eine wirkungsvolle Maßnahme und gleichzeitig die am meisten unterschätzte. Diese Workshops sind keine technischen Meetings. Sie sind Moderationsaufgaben, die Organisationsverständnis, Konfliktlösungskompetenz und semantisches Fingerspitzengefühl erfordern.  

Domain-Driven Design: Semantische Klarheit im Datenmodell

Domain-Driven Design (DDD) bietet einen strukturierten Ansatz, um semantische Kontexte, sogenannte Bounded Contexts, explizit zu machen. Jede Domain definiert ihre eigene Sprache, und an den Grenzen zwischen Domains werden Übersetzungsregeln explizit dokumentiert. Im Kontext der Blockbuster Bytes AG: Der Begriff „film” in der Domain „Movies” hat eine andere Bedeutung als in der Domain „Marketing-Analytics“. Beide sind legitim, aber sie müssen klar voneinander abgegrenzt und dokumentiert sein. 

Erforderliche Kompetenzen: Wer Keyser Söze sehen kann.

Ambiguität zu steuern ist eine Führungsaufgabe, keine Technikaufgabe. Die dafür erforderlichen Kompetenzen sind interdisziplinär und finden sich selten in einer einzigen Person.

• Semantische Modellierung: die Fähigkeit, Begriffe präzise zu definieren und in Beziehung zu setzen
• Organisationsverständnis: Wissen über Strukturen, Prozesse und Interessenlagen der beteiligten Bereiche
• Moderations- und Konfliktlösungskompetenz: Bedeutungskonflikte sind immer auch Interessenkonflikte.
• Strategisches Denken: Data Governance muss zur Unternehmensstrategie passen, nicht gegen sie arbeiten.
• Regulatorisches Verständnis: Ambiguität hat rechtliche Konsequenzen, die erkannt werden müssen.
• Kommunikationsstärke zwischen Fachbereich und IT: die klassische, unverzichtbare Übersetzungsrolle
• Systemisches Denken: Ambiguität entsteht in komplexen Wechselwirkungen, nicht in isolierten Ursachen.

Data Governance braucht Menschen, die bereit sind, die unbequemen Fragen zu stellen. Die nicht zufrieden sind mit einer stimmigen Geschichte, sondern die fragen: Woher kommt diese Zahl? Wer hat sie definiert? Gilt das auch für den anderen Kontext? Menschen, die im Gegensatz zu Agent Kujan rechtzeitig auf die Pinnwand schauen. 

Methoden und Verfahren: Der Werkzeugkasten

Der Markt bietet eine Vielzahl von Methoden und Tools. Die Herausforderung ist nicht das Fehlen von Werkzeugen, sondern die Auswahl der richtigen für den richtigen Reifegrad.

• DAMA-DMBOK-orientierte Frameworks: strukturierter Rahmen für alle Dimensionen des Datenmanagements
• Data Catalogs und Business-Glossare (z. B. OpenMetadata): technische Heimat für semantische Definitionen
• KPI Definition Workshops: der kommunikative Kern jeder Ambiguitätsreduktion
• RACI-Modelle: Rollenklarheit als Voraussetzung für semantische Verantwortung
• Data Lineage Tools: Transparenz über Bedeutungswandel in Datenpipelines
• Domain-Driven Design: semantische Strukturierung von Datenmodellen
• Maturity Assessments: Diagnose des aktuellen Governance-Reifegrads als Ausgangspunkt

Strategische Einordnung: Data Governance als Management of Meaning

Wenn man die gesamte Blogreihe zur Data Governance Revue passieren lässt, von Data Domains über Metadaten, Datenqualität, Data Lineage, IAM, Data Contracts bis hin zu KI-Integration und EU-Regulierung, dann zeigt sich ein roter Faden: All diese Konzepte sind letztlich Antworten auf das Problem der Ambiguität.

Data Governance ist, in seinem Kern, kein Datenmanagement. Es ist Management of Meaning. Die Gestaltung von Bedeutung in einer Organisation. 

Ambiguitätstoleranz und strukturelle Klarheit sind keine Gegensätze.

Eine ausgereifte Governance-Organisation weiß: Nicht jede Mehrdeutigkeit muss aufgelöst werden. Manche Kontexte erfordern unterschiedliche Definitionen desselben Begriffs, und das ist legitim, solange diese Unterschiede explizit dokumentiert und kommuniziert sind. Ambiguitätstoleranz bedeutet nicht, Unklarheit zu akzeptieren. Es bedeutet, mit Unklarheit bewusst umzugehen: sie zu benennen, sie auszuhalten, ihre Konsequenzen zu kennen und ihre Auflösung zu priorisieren. 

Kulturelle Veränderung als Voraussetzung

Wie in Beitrag #15 dieser Reihe beschrieben: Governance ist eine Frage der Kultur. Das gilt für Ambiguität in besonderer Weise. Eine Organisation, die semantische Konflikte als Bedrohung erlebt und unter den Teppich kehrt, wird Ambiguität nie strukturiert steuern können. Eine Organisation, die semantische Konflikte als Erkenntnisquelle versteht, als Zeichen dafür, dass unterschiedliche Perspektiven im Spiel sind, die gehört und integriert werden wollen, hat die kulturelle Grundlage für nachhaltiges Meaning Management. 

Die strategische Schlussfolgerung

Organisationen, die Ambiguität ignorieren, zahlen einen hohen Preis in Entscheidungsqualität, Compliance-Risiko und Vertrauen. Organisationen, die Ambiguität strukturiert steuern, gewinnen nicht nur sauberere Daten. Sie gewinnen eine gemeinsame Sprache. Und eine Organisation, die eine gemeinsame Sprache spricht, entscheidet besser, schneller und mit mehr Vertrauen in ihre eigenen Zahlen.

„Die üblichen Verdächtigen” endet mit einer erschütternden Erkenntnis: Kujan hatte alle Informationen. Er hatte die Zeit. Er hatte die Ressourcen. Was ihm fehlte, war nicht die Datenbasis, sondern die Bereitschaft, die richtigen Fragen zu stellen und die Grundannahmen zu hinterfragen.

In Ihrer Organisation haben Sie eventuell dasselbe Problem und, anders als Kujan, noch die Möglichkeit, es zu lösen. Schauen Sie auf die Pinnwand. Fragen Sie, wer Keyser Söze ist. Und fangen Sie an, Definitionen zu dokumentieren, bevor jemand den Raum verlässt.

Sie haben Fragen und/oder Feedback zum Thema Data Literacy, Culture und/oder Governance? Sprechen Sie mit uns.

P.S. The Usual Suspects (1995); https://www.imdb.com/de/title/tt0114814/ 

Seminarempfehlungen