Migration vers SAP Service Cloud V2 : un guide pratique

SAP Service Cloud V2 n’est pas une mise à jour. C’est une refonte architecturale. Complète. V2 a été construit nativement sur SAP BTP et SAP HANA Cloud, remplaçant entièrement la plateforme C4C par une base technique fondamentalement différente.

Ceux qui considèrent cela comme « V1 plus quelques nouvelles fonctionnalités » vont rencontrer des problèmes en migration. Soyons francs : traitez-le pour ce qu’il est. Un nouveau produit.

Pour les organisations actuellement sur Service Cloud V1 (C4C), le parcours de migration nécessite une planification minutieuse. Ce guide explique ce à quoi vous devez concrètement vous attendre.

Ce qui change dans V2

Plateforme technique. V2 fonctionne sur SAP BTP (Business Technology Platform) plutôt que sur le stack cloud C4C. Cela apporte une meilleure intégration avec les autres services BTP. Mais la configuration, l’extensibilité et les API fonctionnent différemment. Complètement différemment.

Modèle de données. Le modèle de données sous-jacent a été entièrement refondu. Les champs personnalisés, extensions et intégrations construits sur les API C4C ne migrent pas automatiquement. Ils doivent être reconstruits dans le modèle V2. Pas de copier-coller. Pas de lift-and-shift. Une reconstruction.

Interface utilisateur. L’interface utilisateur final est entièrement nouvelle. V2 utilise une UI moderne et basée sur les rôles dans laquelle SAP continuera d’investir. L’interface de style Fiori de C4C est abandonnée. Prima vista, V2 a un autre aspect, se comporte différemment, se navigue autrement.

Extensibilité. C4C utilisait des outils key-user et des extensions basées sur le SDK. L’extensibilité de V2 passe par les services SAP BTP — plus puissante, oui. Mais elle nécessite des compétences différentes. Votre équipe a besoin de connaissances BTP, pas de connaissances C4C.

Ce qui reste identique

Les concepts fondamentaux du service. Tickets, comptes, contacts, niveaux de service, base de connaissances. Tout cela est préservé. Si votre équipe comprend la gestion de service, elle s’adaptera à V2. Les concepts sont les mêmes, les outils sont nouveaux.

Le paradigme d’intégration est également similaire : V2 expose des API REST/OData pour l’intégration avec l’ERP, le commerce et les systèmes externes. Les endpoints spécifiques changent, mais les principes architecturaux restent les mêmes.

Approche de migration

Étape 1 : Évaluation. Cataloguez toutes les configurations actives, intégrations, extensions personnalisées et rapports dans C4C. Pour chaque élément, déterminez s’il est nécessaire dans V2 et, le cas échéant, comment l’implémenter. Cela semble trivial. Ce ne l’est pas. Cette phase détermine le succès du projet.

Étape 2 : Reconception des intégrations. La plupart des intégrations C4C devront être reconstruites. Saisissez cette opportunité pour simplifier lorsque c’est possible. Les connecteurs natifs de V2 vers S/4HANA et SAP Commerce Cloud sont nettement meilleurs que leurs équivalents C4C. Qui fait le ménage ici correctement s’épargne des semaines plus tard.

Étape 3 : Configuration dans V2. Construisez l’environnement V2 en parallèle du système C4C en production. N’essayez pas une migration directe des données de configuration. Cela ne fonctionne pas et ne génère que de la frustration.

Étape 4 : Migration des données. Migrez les données historiques de tickets et de clients en utilisant les outils de migration SAP. Définissez une stratégie de bascule claire. La migration delta est une obligation, pas un luxe.

Étape 5 : Formation et gestion du changement. Le changement d’interface à lui seul nécessite un programme de formation. Planifiez-le. De facto, l’adoption par les utilisateurs est systématiquement le défi le plus sous-estimé dans les migrations V2. La technique, on peut toujours la corriger. Les gens, il faut les embarquer.

Attentes de calendrier

Une migration typique de Service Cloud V2 pour une organisation de taille moyenne (50 à 200 agents de service, complexité d’intégration modérée) prend 6 à 10 mois du lancement du projet à la mise en production. Pour un aperçu complet de SAP Service Cloud V2, consultez notre page solution SAP Service Cloud V2.

Les organisations qui traitent V2 comme un « lift and shift » rencontrent systématiquement des problèmes dans les phases finales. Traitez-le comme une nouvelle implémentation dont la migration est l’un des flux de travail. Pas l’inverse.

Spadoom a réalisé plusieurs migrations Service Cloud V2. Contactez-nous pour discuter de votre situation.