The Hidden Cost of Disconnected ERP and CRM Data in Manufacturing
Why the gap between SAP and Salesforce is costing you more than you think, and what a practical path forward looks like.
The Hidden Cost of Disconnected ERP and CRM Data in Manufacturing
Why the gap between SAP and Salesforce is costing you more than you think, and what a practical path forward looks like.
If your Finance team closes the month with spreadsheets, if your OTIF number changes depending on who you ask, and if your VP of Sales and your CFO can't agree on the revenue figure, your ERP and CRM systems are not working together.
That's not a technology problem. It's a business risk. And in manufacturing, where margin is thin, supply chains are complex, and customers expect precision, the gap between SAP and Salesforce is quietly draining value from every corner of the business.
This post is about what that costs, why it persists, and what a practical path forward looks like.
Get an Honest Platform Assessment
The Data Gap That Manufacturing Leaders Don't See on the P&L
Ask any manufacturing CFO where the biggest data problem is. Most will point to a symptom: slow close, unreliable forecasts, manual reconciliation, rather than the root cause.
The root cause is almost always the same: SAP and Salesforce are not integrated at the data level, and the gap between them is filled by manual effort, shadow tools, and organisational workarounds.
Here's what that looks like in practice:
"These are not edge cases. They are the standard operating condition for manufacturers that have invested heavily in both SAP and Salesforce without ever connecting them at the data layer."
Why SAP and Salesforce Don't Just "Talk", and Why That Matters for BI
It is tempting to assume that middleware: MuleSoft, Informatica, SAP Integration Suite, solves this problem. It does not.
Middleware handles transactional integration: sending a sales order from Salesforce to SAP, or pushing a delivery status back to an account record. That is valuable. But it is not the same as analytical integration.
Analytical integration means having a governed, joined, quality-validated dataset that a Finance analyst or a BI tool can query without calling data engineering. It means:
- A single canonical definition of "customer" that reconciles the SAP customer number with the Salesforce Account ID
- A single OTIF calculation that joins SAP delivery data with Salesforce order commitments and applies agreed business rules
- A single pricing view that joins SAP condition records with Salesforce opportunity pricing and billing document actuals
None of these exist out of the box. And none of them can be built reliably on top of middleware that was designed for operational transaction flow, not analytical query.
ARCHITECTURE NOTE
This is the gap that Databricks fills (when implemented correctly)
A governed medallion architecture (Bronze → Silver → Gold) with proper SAP extraction patterns, Unity Catalog governance, and version-controlled business rule logic in the Silver layer closes this gap structurally. Without it, the alternative is a proliferation of point-to-point data flows, shadow BI tools, and Excel, all producing different numbers.
The ABAP Problem Nobody Wants to Talk About
Buried inside most manufacturing SAP landscapes is a collection of custom ABAP programs that nobody fully understands.
They were written years ago. The developer who wrote them left. The business logic they encode, pricing calculation rules, customer allocation logic, exception classifications, was never documented. They run every night. Everyone depends on the output. Nobody can explain why the number is what it is.
This is the ABAP problem, and it becomes a critical risk when ECC decommission timelines arrive.
As SAP pushes manufacturers toward S/4HANA and a cloud-first model, the question "what do we do with our custom ABAP code?" becomes urgent. The honest answer is: most organisations don't know what they have.
The ABAP problem manifests in three ways:
- Migration paralysis. ECC decommission is stalled because nobody is willing to sign off on retiring a program they don't understand.
- Reporting debt. ABAP custom reports are producing numbers the business relies on, but that cannot be reproduced in any modern BI tool because the logic is opaque.
- Knowledge concentration. One or two people carry the context for how specific ABAP programs work. When they leave, the knowledge leaves with them.
The solution is not to run ABAP programs forever. It is to inventory them, document the business logic they contain, migrate that logic to a modern, testable environment (Databricks PySpark or SQL) and then retire the ABAP programs with confidence, backed by a reconciliation report that proves the output matches.
What Governed Data Products Actually Mean, in Practice, Not Theory
The word "governance" gets used in almost every data platform conversation. It rarely gets defined. In the context of manufacturing data activation, governance means five specific things:
- Ownership. Every data product (every Gold mart, every KPI definition) has a named owner who is accountable for its accuracy. Not the data engineering team. The Finance Director who relies on it.
- Definitions. DSO is calculated how? Which open items are included? Does it exclude disputed items? What is the denominator, trailing 12 months or rolling 90 days? These questions have to be answered in writing, agreed by Finance and IT, before a single line of SQL is written.
- Lineage. If a number changes, you can trace back through every transformation step to understand why. Unity Catalog on Databricks provides this automatically when the platform is configured correctly.
- Quality contracts. Every data product has published SLAs: freshness (updated by 06:00 daily), completeness (no missing mandatory fields), and accuracy (within defined tolerance of source system output). Breaches trigger alerts, not surprises.
- Access control. The Finance mart is accessible to Finance. Operations OTIF data is accessible to plant managers. Salesforce opportunity pricing is not available to every analyst. Access is role-based, auditable, and enforced at the platform level, not managed by sharing Excel files or emailing exports.
"Without governance, a data platform is just a faster way to produce the wrong numbers."
Three Paths Forward, Matched to Where You Are Today
Not every manufacturing organisation is in the same position. Some have Databricks in place but no SAP data. Some are planning an ECC exit with no migration plan for ABAP. Some have a Finance team demanding a single source of truth. Customertimes has structured three offers to match the most common starting points:
These three paths are composable. Many clients begin with the Quick Starter, use it to build internal confidence and executive sponsorship, and then expand to Finance 360. The architecture is designed to scale, so the work done in week one is still load-bearing in month twelve.
What to Do Next
If any of the patterns in this post match what you're experiencing, the right first step is a structured conversation, not a lengthy RFP or a six-month proof-of-concept.
Customertimes offers a free 60-minute data landscape assessment for manufacturing organisations. In that session, we'll map your current SAP and Salesforce data landscape, identify the two or three use cases that would deliver the most immediate value, and give you an honest recommendation on which offer, or which sequence of offers, fits your situation. No commitment required. No sales deck.
Ready to Activate Your Manufacturing Data?
