Single Point of Truth (SPoT)

Ein Single Point of Truth (SPoT) bezeichnet eine einzige, organisatorisch und technisch verbindliche Quelle, an der ein bestimmtes Datum oder ein Datensatz im Unternehmen geführt, gepflegt und für alle Beteiligten autoritativ bereitgestellt wird. Greifen unterschiedliche Abteilungen oder Systeme auf eine Information zu, verweisen sie idealerweise auf genau diesen einen Punkt statt auf eigene Kopien.

Im ERP-Umfeld ist der SPoT ein Leitprinzip für die Datenhaltung: Es soll verhindern, dass dieselbe Information – etwa eine Kundenadresse, ein Materialstamm oder ein Lagerbestand – in mehreren Systemen parallel und widersprüchlich existiert.

Grundidee und Funktionsweise

Der Single Point of Truth beruht auf einem einfachen Gedanken: Für jede Information gibt es genau einen Ort, der als verbindlich gilt. Alle anderen Stellen, an denen diese Information erscheint, sind abgeleitete Sichten oder Kopien, die ihren Wert aus dieser einen Quelle beziehen. Ändert sich der Wert, geschieht das ausschließlich am verbindlichen Punkt; nachgelagerte Systeme übernehmen die Änderung automatisch oder durch definierte Abgleichprozesse.

Technisch wird ein SPoT meist über eine zentrale Datenbank, einen führenden Datensatz oder ein dediziertes System realisiert. Entscheidend ist nicht allein die Technik, sondern die organisatorische Festlegung, welches System für welches Datum „führend“ ist. Diese Zuständigkeitsregel wird häufig im Rahmen des Master Data Management dokumentiert und verbindlich gemacht.

Bestandteile und typischer Ablauf

Damit ein Single Point of Truth funktioniert, müssen mehrere Elemente zusammenspielen. Zunächst braucht es eine klare Festlegung des führenden Systems je Datenobjekt. Anschließend werden Erfassungs- und Pflegeregeln definiert, sodass neue oder geänderte Werte nur dort entstehen. Schließlich sorgen Schnittstellen und Abgleichmechanismen dafür, dass abhängige Systeme aktuell bleiben.

• Führendes System: festgelegte Quelle je Datenobjekt (z. B. ERP für Materialstämme).
• Pflegeprozess: geregelte Stammdatenpflege mit Verantwortlichkeiten und Freigaben.
• Verteilung: Synchronisation über Schnittstellen, etwa per API oder ETL-Strecken.
• Nachvollziehbarkeit: Protokollierung von Änderungen, oft über einen Audit-Trail.

Relevanz im ERP-Kontext

Ein ERP-System ist in vielen Unternehmen der natürliche Kandidat für den Single Point of Truth, weil es Stammdaten, Bewegungsdaten und Prozesse abteilungsübergreifend bündelt. Vertrieb, Einkauf, Produktion und Buchhaltung arbeiten dann auf demselben Datenbestand, statt jeweils eigene Listen zu führen. Das reduziert Abstimmungsaufwand, vermeidet widersprüchliche Auskünfte und erhöht die Verlässlichkeit von Auswertungen.

Die Mandantenfähigkeit spielt hier eine Rolle, weil ein SPoT je Mandant oder konzernweit definiert werden kann. Wichtig ist die Unterscheidung: Der SPoT betrifft die organisatorische und logische Hoheit über ein Datum, nicht zwingend dessen physische Speicherung an nur einem technischen Ort.

Praxisbeispiel

Ein mittelständischer Fertigungsbetrieb pflegt Kundenadressen bislang im CRM, in der Versandsoftware und in einer Excel-Liste der Buchhaltung. Bei einer Adressänderung entstehen drei abweichende Stände, Rechnungen gehen an veraltete Anschriften. Durch Einführung eines Single Point of Truth wird festgelegt, dass das ERP-System der führende Ort für Kunden-Stammdaten ist. Das CRM und die Versandsoftware beziehen Adressen fortan über eine Schnittstelle aus dem ERP. Eine Änderung wird nur noch einmal erfasst und wirkt sich überall aus. Beispielhaft und ohne Wertung lassen sich solche Architekturen mit verschiedenen Systemen umsetzen, etwa SAP, Microsoft Dynamics 365, Infor oder Sage – entscheidend ist das Konzept, nicht das Produkt.

Umsetzungshinweise und Auswahl

