SAP Service Cloud V2 + S/4HANA Public Cloud : du cas à l'ordre de service, puis à la facture

Un client appelle pour une machine en panne. L’agent peut-il voir de quelle machine il s’agit, si elle est encore sous garantie, et ouvrir l’ordre de service ERP sans changer de système ? Avec SAP Service Cloud V2 et SAP S/4HANA Public Cloud reliés par SAP Integration Suite, oui, et l’essentiel du mécanisme repose sur des contenus SAP standard plutôt que sur du code spécifique.

Cet article couvre le côté service de la connexion : où vit le cas, où vit l’exécution, quelles données circulent dans quel sens, et les règles de base que nous appliquons en projet. Pour le côté vente de la même topologie, voir l’architecture d’intégration de Sales Cloud V2 ; pour la vue d’ensemble, voir notre guide de la pile intégrée S/4HANA Public Cloud et Sales Cloud V2.

En bref : le cas vit dans Service Cloud V2, l’exécution (ordre de service, pièces de rechange, confirmation, facturation) dans S/4HANA Public Cloud. SAP fournit des packages d’intégration standard sur SAP Integration Suite pour les données de base (partenaires commerciaux, produits, équipements) et pour les processus de service (ordres de service, contrats, offres, retours). Répliquez d’abord les données de base, puis connectez le processus. La logique spécifique a sa place sur SAP BAIP (anciennement BTP) en extension side-by-side, jamais dans l’un des deux systèmes cœur.

Comment Service Cloud V2 s’intègre-t-il à S/4HANA Public Cloud ?

L’intégration passe par SAP Integration Suite (Cloud Integration) sur SAP BAIP. Service Cloud V2 expose des API REST ; S/4HANA Public Cloud expose des API publiées (released), documentées sur le SAP Business Accelerator Hub et activées par scénario au moyen de communication arrangements. Aucun des deux systèmes n’appelle l’autre directement. Integration Suite mappe, route et surveille chaque message, ce qui vous donne une seule file d’erreurs, une logique de relance et un seul runbook d’exploitation.

SAP livre les contenus d’intégration prêts à déployer. Deux packages comptent pour le service :

• Le package de données de base pour Sales et Service Cloud V2 avec S/4HANA Cloud Public Edition : partenaires commerciaux et relations de contact dans les deux sens, produits, données organisationnelles, ainsi que les équipements et postes techniques depuis S/4HANA.
• Le package service pour Service Cloud V2 avec S/4HANA : ordres de service dans les deux sens, contrats de service et offres de service depuis S/4HANA, commandes de retour et commande client de suivi pour la facturation.

Le déploiement consiste à copier le package dans votre tenant Integration Suite, à configurer les connexions et les mappings de valeurs, puis à activer les iFlows. Au préalable, Integration Suite doit être provisionné dans votre sous-compte BAIP et les communication arrangements doivent exister dans S/4HANA. Les équipes qui traitent cette mise en place comme un détail perdent généralement un sprint au début de la phase d’intégration. La documentation SAP Integration Suite couvre le côté plateforme.

Où vit le cas, où vit l’exécution

L’architecture commence par une répartition délibérée des rôles. Le cas vit dans Service Cloud V2. C’est là que convergent tous les canaux (courriel, téléphone, portail client) en un seul objet, avec les catégories de cas, les accords de niveau de service, les escalades et toute la communication avec le client. L’agent voit d’un coup d’œil qui demande, ce qui s’est déjà passé et combien de temps il reste avant le dépassement du SLA.

L’exécution vit dans S/4HANA : ordre de service, retour, logistique des pièces de rechange, confirmation, facture ou note de crédit. Derrière ces documents se trouvent la gestion des stocks, le contrôle de gestion et la comptabilité. Un CRM ne devrait pas s’y essayer ; reconstruire les stocks ou la facturation dans le CRM revient à bâtir un second ERP, moins bon.

Deux systèmes, deux rôles. L’intégration les relie sans les mélanger.

Les données de base d’abord, le processus ensuite

L’erreur la plus fréquente dans ces projets est l’ordre des étapes. Tout le monde veut construire le flux de processus en premier : créer l’ordre de service depuis le cas, voir le statut revenir. Sans données de base synchronisées, rien de cela ne fonctionne.

Clients. Les comptes dans Service Cloud V2 et les partenaires commerciaux dans S/4HANA doivent être les mêmes enregistrements, avec un mapping d’identifiants propre via la réplication standard. Les doublons d’aujourd’hui deviennent les historiques de service en double de demain.

Base installée. S/4HANA est le système de référence pour les équipements, les postes techniques et les contrats de service. Les iFlows standard répliquent les équipements et les postes techniques vers Service Cloud V2, où ils apparaissent comme produits enregistrés sur le compte, avec numéro de série, produit et date d’installation. Quand un client appelle, l’agent voit la machine, pas seulement le client.

Statut de garantie et de contrat. Les contrats de service sont également répliqués depuis S/4HANA. Le tri devient concret : l’agent voit si le défaut est sous garantie ou couvert par un contrat avant de s’engager sur une intervention facturable.

