Quote-to-cash entre SAP Sales Cloud V2 et S/4HANA Public Cloud : qui possède quel document ?

Quand un CRM et un ERP portent le même processus de vente, une question décide si l’intégration tiendra des années ou deviendra un chantier permanent : qui possède quel document ? Pas l’interface choisie ni l’outil de mapping, mais dans quel système naît une offre, où naît la commande, et qui a le droit de modifier quoi. Presque chaque intégration quote-to-cash douloureuse que l’on nous a demandé de corriger n’avait pas de réponse claire à cette question au départ.

Pour SAP Sales Cloud V2 et S/4HANA Public Cloud, il existe une réponse nette. Elle découle des contenus d’intégration standard de SAP, à condition de les lire de façon cohérente. La voici, avec les endroits où les projets trébuchent le plus souvent.

En bref : chaque objet a exactement un système maître. Les clients, les produits et les prix sont gérés par S/4HANA Public Cloud ; l’offre est gérée par Sales Cloud V2 ; la commande client est créée dans S/4HANA comme document de suivi et répliquée en retour en lecture seule. Les prix sont simulés en direct dans S/4HANA au lieu d’être maintenus deux fois. Fixez le niveau de statut des offres et une liste gouvernée de motifs de refus avant de construire le premier iFlow, et convenez de qui corrige quel message en échec.

La matrice de propriété : un objet, un système maître

La règle de base est simple : chaque objet a exactement un système maître. C’est là qu’il est créé et modifié. Partout ailleurs, c’est une copie, et les copies sont en lecture seule.

Objet	Système maître	Dans l’autre système
Clients (partenaires commerciaux)	S/4HANA Public Cloud	répliqués vers le CRM
Produits	S/4HANA Public Cloud	répliqués vers le CRM, en lecture seule
Prix et conditions	S/4HANA Public Cloud	simulés en direct depuis l’offre, pas maintenus dans le CRM
Offre	Sales Cloud V2	devient une commande client de suivi dans S/4HANA
Commande client	S/4HANA Public Cloud	répliquée vers le CRM, en lecture seule

L’offre naît dans le CRM parce que c’est là que travaille la vente : opportunité, historique des contacts et activités dans une seule vue. La commande client naît dans S/4HANA parce que c’est là que se trouvent la disponibilité, la limite de crédit, la logistique et la facturation. La transition se fait sous forme de document de suivi via les iFlows standard de SAP Integration Suite, publiés sur le SAP Business Accelerator Hub comme package d’intégration des processus de vente entre Sales Cloud V2 et S/4HANA Cloud Public Edition. Dans l’autre sens, la commande apparaît dans le CRM comme document répliqué que la vente peut consulter, mais pas modifier.

Cette matrice doit être affichée au mur de la salle de projet avant le déploiement du premier iFlow. Elle compte davantage que n’importe quel document de conception technique. Pour la vue technique complète, voir l’architecture d’intégration de Sales Cloud V2.

Prix en direct : une seule vérité des prix, pas deux

La partie la plus élégante de cette architecture est celle qui n’est pas maintenue deux fois : les prix. Pendant que le commercial saisit une ligne, l’offre du CRM est simulée dans S/4HANA et le prix revient avec les conditions, les prix spécifiques au client, les barèmes et les remises. SAP décrit la mise en place dans son aide sur l’intégration de Sales Cloud V2 avec S/4HANA Cloud Public Edition pour la simulation et le transfert.

Le package de données de base de SAP peut aussi répliquer les conditions de prix vers le CRM. Nous utilisons la simulation partout où la connexion le permet. Dès que les prix sont maintenus ou calculés à deux endroits, vous avez deux vérités des prix, et tôt ou tard quelqu’un établit une offre avec la mauvaise. Avec les prix en direct, il existe un seul endroit où les conditions sont maintenues, et l’offre calcule avec les mêmes chiffres que la commande puis la facture : pas de rapprochement, pas de conversation gênante sur l’écart entre offre et facture.

Deux pièges tirés de projets réels

L’architecture ci-dessus est propre. D’après notre expérience, les projets n’ont pas trébuché sur la technique, mais sur deux détails fonctionnels que personne n’avait réglés avant la construction.

Piège 1 : le statut gagné/perdu vivait sur deux niveaux. Dans un projet, l’ERP suivait le statut de l’offre au niveau de l’en-tête : une offre est gagnée ou perdue. Le CRM suivait le même statut par poste, parce qu’un client peut commander trois articles sur cinq. Les deux se défendent ; les deux à la fois sont un poison. Les analyses de taux de réussite du CRM comptaient des postes, le reporting de l’ERP des en-têtes, et la direction voyait deux chiffres très éloignés. Définissez le niveau de statut une seule fois, de manière identique des deux côtés, avant de construire la première brique d’intégration. Le changer après coûte bien plus cher.

