Comment nous avons construit un cycle de gestion des revenus pour le matériel de point de vente et les abonnements

Une transaction portant sur une solution de point de vente cesse d’être simple lorsqu’un même accord combine des terminaux, des scanners, des imprimantes, des appareils de paiement, des abonnements logiciels, l’installation, la formation et le support. Chaque ligne peut avoir ses propres règles de configuration, conditions contractuelles, étapes d’exécution et échéanciers de facturation. Si l’architecture se contente de relier les enregistrements CRM aux enregistrements ERP, l’entreprise ne peut toujours pas suivre de manière fiable ce qui a été vendu, accepté, livré, installé, facturé, modifié ou renouvelé.

Pour un fournisseur américain de technologies destinées au commerce de détail, nous avons mis en œuvre un cycle de revenus pour le matériel de point de vente dans Salesforce et SAP. Cet article explique les choix de conception qui sous-tendent l’étude de cas complète de cette mise en œuvre : répartition des responsabilités entre systèmes, modélisation des produits, configuration, tarification, orchestration des commandes, exécution des commandes, facturation et modifications après-vente.

Le choix de conception central

Nous avons abordé ce projet comme la mise en œuvre d’une architecture de gestion des revenus, et non comme un déploiement CPQ isolé. Chaque décision commerciale devait rester exploitable par les équipes et les systèmes responsables de l’exécution des commandes, de la comptabilité et du suivi de la relation client.

Les problèmes que la mise en œuvre devait résoudre

Le client avait fait migrer son organisation commerciale de HubSpot vers Salesforce Sales Cloud, tandis que SAP restait sa plateforme de planification des ressources de l’entreprise. Une intégration élémentaire du catalogue synchronisait les informations produits, mais elle ne créait pas de parcours fiable entre la clôture de l’opportunité et l’acceptation de la commande, la livraison, l’installation, la facturation et le renouvellement.

Des modèles de revenus mixtes

Une même transaction devait conserver les spécificités du matériel vendu en achat ponctuel, des logiciels souscrits pour une durée définie, du support récurrent, des services et des différentes fréquences de facturation.

Les risques de configuration

Il était difficile d’encadrer la compatibilité des composants et les dépendances entre quantités sans créer des centaines de références commerciales presque identiques.

Une exécution déconnectée

La clôture d’une opportunité ne prouvait ni que SAP avait accepté la commande, ni que les opérations en entrepôt, la livraison et l’installation étaient terminées.

Une gestion fragmentée des changements chez les clients

L’ajout de sites, les montées en gamme, les résiliations et les renouvellements étaient traités comme de nouvelles ventes, au lieu de modifications des actifs et abonnements existants.

Le projet associait donc la mise en œuvre de Salesforce à l’intégration et à la conception du modèle opérationnel. L’objectif n’était pas de disposer d’un système de référence universel, mais de désigner un responsable faisant autorité pour chaque domaine de données et d’encadrer les échanges d’événements du cycle de vie.

Architecture : une couche commerciale reliée aux opérations

Nous avons mis en œuvre Salesforce Agentforce Revenue Management comme couche commerciale au-dessus de Salesforce Sales Cloud. SAP restait la source faisant autorité pour le référentiel des produits physiques, les coûts d’approvisionnement, les stocks, les expéditions et les enregistrements comptables. L’architecture ainsi conçue reliait les capacités cloud sans brouiller les frontières entre la vente, l’exécution opérationnelle et la comptabilité.

1. Nous avons attribué les responsabilités par domaine de données

Nous avons commencé par un modèle de responsabilité définie au niveau de chaque champ. Les copies synchronisées étaient autorisées, mais chaque valeur conservait une seule source faisant autorité. Des identifiants partagés, des dates d’effet et des informations de version reliaient une offre commerciale dans Salesforce à son article physique dans SAP.

