Déployer S/4HANA Public Cloud et Sales Cloud V2 ensemble : séquençage, délais, écueils

Faut-il implémenter S/4HANA Public Cloud et SAP Sales Cloud V2 en même temps ?

C’est l’une des questions les plus fréquentes que nous recevons des entreprises DACH qui modernisent leur paysage SAP. La réponse honnête : cela dépend du problème le plus urgent — et de la capacité de votre organisation à piloter les deux en parallèle.

Bien fait, un déploiement conjoint vous donne dès le premier jour un modèle de données partagé et propre : un enregistrement Business Partner, un catalogue produits, un flux de commandes. Mal fait, deux projets parallèles se disputent la même bande passante IT, les mêmes utilisateurs clés et la même attention au change management. Quelque chose se casse, ou les deux arrivent en retard.

Cet article présente les trois options de séquençage, à quoi ressemble un calendrier combiné réaliste, où les deux équipes de projet doivent rester synchronisées — et les écueils que nous avons vus plus d’une fois.

Faut-il implémenter S/4HANA Public Cloud et Sales Cloud V2 en même temps ?

Le point de départ est une évaluation honnête de vos contraintes.

Mener deux grandes implémentations SAP en parallèle est ambitieux. Les deux systèmes touchent vos processus métier fondamentaux. Les deux requièrent du temps des utilisateurs clés pour les ateliers, les tests et la formation. Les deux nécessitent un travail d’intégration sur BTP. Si votre équipe IT ou votre budget de conseil est limité, la séquentialisation est plus sûre.

Mais il y a un véritable argument pour la livraison parallèle. Le modèle Business Partner est partagé entre S/4HANA Public Cloud et SAP Sales Cloud V2. Si vous implémentez le CRM sans l’ERP en premier, vous construisez une intégration temporaire avec votre ERP existant — puis vous devrez en refaire des parties quand S/4HANA arrivera. C’est du retravail évitable avec un meilleur séquençage.

La bonne réponse dépend de trois facteurs : quel système est le plus urgent pour le business, quelle est votre capacité de change management, et si vous disposez d’un partenaire capable de tenir la couche d’intégration responsable sur les deux flux de travail.

Trois options de séquençage

ERP d’abord, puis CRM

C’est le choix par défaut le plus sûr. S/4HANA Public Cloud va en production en premier, établissant le modèle de données maîtres Business Partner, le catalogue produits et les processus financiers. Une fois l’ERP stable — typiquement 3 à 6 mois après le go-live — le projet Sales Cloud V2 démarre avec des données sources propres à intégrer.

Le compromis : votre équipe commerciale attend. Si la situation CRM est critique — processus manuels, données dans des tableurs, aucune visibilité sur le pipeline — attendre 9 à 12 mois pour un meilleur outil de vente est douloureux.

Ce que cette option vous apporte : Sales Cloud V2 démarre avec de vraies données ERP dès le premier jour. Pas de connecteurs temporaires à retirer ensuite. Pas de migration de données depuis un état CRM intermédiaire. Le travail d’intégration est fait une seule fois, correctement.

CX d’abord, puis ERP

Moins courant, mais pertinent quand le processus commercial est le point de douleur principal et que l’ERP est assez stable pour être laissé en l’état pour l’instant.

SAP Sales Cloud V2 va en production contre l’ERP existant — qu’il s’agisse d’ECC, de S/4HANA on-premise ou d’autre chose. L’intégration est construite pour cet ERP. Quand S/4HANA Public Cloud arrive, l’intégration est reconstruite contre les nouveaux endpoints ERP.

Le compromis : vous acceptez un double travail d’intégration. La première intégration est abandonnée quand l’ERP change. C’est un coût et un retravail réels — mais si la priorité est d’apporter un CRM moderne à l’équipe commerciale dans le prochain trimestre, cela peut être le bon choix.

Un risque à signaler : si votre ERP existant a des données maîtres désordonnées — enregistrements Business Partner incohérents, comptes en doublon, prix obsolètes — vous importerez ce désordre dans Sales Cloud. Puis vous le nettoierez à nouveau avant la migration S/4HANA. Mieux vaut nettoyer une seule fois, dans la migration ERP, et démarrer Sales Cloud proprement.

Livraison parallèle

Les deux projets se déroulent simultanément avec un flux de travail d’intégration partagé. Cela comprime le calendrier global mais ajoute une surcharge de coordination significative.

Pour que cela fonctionne, il vous faut : un responsable de programme dédié qui gère les dépendances cross-stream, un propriétaire clair de l’intégration sur BTP, et un steering commun capable de résoudre les conflits de priorité quand les deux projets réclament les mêmes utilisateurs clés au même moment.

Nous avons vu la livraison parallèle bien fonctionner quand les deux flux de travail sont réellement séparés en termes d’équipe et de périmètre — l’équipe ERP gère la finance et la logistique, l’équipe CX gère le processus commercial — et ne doivent converger que sur la couche d’intégration et la gouvernance des données maîtres. Là où ça échoue : quand les mêmes trois personnes sont attendues comme utilisateurs clés sur les deux projets simultanément.

Un calendrier combiné réaliste

Ce sont des estimations séparées, pas un chiffre combiné unique.

Les implémentations greenfield de S/4HANA Public Cloud pour les PME avec un périmètre de processus standard — pas de personnalisation lourde, processus standard — durent typiquement de 6 à 9 mois du lancement au go-live. C’est la plage documentée pour les déploiements greenfield standard. Un périmètre complexe, multi-pays ou une migration de données significative prolongent ce délai.

