Single Source of Truth reicht nicht

Es gibt einen Moment in Reporting-Projekten, der sich in fast jeder Organisation wiederholt. Zwei Bereiche sitzen im selben Meeting, schauen auf dieselbe Kennzahl, gespeist aus derselben Quelle, technisch sauber modelliert, geprüft und freigegeben — und kommen zu unterschiedlichen Einschätzungen darüber, wie die Lage eigentlich ist.

Die übliche Reaktion darauf ist eine technische: Wir brauchen eine gemeinsame Datenbasis. Eine zentrale Quelle. Eine Wahrheit.

Das ist richtig, und es ist notwendig. Es reicht nur nicht.

Technisch eine Wahrheit, fachlich keine gemeinsame Bedeutung

Viele Initiativen zielen auf eine Single Source of Truth. Daten sollen zentral harmonisiert und bereitgestellt werden, damit alle auf denselben Zahlenstand schauen. Wenn das gelingt, ist ein echtes Problem gelöst: Man streitet nicht mehr darüber, welcher Export der aktuelle ist.

Danach beginnt aber das eigentliche Problem, und es ist kein technisches.

Wenn Kennzahlenbegriffe nicht eindeutig sind, kann eine Organisation selbst bei identischer Datenbasis unterschiedliche Wirklichkeiten produzieren. Dann gibt es technisch eine Wahrheit, aber fachlich keine gemeinsame Bedeutung.

Umsatz, Plan, Budget, Forecast, Marge — das sind keine neutralen Wörter. Es sind organisatorisch verhandelte Begriffe. Sie tragen Entscheidungen darüber in sich, was mitgezählt wird und was nicht, ab wann etwas zählt, welcher Zeitraum gilt, wie mit Stornos umgegangen wird, welche Währung und welche Abgrenzung Anwendung findet. Jede dieser Entscheidungen ist legitim. Problematisch wird es erst, wenn sie nicht verbindlich geklärt und nicht sichtbar sind.

Vertrieb und Controlling streiten deshalb selten über einen Wert. Sie streiten über Bedeutung, Definition und Konsequenz. Eine gemeinsame Datenquelle löst diesen Streit nicht auf, weil sie an einer anderen Stelle ansetzt.

Was fehlt, ist eine Single Source of Meaning

Steuerung entsteht nicht durch Verfügbarkeit von Zahlen. Sie entsteht durch verbindliche Definitionen, klare Interpretationsregeln und die Fähigkeit, Kennzahlen in Entscheidungen zu überführen.

Konkret braucht es dafür vier Ebenen, die zusammengehören und in der Praxis fast immer getrennt behandelt werden:

Definition. Was genau misst diese Kennzahl, in welchem Zeitraum, mit welcher Granularität, mit welchen Filtern und Abgrenzungen? Und wer ist fachlicher Owner, also die Person, die im Konfliktfall entscheidet?

Regeln. Welche Sicht ist für welchen Zweck führend? Zwei Berichte können unterschiedliche Werte zeigen und beide korrekt sein, wenn sie unterschiedliche Fragen beantworten. Ohne Regel darüber, welche Sicht wann gilt, wird jede Abweichung zum Anlass für eine Grundsatzdiskussion.

Notation. Wie werden Vorzeichen, Abweichungen, Einheiten und Skalierungen dargestellt? Farbe muss Bedeutung tragen und nicht Dekoration sein. Wenn dieselbe Information in jedem Bericht anders aussieht, muss die Nutzerin jedes Mal neu lernen, wie sie lesen soll.

Nutzungsart. Ein Monitoring, eine operative Steuerungssicht und eine explorative Analyse verfolgen unterschiedliche Zwecke und brauchen unterschiedliche Artefakte. Wenn alles in ein Dashboard gepackt wird, entsteht ein Kompromiss, der niemandem hilft: für die operative Steuerung zu diffus, für die analytische Klärung zu starr.

Diese vier Ebenen sind das, was ich Single Source of Meaning nenne. Sie liegen über der Datenschicht, nicht darunter.

Die sechs Fragen, an denen sich das entscheidet

In der Praxis lässt sich der Zustand einer Kennzahl mit wenigen Fragen prüfen. Sie klingen banal. Genau deshalb funktionieren sie:

• Welche Entscheidung soll mit dieser Kennzahl vorbereitet oder getroffen werden?
• Was ist die verbindliche Definition, inklusive Zeitraum und Granularität?
• Welche Filter und Abgrenzungen gelten?
• Welche Zielwerte oder Toleranzbereiche sind relevant?
• Wer ist fachlicher Owner?
• Wie wird die Kennzahl dargestellt, damit die Interpretation über Bereiche hinweg konsistent bleibt?