Les coûts issus de SAP étaient synchronisés dans Salesforce pour le calcul des marges, mais restaient non modifiables en dehors de SAP. C’est ce même principe, qui consiste à définir d’abord les responsabilités, que nous appliquons dans une intégration de SAP avec Salesforce encadrée par une gouvernance.

2. Nous avons séparé les produits des modèles de vente et de facturation

Un terminal de point de vente, un abonnement logiciel de trois ans et un support annuel peuvent figurer sur le même devis sans fonctionner de la même manière. Nous avons modélisé la nature du produit indépendamment de la manière dont il est vendu et facturé.

Modèle de produit

Articles physiques, logiciels, services, attributs, relations et identifiants nécessaires en aval.

Modèle de vente

Engagements ponctuels ou à durée définie, avec leurs dates de début et de fin et leurs modalités de renouvellement.

Modèle de facturation

Calendrier et fréquence de facturation, maintenus distincts de la durée de l’engagement commercial.

Cette séparation permettait de conserver une visibilité sur les revenus du matériel, les revenus récurrents, la valeur totale du contrat, les durées d’abonnement et les obligations futures, sans multiplier les entrées du catalogue pour chaque variante commerciale possible.

3. Nous avons configuré des solutions valides avant de les tarifer

Une solution complète pour le commerce de détail pouvait inclure un terminal, un scanner, une imprimante de tickets, un terminal de paiement, un logiciel de point de vente, un abonnement à un logiciel de gestion des stocks et du support. Nous avons représenté cette solution à l’aide d’offres groupées, d’attributs produits, de règles de compatibilité, de composants obligatoires, d’exclusions et de dépendances entre quantités.

Les règles d’Advanced Configurator pouvaient imposer un composant, exclure une combinaison impossible, masquer une option non pertinente, afficher un message contextuel ou agir à l’échelle de la transaction. Le contrôle intervenait délibérément en amont : une solution non valide ne devait jamais atteindre les étapes de tarification, de contractualisation, de commande ou d’exécution de la commande.

Pourquoi c’était important

La configuration ne servait pas uniquement à améliorer l’expérience des commerciaux. Elle limitait la multiplication des références et protégeait les équipes d’entrepôt et d’installation contre des exceptions évitables en aval.

4. Nous avons centralisé la tarification et encadré les exceptions

Nous avons modélisé les procédures de tarification et les ajustements dans Salesforce afin que le produit, la configuration, la quantité, l’accord client, le pays, la durée d’abonnement et les conditions promotionnelles puissent contribuer à un résultat commercial cohérent. SAP fournissait les données de coût à jour pour assurer la visibilité sur les marges.

Nous avons également séparé le prix calculé de la remise demandée par un commercial. Les politiques d’approbation pouvaient alors évaluer la remise, la marge, la valeur de la transaction et d’autres facteurs commerciaux. Les transactions standard suivaient leur cours sans intervention inutile, tandis que les exceptions plus importantes étaient transmises à l’approbateur compétent au sein des ventes, de la direction commerciale ou des finances.

Ces contrôles ont été mis en œuvre dans Salesforce Revenue Cloud dans le cadre du cycle de vie global, plutôt que sous forme de calculs isolés rattachés uniquement à un devis.

5. Nous avons préservé l’intention commerciale tout au long de la commande et de son exécution

Le devis contenait davantage que la quantité et le prix unitaire. Il conservait les dates, les dépendances, les exigences d’exécution, les échéanciers de facturation et les obligations de renouvellement afin que la commande et les systèmes en aval puissent donner suite à l’accord sans avoir à le reconstituer.

1. Configurez une combinaison valide de matériel, de logiciels, de services et de support.
2. Calculez les prix et les marges, puis ne soumettez à approbation que les exceptions répondant aux critères.
3. Activez une commande qui conserve les conditions, les dates, les quantités et les dépendances convenues.
4. Utilisez Dynamic Revenue Orchestrator pour créer le plan d’exécution de la commande, les tâches, les jalons et les actions d’API.
5. Laissez SAP gérer les stocks et les expéditions tout en renvoyant les statuts à Salesforce.
6. Suivez l’installation dans Salesforce Field Service en parallèle du reste du plan d’exécution de la commande.

