Single Source of Truth im CRM: Ein Mythos, der scheitert

Der Mythos der einen Wahrheit

Ein CRM kann keine einzige, verbindliche Wahrheit über einen Kunden liefern, weil unterschiedliche Systeme unterschiedliche Ausschnitte der Realität abbilden. Marketing-Automatisierung, Vertriebs-CRM und Service-Tool erfassen jeweils andere Ereignisse, zu anderen Zeitpunkten, mit anderer Aktualität. Die Idee einer Single Source of Truth klingt in Projektpräsentationen überzeugend, hält der Praxis aber selten stand. Genau daran scheitern viele CRM-Einführungen: nicht an der Software, sondern an der Annahme, ein System könne alle Daten dauerhaft konsistent halten.

Gemeint ist mit dem Begriff meist: Alle Kundendaten landen in einem System, jede Abteilung arbeitet mit denselben Werten, Widersprüche verschwinden von selbst. In der Realität erfassen Marketing-Tools Kampagnendaten und Consent-Status nahezu in Echtzeit, das Vertriebs-CRM verwaltet Deal-Stadien und Ansprechpartner, Service-Systeme führen Ticket-Historien und SLA-Fristen. Jedes dieser Systeme hat eigene Aktualisierungszyklen, eigene Datenmodelle und eigene Zugriffsrechte. Wer versucht, das alles in einem einzigen System zu bündeln, baut entweder ein überladenes CRM, das für keinen der drei Anwendungsfälle gut funktioniert, oder Schnittstellen, die ständig gegeneinander laufen.

System of Record vs. System of Engagement

Der Unterschied zwischen System of Record und System of Engagement hilft, das Problem zu strukturieren. Ein System of Record ist die verbindliche Quelle für einen bestimmten Datentyp, zum Beispiel das ERP für Rechnungsadressen oder das CRM für Deal-Werte. Ein System of Engagement ist das Werkzeug, mit dem Teams täglich arbeiten. Es zeigt Daten an, reichert sie an, nutzt sie für Automatisierung, muss aber nicht zwingend die Ursprungsquelle sein.

Diese Unterscheidung klingt banal, wird in der Praxis aber selten sauber durchgezogen. Viele Unternehmen deklarieren HubSpot oder Salesforce pauschal zum Master-System, ohne festzulegen, für welche Felder das tatsächlich gilt. Das Ergebnis: Ein System gilt formal als führend, tatsächlich pflegen mehrere Abteilungen dieselben Felder parallel weiter, weil die Zuständigkeit nie konkret dokumentiert wurde.

Wo Datenkonflikte tatsächlich entstehen

Konflikte entstehen selten durch technische Fehler, sondern durch fehlende Zuordnung. Ein typisches Beispiel ist der Lead-Status: Marketing markiert einen Kontakt als Marketing Qualified Lead, Sales überschreibt den Status beim ersten Anruf, Service ändert ihn erneut, wenn ein Ticket entsteht. Ohne klare Regel, welches System zu welchem Zeitpunkt schreibberechtigt ist, überschreiben sich die Abteilungen gegenseitig, teils mehrfach am Tag.

Ähnliches gilt für Firmendaten: Ein Marketing-Tool reichert Firmengröße und Branche über einen Drittanbieter an, das ERP führt die rechtsverbindliche Adresse, der Vertrieb pflegt manuell abweichende Werte, weil der Kontakt vor Ort andere Informationen genannt hat. Am Ende weiß niemand mehr, welches Feld verlässlich ist, und Reports aus unterschiedlichen Systemen widersprechen sich, obwohl sie theoretisch dieselbe Grundlage haben sollten.

Ein Governance-Modell für Systemverantwortlichkeiten

Ein praxisnahes Modell verteilt Verantwortlichkeiten nicht pauschal pro System, sondern pro Datenobjekt und Feld. Für jedes zentrale Objekt – Kontakt, Firma, Deal, Ticket – wird festgelegt, welches System für welches Feld als System of Record gilt, wer schreiben darf, wer nur lesen darf, wie häufig synchronisiert wird und was bei Konflikten passiert.

