Single Source of Truth – die einzige Datenwahrheit im ERP
Definition: Single Source of Truth (SSoT) bezeichnet das Architekturprinzip, dass jede Information genau einmal an einer eindeutig definierten, autoritativen Stelle gepflegt und von dort an alle abhängigen Systeme propagiert wird. Das ERP-System übernimmt in vielen Unternehmen genau diese Rolle – als zentrale Datenwahrheit für Geschäftsobjekte wie Kunden, Lieferanten, Materialien, Aufträge und Konten.
Mit zunehmender Anzahl spezialisierter Systeme – CRM, MES, Webshops, BI-Plattformen, DMS – wird SSoT zu einer der zentralen Anforderungen moderner IT-Architekturen. Ohne klare Quelle entstehen widersprüchliche Datenstände, fehlerhafte Auswertungen, doppelte Pflegeaufwände und letztlich falsche Geschäftsentscheidungen.
Funktionsweise und Prinzipien
SSoT folgt drei Prinzipien: Eindeutigkeit (jede Information existiert nur einmal logisch), Autorität (eine festgelegte Quelle ist führend) und Verteilung (alle anderen Systeme erhalten Daten von dieser Quelle, ändern sie aber nicht eigenständig). Praktisch bedeutet das: Das ERP führt z. B. den Kundenstamm, das CRM nutzt diese Daten, ergänzt um Kontaktverläufe, schreibt aber keine Stammdatenänderungen direkt zurück, sondern triggert sie über definierte Workflows.
Technisch wird SSoT über Master-Data-Management-Plattformen, integrierte ERP-Suiten oder Data-Hub-Architekturen umgesetzt. Wesentlich sind ein dokumentiertes Datenmodell, klare Owner pro Datenobjekt, definierte Schnittstellen und ein Governance-Modell mit Pflegeprozessen, Zugriffsrechten und Datenqualitäts-KPIs.
SSoT vs. Master Data Management
Die Begriffe werden häufig verwechselt. Master Data Management (MDM) ist der prozessuale und technische Rahmen zur Steuerung der Stammdatenqualität – ein „Wie“. Single Source of Truth ist das übergeordnete Architekturprinzip – ein „Was bzw. Wo“. MDM ist somit das wichtigste Werkzeug, um eine SSoT operativ umzusetzen.
Typische Umsetzungsmuster
Drei Muster dominieren: Erstens das ERP als zentrale SSoT, von dem aus alle anderen Systeme Daten beziehen. Zweitens ein dediziertes MDM-System, das übergreifend für mehrere ERPs die Stammdaten konsolidiert (typisch in Konzernen mit Two-Tier-Architektur). Drittens ein Data Hub bzw. ein Data Lakehouse, der Daten verschiedener Quellen integriert, aber nicht selbst pflegt.
In Composable- und Postmodern-ERP-Architekturen wird SSoT differenziert: Kundenstamm im CRM, Kreditorenstamm im ERP, Produktinformationen im PIM. Wichtig ist dann eine eindeutige Domain-Verteilung: pro Datenobjekt ein klar definiertes Quellsystem.
Vorteile und Herausforderungen
Vorteile: konsistente Daten in Reports und Prozessen, geringere Pflegeaufwände, höhere Datenqualität, vereinfachte Compliance, klare Verantwortlichkeiten. Herausforderungen: organisatorische Abstimmung über Abteilungsgrenzen hinweg, Investition in Integrationsplattformen, Disziplin in der Pflege, technische Konflikte zwischen historisch gewachsenen Systemen.
Erfolgsentscheidend ist nicht die Technik, sondern die Governance: Wer entscheidet, welches System für welches Datenobjekt führend ist? Wie werden Konflikte gelöst? Wie werden neue Systeme an die SSoT angeschlossen?
Datenobjekte und ihre Quellsysteme
In der Praxis werden Datenobjekte typischerweise wie folgt zugeordnet: Finanzdaten (Konten, Buchungen, Kostenstellen) im ERP, Kundenstammdaten und Aktivitäten im CRM, Produktdaten und Marketing-Inhalte im PIM, Mitarbeitendendaten im HR-System, Lieferantendaten im SRM oder ERP, Lagerbestände im WMS bzw. ERP. Übergreifend werden diese Objekte in einem zentralen MDM-Tool oder Data Hub konsolidiert.
Wichtig ist die Unterscheidung zwischen führendem System und konsumierenden Systemen sowie die saubere Definition von Schnittstellen-Verträgen (Data Contracts). Diese legen fest, in welchem Format, mit welcher Frequenz und unter welchen Qualitätskriterien Daten ausgetauscht werden.
SSoT in Cloud- und Composable-Architekturen
In modernen Cloud- und Composable-Architekturen wird SSoT durch APIs und Event-Streaming umgesetzt. Statt Daten zu kopieren, werden sie über REST oder GraphQL on demand abgefragt. Event-Plattformen wie Kafka oder Cloud-Pub-Sub-Systeme sorgen dafür, dass Änderungen in Echtzeit an alle interessierten Konsumenten gepusht werden.
Damit verschiebt sich die Verantwortung von der zentralen Datenkopie zur dezentralen Verfügbarkeit. Voraussetzung ist eine konsequente API-First-Strategie, eindeutige Datenmodelle (Domain-Driven Design) und ein professionelles Monitoring der Datenflüsse, das Inkonsistenzen schnell erkennt.
Ja – aber jeweils pro Datenobjekt nur eine. Es ist üblich, dass das ERP die SSoT für Finanzen und Logistik ist, das CRM für Vertriebskontakte, ein PIM für Produktdaten. Wichtig ist die klare, dokumentierte Aufteilung.
Wie unterscheidet sich SSoT von einem Data Warehouse ?
Ein Data Warehouse aggregiert Daten aus operativen Systemen für Auswertungszwecke und ist selten die Bearbeitungsquelle. SSoT bezieht sich dagegen primär auf die operative Datenführung. Das Warehouse kann jedoch eine „Single Source of Reporting Truth“ sein.
Welche Rolle spielt ein API -First-ERP für SSoT?
API-First-Architekturen sind die technische Voraussetzung, um SSoT in einer heterogenen Systemlandschaft umzusetzen. Sie ermöglichen, dass viele Systeme auf eine zentrale Datenquelle zugreifen, ohne dass Daten kopiert und unkontrolliert verändert werden.
In der Praxis variiert die genaue Ausgestaltung je nach Branche, Größenklasse und Customizing-Tiefe des konkreten ERP-Setups.
