Abonniere den Blog und erhalte wertvolles Wissen und praktische Tipps rund um Customer Intelligence ✨
Im globalen Account Review präsentiert das KAM-Team den Top-Konzern Bosch. Die DE-Tochter zeigt 4,2 Mio Euro Umsatz, die JP-Tochter 1,1 Mio Euro, die BR-Tochter unbekannt. Aggregation auf Konzern-Ebene? Nicht im CRM. Im Excel-Sheet 23 Zeilen mit Buchungen fragwürdiger Zuordnung. Das ist kein Bosch-spezifisches Problem. Jeder Maschinenbauer mit Konzern-Kunden kennt diese Situation: Die Holding sitzt in München, das Werk produziert in Shanghai, die Rechnung geht nach Singapur, der Service-Vertrag läuft auf die Schweizer Tochter. Im CRM erscheinen alle vier als separate Accounts, mit fragmentiertem Umsatz, zersplitterten Ansprechpartnern und ohne konsolidierte Sicht auf die Gesamtbeziehung. Hierarchische Account-Strukturen sind im B2B-Maschinenbau keine Kür, sondern Hygienefaktor, und technisch anspruchsvoller, als die meisten CRM-Systeme out-of-the-box abbilden können.
Im Maschinenbau treffen drei Komplexitätsebenen aufeinander, die in anderen B2B-Branchen isoliert auftreten, hier aber gleichzeitig wirken. Erstens: Die Multi-Standort-Struktur der Kunden. Ein Konzern wie ABB betreibt über 100 Produktionsstandorte in 53 Ländern, BASF hat mehr als 230 Produktionsstandorte weltweit, Bosch rund 400 Tochtergesellschaften. Jeder Standort ist potenziell ein eigenständiger Geschäftspartner mit lokaler Einkaufsverantwortung, aber ohne konsolidierte Verhandlungsmacht würde der Konzern deutlich höhere Preise zahlen.
Zweitens: Die eigene internationale Struktur des Maschinenbauers. Ein deutscher Maschinenbauer bedient seinen japanischen Konzern-Kunden über die Japan-Niederlassung, den brasilianischen Standort desselben Konzerns über die Brasilien-Tochter. Beide Niederlassungen führen eigene CRM-Systeme oder separate Salesforce-Orgs. Die Frage „Wie viel Umsatz machen wir mit Bosch weltweit?“ ist ohne übergreifende Hierarchie nicht beantwortbar.
Drittens: Vertragliche Komplexität über Hierarchieebenen hinweg. Master Service Agreements laufen auf Konzern-Ebene, einzelne Wartungsverträge auf Werk-Ebene, Ersatzteillieferungen auf Profit-Center-Ebene. Rabattstaffeln gelten konzernweit, aber die Abrechnung erfolgt pro rechtlicher Einheit. Ohne saubere Hierarchie-Zuordnung ist nicht erkennbar, ob ein neuer Service-Vertrag mit „Bosch Rexroth AG, Werk Homburg“ unter den globalen Rahmenvertrag fällt oder separat verhandelt werden muss.
Die Herausforderung ist nicht nur technisch, sie ist konzeptionell. Standardmäßige CRM-Systeme bieten Parent-Child-Beziehungen an, aber diese sind meist auf zwei Ebenen begrenzt (Account → Unteraccount) und ohne Aggregationslogik. Wer mehr als drei Hierarchieebenen abbilden muss, stößt an Grenzen. Wer konsolidierte KPIs über alle Ebenen braucht, muss Custom Reports bauen, die bei jeder Datenänderung neu berechnet werden müssen. Und wer diese Hierarchie bidirektional mit ERP, Service-System und Produktkonfigurator synchronisieren will, baut eine Integrationslandschaft, die bei jedem M&A-Fall des Kunden neu konfiguriert werden muss.
Im B2B-Maschinenbau haben sich vier Hierarchieebenen als Standard etabliert, die jeweils eigene Geschäftslogik tragen. Konzern (Holding) ist die oberste Ebene: Hier laufen globale Rahmenverträge, konzernweite Rabattstaffeln und strategische Partnerschaften. Beispiel: „Bosch“ als Holding mit zentral verhandelten Konditionen für alle Tochtergesellschaften. Diese Ebene ist oft nicht operativ, es gibt keine Bestellungen auf Holding-Ebene -, aber sie definiert die Vertragsbasis für alle darunterliegenden Einheiten.
Ebene zwei: Tochter (rechtliche Einheit). Das ist die Gesellschaft im rechtlichen Sinne: „Bosch Rexroth AG“, „BASF Schwarzheide GmbH“, „ABB Sécheron SA“. Hier werden Rechnungen gestellt, hier existiert eine Bilanz, hier läuft die Bonität. Im ERP (SAP S/4HANA, Dynamics 365 Finance & Operations) ist die rechtliche Einheit der primäre Geschäftspartner. Im CRM hingegen oft unsichtbar, weil der Vertrieb auf Werk-Ebene denkt.
Ebene drei: Werk (Produktionsstandort). Operative Einheit, an der produziert wird. „Bosch Rexroth, Werk Homburg“, „BASF, Standort Ludwigshafen“. Hier sitzen die Entscheider für Maschineninvestitionen, hier werden Service-Verträge verhandelt, hier laufen die meisten Vertriebsaktivitäten. Das CRM organisiert sich typischerweise um diese Ebene herum, Opportunities, Contacts, Activities sind primär Werk-bezogen.
Ebene vier: Profit Center (Geschäftseinheit). Innerhalb eines Werks gibt es oft mehrere Produktionslinien oder Geschäftsbereiche mit eigenen Budgets. „Bosch Rexroth, Werk Homburg, Mobile Hydraulics“ vs. „Bosch Rexroth, Werk Homburg, Industrial Hydraulics“. Für Ersatzteilgeschäft und Retrofits ist diese Ebene entscheidend, der Vertrieb muss wissen, welche Maschinen in welchem Profit Center installiert sind, um Cross-Sell-Potenziale zu erkennen.
Das Problem: Die meisten CRM-Systeme bilden maximal zwei dieser Ebenen nativ ab. Salesforce kennt Account Hierarchies, aber ohne Differenzierung nach Hierarchietyp (ist „Bosch Rexroth AG“ eine Tochter oder ein Werk?). HubSpot bietet Parent Company-Felder, aber keine mehrstufige Aggregation. SAP Sales Cloud hat Corporate Account-Strukturen, aber die Sync-Logik ins ERP versagt, sobald ein Werk zu einer anderen Tochter umgehängt wird. Und alle drei Systeme scheitern, wenn ein Maschinenbauer seine eigene Niederlassungsstruktur mit der Konzernstruktur des Kunden in Beziehung setzen muss: „Unsere DE-Niederlassung betreut die EMEA-Werke von Bosch, unsere US-Niederlassung die AMER-Werke.“ Diese Matrix-Logik ist in Standard-CRM nicht abbildbar.
Die MARINI Data Cloud löst das Hierarchie-Problem durch hierarchische DataEngine Data Objects mit automatischer Aggregationslogik. Statt flacher Account-Listen verwaltet die DataEngine strukturierte Hierarchiebäume, in denen jedes Data Object weiß, auf welcher Ebene es steht und zu welchem übergeordneten Objekt es gehört. Ein Beispiel aus der Praxis: Der Account „Bosch Rexroth AG, Werk Homburg“ ist als Data Object vom Typ „Werk“ definiert. In seinem Hierarchie-Feld steht eine Referenz auf „Bosch Rexroth AG“ (Typ: Tochter), die wiederum auf „Robert Bosch GmbH“ (Typ: Konzern) verweist. Alle drei Objekte existieren parallel in der DataEngine, nicht als redundante Kopien, sondern als verlinkte Entitäten mit unterschiedlichen Verantwortlichkeiten.
Die Aggregationslogik ist bidirektional: Wird im CRM ein neuer Service-Vertrag auf Werk-Ebene angelegt, propagiert die DataEngine den Vertragswert automatisch nach oben, zur Tochter, zum Konzern. KPIs wie „Gesamtumsatz Bosch Konzern“ oder „Anzahl aktiver Service-Verträge EMEA-Töchter“ werden in Echtzeit berechnet, ohne manuelle Reports. Umgekehrt: Wird auf Konzern-Ebene ein neuer Rabatt hinterlegt, fließt diese Information automatisch nach unten, zu allen Töchtern, allen Werken. Der Vertrieb sieht beim nächsten Angebot sofort die aktualisierte Kondition, ohne dass ein Admin jeden einzelnen Account manuell anfassen muss.
Ein konkretes Szenario: Ein Maschinenbauer betreut BASF mit 230 Produktionsstandorten weltweit. Im CRM (Dynamics 365 Sales) existieren diese 230 Standorte als separate Accounts. Im ERP (SAP S/4HANA) sind sie als Geschäftspartner mit unterschiedlichen Buchungskreisen hinterlegt. Im Service-System laufen pro Standort zwischen 5 und 50 Wartungsverträge. Die MARINI Data Cloud konsolidiert alle drei Datenquellen in hierarchischen Data Objects: Konzern BASF (mit globalem Rahmenvertrag), darunter 12 rechtliche Töchter (mit jeweils eigener Bonität), darunter 230 Werke (mit jeweils eigenen Ansprechpartnern), darunter Profit Centers nach Produktlinie. Ein KAM-Dashboard zeigt auf einen Blick: „BASF Konzern: 47,3 Mio Euro Umsatz p.a., 1.240 aktive Service-Verträge, 23 laufende Opportunities, durchschnittliche Vertragslaufzeit 4,2 Jahre.“ Drill-down auf Tochter-Ebene: „BASF Schwarzheide GmbH: 3,1 Mio Euro, 87 Verträge, Renewal Rate 94 %.“ Drill-down auf Werk-Ebene: „Schwarzheide Werk 1: 1,8 Mio Euro, 42 Verträge, nächste Renewal in 90 Tagen.“
Die Hierarchie ist nicht statisch. Bei M&A-Aktivitäten (Bosch verkauft eine Sparte, ABB kauft eine Tochter hinzu) wird die Struktur in der DataEngine angepasst, und alle abhängigen Systeme werden via HubEngine synchronisiert. Kein manuelles Umhängen von Accounts in jedem System, keine Excel-Listen zur Nachverfolgung. Die DataEngine ist die Single Source of Truth für Konzern-Hierarchien, CRM, ERP und Service-System lesen die Struktur aus der Data Cloud und übernehmen sie in ihre lokalen Datenmodelle.
Hierarchische Strukturen brechen, wenn die Zuordnung zur richtigen Ebene fehlerhaft ist. Ein typisches Problem: Im CRM wird „Bosch Rexroth Werk Homburg“ als eigenständiger Account angelegt, obwohl er eigentlich zur „Bosch Rexroth AG“ gehört. Der Vertrieb weiß das, das CRM nicht, weil die Information nur im Kopf des Vertriebs existiert oder in einem Freitext-Feld versteckt ist. Externe Identifier schaffen Sicherheit, indem sie Accounts über Systemgrenzen hinweg eindeutig zuordnen und Fehl-Konsolidierungen verhindern.
Der wichtigste Identifier im B2B: Die DUNS-Number (Data Universal Numbering System) von Dun & Bradstreet. Jede rechtliche Einheit weltweit bekommt eine eindeutige neunstellige Nummer, die unabhängig von Namensänderungen, Umzügen oder Umfirmierungen stabil bleibt. „Bosch Rexroth AG“ hat eine DUNS-Number, „Bosch Rexroth Werk Homburg“ eine andere (als Standort-Ebene der AG zugeordnet). Die MARINI Data Cloud integriert Dun & Bradstreet als primäre Datenanreicherungsquelle: Beim Anlegen eines neuen Accounts wird automatisch die DUNS-Number abgefragt und im Data Object hinterlegt. Existiert bereits ein Account mit dieser DUNS-Number, wird eine Dubletten-Warnung ausgegeben. Existiert ein übergeordneter Account (Parent DUNS), wird die Hierarchie-Verknüpfung vorgeschlagen.
Ergänzend: Handelsregisternummer und Umsatzsteuer-ID. Beide sind in DACH-Ländern rechtlich verbindlich und in ERP-Systemen Pflichtfelder. Die Data Cloud synchronisiert diese Identifier aus SAP S/4HANA oder Dynamics 365 Finance & Operations und gleicht sie mit den CRM-Daten ab. Fehlt im CRM die USt-ID, wird sie aus dem ERP ergänzt. Weichen Handelsregisternummer im CRM und ERP voneinander ab, wird ein Data-Quality-Alert ausgelöst, möglicherweise sind zwei rechtlich unterschiedliche Einheiten unter demselben Account zusammengefasst.
Ein Praxisbeispiel: Ein Maschinenbauer legt im CRM einen neuen Account „ABB Sécheron“ an. Die Data Cloud fragt die DUNS-Number ab und findet: „ABB Sécheron SA, Genf, DUNS 549876234, Parent: ABB Ltd, DUNS 532198765“. Die Hierarchie-Verknüpfung wird automatisch vorgeschlagen. Der Vertrieb bestätigt, der Account wird korrekt als Tochter unter „ABB Ltd“ eingeordnet. Ohne DUNS-Abfrage wäre „ABB Sécheron“ möglicherweise als eigenständiger Konzern klassifiziert worden, mit der Folge, dass alle Umsätze und Verträge falsch aggregiert wären.
Die Identifier-Logik verhindert auch technische Dubletten: Wird derselbe Account über verschiedene Wege angelegt (CRM-Formular, ERP-Sync, Lead-Import), erkennt die Data Cloud die Übereinstimmung anhand der DUNS-Number und führt die Datensätze zusammen, statt separate Accounts zu erzeugen. Das ist besonders in internationalen Organisationen kritisch, wo verschiedene Niederlassungen denselben Konzern-Kunden parallel betreuen und potenziell mehrfach im System anlegen.
Die Herausforderung im Maschinenbau ist nicht, dass CRM-Systeme keine Hierarchien können, die meisten bieten Parent-Child-Beziehungen an. Die Herausforderung ist die Synchronisation dieser Hierarchien über eine heterogene Systemlandschaft hinweg und die dynamische Aggregation von Kennzahlen über alle Ebenen. MARINI, die Plattform für Customer Intelligence, mit Data Integration, Data Cloud und Agentic, setzt an drei Punkten an, die Standard-Integrationen nicht leisten.
Erstens: Hierarchische DataEngine Data Objects als zentrales Konstrukt. Statt flacher Account-Listen verwaltet die Data Cloud strukturierte Hierarchiebäume mit Typ-Definition pro Ebene (Konzern, Tochter, Werk, Profit Center). Jedes Data Object kennt seine Position in der Hierarchie und kann Daten sowohl nach oben aggregieren (Umsatz, Verträge, KPIs) als auch nach unten propagieren (Rabatte, Konditionen, Vertragsänderungen). Diese Logik ist in der DataEngine nativ implementiert, kein Custom Code, keine manuellen Aggregations-Reports.
Zweitens: Bidirektionale Hierarchie-Synchronisation via HubEngine. Die Hierarchie-Struktur wird nicht nur im CRM oder ERP gepflegt, sondern in der Data Cloud als Single Source of Truth konsolidiert. Änderungen (ein Werk wird einer anderen Tochter zugeordnet, eine Tochter wird verkauft) werden in der DataEngine durchgeführt und automatisch in alle angebundenen Systeme synchronisiert, CRM, ERP, Service-System, Produktkonfigurator. Die HubEngine stellt sicher, dass alle Systeme dieselbe Hierarchie-Sicht haben, ohne dass jedes System manuell angepasst werden muss.
Drittens: Integration der Hierarchie mit Dublettenerkennung und Cross-Sell-Logik. Hierarchische Accounts sind anfällig für Dubletten: „Bosch Rexroth AG“ vs. „Bosch-Rexroth AG“ vs. „Bosch Rexroth“ werden als separate Accounts angelegt, obwohl sie dieselbe rechtliche Einheit bezeichnen. Die MARINI Data Cloud kombiniert Dublettenerkennung mit Hierarchie-Logik: Potenzielle Dubletten werden nicht nur anhand von Name und Adresse erkannt, sondern auch anhand von DUNS-Number und USt-ID. Bestätigte Dubletten werden konsolidiert, ihre Hierarchie-Beziehungen werden zusammengeführt. Umgekehrt nutzt die Cross-Sell-Logik die Hierarchie-Struktur, um Potenziale zu identifizieren: „Werk A hat Maschine X installiert, Werk B (derselben Tochter) hat Maschine Y, Cross-Sell-Potenzial für kompatibles Zubehör.“
Ein konkretes Beispiel: Ein deutscher Maschinenbauer nutzt Dynamics 365 Sales als CRM und SAP S/4HANA als ERP. Die Konzern-Struktur der Top-Kunden (ABB, BASF, Siemens, Bosch) ist in beiden Systemen unterschiedlich abgebildet, im CRM nach Vertriebs-Territorien, im ERP nach rechtlichen Einheiten. Die MARINI Data Cloud konsolidiert beide Sichten in einer hierarchischen Struktur und synchronisiert sie bidirektional: Neue rechtliche Einheiten aus SAP werden automatisch ins CRM übertragen und korrekt in die Hierarchie eingeordnet. Neue Werke aus dem CRM werden ins ERP repliziert und mit der richtigen Buchungskreis-Logik versehen. KPIs werden über alle Systeme hinweg aggregiert: „Gesamtumsatz Bosch Konzern“ setzt sich zusammen aus CRM-Opportunities (gewichtet nach Wahrscheinlichkeit), ERP-Aufträgen (fakturiert) und Service-Verträgen (wiederkehrend). Alle drei Quellen fließen in ein konsolidiertes KAM-Dashboard, das in Echtzeit aktualisiert wird.
Die MARINI Professional Services begleiten Maschinenbauer bei der Einführung hierarchischer Account-Strukturen, von der Definition der Hierarchieebenen über die Datenbereinigung (welche Accounts gehören zusammen?) bis zur Einrichtung der Sync-Logik und der Schulung der KAMs. Das Ergebnis: Eine konsolidierte Sicht auf Konzern-Kunden, die endlich die Frage beantwortet, die jedes Account Review beginnt: „Wie viel Geschäft machen wir wirklich mit diesem Kunden?“
Mehr dazu findest du im Fachbuch Customer Intelligence: Strategien und Use Cases zur Nutzung von Kundendaten von Prof. Dr. Emanuel Bayer und Manuel Marini, das über Springer Gabler publiziert wurde.
