Établir des offres pour des produits configurables sur le terrain : Sales Cloud V2 + AVC dans S/4HANA Public Cloud

Dans les entreprises industrielles de taille moyenne, l’offre est souvent le document le plus lent de toute l’entreprise. Non parce que le calcul est difficile, mais parce qu’un article doit exister avant que quiconque puisse le proposer. Le commercial est assis à la table du client, la demande est concrète, et puis : ticket au back-office, création d’un numéro d’article, saisie des données de base, et deux jours plus tard l’offre part. Si vous fabriquez à la commande, vous connaissez ce schéma. Votre fichier articles aussi : chez un fabricant suisse avec lequel nous travaillons, des centaines de milliers d’articles uniques se sont accumulés au fil des ans, chacun proposé une seule fois, beaucoup jamais revendus.

Ce n’est pas un problème de données de base. C’est un problème de processus déguisé en problème de données de base.

En bref : arrêtez de créer un numéro d’article pour chaque produit spécifique à un client. Modélisez des familles de produits avec Advanced Variant Configuration (AVC) dans S/4HANA Public Cloud, gardez l’offre dans Sales Cloud V2 légère (famille de produits plus cinq à sept caractéristiques sous forme de champs), et configurez le produit lorsque l’offre devient une commande client dans S/4HANA. Le CRM reste léger, l’ERP reste maître, et il n’y a pas de seconde logique de configuration à synchroniser.

Pourquoi les articles uniques ne passent pas à l’échelle

Créer un numéro d’article dédié pour chaque produit spécifique semble pragmatique sur le papier. En réalité, vous payez trois fois. Le back-office devient le goulet d’étranglement du processus d’offre. Le reporting se noie dans le bruit, parce que le calcul des besoins, la planification des capacités et l’analyse des marges regardent des dizaines de milliers de références au lieu de familles de produits. Et au plus tard lors d’une migration de système, le fichier articles devient l’héritage que personne ne veut emporter.

L’alternative est la configuration de variantes : une poignée d’articles configurables par famille de produits, des caractéristiques au lieu de numéros d’article. SAP S/4HANA Public Cloud fournit Advanced Variant Configuration exactement pour cela, super-nomenclature et super-gamme comprises, dont découlent le calcul des coûts et la production.

Reste la question sur laquelle beaucoup d’architectures butent : où vit la configuration quand la vente travaille dans le CRM ?

SAP Sales Cloud V2 peut-il configurer des produits AVC dans l’offre ?

Pas dans l’intégration standard avec S/4HANA Public Cloud. Avant de dessiner des schémas cibles, il est utile de savoir ce que couvre le package d’intégration des processus de vente de SAP en septembre 2026 :

• Une offre dans Sales Cloud V2 crée une commande client de suivi dans S/4HANA Public Cloud via SAP Integration Suite.
• Les offres et les commandes peuvent être simulées dans S/4HANA, de sorte que les prix et les conditions viennent de l’ERP.
• Les commandes clients sont répliquées en retour dans le CRM comme documents en lecture seule.
• Un écran de configuration AVC dans l’offre CRM ne fait pas partie du package.

On peut regretter cette lacune, ou y voir une répartition claire des rôles. C’est notre approche.

Notre approche : offre légère dans le CRM, configuration dans l’ERP

Nous séparons délibérément ce dont la vente sur le terrain a besoin de ce dont la production a besoin. La vente a besoin de rapidité et de simplicité ; la production a besoin d’une configuration complète et cohérente. Ce sont deux moments différents du processus, nous les traitons donc comme tels.

Étape 1, l’offre dans Sales Cloud V2 : le commercial choisit la famille de produits comme poste, l’unique article configurable au lieu d’un nouveau numéro d’article. Les cinq à sept caractéristiques qui comptent (géométrie, matériau, surface, fermeture, tout ce qui définit la famille) sont saisies dans des champs de l’offre. Le prix est fixé manuellement ou par une logique simple de prix indicatif. Pas d’attente du back-office, pas de demande de données de base. Ce que nous livrons de bout en bout comme partenaire d’implémentation est décrit sur notre page SAP Sales Cloud V2.

Étape 2, la commande dans S/4HANA : quand l’offre devient une commande, la commande client est créée dans S/4HANA Public Cloud via l’intégration standard. Là, et seulement là, le produit est configuré dans AVC, avec la logique de validation, la super-nomenclature et la gamme derrière. Avec sept caractéristiques, c’est un travail rapide pour le back-office. Pour automatiser davantage, Integration Suite peut reporter les valeurs de caractéristiques de l’offre CRM dans la configuration de la commande, ce que prend en charge l’API Sales Order (A2X).