Les implémentations SAP Sales Cloud V2 pour le marché intermédiaire — typiquement 50 à 200 utilisateurs, un pays, processus CRM standard — nécessitent de 10 à 16 semaines. Notre médiane sur les projets Sales Cloud V2 complétés est de 14 semaines du lancement au go-live. Les équipes plus petites avec un périmètre plus serré arrivent plus vite. Les déploiements enterprise avec des intégrations ERP complexes prennent plus de temps.

Pour un programme combiné ERP-d’abord : l’ERP est en production entre le mois 6 et le mois 9, le CX démarre 1 à 2 mois avant le go-live ERP (en commençant la conception de l’intégration tôt), et Sales Cloud V2 passe en production aux alentours du mois 10 à 15. C’est la plage réaliste de bout en bout pour un déploiement séquentiel.

La livraison parallèle raccourcit le programme global — les deux systèmes peuvent viser le même trimestre — mais pas autant que les gens l’espèrent. La couche d’intégration doit quand même être construite, testée et stabilisée, que les deux projets se déroulent en séquence ou en parallèle.

Pour un guide détaillé du côté CX, notre guide d’implémentation SAP Sales Cloud V2 couvre les phases complètes du projet, la structure d’équipe et la répartition des coûts.

Où les deux équipes de projet doivent se synchroniser

Même dans un déploiement séquentiel, les deux équipes ne peuvent pas opérer en isolation complète. Il y a quatre domaines où elles doivent se coordonner.

Modèle Business Partner et gouvernance des données maîtres. Le projet S/4HANA définit la structure de l’enregistrement Business Partner — champs, segments, rôles. Sales Cloud V2 consomme cette structure. Si l’équipe CX n’est pas présente lors des ateliers sur les données maîtres ERP, elle découvrira au moment de l’intégration que les champs dont elle a besoin n’existent pas ou ont des noms différents. Solution : inclure un représentant CX dans chaque atelier sur les données maîtres ERP.

Catalogue produits et tarification. Sales Cloud V2 récupère les prix depuis S/4HANA. L’équipe de projet ERP doit finaliser les types de condition et la structure du catalogue avant que l’intégration CX puisse être construite. Une erreur fréquente : l’équipe ERP verrouille le modèle de tarification deux mois après que l’intégration CX a déjà été conçue pour une structure différente.

Gestion des utilisateurs et autorisations. Les deux systèmes utiliseront le même fournisseur d’identité, typiquement SAP Identity Authentication Service. Le provisionnement des utilisateurs, l’attribution des rôles et le SSO doivent être conçus une seule fois et fonctionner pour les deux systèmes. N’autorisez pas chaque projet à résoudre cela indépendamment.

Calendrier du change management. Les utilisateurs clés ne peuvent pas suivre la formation S/4HANA au mois 7 et la formation Sales Cloud V2 au mois 8 sans s’épuiser. Séquencez délibérément les programmes de formation, avec suffisamment d’espace entre les go-live pour que les utilisateurs se stabilisent sur le premier système avant d’apprendre le second.

Les écueils que nous avons vus — et comment les éviter

Deux comités de pilotage sans voie d’escalade commune. Le projet ERP a son propre comité. Le projet CX a le sien. Quand une décision cross-stream doit être prise — qui est responsable du tenant BTP d’intégration ? qui finance le middleware partagé ? — il n’existe pas de forum pour le faire. La décision reste bloquée pendant des semaines. Solution : établir dès le premier jour un steering de programme commun, même s’il ne se réunit qu’une fois par mois.

Périmètre d’intégration défini trop tard. Les deux projets supposent que l’autre équipe gérera l’intégration. Six semaines avant le go-live, personne n’a commencé à construire le flux de commandes de Sales Cloud vers S/4HANA. Solution : le périmètre de l’intégration, les responsabilités et le budget doivent être convenus avant que l’un ou l’autre projet n’entre en phase Realize.

Données ERP sales importées dans Sales Cloud. La migration des données ERP nettoie les enregistrements clients. Mais l’intégration CRM est construite à partir des anciennes données ERP, pas des données nettoyées, parce que les calendriers ne sont pas alignés. Sales Cloud part en production avec 14’000 comptes en doublon. Solution : la migration des données CRM doit puiser dans l’état ERP post-nettoyage, ce qui signifie séquencer le nettoyage des données avant le go-live CRM, pas en parallèle.

Fatigue du changement. Les utilisateurs de la finance absorbent un nouvel ERP. Deux mois plus tard, la même organisation est invitée à adopter un nouveau CRM. L’adoption souffre des deux côtés. Solution : élaborer un plan réaliste de capacité de change management avant de valider le calendrier du programme. La stack intégrée S/4HANA Public Cloud et Sales Cloud V2 ne vaut rien si les utilisateurs retournent aux tableurs.

Empreinte BTP sous-estimée. Les deux projets utiliseront BTP — Integration Suite, Identity Authentication, peut-être Build. Si chaque projet acquiert ses propres instances BTP, vous vous retrouvez avec des tenants dupliqués, des coûts doublés et une architecture d’intégration qui ne peut pas partager de composants. Solution : définir la stratégie BTP comme une décision de programme, pas de projet.

L’intégration technique entre SAP S/4HANA Public Cloud et Sales Cloud V2 est bien documentée et réalisable. La partie difficile n’est pas la technologie. C’est de piloter deux grands programmes de changement dans la même organisation, avec les mêmes personnes, sans que l’un n’érode l’autre.

Un séquençage juste, une responsabilité claire sur la couche d’intégration, et suffisamment de temps pour que votre organisation absorbe chaque système avant que le suivant n’arrive : voilà ce qui distingue un déploiement combiné propre d’un long et coûteux projet de rattrapage.

Vous voulez discuter du séquençage pour votre situation spécifique ? Contactez-nous — pas de présentation commerciale, juste une conversation.