Why Your CRM Data Is Only as Good as Your Data Foundation

A pattern from a decade of CRM projects: the client calls about the CRM: reps do not trust the forecast, the AI features underwhelm, adoption sags after month three. We audit, and the CRM configuration is usually fine. What is broken sits underneath: duplicate accounts, three versions of the customer master, opportunity amounts that disagree with order intake, and no one who owns any of it.

The one-sentence takeaway: you cannot configure your way out of a foundation problem; fix ownership and join keys first, then let the platform carry the maintenance.

The symptoms are in the CRM; the disease is not

The forecast meeting is where it shows. Sales presents pipeline from Sales Cloud V2; finance presents revenue from the ERP; the two decks disagree; the meeting becomes an argument about whose number is right instead of what to do. Every company we meet has a version of this meeting.

The CRM gets the blame because the CRM is where people look. But trace any single disagreement and you land on foundation issues: an account that exists twice because two subsidiaries onboarded it separately, an opportunity closed-won that never matched to its order, a currency conversion done differently in two reports. None of that is a CRM setting.

Fix it in this order

Sequence matters more than tooling. What works, in order:

1. Ownership before cleansing. Decide who owns each attribute (ERP owns the commercial customer, CRM owns the relationship) before anyone touches a record. Cleansing without ownership is mopping with the tap open. (On the integrated SAP stack, most of these decisions are made for you by the standard integration, one of its quietly underrated benefits.)
2. Join keys before completeness. Perfect address data on records that cannot be joined to their orders is decoration. The keys (account to business partner, opportunity to order) are what analytics and AI stand on. Fix those first.
3. One domain before the landscape. Clean accounts-and-opportunities against orders, ship the pipeline-to-cash view, show the meeting where both decks carry one number. That result funds domain two. A two-year cleansing programme with no visible output funds nothing.
4. Platform before heroics. The reason foundations rot is maintenance: the person who built the pipeline leaves, releases break it, entropy wins. This is exactly the burden SAP Business Data Cloud moves to SAP: data products maintained through every release, so quality work you did stays done. The integration patterns post covers the mechanics.

The mid-market angle

Large enterprises solve this with a data governance office. A 200-person Swiss distributor cannot and should not. The realistic mid-market model: one named owner per domain (not a committee), the standard SAP data products as the maintained backbone, and modelling effort only in the last mile where your industry logic lives. That model runs on a fraction of an FTE once it stands, which is precisely why the platform choice matters more in the mid-market than in the enterprise: you have no team to absorb what the platform will not.

Why this is urgent now, not eventually

For years, bad foundations cost you reporting time: annoying, survivable. AI changes the cost curve. Every AI feature you switch on (lead scoring, forecasting, Joule) reads the foundation and amplifies it: clean data in, leverage out; noise in, confident noise out. Companies switching on AI features over a rotten foundation are paying AI prices for amplified garbage.

Started from what BDC actually is? The series continues into what that AI dependency means in practice. But the order of operations stands on its own: ownership, join keys, one domain, platform. The CRM was never the problem.