An account in the CRM shows Mueller GmbH. In SAP it says Mueller GmbH & Co KG. The delivery address is incorrect in both systems. The next order requires half a day of clarification work. In DACH mechanical engineering, an SAP-dominated ERP landscape meets a highly fragmented CRM world. This constellation is unique worldwide: While SAP holds around 25 percent CRM market share here, Microsoft Dynamics, Salesforce, HubSpot, CAS, and numerous proprietary developments compete for the remaining shares. The consequence: Without precise mastership rules per field and bidirectional real-time synchronization, master data inevitably drifts apart.
The SAP-CRM Dissonance in DACH Mechanical Engineering
The CRM landscape in German mechanical engineering differs fundamentally from international markets. Globally, Salesforce dominates with around 22 percent market share, followed by Microsoft and SAP. In DACH mechanical engineering, however, SAP holds a special position: The company unites around 25 percent of the CRM market here, while simultaneously the ERP system in many companies also comes from Walldorf. This sounds like ideal conditions for integration. Practice, however, shows a different picture: Alongside SAP CRM solutions like Cloud for Customer or Sales Cloud V2, Microsoft Dynamics 365 (about 19 percent), Salesforce Sales Cloud (around 11 percent), HubSpot, CAS genesisWorld, and a remarkable number of proprietary developments (approximately 17 percent) compete for sales teams. This fragmentation has grown historically. Many mechanical engineering companies have established SAP as their ERP backbone over decades, while CRM implementation often occurred later and was driven by different requirements: Marketing wanted HubSpot, sales swore by Salesforce, field service needed mobile CRM functions that SAP didn’t offer at the time. The result: heterogeneous system landscapes where master data must be maintained in multiple places.
Three Classes of Master Data Conflicts
Master data is not all the same. For synchronization between SAP and CRM, three categories can be distinguished, each bringing its own challenges:
Account Master Data (Name, Address, VAT ID, Legal Form): These are the basic information about the business partner. In SAP they are often called Business Partner or Customer, in CRM Account or Company. The naming alone shows the problem: In SAP, accounts are frequently created with the full legal form (Mueller GmbH & Co KG), while in CRM the short form suffices (Mueller GmbH). Different spellings, abbreviations (GmbH vs. G.m.b.H.), and missing standards during initial creation lead to the same customer having different names in both systems.
Contact Master Data (Position, Phone Number, Email, Department): Contacts are highly dynamic. A technical buyer changes departments, the managing director retires, a new project manager appears. According to industry studies, about 30 percent of B2B contact data becomes outdated annually. If these changes are only maintained in the CRM (because sales works there), they remain invisible in SAP. Conversely, accounting updates invoice addresses directly in the ERP without the CRM learning about it.
Relationship Data (Account Hierarchy, Buying Center Roles, Location Assignments): In mechanical engineering, corporate structures are the rule. A main plant in Germany, production sites in Poland and Czech Republic, a purchasing center in Switzerland. In SAP, these are often managed as separate customers, while the CRM attempts to map a superior account hierarchy. Without clear assignment logic, duplicates and inconsistent hierarchies emerge that distort sales forecasts and revenue analyses.
Define Mastership Rules Per Field
The central problem of master data synchronization is not technical but organizational: Who is allowed to change what? And which system is correct in case of conflict? Many companies try to solve this problem with a blanket rule: “SAP is master for all master data.” This fails in practice because not every field in the ERP is more current or correct than in the CRM. Instead, mastership rules at field level are needed:
ERP-mastered: Inventory levels, credit limits, payment terms, invoice addresses, accounting-relevant data. These fields are exclusively maintained in SAP. Changes in the CRM are blocked or overwritten.
CRM-mastered: Pipeline status, lead scores, campaign assignments, contact history, sales notes. This data originates in the CRM and has its only source there. The ERP can read it (for reporting purposes) but not change it.
Bidirectional with Conflict Resolution: Contact data (phone, email), addresses (if not invoice-relevant), contact persons. These fields may be changed in both systems. In case of simultaneous changes, a predefined rule applies: “Last Write Wins” (the most recent change prevails) or “CRM Wins” (the CRM overrides the ERP for contact data). A concrete example from practice: A mid-sized mechanical engineering company synchronizes between SAP S/4HANA and Salesforce Sales Cloud. The mastership matrix looks like this: Customer number (SAP), Company name (SAP), Invoice address (SAP), Credit limit (SAP), Contact person name (bidirectional, Last Write Wins), Contact person email (bidirectional, CRM Wins in conflict), Lead status (CRM), Opportunity stage (CRM), Open items (SAP, Read-Only in CRM). These rules must not only be technically implemented but also organizationally anchored. Accounting must know that they cannot change contact emails in SAP. Sales must understand that credit limits can only be set in the ERP. Without change management, the best synchronization logic remains ineffective.
Real-Time Sync vs. Batch Sync
The second central decision: How quickly must changes be transferred?
Real-time synchronization means: Every change in the source system triggers an update in the target system within seconds. This is technically demanding (API-based, event-driven), but indispensable for certain fields. A sales representative must see whether a customer is overdue on payment before creating a new quote. A service technician needs the current serial number of the machine, not yesterday’s status.
Batch synchronization, on the other hand, runs at fixed times: once per hour, once at night, once weekly. This suffices for non-critical fields like historical revenue data, industry classifications, or statistical analyses. Batch sync is easier to implement, puts less load on the systems, and is more fault-tolerant (if a batch fails, the next one simply runs again). The golden rule: Real-time for transactional fields, batch for master data bulk. Account status, credit limit, open orders: real-time. Initial load at go-live, historical contacts, mass mutations: batch. In practice, this looks like this: The MARINI HubEngine defines a so-called plan for each connection between SAP and CRM. This plan contains the mastership rules, field mappings, and sync strategy. A plan for credit limits synchronizes in real-time via SAP OData API. A plan for contact data runs bidirectionally, also in real-time. A plan for historical orders runs once nightly as a batch. The advantage of this granularity: Each data object can be controlled individually. No blanket “all-or-nothing” logic, but precise rules per field and object. This reduces system load, minimizes conflict risks, and makes synchronization maintainable.
The Role of Data Quality
Even the best synchronization logic fails if the source data is flawed. Duplicates, incomplete addresses, inconsistent spellings: These problems are not solved by synchronization but multiplied. A classic scenario: In SAP, three customer records exist for the same customer (one main plant, two production sites). In the CRM, there are two accounts (one created by marketing, one by sales). Synchronization now attempts to reconcile these five records. Without golden record logic, either more duplicates emerge or the wrong records are merged. The solution: Data cleansing before integration. This means: Identify and consolidate duplicates in SAP, deduplicate accounts in CRM, define a unique matching logic (for example via an external ID or VAT ID), complete missing mandatory fields. The MARINI Data Cloud supports this process through AI-powered record linkage: Records that belong together (even if they are not identical) are recognized and linked. A record “Mueller GmbH & Co KG” in SAP and “Mueller GmbH” in CRM are identified as the same customer, even if the strings don’t match exactly. Additionally, the Data Cloud can integrate external data sources, such as Dun & Bradstreet for credit information or commercial register data for legal forms and managing directors. This enrichment ensures that master data is not only synchronized but also correct and current.
What MARINI Does Differently in Mechanical Engineering
MARINI was developed precisely for these scenarios: fragmented system landscapes in mid-market companies where SAP ERP systems meet heterogeneous CRM solutions. The platform consists of two engines: The HubEngine handles integration and synchronization. It connects SAP (S/4HANA, ECC, Business One) bidirectionally with CRM systems like Salesforce, Microsoft Dynamics, HubSpot, CAS, or proprietary developments. Each connection is configured via a plan that contains mastership rules, mapping, validation, and conflict resolution. The DataEngine enriches the synchronized data: Deduplication, golden record creation, AI-powered record linkage, external data enrichment (Dun & Bradstreet, web crawlers, pattern recognition). The result: not only synchronized but quality-checked and consolidated master data. A concrete use case from mechanical engineering: A plant manufacturer with SAP S/4HANA and Salesforce Sales Cloud had the problem that contact data persistently diverged. Sales maintained contacts in the CRM, accounting changed invoice addresses in SAP, nobody had an overview. MARINI implemented a bidirectional real-time synchronization with the following rules: Invoice address SAP-mastered (read-only in CRM), contact person bidirectional (CRM wins in conflict), open items SAP-mastered (automatic push to CRM every 15 minutes). Additionally, the Data Cloud was activated to consolidate duplicates. The result: From 1,200 accounts in the CRM and 980 customers in SAP, 850 unique customers remained after cleansing. Data quality increased measurably: The rate of undeliverable emails dropped from 12 to 3 percent, the number of duplicate quotes decreased by 70 percent. MARINI deliberately does not position itself as an agency or system consultancy. The platform is independently usable. For services in the connected systems (SAP customizing, Salesforce configuration, HubSpot setup), MARINI refers to its partner network. The focus is on what happens between the systems: Data integration, data quality, and customer intelligence.
Lessons Learned: What Mechanical Engineers Should Consider
The most important insights from integration projects in DACH mechanical engineering can be summarized in five points:
First: Mastership rules are not an IT decision but an organizational one. Departments (sales, accounting, service) must jointly define who maintains which data. Without this clarification, the best synchronization remains ineffective.
Second: Not everything needs to be synchronized in real-time. Real-time is expensive (technically and organizationally) and should only be used where truly necessary: for transactional data, credit limits, inventory levels. Master data bulk can run at night.
Third: Data cleansing before integration saves months of rework. Duplicates, incomplete records, and inconsistent spellings must be cleaned before the first synchronization, not after.
Fourth: Bidirectional synchronization is not magic, but requires precise conflict resolution rules. Last Write Wins only works for fields that are rarely changed simultaneously. For critical fields (contact data, addresses), explicit prioritization logic is needed.
Fifth: Integration is not a one-time project. Systems change, data models grow, new fields are added. A maintainable, documented synchronization logic is the key to long-term success. DACH mechanical engineering faces a structural challenge: SAP in ERP, fragmentation in CRM, data silos everywhere. But this challenge is solvable. With clear mastership rules, granular sync strategy, and consistent data quality, the result is not isolated solutions but continuous, reliable data flows. Then “SAP versus CRM” becomes “SAP and CRM”, and master data no longer drifts apart but converges.