Piège 2 : les motifs de refus en texte libre. Pourquoi une offre a-t-elle été perdue ? Avec un champ de texte libre, vous obtenez « prix », « trop cher », « prix trop élevé », « concurrent moins cher » et quarante autres variantes du même motif, et le reporting est mort avant d’avoir commencé. Les motifs de refus ont leur place dans une liste de valeurs gouvernée, mappée de manière identique des deux côtés, avec un responsable qui approuve les nouvelles valeurs. Une heure de gouvernance en phase de conception épargne des années d’analyses inutiles.

Si vos offres portent sur des produits configurables, la même logique de propriété s’applique à la configuration ; notre article sur les offres de produits configurables avec Sales Cloud V2 et AVC montre comment, et quand SAP CPQ est nécessaire avec S/4HANA Public Cloud couvre le cas plus lourd.

Monitoring : qui corrige quoi

Réplication signifie messages asynchrones, et les messages asynchrones échouent de temps en temps : un client sans numéro de TVA valide, un produit bloqué, une valeur de mapping inexistante côté cible. C’est normal. Ce qui ne l’est pas, c’est que personne ne le remarque.

Le monitoring des messages d’Integration Suite affiche chaque message en échec avec la charge utile et le motif d’erreur. Il faut y ajouter des alertes qui atteignent une personne nommée au lieu de s’accumuler dans une boîte partagée. Réglez ensuite la question des responsabilités avant le go-live : l’administrateur CRM corrige ce qui provient du CRM (données d’offre, champs obligatoires manquants, mappings de valeurs côté CRM) ; le key user ERP corrige ce qui trouve sa source dans l’ERP (erreurs de données de base, problèmes de conditions, partenaires commerciaux bloqués). Sans cette répartition, chaque message en échec fait des allers-retours entre deux équipes avant que quelqu’un ne s’en occupe.

La règle qui tient tout ensemble

Si vous ne retenez qu’une phrase de cet article, retenez celle-ci : un même type de document ne doit jamais être modifiable dans deux systèmes. Dès qu’une commande peut être modifiée dans le CRM et dans l’ERP, la course des versions commence, et l’intégration devient un arbitre qui ne peut que perdre. L’intégration standard de SAP applique largement cette règle d’elle-même, puisque les documents répliqués sont en lecture seule de l’autre côté. Résistez à toute exigence de l’assouplir par une extension ; l’exception qui paraît pratique aujourd’hui est l’atelier de rapprochement de données d’après-demain.

C’est aussi là que la finance et la vente se rencontrent, et c’est pourquoi nous planifions le quote-to-cash avec des consultants ERP et CRM dans la même salle ; notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse explique pourquoi c’est important, et la pile intégrée S/4HANA Public Cloud et Sales Cloud V2 montre l’ensemble.

Questions fréquentes

Peut-on aussi créer des commandes directement dans le CRM ?

Techniquement oui : Sales Cloud V2 possède un objet commande client, et le contenu standard de SAP peut le répliquer vers S/4HANA. Nous recommandons tout de même l’offre dans le CRM et la commande dans l’ERP, car la commande a besoin des données de disponibilité, de limite de crédit et de logistique de S/4HANA. Une commande saisie dans le CRM n’est au mieux qu’une pré-saisie, vérifiée une nouvelle fois dans l’ERP, ce qui fait un endroit de plus où maintenir des données.

Les offres sont-elles répliquées de S/4HANA Public Cloud vers le CRM ?

Pas en tant qu’offres Sales Cloud V2. Le contenu standard peut créer une offre de suivi dans S/4HANA à partir d’une opportunité et conserve la référence sur l’opportunité, mais les offres créées dans l’ERP ne deviennent pas des offres CRM. C’est une raison de plus pour faire naître les offres dans le CRM, afin que la vue commerciale reste complète.

Et pour la vente sur le terrain sans couverture réseau ?

Les prix en direct nécessitent une connexion à S/4HANA. Hors ligne, les commerciaux peuvent saisir les articles et les quantités, et le calcul de prix contraignant s’exécute dès que l’appareil est de nouveau en ligne. Pour le rendez-vous client, un prix indicatif sur la fiche produit, clairement signalé comme non contraignant, a bien fonctionné pour nous.

Que se passe-t-il quand une réplication échoue ?

Le message reste dans le monitoring des messages de SAP Integration Suite, avec la charge utile et le motif d’erreur, et peut être retraité après correction. Ce qui fait la différence, ce sont les alertes et une répartition des responsabilités convenue à l’avance : l’administrateur CRM pour les causes côté CRM, le key user ERP pour les erreurs de données de base et de conditions. Un tel échec se règle alors en quelques minutes, pas en semaines.

---

Vous planifiez l’intégration de Sales Cloud V2 et S/4HANA Public Cloud, ou votre intégration actuelle produit deux vérités ? Nous affichons volontiers la matrice de propriété au mur avec vous. Si S/4HANA Public Cloud est encore devant vous, commencez par l’évaluation de préparation S/4HANA. Parlez à notre équipe.