Wenn diese Fragen unbeantwortet bleiben, verlagert sich die Debatte vom Inhalt auf die Interpretation. Und das ist der teuerste Ort, an dem eine Diskussion stattfinden kann, weil sie sich bei jedem Termin wiederholt, ohne je zu einem Ergebnis zu kommen.

Was passiert, wenn die Bedeutung offen bleibt

Der Verlauf ist erstaunlich gleichförmig, und er hat wenig mit der Reife der Datenlandschaft zu tun.

Zuerst wächst der Wunsch nach Rohdaten. Das ist nachvollziehbar: Wer den Zahlen im Bericht nicht traut, will selbst nachrechnen. Aus diesem Bedürfnis entsteht Schatten-BI — Fachbereiche bauen eigene Auswertungen, oft mit hohem Engagement und guten Absichten. Gleichzeitig entstehen mehrere Versionen derselben Wahrheit.

Parallel steigt der Aufwand auf allen Seiten. Zentrale Berichte werden gebaut, Tickets häufen sich, Rückfragen nehmen zu. Im Meeting werden Zahlen dann erläutert, statt Entscheidungen vorzubereiten. Man spricht über unterschiedliche Logiken und trifft vorsichtshalber keine Entscheidung.

Am Ende ist das Ergebnis für alle unbefriedigend. Das Business bekommt mehr Informationen, aber nicht mehr Orientierung. Die Data-Seite erlebt Rework und sinkende Akzeptanz. Das Controlling verliert Vergleichbarkeit und damit Steuerungsfähigkeit.

Das ist kein Versagen einzelner Rollen. Es ist eine strukturelle Lücke.

Der Semantic Layer ist die halbe Antwort

Man muss fairerweise sagen: Die Branche hat das Problem erkannt. Unter dem Stichwort Semantic Layer wird derzeit intensiv daran gearbeitet, Kennzahlendefinitionen aus einzelnen Berichten herauszulösen und an einer zentralen Stelle verbindlich zu hinterlegen — als Schicht, die technische Strukturen in eine gemeinsame fachliche Sprache übersetzt und die dann von Berichten, Anwendungen und zunehmend auch von KI-Systemen genutzt wird. Das ist eine gute Entwicklung, und sie zielt in genau die richtige Richtung.

Sie löst aber nur den Teil des Problems, der sich modellieren lässt.

Eine Definition kann sauber hinterlegt und trotzdem in der Organisation umstritten sein. Sie kann eindeutig sein und trotzdem niemanden interessieren, weil im Meeting weiter über Zahlenbilder statt über Maßnahmen gesprochen wird. Und sie kann formal existieren, ohne dass jemand befugt wäre, sie im Konfliktfall durchzusetzen.

Der Unterschied lässt sich so beschreiben: Ein Semantic Layer ist der Ort, an dem eine geklärte Bedeutung abgelegt wird. Er ist nicht der Prozess, in dem sie geklärt wird. Wer die Definitionsarbeit als Modellierungsaufgabe behandelt, verschiebt die Konflikte nur in ein anderes Werkzeug — und wundert sich später, warum die Diskussionen nicht aufhören, obwohl die Metrik doch zentral definiert ist.

Bedeutung entsteht im Gespräch, nicht in der Konfiguration. Die Ablage danach ist wichtig. Sie ist nur nicht der Anfang.

Warum das gerade jetzt drängender wird

Semantische Unschärfe ist kein neues Problem. Neu ist, wie schnell sie sich verbreiten kann.

Natürlichsprachliche Zugänge senken die Hürde, Zahlen zu erzeugen, Zusammenhänge zu erklären und Narrative zu formulieren. Das ist ein echter Gewinn für die Adoption, denn breite Nutzung gelingt nur, wenn Systeme anschlussfähig sind und nicht wie Spezialwerkzeuge für wenige wirken.

Genau darin liegt aber auch das Risiko. Wenn die zugrunde liegende Bedeutung nicht geklärt ist, skaliert nicht die Klarheit, sondern die Unschärfe — mit hoher Geschwindigkeit, niedriger Nutzungshürde und in sprachlich sehr plausibler Form. Was vorher als abweichende Excel-Auswertung in einem Bereich existierte, kann jetzt in Minuten in mehreren Varianten entstehen.

Der Engpass verschiebt sich damit von der Produktion zur Einordnung. Was ist verbindlich definiert? Wo brauchen wir Vergleichbarkeit? Wo ist Varianz zwischen Domänen sinnvoll und wo nicht? Und für welche Entscheidung wird eine Kennzahl überhaupt genutzt?

