Vous êtes ici :
Modifications de l'architecture de tarification
La tarification est l'une des différences architecturales les plus importantes entre Salesforce CPQ et Gestion du revenu. S'il n'est pas exploré tôt, c'est l'un des domaines où la complexité peut émerger plus tard. Nous recommandons que l'équipe de migration comprenne clairement les changements apportés au modèle de tarification et leur impact sur la configuration et la migration avant que les décisions de conception soient finalisées.
Tarification dans CPQ
Dans Salesforce CPQ, la tarification est basée sur un moteur de règles. Les règles de prix évaluent les conditions et appliquent les ajustements dans un ordre séquentiel défini. L'ordre d'exécution est important, et la modification de l'ordre change le résultat.
Les constructions courantes de tarification CPQ comprennent les composants suivants.
- Les règles de prix sont basées sur des conditions et exécutées de façon séquentielle pour calculer le prix catalogue, le prix net et la tarification spéciale.
- Les barèmes de remise sont des tableaux de remise basés sur le volume et basés sur la durée appliqués aux lignes de devis.
- La tarification par bloc est une tarification par paliers qui s'applique en fonction des plages de quantité.
- Les prix contractés sont des remplacements de tarification spécifiques au compte stockés dans des enregistrements personnalisés CPQ.
- Les plug-ins de calcul de devis (QCP) sont un code personnalisé que le moteur de règles ne peut pas gérer en natif. Ces plug-ins prennent en charge les garde-fous de marge, les calculs interlignes, la visibilité dynamique et toute logique que le moteur de règles ne peut pas exprimer. Les PCQ offrent certes de la flexibilité, mais ils peuvent devenir difficiles à gérer au fil du temps lorsque les règles s'accumulent, lorsque les dépendances entre les règles sont masquées et lorsque la documentation complète fait défaut.
Tarification dans Gestion du revenu
Gestion du revenu remplace le moteur de règles séquentielles par un modèle de procédure de tarification structurée. Une procédure de tarification est une séquence ordonnée et nommée d'éléments de tarification. Chaque élément exécute une action de tarification spécifique, par exemple appliquer un prix au catalogue de prix, appliquer une remise, ajouter un supplément ou calculer un plancher de marge.
- Les procédures de tarification offrent plus de flexibilité et de capacité que les jeux de règles de prix CPQ. Ils définissent la cascade du calcul de la tarification pour un contexte donné, par exemple la vente directe, le canal partenaire ou l'e-commerce. Ils définissent la cascade du calcul de la tarification pour un contexte donné, par exemple la vente directe, le canal partenaire ou l'e-commerce.
- Les éléments de tarification sont des étapes individuelles d'une procédure. Chaque élément a un type tel que Ajustement manuel, Barème de remise, Liste de prix, Tarification basée sur l'attribut, etc. Consultez Utilisation d'éléments de tarification dans des procédures tarifaires.
- Les plans de procédure définissent la procédure de tarification applicable en fonction du contexte. Ces plans activent une logique de tarification différente pour chaque canal, segment de clients ou catégorie de produits sans règles de duplication.
- La tarification basée sur l'attribut calcule le prix d'un produit différemment en fonction de ses attributs de configuration, sans nécessiter d'UGS ou de conditions de règle de prix distinctes pour chaque variante.
- La tarification à l'usage ou à la consommation est un moteur de tarification natif pour les modèles d'utilisation basés sur la consommation et par paliers. Aucun code personnalisé n'est requis.
- La tarification des articles contractés fournit des remplacements de prix spécifiques au compte ou au contrat en utilisant des objets Gestion du revenu standard, remplaçant les enregistrements personnalisés ContractedPrices de CPQ.
La tarification dans Gestion du revenu est flexible et plus facile à maintenir que la cascade des prix CPQ. Voici un exemple de cascade de prix pour un élément de ligne de devis dans Gestion du revenu.
Le prix unitaire net de 10 260 est calculé en appliquant séquentiellement ces remises au prix catalogue de 15 000.
| Étape | Description | Calcul | Résultat |
|---|---|---|---|
| 1 | Prix catalogue | Aucun | 15 000 |
| 2 | Remise basée sur l'attribut | 15,000 − 3,000 |
12 000 |
| 3 | Ajustement basé sur l'offre groupée de 5 % | 12,000 − (12,000 × 5%) = 12,00 − 600 |
11,400 |
| 4 | Remise sur volume de 10 % | 11,400 − (11,400 × 10%) = 11,400 − 1,140 |
10,260 |
Reconception et migration du processus de tarification
La logique de tarification CPQ migre rarement sans modification. Les deux systèmes définissent la tarification de différentes façons. Une traduction directe de règle à règle produit souvent des résultats incorrects, car les règles CPQ dépendent de l'ordre d'exécution, qui n'a pas d'équivalent direct dans les procédures de tarification de Gestion du revenu.
Le passage du moteur de règles séquentielles de CPQ au modèle de procédure de tarification de Gestion du revenu est donc l'occasion de simplifier le processus de tarification de votre entreprise. La question clé n’est pas de savoir comment reproduire les règles CPQ existantes, mais de savoir quels résultats de tarification l’entreprise a réellement besoin et comment les exprimer de la façon la plus claire.
- Auditez toutes les règles de prix actives et la logique QCP avant le début des travaux de migration. Utilisez des outils pilotés par l’IA, tels que Forsys ou IdeaHelix, pour générer des rapports d’explicabilité sur toutes les règles de prix CPQ et la logique QCP. Comprenez l'intention et l'objet métier de chaque règle, qu'il s'agisse du prix catalogue, de la remise, de la protection de la marge ou de l'ajustement du canal, avant de tenter une refonte.
- Classez chaque règle CPQ dans son équivalent Gestion du revenu. Les ajustements de prix simples deviennent des éléments de tarification, et les logiques interlignes complexes deviennent des flux personnalisés ou Apex dans la procédure.
- Rationalisez les règles de tarification qui se sont accumulées au fil du temps sans propriété claire. La migration est le bon moment pour retirer une logique qui n'est plus d'actualité commerciale.
- Mappez les exigences de tarification spécifiques au canal pour les canaux directs, partenaires et en libre-service avec des plans de procédure dans Gestion du revenu. Ce mappage active un catalogue de produits unique avec une tarification adaptée au contexte plutôt que des constructions de tarification séparées pour chaque canal.
- Si votre entreprise évolue vers la monétisation hybride, configurez la tarification basée sur la consommation et l'utilisation dans Gestion du revenu. Les procédures de tarification déterminent le taux net final de consommation en utilisant des règles et des niveaux spécifiques définis dans des cartes de taux de base, de niveau ou d'attribut.
- Validez la tarification reconçue par rapport à un pack de devis organisé, qui est un ensemble représentatif de devis historiques dont les prix de sortie sont connus. Si la procédure de Gestion du revenu produit les mêmes résultats, la nouvelle conception est correcte.
- Pour les organisations qui utilisent des devises multiples, migrez et validez une devise à la fois afin d'éviter les écarts d'arrondi entre les valeurs d'entrée au catalogue de prix.
Avant de vous engager dans une stratégie de migration, investissez du temps dans un audit de logique de tarification. Le volume et la complexité de votre personnalisation de la tarification sont l'un des principaux prédicteurs de l'effort global de migration.
Moteur de tarification unique dans tous les canaux
L'architecture API-first de Gestion du revenu répond au défi d'intégration de la prolifération de logiques de tarification à travers les canaux. De nombreuses entreprises finissent par maintenir des règles de tarification distinctes pour la vente directe, les portails partenaires et les canaux en libre-service, créant trois versions de la même vérité qui divergent au fil du temps et entraînent des incohérences pour les clients.
Chaque opération de revenu dans Gestion du revenu est exposée en tant qu'API. Ainsi, la même logique de produit, de tarification et de configuration qui pilote l'interface utilisateur de Salesforce peut être consommée par un portail partenaire, une expérience d'e-commerce en libre-service ou un flux d'achat dans le produit sans dupliquer les règles. Vous pouvez avoir un catalogue unique et un moteur de tarification unique qui fonctionne pour chaque canal.
Vous pouvez intégrer des outils de visualisation tiers, tels que ThreeKit et RenderDraw, pour la configuration visuelle des produits.