Wer einen Single Point of Truth etablieren möchte, sollte mit einer Bestandsaufnahme beginnen: Welche Datenobjekte existieren mehrfach, und welches System führt sie tatsächlich am verlässlichsten? Erst danach folgt die technische Anbindung. Sinnvoll ist eine schrittweise Einführung je Datendomäne statt eines Big-Bang-Ansatzes.

Bei der Systemauswahl ist relevant, wie offen die Schnittstellen sind und ob sich Pflegeprozesse mit klaren Rollen abbilden lassen. Ein durchdachtes Rollenkonzept stellt sicher, dass nur berechtigte Personen am führenden Punkt schreiben. Ebenso wichtig ist eine saubere Datenmigration, da Altbestände vor der Zusammenführung bereinigt werden müssen.

Abgrenzung

Der Begriff wird häufig synonym zum Single Source of Truth verwendet. In der Praxis betont „Single Point of Truth“ stärker den einen verbindlichen Zugriffs- oder Pflegepunkt, während „Single Source of Truth“ die maßgebliche Datenquelle als Konzept hervorhebt; die Grenzen sind fließend. Ein SPoT ist außerdem kein Data Warehouse: Dieses dient der Analyse aus konsolidierten Daten, ersetzt aber nicht die führende Quelle für die operative Pflege. Auch garantiert ein SPoT keine inhaltliche Richtigkeit – er stellt sicher, dass alle denselben Stand sehen, nicht, dass dieser Stand fehlerfrei ist.

Warum ist Single Point of Truth so wichtig?

Ohne SPoT entstehen klassische Symptome:

• Excel-Wildwuchs — jede Abteilung pflegt eigene Listen mit ähnlichem Inhalt
• Stundenlange Diskussionen in Meetings, wessen Zahl stimmt
• Reports aus Tool A widersprechen denen aus Tool B
• Compliance-Audits werden zur Detektiv-Arbeit
• Strategische Entscheidungen basieren auf unsicheren Daten

Der Aufwand, Inkonsistenzen aufzulösen, übersteigt langfristig den initialen Aufwand, eine SPoT-Architektur aufzubauen.

Wie wird SPoT in einem ERP-System realisiert?

Ein gut implementiertes ERP-System ist der natürliche SPoT für transaktionale Daten:

• Kunden-Stammdaten: zentral im ERP, von dort an CRM, Webshop, Mailings repliziert
• Artikel-Stammdaten: ERP als Quelle, von dort an Webshop, Marktplätze, Kataloge syndiziert
• Preise und Konditionen: ERP-Preisliste als alleinige Wahrheit
• Aufträge und Belege: alle Vertriebs-Kanäle landen im ERP
• Buchhaltungs-Konten: Finanz-Modul des ERP als alleinige Buchungs-Quelle

Für analytische Daten (KPIs, Berichte) übernimmt typisch ein Data Warehouse oder ein Lakehouse die SPoT-Rolle — es konsolidiert ERP-Daten mit Web-Tracking, CRM-Aktivitäten und Markt-Daten.

Welche Hürden stehen einer SPoT-Architektur im Weg?

• Historisch gewachsene Systeme: Best-of-Breed-Landschaften (CRM, ERP, Shop, PIM, separate Excel) haben jeweils eigene Daten-Bestände
• M&A-Bedingt: Zugekaufte Unternehmen bringen eigene ERPs mit — Konsolidierung dauert Jahre
• Abteilungs-Politik: Marketing will andere KPI-Definitionen als Vertrieb
• Zeitliche Konsistenz: Replikation in Sekunden vs. Tagen — wann ist ein Datum aktuell genug?
• Fehlende Master-Data-Governance: Niemand ist verantwortlich für die Pflege der Stammdaten

SPoT in der Praxis: Master Data Management

Operativ wird SPoT durch Master Data Management (MDM) umgesetzt:

• Definition: welches System ist Master für welche Daten-Domain (Kunde, Artikel, Lieferant)?
• Governance: Rollen wie Data Steward, Data Owner werden benannt
• Werkzeuge: dedizierte MDM-Plattformen (Stibo, Informatica, SAP MDG, Profisee) oder ERP-eigene Stammdaten-Module
• Prozesse: Pflege-Workflows mit Vier-Augen-Prinzip, Daten-Qualitäts-Checks
• Integration: APIs oder ESBs verteilen Daten vom Master in alle abhängigen Systeme

Verwandte Themen

• ERP – Enterprise Resource Planning
• Data Warehouse
• Stammdatenpflege
• API – Application Programming Interface
• Composable ERP

← Zurück zur Startseite