Avez-vous vraiment besoin de SAP CPQ ? Un guide de décision honnête aux côtés de S/4HANA Public Cloud

Peu de produits SAP arrivent aussi vite sur la shortlist que CPQ. Les ventes veulent des devis plus rapides, le conseiller en licences acquiesce, et soudain un produit de plus figure dans l’architecture cible, sans que personne ait demandé quel problème il doit résoudre. La question est rarement de savoir si SAP CPQ est bon. Il l’est. La question est de savoir si votre processus de devis a besoin de cette machinerie. Nos projets autour de S/4HANA Public Cloud et Sales Cloud V2 le montrent : dans environ la moitié des cas, la réponse honnête est non. Cet article est le guide de décision que nous aurions aimé avoir au début de certaines évaluations.

Ce qu’est réellement SAP CPQ

CPQ signifie Configure, Price, Quote. Le produit livre ces trois lettres à l’échelle industrielle :

• Guided selling : un parcours guidé par questions mène le vendeur au bon produit. Précieux quand même les commerciaux expérimentés ne connaissent pas toutes les combinaisons.
• Règles complexes : règles de compatibilité et contraintes entre composants. Si moteur X, alors jamais boîte Y ; si variante de tension A, alors accessoire obligatoire B. Le référentiel empêche les devis techniquement impossibles de quitter la maison.
• Matrices d’approbation à plusieurs niveaux : seuils de remise avec un vrai workflow. Jusqu’à 5 pour cent le vendeur décide, jusqu’à 12 le directeur des ventes, au-delà la direction, le tout journalisé.
• Génération de propositions : documents d’offre à votre marque, avec blocs de texte, images et récapitulatifs de prix, générés au lieu d’être bricolés dans Word.
• Vente indirecte et partenaires : portails où revendeurs et partenaires configurent et quotent eux-mêmes, avec leurs propres listes de prix.

Cela fait beaucoup de machinerie. Elle coûte des licences, une implémentation et un entretien permanent. Raison de plus pour un regard sobre avant que l’encre ne sèche.

L’arbre de décision issu de nos projets

Au fil des ans, un arbre de décision simple s’est dégagé chez nous. Ce n’est pas une science, mais il a tenu la route en projet.

Pas de CPQ si les trois points s’appliquent : moins d’une dizaine de caractéristiques par famille de produits, vente directe uniquement sans canal de revendeurs, et des prix que le vendeur fixe manuellement ou selon une logique simple de prix indicatif. Dans cette constellation, un devis allégé dans le CRM plus l’Advanced Variant Configuration dans l’ERP est en production plus vite, coûte moins cher et s’apprend plus facilement sur le terrain. Notre article sur la configuration de variantes décrit cette architecture en détail.

CPQ se rentabilise dès qu’un de ces schémas domine : des règles de compatibilité qui ne tiennent plus dans une poignée de caractéristiques. Un canal de partenaires ou de revendeurs qui doit établir ses devis de manière autonome. Des approbations de remises formelles qui passent aujourd’hui par e-mail et qui dérapent régulièrement. Ou des documents d’offre qui doivent servir de carte de visite, parce que le concurrent se présente avec des PDF soignés.

La zone grise entre les deux existe, bien sûr. Notre conseil dans ce cas : construire d’abord la voie allégée, mesurer le processus pendant six mois, puis décider. Un CPQ peut se rajouter. Démonter une plateforme surdimensionnée est autrement plus douloureux.

Le schéma d’intégration quand CPQ est retenu

Une fois la décision prise en faveur de CPQ, sa place est clairement définie : entre Sales Cloud V2 et S/4HANA Public Cloud. L’opportunité vit dans le CRM. Le devis naît dans CPQ à partir d’elle, avec configuration, tarification et approbation. La commande gagnée part vers S/4HANA, où nomenclature, gamme et production prennent le relais.

Deux points font la différence entre un succès et un chantier permanent. Premièrement, la synchronisation des prix de variantes : prix et valeurs de caractéristiques pertinentes pour le prix doivent rester alignés entre les modèles AVC dans S/4HANA et CPQ, sinon les ventes proposent des prix que le calcul des coûts ne confirmera jamais. Deuxièmement, et plus important : ne modélisez jamais les mêmes règles deux fois. Qui duplique tout le référentiel AVC dans CPQ entretient deux vérités dès le premier jour, et elles divergeront. Décidez par type de règle où vit la vérité de configuration : logique de vente dans CPQ, logique de fabrication dans AVC, et l’interface entre les deux aussi étroite que possible.

Trois leçons qu’aucune fiche technique ne mentionne

Tirées de projets, anonymisées mais réelles :

1. La gouvernance du référentiel de règles est le coût caché. Construire les règles est le petit problème. Les maintenir quand les produits changent est le grand. Nommez un responsable, une personne avec un nom, pas un comité, et fixez une revue trimestrielle. Sans ce rythme, le référentiel vieillit en silence et les ventes construisent des contournements.
2. Les matrices d’approbation doivent refléter la vraie politique de signature, pas en inventer une nouvelle. La tentation de réformer les compétences décisionnelles en même temps que l’outil est forte. Résistez-y. Un workflow qui ne correspond pas à la pratique vécue sera contourné, et vous aurez des coûts de licence plus un processus fantôme.
3. Mesurez le délai de devis avant et après. De la demande au devis envoyé, en heures. Sans valeur de départ, pas de business case, juste une intuition. Avec elle, vous verrez noir sur blanc après six mois si l’investissement se justifie.

Questions fréquentes

CPQ peut-il calculer les prix à partir des conditions de S/4HANA ?

Oui. CPQ peut se connecter à la logique de tarification de S/4HANA et utiliser les conditions comme base ; il peut aussi tenir ses propres listes de prix, mises à jour par synchronisation. L’essentiel est la décision de principe : quel système fait référence pour le prix. Deux logiques de prix en parallèle sont la même erreur que deux référentiels de règles.

CPQ remplace-t-il l’Advanced Variant Configuration ?

Non, les deux se complètent. CPQ vend : guided selling, règles de vente, document d’offre. AVC fabrique : super-nomenclature, gamme, calcul des coûts. Éteindre l’AVC parce que CPQ est arrivé, c’est confondre la vue commerciale avec la vue de fabrication et déplacer le problème vers la production.

Quel est un calendrier réaliste pour une introduction de CPQ ?

Pour une première ligne de produits avec un référentiel propre et les connexions vers Sales Cloud V2 et S/4HANA Public Cloud, nous comptons quatre à six mois. Ensuite, le modèle grandit ligne par ligne. Vouloir modéliser toutes les familles de produits d’un coup devient de facto un projet pluriannuel, et on ne s’en aperçoit qu’en deuxième année.

Et si nous voulons seulement des devis plus rapides, sans tout l’appareil ?

Alors la voie allégée est généralement la bonne : devis dans Sales Cloud V2, caractéristiques comme champs, configuration seulement dans la commande S/4HANA. C’est le schéma décrit dans l’article sur la configuration de variantes mentionné plus haut. Vous pourrez toujours rajouter CPQ quand le canal de revendeurs ou le référentiel de règles arrivera vraiment.

Vous êtes face à exactement cette décision ? Nous examinons votre processus de devis et vous disons honnêtement si CPQ vaut sa licence, même si la réponse est non. Parlez-nous.