Case-to-Resolution : connecter SAP Service Cloud V2 avec S/4HANA Public Cloud

Une livraison arrive cabossée chez le client. L’appel tombe au service, l’e-mail avec photos suit une heure plus tard, et à partir de là commence dans beaucoup d’entreprises une errance : la réclamation vit dans la boîte mail partagée, la commande de remplacement dans une liste Excel, l’avoir quelque part en comptabilité. Le client appelle trois fois pour savoir où en est son dossier, et reçoit trois réponses différentes. C’est exactement ce flux que nous avons reconstruit chez un fabricant B2B : ticket dans SAP Service Cloud V2, exécution dans S/4HANA Public Cloud, statut de retour dans le ticket. Cet article montre à quoi ressemble la connexion quand elle est faite proprement, et quelles règles du jeu ont fait leurs preuves dans le projet.

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

L’architecture commence par une répartition délibérée des tâches. Le ticket vit dans Service Cloud V2. C’est là que tous les canaux convergent : e-mail, téléphone, portail client, tout devient le même objet, le case. C’est là aussi que se trouvent les catégories de tickets, les accords de niveau de service avec leurs délais et escalades, et toute la communication avec le client. L’agent voit d’un coup d’oeil qui demande, ce qui s’est déjà passé et combien de temps il reste avant la violation du SLA.

L’exécution vit dans S/4HANA. Ordre de service, retour, logistique des pièces de rechange, confirmation, facture ou avoir : autant de documents avec la gestion des stocks, la comptabilité analytique et la comptabilité financière derrière. Un CRM ne sait pas faire ces choses, et il ne doit pas essayer. Qui reconstruit les niveaux de stock ou la facturation dans le CRM construit un deuxième ERP, en moins bien.

Deux systèmes, deux rôles. L’intégration les relie, elle ne les mélange pas.

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

L’erreur la plus fréquente dans ces projets, c’est l’ordre des choses. Tout le monde veut construire tout de suite le flux de processus, créer l’ordre de service depuis le ticket, voir le statut revenir. Sauf que : sans données de base synchronisées, rien de tout cela ne tourne. Avant qu’un document circule, deux choses doivent être en place.

D’abord les clients. Les comptes dans Service Cloud V2 et les partenaires dans S/4HANA doivent être les mêmes, avec un mapping d’identifiants propre via la réplication standard. Ensuite les produits enregistrés, l’équipement en langage ERP. L’agent doit voir dans le ticket quelle machine, quel appareil, quelle installation se trouve chez le client, avec numéro de série et date d’installation.

C’est seulement alors que le ticket devient intelligent : le contrôle de garantie et de droits tourne contre les données S/4. L’appareil est-il encore sous garantie ? Y a-t-il un contrat de service ? Sans cette connexion, l’agent devine ou va chercher dans l’ERP, et les deux coûtent des minutes sur chaque dossier. L’intégration des données de base n’a rien de spectaculaire, mais c’est la fondation. De facto, elle décide si l’intégration de processus qui suit prend des semaines ou des mois.

Le flux propre : du ticket à la résolution

Voici à quoi ressemble le case-to-resolution quand chaque système joue son rôle :

1. Le ticket naît dans Service Cloud V2, quel que soit le canal. Appel, e-mail, entrée portail : tout atterrit dans le même case, relié au client et au produit enregistré.
2. L’agent catégorise et vérifie. Poser la catégorie, contrôler garantie et droits contre les données S/4, le chrono SLA démarre maintenant.
3. Le document consécutif naît dans S/4HANA. Depuis le ticket, la bonne transaction est déclenchée : ordre de service, retour ou demande d’avoir, selon le scénario.
4. S/4HANA exécute. Préparer la pièce de rechange, confirmer l’intervention du technicien, facturer ou créditer. L’ERP mène, comme toujours.
5. Le statut revient dans le ticket. L’agent voit dans le case que la livraison de remplacement est partie ou que l’avoir est comptabilisé, et informe le client depuis là.

Le dernier point est le plus important : la communication client reste entièrement dans le CRM. Le client a un point de contact, un fil, un historique. Ce qui se passe dans l’ERP, il ne le voit jamais directement, il l’apprend via le ticket.

Notre scénario d’exemple, la livraison cabossée, se déroule alors ainsi : l’appel arrive, le ticket est créé avec la catégorie dommage de transport, les photos s’attachent au même case par e-mail. L’agent vérifie la livraison dans le document S/4 lié, déclenche le retour et la livraison de remplacement, plus la demande d’avoir dans la foulée. Dès que S/4 confirme le remplacement, l’information part au client depuis le ticket. Un dossier, un numéro, pas de recherche.

Ce qui a fait ses preuves dans le projet

Garder la taxonomie des tickets petite. La tentation est réelle : construire pour le go-live un arbre de catégories à quarante branches, une pour chaque cas imaginable. Résultat : les agents choisissent n’importe quoi, et le reporting perd toute valeur. Notre règle : cinq à huit catégories au départ, puis affiner après trois mois sur la base des vrais dossiers. Les données montrent elles-mêmes où il faut des branches plus fines.

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 à l’agent pendant que le téléphone sonne encore économise la première minute de chaque appel, plus la pénible question du numéro client. Nous avons construit de tels adaptateurs CTI pour Service Cloud V2 à plusieurs reprises ; l’effort est raisonnable, l’effet au quotidien est grand.

Et ce qu’il vaut mieux laisser : premièrement, reconstruire la logique de statuts de l’ERP dans le CRM. Le ticket n’a pas besoin d’un jumeau de chaque statut de document S/4, il a besoin de la réponse à la question du client : en cours, en route, terminé. Qui reflète chaque flux de documents entretient dès lors deux modèles de statuts. Deuxièmement, maintenir les hiérarchies de produits en double. La hiérarchie a un seul domicile, l’ERP, et se réplique depuis là. Deux hiérarchies maintenues à la main divergeront, c’est garanti, la seule question est quand.

Ce que vous obtenez au final

Un dossier traçable du premier appel jusqu’à l’avoir. Un agent qui voit garantie et 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.

Questions fréquentes

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

Pour le service orienté client : oui. Réception omnicanale, catégories de tickets, SLA, base de connaissances et historique client sont à bord, et la connexion ERP est le vrai avantage face à un outil de ticketing générique. Pour le ticketing IT interne, un outil dédié reste souvent le meilleur choix ; c’est un autre cas d’usage.

Les techniciens de terrain peuvent-ils travailler avec ?

Oui, pour des interventions simples, directement avec le ticket et l’ordre de service S/4. Quand la planification devient exigeante, avec équipes, compétences et optimisation des tournées, SAP Field Service Management est le bon complément : le ticket reste dans Service Cloud V2, la planification tourne dans FSM. Le pont entre les deux est standard.

Quel effort est réaliste ?

Si l’intégration des données de base est en place, c’est-à-dire que comptes et équipements se répliquent déjà, on parle de semaines pour le flux case-to-resolution, pas de mois. L’intégration standard via SAP Integration Suite couvre les flux de documents. Cela ne devient cher que si les données de base manquent ou si quelqu’un construit des exceptions maison dans la logique de statuts.

Vos réclamations vivent dans une boîte mail partagée et votre équipe de service cherche les statuts de livraison dans l’ERP ? Nous vous montrons volontiers le flux en direct, avec vos processus de service. Parlez-nous.