Abonniere den Blog und erhalte wertvolles Wissen und praktische Tipps rund um Customer Intelligence ✨
Ein Account im CRM zeigt die Mueller GmbH. Im SAP steht Mueller GmbH & Co KG. Die Lieferadresse stimmt in keinem System. Der nächste Auftrag dauert einen halben Tag Klärungsarbeit. Im DACH-Maschinenbau trifft eine SAP-dominierte ERP-Landschaft auf eine stark fragmentierte CRM-Welt. Diese Konstellation ist weltweit einzigartig: Während SAP hier rund 25 Prozent CRM-Marktanteil hält, konkurrieren Microsoft Dynamics, Salesforce, HubSpot, CAS und zahlreiche Eigenentwicklungen um die verbleibenden Anteile. Die Folge: Ohne präzise Mastership-Regeln pro Feld und bidirektionale Echtzeit-Synchronisation laufen Stammdaten zwangsläufig auseinander.
Die CRM-Landschaft im deutschen Maschinenbau unterscheidet sich fundamental von internationalen Märkten. Global dominiert Salesforce mit rund 22 Prozent Marktanteil, gefolgt von Microsoft und SAP. Im DACH-Maschinenbau hingegen hält SAP eine Sonderposition: Das Unternehmen vereint hier etwa 25 Prozent des CRM-Marktes auf sich, während gleichzeitig in vielen Betrieben das ERP-System ebenfalls aus Walldorf stammt. Das klingt nach idealen Voraussetzungen für Integration. Die Praxis zeigt jedoch ein anderes Bild: Neben SAP-CRM-Lösungen wie Cloud for Customer oder Sales Cloud V2 konkurrieren Microsoft Dynamics 365 (etwa 19 Prozent), Salesforce Sales Cloud (rund 11 Prozent), HubSpot, CAS genesisWorld und eine bemerkenswerte Zahl von Eigenentwicklungen (circa 17 Prozent) um die Vertriebsteams. Diese Fragmentierung ist historisch gewachsen. Viele Maschinenbauer haben über Jahrzehnte SAP als ERP-Rückgrat etabliert, während die CRM-Einführung oft später erfolgte und durch andere Anforderungen getrieben wurde: Marketing wollte HubSpot, der Vertrieb schwor auf Salesforce, der Außendienst brauchte mobile CRM-Funktionen, die SAP damals nicht bot. Das Ergebnis: heterogene Systemlandschaften, in denen Stammdaten an mehreren Stellen gepflegt werden müssen.
Stammdaten sind nicht gleich Stammdaten. Für die Synchronisation zwischen SAP und CRM lassen sich drei Kategorien unterscheiden, die jeweils eigene Herausforderungen mitbringen:
Account-Stammdaten (Name, Adresse, USt-ID, Rechtsform): Dies sind die Grundinformationen zum Geschäftspartner. Im SAP heißen sie oft Geschäftspartner oder Debitor, im CRM Account oder Firma. Schon die Benennung zeigt das Problem: In SAP werden Accounts häufig mit voller Rechtsform angelegt (Mueller GmbH & Co KG), während im CRM die Kurzform reicht (Mueller GmbH). Unterschiedliche Schreibweisen, Abkürzungen (GmbH vs. G.m.b.H.) und fehlende Standards bei der Erstanlage führen dazu, dass derselbe Kunde in beiden Systemen anders heißt.
Kontaktstammdaten (Position, Telefonnummer, E-Mail, Abteilung): Ansprechpartner sind hochdynamisch. Ein technischer Einkäufer wechselt die Abteilung, der Geschäftsführer geht in Rente, ein neuer Projektleiter tritt auf. Laut Branchenstudien veralten etwa 30 Prozent der B2B-Kontaktdaten jährlich. Werden diese Änderungen nur im CRM gepflegt (weil der Vertrieb dort arbeitet), bleiben sie im SAP unsichtbar. Umgekehrt aktualisiert die Buchhaltung Rechnungsadressen direkt im ERP, ohne dass das CRM davon erfährt.
Beziehungsdaten (Account-Hierarchie, Buying-Center-Rollen, Standortzuordnungen): Im Maschinenbau sind Konzernstrukturen die Regel. Ein Stammwerk in Deutschland, Produktionsstandorte in Polen und Tschechien, eine Einkaufszentrale in der Schweiz. Im SAP werden diese oft als separate Debitoren geführt, während das CRM versucht, eine übergeordnete Account-Hierarchie abzubilden. Ohne klare Zuordnungslogik entstehen Dubletten und inkonsistente Hierarchien, die Sales-Forecasts und Umsatzauswertungen verfälschen.
Das zentrale Problem der Stammdatensynchronisation ist nicht technischer, sondern organisatorischer Natur: Wer darf was ändern? Und welches System hat im Konfliktfall Recht? Viele Unternehmen versuchen, dieses Problem durch eine pauschale Regel zu lösen: „SAP ist Master für alle Stammdaten.“ Das scheitert in der Praxis, weil nicht jedes Feld im ERP aktueller oder richtiger ist als im CRM. Stattdessen braucht es Mastership-Regeln auf Feldebene:
ERP-mastered: Inventarstände, Kreditlimits, Zahlungsbedingungen, Rechnungsadressen, buchhalterisch relevante Daten. Diese Felder werden ausschließlich im SAP gepflegt. Änderungen im CRM werden blockiert oder überschrieben.
CRM-mastered: Pipeline-Status, Lead-Scores, Kampagnenzuordnungen, Kontakthistorie, Vertriebsnotizen. Diese Daten entstehen im CRM und haben dort ihre einzige Quelle. Das ERP kann sie lesen (für Reportingzwecke), aber nicht ändern.
Bidirektional mit Konfliktlösung: Kontaktdaten (Telefon, E-Mail), Adressen (wenn nicht rechnungsrelevant), Ansprechpartner. Diese Felder dürfen in beiden Systemen geändert werden. Bei gleichzeitigen Änderungen greift eine vorab definierte Regel: „Last Write Wins“ (die neueste Änderung setzt sich durch) oder „CRM Wins“ (das CRM überstimmt das ERP bei Kontaktdaten). Ein konkretes Beispiel aus der Praxis: Ein mittelständischer Maschinenbauer synchronisiert zwischen SAP S/4HANA und Salesforce Sales Cloud. Die Mastership-Matrix sieht so aus: Debitorennummer (SAP), Firmenname (SAP), Rechnungsadresse (SAP), Kreditlimit (SAP), Kontaktperson Name (bidirektional, Last Write Wins), Kontaktperson E-Mail (bidirektional, CRM Wins bei Konflikt), Lead Status (CRM), Opportunity Stage (CRM), Offene Posten (SAP, Read-Only im CRM). Diese Regeln müssen nicht nur technisch implementiert, sondern auch organisatorisch verankert werden. Die Buchhaltung muss wissen, dass sie Kontakt-E-Mails nicht im SAP ändern darf. Der Vertrieb muss verstehen, dass Kreditlimits nur im ERP gesetzt werden können. Ohne Change Management bleibt die beste Synchronisationslogik wirkungslos.
Die zweite zentrale Entscheidung: Wie schnell müssen Änderungen übertragen werden?
Echtzeit-Synchronisation bedeutet: Jede Änderung im Quellsystem löst innerhalb von Sekunden eine Aktualisierung im Zielsystem aus. Das ist technisch anspruchsvoll (API-basiert, event-driven), aber für bestimmte Felder unverzichtbar. Ein Vertriebsmitarbeiter muss sehen, ob ein Kunde zahlungsüberfällig ist, bevor er ein neues Angebot erstellt. Ein Servicetechniker braucht die aktuelle Seriennummer der Maschine, nicht den Stand von gestern Nacht.
Batch-Synchronisation hingegen läuft zu festen Zeitpunkten: einmal pro Stunde, einmal nachts, einmal wöchentlich. Das reicht für unkritische Felder wie historische Umsatzdaten, Branchenzuordnungen oder statistische Auswertungen. Batch-Sync ist einfacher zu implementieren, belastet die Systeme weniger und ist fehlertoleranter (wenn ein Batch fehlschlägt, läuft der nächste einfach erneut). Die goldene Regel: Echtzeit für transaktionale Felder, Batch für Stammdaten-Bulk. Account-Status, Kreditlimit, offene Aufträge: Echtzeit. Initial-Load beim Go-Live, historische Kontakte, Massenmutationen: Batch. In der Praxis sieht das so aus: Die MARINI HubEngine definiert für jede Verbindung zwischen SAP und CRM einen sogenannten Plan. Dieser Plan enthält die Mastership-Regeln, die Feldzuordnungen (Mapping) und die Sync-Strategie. Ein Plan für Kreditlimits synchronisiert in Echtzeit via SAP OData API. Ein Plan für Kontaktdaten läuft bidirektional, ebenfalls in Echtzeit. Ein Plan für historische Aufträge läuft einmal nachts als Batch. Der Vorteil dieser Granularität: Jedes Datenobjekt kann individuell gesteuert werden. Keine pauschale „Alles-oder-Nichts“-Logik, sondern präzise Regeln pro Feld und Objekt. Das reduziert die Systemlast, minimiert Konfliktrisiken und macht die Synchronisation wartbar.
Selbst die beste Synchronisationslogik scheitert, wenn die Ausgangsdaten fehlerhaft sind. Dubletten, unvollständige Adressen, inkonsistente Schreibweisen: Diese Probleme werden durch Synchronisation nicht gelöst, sondern multipliziert. Ein klassisches Szenario: Im SAP existieren drei Debitoren für denselben Kunden (ein Stammwerk, zwei Produktionsstandorte). Im CRM gibt es zwei Accounts (einer vom Marketing angelegt, einer vom Vertrieb). Die Synchronisation versucht nun, diese fünf Datensätze abzugleichen. Ohne Golden-Record-Logik entstehen entweder weitere Dubletten oder die falschen Datensätze werden zusammengeführt. Die Lösung: Datenbereinigung vor der Integration. Das bedeutet: Dubletten im SAP identifizieren und konsolidieren, Accounts im CRM deduplizieren, eine eindeutige Matching-Logik definieren (zum Beispiel über eine externe ID oder USt-ID), fehlende Pflichtfelder ergänzen. Die MARINI Data Cloud unterstützt diesen Prozess durch KI-gestütztes Record Linkage: Datensätze, die zusammengehören (auch wenn sie nicht identisch sind), werden erkannt und verknüpft. Ein Datensatz „Mueller GmbH & Co KG“ im SAP und „Mueller GmbH“ im CRM werden als derselbe Kunde identifiziert, auch wenn die Strings nicht exakt übereinstimmen. Zusätzlich kann die Data Cloud externe Datenquellen einbinden, etwa Dun & Bradstreet für Bonitätsinformationen oder Handelsregisterdaten für Rechtsformen und Geschäftsführer. Diese Anreicherung sorgt dafür, dass Stammdaten nicht nur synchron, sondern auch korrekt und aktuell sind.
MARINI wurde genau für diese Szenarien entwickelt: fragmentierte Systemlandschaften im Mittelstand, in denen SAP-ERP-Systeme auf heterogene CRM-Lösungen treffen. Die Plattform besteht aus zwei Engines: Die HubEngine übernimmt die Integration und Synchronisation. Sie verbindet SAP (S/4HANA, ECC, Business One) bidirektional mit CRM-Systemen wie Salesforce, Microsoft Dynamics, HubSpot, CAS oder Eigenentwicklungen. Jede Verbindung wird über einen Plan konfiguriert, der Mastership-Regeln, Mapping, Validierung und Konfliktlösung enthält. Die DataEngine reichert die synchronisierten Daten an: Deduplizierung, Golden-Record-Bildung, KI-gestütztes Record Linkage, externe Datenanreicherung (Dun & Bradstreet, Web-Crawler, Mustererkennung). Das Ergebnis: nicht nur synchrone, sondern qualitätsgeprüfte und konsolidierte Stammdaten. Ein konkreter Use Case aus dem Maschinenbau: Ein Anlagenbauer mit SAP S/4HANA und Salesforce Sales Cloud hatte das Problem, dass Kontaktdaten dauerhaft auseinanderliefen. Der Vertrieb pflegte Ansprechpartner im CRM, die Buchhaltung änderte Rechnungsadressen im SAP, niemand hatte den Überblick. MARINI implementierte eine bidirektionale Echtzeit-Synchronisation mit folgenden Regeln: Rechnungsadresse SAP-mastered (Read-Only im CRM), Kontaktperson bidirektional (CRM Wins bei Konflikt), offene Posten SAP-mastered (automatischer Push ins CRM alle 15 Minuten). Zusätzlich wurde die Data Cloud aktiviert, um Dubletten zu konsolidieren. Das Ergebnis: Von 1.200 Accounts im CRM und 980 Debitoren im SAP blieben nach der Bereinigung 850 eindeutige Kunden übrig. Die Datenqualität stieg messbar: Die Quote unzustellbarer E-Mails sank von 12 auf 3 Prozent, die Anzahl doppelt angelegter Angebote ging um 70 Prozent zurück. MARINI positioniert sich bewusst nicht als Agentur oder System-Beratung. Die Plattform ist eigenständig nutzbar. Für Leistungen in den angebundenen Systemen (SAP-Customizing, Salesforce-Konfiguration, HubSpot-Setup) verweist MARINI auf sein Partnernetzwerk. Der Fokus liegt auf dem, was zwischen den Systemen passiert: Datenintegration, Datenqualität und Customer Intelligence.
Die wichtigsten Erkenntnisse aus Integrationsprojekten im DACH-Maschinenbau lassen sich in fünf Punkten zusammenfassen:
Erstens: Mastership-Regeln sind keine IT-Entscheidung, sondern eine organisatorische. Fachabteilungen (Vertrieb, Buchhaltung, Service) müssen gemeinsam definieren, wer welche Daten pflegt. Ohne diese Klärung bleibt die beste Synchronisation wirkungslos.
Zweitens: Nicht alles muss in Echtzeit synchronisiert werden. Echtzeit ist teuer (technisch und organisatorisch) und sollte nur dort eingesetzt werden, wo es wirklich nötig ist: bei transaktionalen Daten, Kreditlimits, Lagerbeständen. Stammdaten-Bulk kann nachts laufen.
Drittens: Datenbereinigung vor Integration spart Monate an Nacharbeit. Dubletten, unvollständige Datensätze und inkonsistente Schreibweisen müssen vor der ersten Synchronisation bereinigt werden, nicht danach.
Viertens: Bidirektionale Synchronisation ist keine Hexerei, erfordert aber präzise Konfliktlösungsregeln. Last Write Wins funktioniert nur bei Feldern, die selten gleichzeitig geändert werden. Bei kritischen Feldern (Kontaktdaten, Adressen) braucht es explizite Priorisierungslogik.
Fünftens: Integration ist kein einmaliges Projekt. Systeme ändern sich, Datenmodelle wachsen, neue Felder kommen hinzu. Eine wartbare, dokumentierte Synchronisationslogik ist der Schlüssel zu langfristigem Erfolg. Der DACH-Maschinenbau steht vor einer strukturellen Herausforderung: SAP im ERP, Fragmentierung im CRM, Datensilos überall. Aber diese Herausforderung ist lösbar. Mit klaren Mastership-Regeln, granularer Sync-Strategie und konsequenter Datenqualität entstehen keine Insellösungen, sondern durchgängige, verlässliche Datenflüsse. Dann wird aus „SAP versus CRM“ ein „SAP und CRM“, und Stammdaten laufen nicht mehr auseinander, sondern zusammen.
Hrsg. Prof. Dr. Emanuel Bayer und Manuel Marini · Springer Gabler, 2025
Der Sammelband zeigt, wie aus Kundendaten messbarer Wert wird — mit 22 Beiträgen aus Wissenschaft und Praxis, strukturiert entlang der fünf Stufen des Customer Intelligence Evolution Framework (CIEF).
