Single Source of Truth: Wie du CRM, ERP und Marketing-Software synchronisierst

Marketing sagt, der Kunde wurde dreimal kontaktiert. Sales sagt, zweimal. Das ERP zeigt einen offenen Posten, von dem Sales nichts weiß. Customer Success hat eine andere Adresse als die Buchhaltung.

Vier Systeme. Vier Versionen der Realität.

Das ist kein Datenproblem. Es ist ein Architekturproblem. Und es löst sich nicht durch bessere Datenpflege allein, sondern durch eine klare Entscheidung: Welches System ist die Quelle der Wahrheit, und wie fließen Daten von dort in alle anderen?

Was Single Source of Truth bedeutet – und was nicht

Single Source of Truth bedeutet nicht, dass alle Daten in einem einzigen System leben. Das ist weder praktisch noch notwendig.

Es bedeutet: Für jeden Datentyp gibt es genau eine autoritative Quelle. Alle anderen Systeme konsumieren diese Daten – sie erstellen sie nicht neu.

Konkret:

Das Ziel ist nicht ein System, sondern eine klare Architektur, in der jedes System weiß, woher seine Daten kommen und wohin sie fließen.

Warum fehlende Synchronisation teurer ist als gedacht

Der offensichtliche Kostenfaktor ist Zeitverlust: Mitarbeiter suchen Informationen, übertragen Daten manuell, klären Widersprüche. Laut einer IDC-Studie verbringen Wissensarbeiter durchschnittlich 2,5 Stunden pro Tag mit der Suche nach Informationen, die bereits irgendwo im Unternehmen existieren.

Der unsichtbare Kostenfaktor ist Entscheidungsqualität.

Wenn der Vertriebsleiter im Forecast-Meeting auf CRM-Daten schaut, die Geschäftsführung aber auf ERP-Zahlen – und beide nicht identisch sind – werden Entscheidungen auf unterschiedlicher Grundlage getroffen. Das führt zu Fehlallokationen, verpassten Chancen und im schlimmsten Fall zu strategischen Fehlentscheidungen.

Ein B2B-Softwareunternehmen das ich begleitet habe, hatte genau dieses Problem: Das CRM zeigte eine Pipeline von 1,2 Millionen Euro. Das ERP zeigte laufende Verträge von 820.000 Euro Jahresumsatz. Die Differenz ließ sich nicht erklären, weil die Datenpflege in beiden Systemen unabhängig voneinander lief. Budgetentscheidungen wurden auf Basis der jeweils günstigeren Zahl getroffen. Das war kein Zufall, es war strukturelles Missmanagement durch fehlende Synchronisation.

Die drei häufigsten Synchronisations-Probleme

Die drei häufigsten Synchronisationsfehler
Kundenstammdaten in mehreren Systemen gepflegt
Name, Adresse, Ansprechpartner – in CRM, ERP und Marketing-Tool jeweils separat. Wenn ein Kunde umzieht, wird es in einem System aktualisiert. In den anderen nicht.

Nach zwei Jahren hat jedes System eine andere Version des Kunden.
Keine Sichtbarkeit über System-Grenzen hinweg
Sales sieht offene Angebote – aber keine offenen Rechnungen. Customer Success sieht Supporttickets – aber nicht den Deal-Hintergrund. Marketing sieht Klicks – aber nicht welche Kunden daraufhin wirklich gekauft haben.
Jedes Team arbeitet mit seinem Ausschnitt der Realität.
Doppelte Datenanreicherung
Marketing recherchiert firmografische Daten zu einem Lead. Sales recherchiert dieselben Daten nochmal.

Weil niemand weiß, dass die Information bereits vorliegt – in einem anderen System.

Wie eine Single Source of Truth Architektur aufgebaut wird

Schritt 1: Datenverantwortung klären

Für jeden relevanten Datentyp wird eine Frage beantwortet: Welches System ist die autoritative Quelle – und welche Teams sind für die Pflege verantwortlich?

Eine einfache Matrix reicht:

Datentyp
Quelle
Konsumenten
Kontaktdaten
CRM
ERP Marketing
Firmendaten
CRM
ERP Marketing
Auftragsdaten
ERP
CRM Anzeige
Rechnungsdaten
ERP
CRM Anzeige
E-Mail-Engagement
Marketing-Tool
CRM
Lead-Score
Marketing-Tool
CRM

Schritt 2: Synchronisations-Logik definieren

Welche Daten fließen in welche Richtung? Mit welcher Frequenz? Was passiert bei Konflikten?

Beispiel:
Kontaktdaten fließen bidirektional zwischen CRM und ERP. Bei Konflikten gilt das CRM als Quelle (weil Sales die Daten aktueller hält). Synchronisation läuft stündlich.

Schritt 3: Technische Umsetzung

