Pourquoi vos données CRM ne valent que ce que vaut votre fondation de données

Un schéma tiré d’une décennie de projets CRM : le client appelle au sujet du CRM : les commerciaux ne font pas confiance au forecast, les fonctions IA déçoivent, l’adoption s’essouffle après le troisième mois. Nous auditons, et la configuration du CRM est généralement correcte. Ce qui est cassé se trouve dessous : comptes en double, trois versions du fichier client, montants d’opportunités qui contredisent les entrées de commandes, et personne qui ne possède quoi que ce soit de tout cela.

À retenir en une phrase : on ne se sort pas d’un problème de fondation par la configuration. Réglez d’abord l’ownership et les clés de jointure, puis laissez la plateforme porter la maintenance.

Les symptômes sont dans le CRM ; la maladie, non

C’est à la réunion de forecast que cela se voit. Les ventes présentent le pipeline depuis Sales Cloud V2 ; la finance présente le chiffre d’affaires depuis l’ERP ; les deux présentations se contredisent ; la réunion devient une dispute sur le chiffre qui a raison au lieu de porter sur ce qu’il faut faire. Chaque entreprise que nous rencontrons a une version de cette réunion.

Le CRM prend le blâme parce que le CRM est là où les gens regardent. Mais remontez n’importe quelle contradiction et vous tombez sur des problèmes de fondation : un compte qui existe deux fois parce que deux filiales l’ont créé séparément, une opportunité gagnée jamais rapprochée de sa commande, une conversion de devise faite différemment dans deux rapports. Rien de tout cela n’est un paramètre du CRM.

Réparez dans cet ordre

La séquence compte plus que l’outillage. Ce qui fonctionne, dans l’ordre :

1. L’ownership avant le nettoyage. Décidez qui possède chaque attribut (l’ERP possède le client commercial, le CRM possède la relation) avant que quiconque ne touche un enregistrement. Nettoyer sans ownership, c’est passer la serpillière avec le robinet ouvert. (Sur la pile SAP intégrée, la plupart de ces décisions sont prises pour vous par l’intégration standard, un de ses bénéfices discrètement sous-estimés.)
2. Les clés de jointure avant la complétude. Des données d’adresse parfaites sur des enregistrements qu’on ne peut pas joindre à leurs commandes, c’est de la décoration. Les clés (compte vers partenaire commercial, opportunité vers commande) sont ce sur quoi reposent l’analytique et l’IA. Réparez-les d’abord.
3. Un domaine avant le paysage. Nettoyez comptes-et-opportunités face aux commandes, livrez la vue pipeline-to-cash, montrez la réunion où les deux présentations portent un seul chiffre. Ce résultat finance le domaine deux. Un programme de nettoyage de deux ans sans résultat visible ne finance rien.
4. La plateforme avant les héroïsmes. La raison pour laquelle les fondations pourrissent, c’est la maintenance : la personne qui a construit le pipeline s’en va, les releases le cassent, l’entropie gagne. C’est exactement la charge que SAP Business Data Cloud transfère à SAP : des produits de données (« data products ») maintenus à travers chaque release, pour que le travail de qualité que vous avez fait reste fait. Le billet sur les patterns d’intégration couvre la mécanique.

L’angle mid-market

Les grandes entreprises résolvent cela avec un bureau de gouvernance des données. Un distributeur suisse de 200 personnes ne le peut pas et ne le devrait pas. Le modèle mid-market réaliste : un propriétaire nommé par domaine (pas un comité), les produits de données SAP standard comme colonne vertébrale maintenue, et un effort de modélisation uniquement sur le dernier kilomètre où vit votre logique métier. Ce modèle tourne sur une fraction d’ETP une fois en place, et c’est précisément pourquoi le choix de plateforme compte davantage dans le mid-market que dans la grande entreprise : vous n’avez pas d’équipe pour absorber ce que la plateforme ne prend pas en charge.

Pourquoi c’est urgent maintenant, pas un jour

Pendant des années, de mauvaises fondations vous coûtaient du temps de reporting : agaçant, survivable. L’IA change la courbe de coût. Chaque fonction IA que vous activez (lead scoring, forecasting, Joule) lit la fondation et l’amplifie : données propres en entrée, levier en sortie ; bruit en entrée, bruit assuré en sortie. Les entreprises qui activent des fonctions IA sur une fondation pourrie paient le prix de l’IA pour des déchets amplifiés.

Vous avez commencé par ce qu’est réellement BDC ? La série se poursuit sur ce que cette dépendance à l’IA signifie en pratique. Mais l’ordre des opérations tient tout seul : ownership, clés de jointure, un domaine, plateforme. Le CRM n’a jamais été le problème.