Dynamic Revenue Orchestrator donnait aux équipes commerciales et opérationnelles une vue partagée du travail, sans obliger les équipes d’entrepôt à quitter SAP. La livraison restait également distincte de l’installation : la réception d’un appareil ne signifiait pas que le client était prêt à utiliser la solution complète.

Pour un autre exemple de coordination du travail opérationnel dans Salesforce, découvrez comment un client a utilisé Sales Cloud et Field Service pour relier les activités de vente et de service.

6. Nous avons généré les factures dans Salesforce et assuré leur comptabilisation dans SAP

Nous avons utilisé Salesforce Billing Engine pour générer les factures à partir des échéanciers convenus et des jalons opérationnels pertinents. Les données de facturation étaient ensuite transférées à SAP pour la comptabilisation, en préservant une frontière claire : Salesforce assurait la génération des factures commerciales, tandis que SAP tenait les enregistrements comptables.

Relier l’engagement commercial aux jalons de livraison et de facturation donnait également à l’équipe financière une base plus solide pour déterminer ce qui avait été vendu, livré, facturé et était prêt à entrer dans son processus de comptabilisation des revenus. La mise en œuvre ne remplaçait pas les règles comptables et ne prétendait pas que la seule génération d’une facture suffisait à comptabiliser les revenus.

7. Nous avons intégré les avenants et les renouvellements à l’architecture

La relation client se poursuivait après la commande initiale. Un nouveau magasin, des appareils supplémentaires, le passage à un support premium, une résiliation ou un renouvellement modifiaient une situation commerciale existante.

Nous avons configuré les fonctionnalités de gestion des transactions autour des actifs et des abonnements des clients. Les équipes pouvaient partir de ce que le client possédait déjà, conserver l’historique du cycle de vie et appliquer des avenants, des montées en gamme, des résiliations et des renouvellements sans recréer la configuration initiale de toutes pièces.

Le même socle peut prendre en charge ultérieurement des engagements progressifs ou une tarification à l’usage, mais nous les avons considérés comme des possibilités de conception futures, avec leurs propres exigences de mesure, de tarification, de facturation et de comptabilité, et non comme des résultats automatiques de la mise en œuvre initiale.

Enseignements de mise en œuvre pour les modèles de revenus hybrides

• Commencez par le cycle de vie métier et le modèle de responsabilité des données, plutôt que par les différents écrans Salesforce.
• Attribuez à chaque valeur importante un seul responsable faisant autorité et faites en sorte que les copies synchronisées ne fassent pas autorité.
• Séparez les modèles de produit, de vente et de facturation pour que le matériel et les abonnements puissent coexister sans prolifération des entrées du catalogue.
• Bloquez les configurations non valides avant qu’elles ne créent des exceptions dans la tarification, les commandes, les opérations en entrepôt ou l’installation.
• Préservez les dates, les dépendances, les jalons et les obligations à chaque passage de relais en aval.
• Concevez ensemble la vente initiale et le cycle de vie après-vente ; les avenants et les renouvellements ne sont pas des cas marginaux.
• Définissez explicitement les responsabilités en matière de facturation commerciale, d’exécution opérationnelle des commandes et de comptabilité.

Une étude de cas connexe sur la synchronisation des données entre Salesforce et SAP montre pourquoi des données ERP à jour et une répartition fiable des responsabilités sont des prérequis à l’automatisation en aval.

La solution mise en œuvre fonctionnait comme une architecture unifiée de gestion des revenus : la modélisation des produits déterminait la configuration, la configuration déterminait la tarification, le devis déterminait la commande et son exécution, la facturation suivait les conditions commerciales et les jalons, et les actifs clients régissaient toute modification ultérieure.