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 seule question décide si l’intégration tient des années ou devient un chantier permanent : qui possède quel document ? Pas quelle interface vous choisissez, pas quel outil de mapping. Mais : dans quel système naît le devis, où naît la commande, et qui a le droit de modifier quoi ? Notre expérience projet nous permet de l’affirmer : presque chaque intégration quote-to-cash laborieuse que nous avons été appelés à assainir n’avait, au départ, aucune réponse claire à cette question.

Pour la combinaison SAP Sales Cloud V2 et S/4HANA Public Cloud, il existe une réponse propre. Vous ne la trouverez dans aucun document SAP isolé, mais elle découle du standard si on le lit avec cohérence. La voici, y compris les endroits où nous nous sommes déjà brûlé les doigts en projet.

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.

Le devis naît dans le CRM parce que c’est là que vivent les ventes : opportunité, historique des contacts, activités, tout dans une seule vue. La commande client naît dans S/4HANA parce que c’est là que sont rattachés disponibilité, limite de crédit, logistique et facturation. Le passage de l’un à l’autre s’effectue comme document consécutif via les iFlows standard de SAP Integration Suite. Et dans le sens retour : la commande apparaît dans le CRM comme document répliqué, que les ventes voient mais ne touchent pas.

Cette matrice a sa place sur le mur de la salle de projet avant le déploiement du premier iFlow. De facto, elle compte plus que n’importe quel document de conception technique.

External pricing : une seule vérité de prix, pas deux

La partie la plus élégante de cette architecture est celle qui ne réplique rien : la détermination des prix. Le devis CRM appelle en direct la détermination des prix de S/4HANA. Conditions, prix spécifiques au client, barèmes, remises : tout vient de l’ERP au moment même où le commercial saisit le poste.

Pourquoi c’est important : dès que les prix sont maintenus dans deux systèmes, il existe deux vérités de prix, et tôt ou tard quelqu’un établit une offre avec la mauvaise. Avec l’external pricing, il existe exactement un seul lieu de maintenance des conditions, l’ERP, et le devis dans le CRM calcule avec les mêmes chiffres que la commande et la facture plus tard. Pas de réplications de prix nocturnes, pas de job de réconciliation, pas de conversation gênante avec le client pour expliquer pourquoi devis et facture ne concordent pas.

Deux pièges tirés de la pratique

L’architecture ci-dessus semble bien rangée, et elle l’est. Selon notre expérience, les projets n’ont pas échoué sur la technique, mais sur deux détails métier que personne n’avait réglés avant la construction de l’intégration.

Piège 1 : le statut gagné/perdu vivait à deux niveaux. Dans un de nos projets, l’ERP suivait le statut du devis au niveau de l’en-tête : un devis est gagné ou perdu, point. Le CRM suivait le même statut par poste, parce qu’un client peut évidemment commander trois postes sur cinq. Les deux se défendent. Les deux en même temps sont un poison : l’analyse du taux de réussite dans le CRM comptait des postes, le reporting ERP comptait des en-têtes, et la direction s’est vu présenter deux vérités séparées par des points de pourcentage à deux chiffres. La leçon : le niveau de statut se définit une seule fois, à l’identique des deux côtés, et cela avant que la première brique d’intégration soit construite. Prendre la même décision après coup coûte plusieurs fois plus cher.

Piège 2 : les motifs de refus en texte libre. Pourquoi un devis a-t-il été perdu ? Si la réponse est un champ de texte libre, vous obtenez « prix », « trop cher », « prix trop élevé », « concurrent moins cher » et quarante autres variantes du même motif. Cela tue tout reporting avant même qu’il commence. Les motifs de refus appartiennent à une liste de valeurs gouvernée, mappée à l’identique des deux côtés, avec un propriétaire qui approuve les nouvelles valeurs. C’est une heure de travail de gouvernance en phase de conception, et cela vous épargne des années d’analyses inutilisables.

Monitoring : qui répare quoi

Réplication signifie messages asynchrones, et les messages asynchrones finissent par échouer. Un client sans numéro de TVA valide, un produit bloqué, une valeur de mapping qui n’existe pas côté cible. C’est normal. Ce qui n’est pas normal, c’est que personne ne le remarque.

Le message monitoring d’Integration Suite montre chaque message en échec avec payload et motif d’erreur. Par-dessus, il faut une alerte qui ne prend pas la poussière dans une boîte partagée mais atteint une personne nommée. Et ensuite la question des responsabilités, à régler nota bene avant le go-live : l’administrateur CRM corrige ce qui naît dans le CRM, c’est-à-dire données de devis, champs obligatoires manquants, mappings de listes de valeurs côté CRM. Le key user ERP corrige ce qui s’enracine dans l’ERP, c’est-à-dire erreurs de données de base, problèmes de conditions, business partners bloqués. Sans cette séparation, vous obtenez le ping-pong bien connu : chaque message en échec fait trois allers-retours entre deux équipes avant que quelqu’un s’en occupe.

La règle qui tient tout ensemble

Si vous ne retenez qu’une phrase de cet article, que ce soit celle-ci : le même type de document ne doit jamais être modifiable dans deux systèmes. Dès qu’une commande peut être changée dans le CRM et dans l’ERP, la course des versions commence, et l’intégration se dégrade en arbitre qui ne peut que perdre. L’intégration standard de SAP impose cette règle en grande partie d’elle-même, les documents répliqués sont en lecture seule de l’autre côté. Résistez à toute exigence de l’assouplir par une extension. Chaque exception qui semble confortable aujourd’hui est l’atelier de réconciliation de données d’après-demain.

Questions fréquentes

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

Techniquement oui, Sales Cloud V2 connaît la commande client comme objet. Le modèle propre reste pourtant : devis dans le CRM, commande dans l’ERP. La commande a besoin du contrôle de disponibilité, de la limite de crédit et des données logistiques, et tout cela vit dans S/4HANA. Une commande saisie dans le CRM est au mieux une pré-saisie qui sera revérifiée dans l’ERP, donc un lieu de maintenance de plus.

Les devis sont-ils répliqués de S/4HANA Public Cloud vers le CRM ?

Non. La réplication des devis de S/4HANA Public Cloud vers le CRM n’est pas supportée en standard. Les devis créés dans l’ERP n’apparaîtront pas dans le CRM. Une raison de plus de s’en tenir à : les devis naissent dans le CRM, et la vue des ventes reste complète.

Et le service externe sans couverture réseau ?

L’external pricing a besoin d’une connexion à l’ERP. Hors ligne, le commercial peut saisir postes et quantités ; la détermination de prix contraignante s’exécute dès que l’appareil est de nouveau en ligne. Pour le rendez-vous client lui-même, un prix indicatif basé sur les données produits répliquées a fait ses preuves chez nous, clairement marqué comme non contraignant, le prix ferme arrivant à la synchronisation.

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

Le message reste dans le message monitoring d’Integration Suite, avec payload et motif d’erreur, et peut être retraité après correction. Ce qui décide du résultat, c’est l’alerte et la répartition des responsabilités définie en amont : admin CRM pour les causes côté CRM, key user ERP pour les erreurs de données de base et de conditions. Un tel échec devient alors une affaire de minutes, pas de semaines.

Vous planifiez l’intégration de Sales Cloud V2 et S/4HANA Public Cloud, ou la vôtre produit deux vérités ? Nous mettons volontiers la matrice de propriété au mur avec vous. Parlez-nous.