Diese Zuordnung gehört in ein Dokument, das für alle Beteiligten einsehbar ist, nicht in den Kopf eines einzelnen Administrators. Wer eine solche Governance sauber aufbauen will, braucht vorab eine gründliche Anforderungsaufnahme über Abteilungsgrenzen hinweg, weil sich Feldverantwortlichkeiten nur klären lassen, wenn Marketing, Sales und Service gemeinsam am Tisch sitzen. Zusätzlich braucht es eine Eskalationsregel: Wenn zwei Systeme widersprüchliche Werte liefern, muss definiert sein, welcher Wert gewinnt, zeitbasiert, also der jeweils neueste Eintrag, oder quellenbasiert, also ein bestimmtes System hat grundsätzlich Vorrang.

Kriterien für eine belastbare Datenhoheit

Bei der Zuordnung eines Feldes zu einem System of Record helfen vier Kriterien:

• Verbindlichkeit: Welches System hat rechtliche oder vertragliche Bindungswirkung, etwa bei Rechnungsadressen oder Vertragskonditionen?
• Aktualität: Welches System erfasst Änderungen an diesem Feld am schnellsten und am direktesten, ohne Umweg über eine manuelle Nacherfassung?
• Reichweite: Wie viele nachgelagerte Prozesse und Automatisierungen hängen an diesem Feld, und wie teuer wird ein falscher Wert?
• Änderungsfrequenz: Wie oft ändert sich der Wert, und wie hoch ist dadurch das Risiko, dass zwei Systeme gleichzeitig schreiben?

Felder mit hoher Änderungsfrequenz und hoher Reichweite, etwa der Lead-Status oder der Deal-Betrag, verdienen eine explizite, dokumentierte Regel. Felder mit geringer Reichweite, etwa interne Notizfelder, lassen sich pragmatischer handhaben.

Was das für die CRM-Architektur bedeutet

Für die technische Umsetzung bedeutet dieses Modell, dass Integrationen nicht mehr als einfache Zwei-Wege-Synchronisation gedacht werden dürfen, sondern feldbasiert konfiguriert werden müssen: Manche Felder fließen nur in eine Richtung, andere bidirektional, wieder andere gar nicht. Genau das ist der Kern moderner RevOps-Ansätze, die Marketing, Sales und Service zusammenführen, ohne ein einzelnes System zu überfrachten. Governance-Regeln ersetzen dabei die Illusion einer zentralen Wahrheit durch klar dokumentierte Verantwortlichkeiten.

Die Aufgabe wird in den kommenden Jahren nicht einfacher. Mit dem Aufkommen autonomer KI-Agenten in CRM-Systemen schreiben künftig nicht mehr nur Menschen und klassische Integrationen Daten, sondern auch automatisierte Agenten, die Felder in Echtzeit aktualisieren. Ohne eine saubere Feld-für-Feld-Governance steigt damit auch das Risiko widersprüchlicher, gleichzeitig geschriebener Werte deutlich. Unternehmen, die jetzt eine belastbare Struktur für Systemverantwortlichkeiten aufbauen, sind auf diese Entwicklung besser vorbereitet als Unternehmen, die weiterhin auf ein einzelnes Master-System hoffen.

Häufig gestellte Fragen

Kann ein CRM überhaupt eine Single Source of Truth sein?

Für einzelne, klar abgegrenzte Datenfelder ja, für alle Kundendaten in der Regel nein. Marketing-, Sales- und Service-Systeme erfassen unterschiedliche Ereignisse zu unterschiedlichen Zeitpunkten, sodass ein einzelnes System diese Vielfalt nicht verlustfrei abbilden kann.

Was ist der Unterschied zwischen System of Record und System of Engagement?

Ein System of Record ist die verbindliche Datenquelle für ein bestimmtes Feld, ein System of Engagement ist das Werkzeug, mit dem Teams täglich arbeiten, ohne zwingend die Ursprungsquelle der Daten zu sein.

Wie löst man Datenkonflikte zwischen Marketing- und Sales-Systemen?

Über eine dokumentierte Governance, die pro Feld festlegt, welches System schreibberechtigt ist, wie synchronisiert wird und welche Regel bei widersprüchlichen Werten greift, zeitbasiert oder quellenbasiert.

Wer sollte die Datenhoheit im Unternehmen festlegen?

Idealerweise ein abteilungsübergreifendes Team aus Marketing, Sales, Service und IT beziehungsweise RevOps, da einseitig getroffene Entscheidungen erfahrungsgemäß von den nicht beteiligten Abteilungen unterlaufen werden.