Je nach Systemlandschaft gibt es verschiedene Wege:

Schritt 4: Datenqualität sichern

Eine Synchronisation verbreitet, was vorhanden ist. Schlechte Daten in System A landen nach der Integration auch in System B – schneller und zuverlässiger als vorher.

Deshalb:
Vor der Integration Datenqualität prüfen. Duplikate bereinigen, fehlende Felder identifizieren, Standardisierung festlegen (z.B. einheitliches Format für Firmennamen, Telefonnummern, Länder).

Aus der Praxis: Wie ein IT-Dienstleister drei Systeme synchronisiert hat

Aus der Praxis
Wie ein IT-Dienstleister drei Systeme synchronisiert hat
30 Angestellte
Systeme: Attio Lexoffice Klavyio — keine Verbindung
Das Problem
Neue Kunden in allen drei Systemen separat angelegt
Rechnungsstatus im CRM nicht sichtbar — Sales wusste nicht, wer offene Posten hatte
Marketing sendete Newsletter auch an Kunden mit überfälligen Rechnungen
Die Lösung
Attio als Single Source of Truth für Kontakt- und Unternehmensdaten
Make als Middleware: neue Kontakte in Attio → automatisch in Lexoffice
Rechnungsstatus aus Lexoffice → zurück in Attio als Custom Property
Klavyio synchronisiert aus Attio — inkl. Segment-Tag „offene Rechnung" für Ausschluss
Das Ergebnis
Einmalige Kontaktanlage statt dreifacher Erfassung
Sales sieht Rechnungsstatus direkt im CRM-Deal
Keine Newsletter mehr an Kunden mit überfälligen Rechnungen
Setupzeit: drei Tage
Datenfluss Attio Make Lexoffice · Klavyio

Was Single Source of Truth nicht ist

Ein häufiges Missverständnis: Single Source of Truth bedeutet nicht, dass alle Daten in einem System gepflegt werden müssen. Es bedeutet, dass jeder Datentyp eine definierte Heimat hat.

Es bedeutet auch nicht, dass alle Systeme ständig synchron sein müssen. Für manche Datentypen reicht eine tägliche Synchronisation, für andere (z.B. Lead-Score bei aktiven Kampagnen) ist Echtzeit wichtig.

Die richtige Granularität hängt vom Use Case ab, nicht von einem theoretischen Ideal.

FAQ: Single Source of Truth

Muss ich dafür ein neues System einführen?
Meistens nicht. In den meisten Fällen existieren die richtigen Systeme bereits – sie sind nur nicht verbunden. Der Aufwand liegt in der Synchronisations-Architektur, nicht in neuen Tools.
Was kostet eine Middleware-Lösung wie Make oder Zapier?
Make beginnt bei etwa 9 Euro pro Monat für einfache Szenarien. Komplexere Setups mit vielen Operationen kosten 20–100 Euro monatlich. Dazu kommt der einmalige Setup-Aufwand.
Was passiert wenn die Synchronisation abbricht?
Das ist das wichtigste Risiko bei Middleware-Lösungen. Fehler müssen überwacht werden. Make und Zapier bieten Error-Notifications – aber jemand muss darauf reagieren. Kritische Integrationen (CRM ↔ ERP) sollten mit API-Direktverbindungen stabiler aufgebaut werden.
Kostenlose vs. kostenpflichtige CRMs. Lohnt sich der Unterschied?
HubSpot hat ein starkes kostenloses Paket. Für kleine Teams reicht es oft aus. Sobald Automatisierungen, erweitertes Reporting oder Marketing-Features gebraucht werden, kommt man um kostenpflichtige Pläne nicht herum.
Brauchen wir dafür technisches Know-how?
Für Middleware-Lösungen: begrenzt. Make und Zapier sind ohne Programmierung nutzbar. Für API-Integrationen: ja. Wer keine technischen Ressourcen intern hat, sollte externe Unterstützung für den Aufbau einplanen.

Fazit: Eine Wahrheit ist besser als vier

Vier Systeme mit vier verschiedenen Versionen der Realität sind kein Datenproblem. Sie sind ein Führungsproblem – weil Entscheidungen auf inkonsistenter Grundlage getroffen werden.

 

Eine klare Synchronisations-Architektur kostet einmalig Zeit und Aufwand. Sie spart dauerhaft Energie, reduziert Fehler und verbessert die Entscheidungsqualität in allen Teams.

 

Das ist einer der Hebel mit dem besten Verhältnis von Aufwand zu Impact im gesamten Revenue-Prozess.

Deine Systeme reden nicht miteinander?

Ich helfe dir, die Architektur zu definieren und die richtigen Verbindungen aufzubauen – damit deine Teams endlich auf derselben Grundlage arbeiten.

Add comment:

Related Articles

Letzte Insights

Popular Keyword

Ads banner (320 X 320)