Connecter SAP Sales Cloud V2 à Business Data Cloud : les patterns d'intégration qui fonctionnent

Nous implémentons SAP Sales Cloud V2 depuis sa disponibilité initiale, et pendant la majeure partie de cette période, la conversation analytique se terminait de la même manière : exporter vers un entrepôt que quelqu’un maintient, ou se contenter des tableaux de bord embarqués. SAP Business Data Cloud change cette conversation, et après plusieurs mises en production, nous pouvons dire quels patterns d’intégration tiennent et lesquels sont plus beaux sur le tableau blanc qu’au sixième mois.

À retenir en une phrase : consommez les produits de données de SAP pour le modèle standard, dépensez votre propre effort uniquement sur le dernier kilomètre : vos KPI, vos champs d’extension, vos jointures.

Pattern 1 : les produits de données d’abord, les extracteurs jamais

Le réflexe issu d’une décennie d’analytique CRM est de construire un pipeline d’extraction. Résistez-y. SAP livre dans BDC des produits de données (« data products ») Sales Cloud V2 (comptes, opportunités, leads, activités) et les maintient à travers les releases trimestrielles. Chaque extracteur que vous construisez en parallèle d’un produit de données est un passif à votre nom : il casse silencieusement quand l’API change, et il réintroduit la dérive sémantique (« c’est lequel, ce montant d’opportunité ? ») que le produit de données existe pour éliminer.

Là où vous construisez : les champs d’extension. Si votre Sales Cloud V2 porte des champs custom (type de machine, phase de projet, données de configuration AVC), prévoyez une étape de modélisation qui les amène dans la couche sémantique. C’est quelques heures de travail sur un tenant propre, pas des semaines.

Pattern 2 : pipeline-to-cash comme premier modèle

Chaque client le demande ; presque personne ne l’a. Les opportunités vivent dans le CRM, les commandes et les factures dans l’ERP, et la jointure entre les deux est un exercice Excel trimestriel. Avec les produits de données Sales Cloud V2 et S/4HANA dans un seul tenant BDC, le pipeline-to-cash devient une tâche de modélisation au lieu d’un projet d’intégration :

• Les clés de jointure : compte ↔ partenaire commercial, opportunité ↔ référence de commande client, article ↔ produit. Un atelier pour les aligner, surtout si la déduplication des comptes a un passé dans votre CRM.
• Le modèle : opportunités gagnées face aux entrées de commandes réelles et au chiffre d’affaires facturé, par organisation commerciale et par période.
• Le gain : la précision du forecast mesurée contre la réalité livrée, autrement dit le chiffre qui transforme la discipline CRM d’un vœu de la direction en KPI mesuré.

Un constructeur de machines suisse avec lequel nous travaillons a fait tourner exactement ce modèle comme pilote BDC : un domaine, six semaines, et la première réunion de direction où les ventes et la finance ont apporté le même chiffre.

Pattern 3 : gardez le temps réel hors de la couche analytique

L’erreur de conception la plus fréquente : faire passer les besoins opérationnels temps réel par la plateforme analytique. Un commercial qui a besoin du stock et des prix en direct avant un devis obtient cela de l’intégration applicative native Sales Cloud V2 ↔ S/4HANA, pas de BDC. L’analytique tolère les cycles de rafraîchissement ; le devis, non. Tracez la ligne explicitement dans l’architecture : les transactions par les API applicatives, l’analyse par les produits de données. Les architectures qui la brouillent héritent des pires propriétés des deux.

Pattern 4 : un modèle sémantique, plusieurs consommateurs

Une fois la fondation posée, résistez aux variantes par équipe. Tout l’intérêt est que le tableau de bord SAC de la direction, le notebook Databricks de l’analyste curieux des données et l’agent Joule qui répond à « où en est le pipeline Q4 par rapport à l’an dernier » lisent le même modèle gouverné. Dès que quelqu’un forke « sa » version du chiffre d’affaires, vous reconstruisez le problème que vous avez payé pour éliminer. La gouvernance ici n’est pas de la bureaucratie ; c’est le produit.

Où cela mène

Nous avons commencé cette série avec ce qu’est réellement BDC et ce qu’il advient de Datasphere. Les patterns d’intégration ci-dessus sont le milieu pratique. La fin stratégique (pourquoi tout cela compte au-delà du reporting), c’est l’IA : les agents ne valent que ce que vaut le modèle de données qu’ils lisent, et un modèle pipeline-to-cash gouverné est exactement ce dont un agent Joule a besoin pour répondre aux questions de chiffre d’affaires sans halluciner. La suite plus tard dans la série.

Si vous utilisez Sales Cloud V2 et que votre analytique vit encore dans des exports, c’est un correctif en semaines, pas en trimestres. Notre practice BDC commence précisément là.

SAP Integration Suite: supported integration capabilities.