Le CRM reste léger, l’ERP reste maître, et personne ne construit une seconde logique de configuration qu’il faudrait synchroniser pendant des années. Le clean core, dans le processus aussi. La logique de propriété derrière est la même que celle décrite dans notre article sur le quote-to-cash entre Sales Cloud V2 et S/4HANA Public Cloud.

Quatre règles de base pour qu’AVC ne devienne pas un fardeau de maintenance

La crainte légitime face à la configuration de variantes, c’est l’effort de modélisation et de maintenance. Elle est justifiée quand on laisse le modèle proliférer. Notre discipline, tirée de l’expérience projet :

1. Petit modèle, plafond ferme. Cinq à sept caractéristiques par famille. S’il vous faut plus d’une main, vous modélisez probablement des exceptions, pas des produits.
2. Les visuels ne sont pas des caractéristiques. Impressions, designs et documents spécifiques au client sont des pièces jointes à l’article ou à la commande. Ils ne deviennent jamais de la logique de configuration. C’est là qu’échouent la plupart des modèles trop ambitieux.
3. Le prix reste dehors. Quand les prix des matières premières dépendent des bourses (aluminium, cuivre, acier), le prix n’a pas sa place dans la logique des caractéristiques. Prix manuel ou indexé dans l’offre ; la configuration pilote la nomenclature, la gamme et le calcul des coûts, pas les conditions. Effet secondaire : cela supprime la partie la plus difficile de tout projet AVC.
4. Piloter une seule famille. Modélisez d’abord la famille qui génère le plus de chiffre d’affaires, mesurez l’effort, puis décidez pour les autres.

Il existe aussi SAP CPQ pour configurer dans l’offre. Pour un fabricant de taille moyenne avec sept caractéristiques par famille, c’est sortir l’artillerie lourde. CPQ se justifie avec des règles complexes, la vente guidée et la vente indirecte ; nos articles sur quand SAP CPQ est nécessaire avec S/4HANA Public Cloud et sur les meilleurs partenaires d’implémentation SAP CPQ en région DACH couvrent ce cas.

Ce que vous obtenez au final

L’étape des données de base disparaît du processus d’offre, l’offre n’attend donc plus le back-office. Le fichier articles reste stable, parce que les familles grandissent au lieu des articles uniques. La planification et le reporting travaillent sur des familles de produits plutôt que sur un bruit de références. Et l’ensemble continue de fonctionner à la prochaine mise à niveau, parce qu’il est construit dans le standard de Sales Cloud V2, de S/4HANA Public Cloud et d’Integration Suite.

La vente sur le terrain ne remarque qu’une chose : elle peut établir l’offre tout en étant encore assise à la table du client.

Cela fonctionne parce que les côtés CRM et ERP sont conçus ensemble, c’est l’argument de la pile intégrée S/4HANA Public Cloud et Sales Cloud V2 et de notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse.

Questions fréquentes

SAP Sales Cloud V2 configure-t-il des produits AVC dans l’offre ?

Pas via l’intégration standard avec S/4HANA Public Cloud. Le package d’intégration de SAP couvre les documents de suivi, la simulation des prix et la réplication des commandes, mais n’amène pas le configurateur AVC dans l’offre CRM. Nous gardons l’offre légère (famille de produits, caractéristiques clés sous forme de champs, prix) et configurons dans la commande client S/4HANA.

Avons-nous besoin de SAP CPQ pour cela ?

Avec cinq à sept caractéristiques par famille de produits, en général non. CPQ est rentable avec des règles complexes, la vente guidée et la vente indirecte. Pour un jeu réduit de caractéristiques, une offre Sales Cloud V2 combinée à AVC dans la commande S/4HANA est la voie la plus rapide et la moins coûteuse.

Cela fonctionne-t-il avec des prix dépendant des matières premières ?

Oui, et c’est là que l’approche aide le plus. Quand le prix des matières premières bouge chaque jour, il n’a pas sa place dans des tables de conditions ni dans la logique des caractéristiques. Il est fixé manuellement ou par indice dans l’offre, tandis que la configuration pilote la nomenclature, la gamme et le calcul des coûts.

Advanced Variant Configuration est-il disponible dans S/4HANA Public Cloud ?

Oui. SAP S/4HANA Public Cloud inclut Advanced Variant Configuration, avec des articles configurables dans les commandes clients, une super-nomenclature et une super-gamme, et l’API Sales Order (A2X) peut transporter la configuration. Les modèles très exotiques atteignent des limites ; un modèle discipliné avec peu de caractéristiques reste confortablement dans le standard.

---

Vous fabriquez à la commande et votre processus d’offre attend des numéros d’article ? Nous vous montrons l’approche avec vos propres familles de produits ; si S/4HANA Public Cloud est encore devant vous, l’évaluation de préparation S/4HANA est le bon point de départ. Parlez à notre équipe.