Einheitliche Sprache ist notwendig, aber nicht hinreichend

Ein Missverständnis will ich ausräumen: Es geht nicht darum, alles zu vereinheitlichen.

Domänen unterscheiden sich in Prozessreife, Risiko, Volatilität und Entscheidungsfrequenz. Selbst bei ähnlichen Rollen entstehen unterschiedliche Anforderungen an Detailtiefe und Aktualität. Eine Fachcontrollerin, die in Tabellen steuert und in Ausreißer hineinzoomt, arbeitet nicht falsch, nur weil eine andere mit wenigen Signalen auskommt. Beides ist legitim.

Vielfalt ist nicht das Problem. Problematisch wird es, wenn nicht klar ist, wo Vielfalt erlaubt ist und wo Einheitlichkeit zwingend ist.

Zusätzlich zur gemeinsamen Sprache braucht es deshalb Klarheit über die Entscheidungssituation. Derselbe KPI kann je nach Kontext eine andere Funktion haben, mit anderer Toleranz, anderer Darstellung und anderer Handlungslogik. Wer das ignoriert, produziert entweder Einheitlichkeit ohne Nutzen oder Vielfalt ohne Vergleichbarkeit.

Der Punkt

Eine Single Source of Truth beantwortet die Frage, welche Zahl gilt. Sie beantwortet nicht die Frage, was die Zahl bedeutet, für wen sie gilt, wann sie relevant ist und was aus ihr folgen soll.

Solange diese zweite Ebene nicht bewusst gestaltet wird, bleibt jede noch so saubere Datenarchitektur ein Fundament ohne Haus. Die Diskussionen verschwinden nicht, sie verschieben sich nur — weg von der Datenqualität und hin zur Interpretation. Und dort sind sie schwerer zu erkennen, weil sie wie fachliche Auseinandersetzung aussehen, während es eigentlich um ungeklärte Begriffe geht.

Die gute Nachricht: Diese Ebene lässt sich gestalten. Sie braucht kein Großprogramm und keine neue Plattform. Sie braucht Definitionen, Regeln, Ownership und die Bereitschaft, Konflikte über Bedeutung einmal auszuhalten, statt sie in jedem Meeting neu zu führen.

Reflexionsfrage: Wenn in deiner Organisation morgen zwei Bereiche mit unterschiedlichen Umsatzzahlen in ein Meeting kommen — wer entscheidet dann, welche Definition gilt? Und wie lange dauert es, bis diese Entscheidung getroffen ist?

Quellen und weiterführende Hinweise

Zur Rolle, die diese Lücke schließt

• Analytics Translator als Brückenfunktion zwischen technischer und operativer Expertise — McKinsey: Analytics translator: The new must-have role
• Warum Datenexpertise allein keine betriebliche Wirkung erzeugt — Harvard Business Review: You Don't Have to Be a Data Scientist to Fill This Must-Have Analytics Role
• Nachfrage nach Analytics Translators im deutschsprachigen Raum — WHU: Great Demand for Analytics Translators in German Industry

Zur Governance- und Kulturseite

• Warum ein großer Teil der Data-Governance-Initiativen nicht am Werkzeug, sondern an fehlendem Handlungsdruck und an der Wahrnehmung als bürokratisches Regelwerk scheitert: Datenkultur im Vorstand (Digital Chiefs, 2026)
• Data Literacy als die unterschätzte Hälfte der Datenstrategie, inklusive des Arguments, dass gerade überzeugend klingende KI-Antworten Datenkompetenz voraussetzen: The missing half of your data strategy (INNOQ, 2026)

Zur technischen Verankerung von Bedeutung

• Einordnung des Semantic Layer als Ort, an dem festgelegt wird, welche Umsatzdefinition in welchem Kontext gilt: Was ist ein Semantic Layer?

Aus meiner eigenen Arbeit

• Mini-Guide: 100 Fragen über Dashboards — scheinbar naive Fragen, die gutes Reporting besser machen. Kapitel 6 behandelt genau diesen Punkt: warum richtige Zahlen trotzdem falsch verstanden werden.
• Steuerungs-Check — acht Fragen, drei Minuten: Tragen eure Dashboards Entscheidungen oder informieren sie nur?

Werden eure Dashboards nicht verstanden? Dann lasst uns gemeinsam draufschauen — beim Reporting-Check prüfen wir eure Kennzahlenlogik, Standards und Darstellung auf das, was in der Steuerung tatsächlich ankommt.