Le mapping entre les objets techniques de S/4HANA et le modèle de produits enregistrés de Service Cloud V2 demande de l’attention. Le contenu standard gère la traduction principale, mais les champs spécifiques et les règles de hiérarchie nécessitent une configuration explicite. Prévoyez un sprint. L’intégration des données de base n’a rien de spectaculaire, mais elle décide si l’intégration des processus prend ensuite des semaines ou des mois.

Du cas à l’ordre de service, puis à la facture

C’est le flux transactionnel central, celui qui supprime la plus grande partie du travail manuel que les équipes de service détestent :

1. Le cas est créé dans Service Cloud V2, quel que soit le canal. Appel, courriel ou saisie sur le portail aboutissent dans le même cas, lié au client et au produit enregistré.
2. L’agent catégorise et vérifie. Catégorie de cas définie, garantie et droits vérifiés par rapport aux données S/4HANA répliquées, horloge du SLA en marche.
3. Le document de suivi est créé. Depuis le cas, l’agent crée un ordre de service que l’iFlow standard réplique vers S/4HANA. Selon le scénario, il peut aussi s’agir d’une commande de retour.
4. S/4HANA exécute. Les pièces de rechange sont réservées sur le stock, le temps et le matériel du technicien sont confirmés sur l’ordre de service, et la facturation se fait dans S/4HANA, où le contenu standard peut créer une commande client de suivi pour la facturation.
5. Le statut revient dans le cas. L’ordre de service S/4HANA est répliqué en retour vers Service Cloud V2 avec son statut, et l’agent informe le client depuis le cas.

Le dernier point est le plus important : la communication avec le client reste dans le CRM. Le client a un seul interlocuteur, un seul fil et un seul historique, et il apprend ce qui se passe dans l’ERP par le biais du cas.

Un exemple typique est une livraison arrivée endommagée. L’appel arrive, le cas est créé avec la catégorie « dommage de transport », et les photos envoyées par courriel sont rattachées au même cas. L’agent vérifie la livraison dans le document S/4HANA lié et déclenche le retour et le remplacement. Dès que S/4HANA confirme le remplacement, la mise à jour part vers le client depuis le cas. Un processus, une référence, aucune recherche.

Pièces de rechange et transfert vers FSM

Pour les entreprises de service à forte intensité d’équipements, la disponibilité des pièces de rechange est souvent le chemin critique. Les réservations sont faites sur l’ordre de service S/4HANA, de sorte que les pièces sont liées à l’intervention et non au stock du véhicule d’un technicien. Pour les organisations avec plusieurs entrepôts, c’est ce qui rend les promesses de disponibilité fiables.

Quand une intervention sur site est nécessaire et que la planification devient exigeante (horaires, compétences, tournées), SAP Field Service Management est la couche de planification et d’exécution mobile. Le cas reste dans Service Cloud V2, la planification se fait dans FSM, et le temps et le matériel confirmés par le technicien sont reportés sur l’ordre de service S/4HANA pour la facturation. Choisissez un seul déclencheur pour l’intervention, en général l’ordre de service S/4HANA, et documentez-le : deux systèmes capables de créer chacun des interventions FSM pour le même cas produisent des visites en double. Nos articles sur FSM avec S/4HANA Public Cloud et sur la checklist d’intégration FSM, Sales Cloud et S/4HANA entrent dans les détails.

Ce que voit l’agent de service

Un agent qui jongle entre CRM, ERP et FSM pour répondre à une seule question commet des erreurs et prend trop de temps. Dans la configuration intégrée, l’agent voit dans Service Cloud V2 :

• Base installée : équipements, numéros de série et statut du contrat (depuis S/4HANA)
• Ordres de service : les ordres côté ERP liés au cas et leur statut (depuis S/4HANA)
• Contrats et offres de service : répliqués depuis S/4HANA
• Historique des cas : cas précédents, notes de résolution et délai de résolution (natif dans Service Cloud V2)

L’agent n’a pas besoin de travailler dans S/4HANA pour répondre au client. Pour les organisations où le service sur site et l’ERP appartiennent à des équipes différentes, c’est un vrai changement : l’agent en contact avec le client dispose du contexte sans attendre un collègue de la logistique.

Ce qui a fait ses preuves en projet

Garder la taxonomie des cas réduite. Un arbre de catégories à quarante branches au lancement signifie que les agents choisissent ce qui s’en rapproche le plus et que le reporting ne vaut plus rien. Notre règle : cinq à huit catégories au départ, puis affinage après trois mois sur la base des cas réels.

Connecter la téléphonie. Dans le service B2B, le téléphone reste le canal le plus fort. Une intégration CTI qui identifie l’appelant et affiche le contexte client pendant que le téléphone sonne encore fait gagner la première minute de chaque appel. Nous avons développé plusieurs adaptateurs CTI pour Service Cloud V2 ; voir comment fonctionne le screen pop natif dans l’agent desktop.

Laisser le modèle de statuts de l’ERP dans l’ERP. Le cas n’a pas besoin d’un double de chaque statut de document S/4HANA ; il a besoin de la réponse à la question du client : en cours, en route, terminé. Reproduisez chaque flux de documents et vous maintiendrez désormais deux modèles de statuts.

Maintenir les hiérarchies à un seul endroit. Les hiérarchies de produits et d’équipements ont un seul foyer, l’ERP, et sont répliquées depuis là. Deux hiérarchies maintenues à la main divergent ; la seule question est quand.

Modèles d’intégration clean core

Le principe clean core de SAP pour S/4HANA Public Cloud signifie aucune modification du code SAP. La même discipline s’applique à la couche d’intégration.

Copier, puis configurer. SAP maintient les iFlows standard et livre des mises à jour. Si vous modifiez directement un iFlow standard, vous perdez la possibilité d’appliquer proprement ces mises à jour. Copiez-le, faites votre modification dans la copie et documentez l’écart.

Logique spécifique sur BAIP. Des règles de routage par type d’équipement et région, ou des déclencheurs d’escalade par niveau de contrat, ont leur place dans une application CAP ou un iFlow spécifique sur SAP BAIP, pas dans les workflows de Service Cloud V2 ni dans les processus de service de S/4HANA. Notre guide des extensions clean core avec SAP CAP montre le modèle.

Une seule plateforme d’intégration. Tous les flux (données de base, du cas à l’ordre de service, FSM, statut de facturation) passent par le même tenant Integration Suite : une vue de monitoring, une file d’erreurs, une équipe responsable. Les appels point à point entre systèmes sont un problème de maintenance en devenir.

Alertes dès le premier jour. Les packages standard incluent la gestion des erreurs, mais quelqu’un doit décider qui est notifié quand un message échoue, quelle est la politique de relance et qui corrige quoi. Cette étape est souvent sautée dans les projets et devient une lacune au premier incident en production.

Ce que vous obtenez

Un cas traçable du premier appel jusqu’à la note de crédit. Un agent qui voit la garantie et le statut de livraison sans changer de système. Un client qui appelle une fois au lieu de trois. Et deux systèmes qui restent dans le standard, parce qu’aucun n’imite le travail de l’autre.

Si vous planifiez les deux côtés, il est utile d’avoir une seule équipe pour les deux moitiés ; c’est l’argument de notre guide pour choisir un partenaire SAP pour le Cloud ERP et le CRM en Suisse. Si S/4HANA Public Cloud est encore devant vous, l’évaluation de préparation S/4HANA clarifie d’abord le point de départ.

Questions fréquentes

Un cas dans SAP Service Cloud V2 peut-il créer un ordre de service dans S/4HANA Public Cloud ?

Oui. L’agent crée un ordre de service à partir du cas dans Service Cloud V2, et le package d’intégration standard de SAP le réplique vers S/4HANA, où sont gérés les pièces de rechange, les confirmations et la facturation. L’ordre de service S/4HANA est répliqué en retour avec son statut, de sorte que l’agent peut répondre au client depuis le cas sans ouvrir l’ERP.

Comment les données de la base installée circulent-elles entre S/4HANA et Service Cloud V2 ?

S/4HANA est le système maître. Le package de données de base de SAP réplique les équipements et les postes techniques de S/4HANA Public Cloud vers Service Cloud V2, où ils apparaissent comme produits enregistrés sur le compte client. L’agent voit le numéro de série, la date d’installation et le statut du contrat dans le cas, et la hiérarchie n’est jamais maintenue deux fois.

Quelle place pour SAP Field Service Management ?

FSM est la couche de planification et d’exécution mobile. Choisissez un seul déclencheur pour l’intervention sur site, en général l’ordre de service S/4HANA, et laissez FSM la planifier et l’exécuter. Le temps et le matériel confirmés par le technicien sont reportés sur l’ordre de service, qui déclenche ensuite la facturation dans S/4HANA.

Service Cloud V2 remplace-t-il un outil de ticketing séparé ?

Pour le service orienté client, oui : réception omnicanale, catégories de cas, SLA, base de connaissances et historique client sont inclus, et la connexion à l’ERP est le véritable avantage par rapport à un outil de ticketing générique. Pour le ticketing informatique interne, un outil dédié reste souvent le meilleur choix, car il s’agit d’un autre cas d’usage.

Quel effort est réaliste pour le flux du cas à la résolution ?

Cela dépend surtout des données de base. Si les comptes et les équipements sont déjà répliqués proprement, le flux du cas à l’ordre de service se compte en semaines, car les contenus d’intégration de SAP couvrent les flux de documents. Cela devient coûteux quand les données de base manquent ou qu’une logique de statut spécifique est intégrée dans l’un des systèmes.

---

Vos réclamations vivent dans une boîte de courriel partagée et votre équipe de service cherche le statut des livraisons dans l’ERP ? Nous vous présentons le flux avec vos propres processus de service. Parlez à notre équipe.