Pourquoi nous terminons les projets SAP CX quand d'autres échouent

Les projets SAP CX échouent rarement à cause du logiciel. Ils s’enlisent parce que le périmètre était flou, parce que ceux qui ont vendu le projet n’étaient pas ceux qui l’ont réalisé, et parce que l’intégration ERP a été repoussée aux dernières semaines. On nous appelle régulièrement sur ce type de projets, et les remèdes sont moins spectaculaires qu’on ne l’imagine : les mêmes personnes expérimentées du premier atelier à la mise en production, un périmètre rédigé sous forme de livrables, le travail d’intégration dès la première semaine et la discipline de dire non.

En bref : Quatre habitudes mènent nos projets en production : des personnes expérimentées qui cadrent et réalisent, un périmètre fait de livrables vérifiables, l’intégration ERP et des données réelles dès les premiers sprints, et le refus des projets que nous ne pouvons pas livrer tels que demandés. Les preuves sont publiques : le projet V2 bloqué d’OPO Oeschger était en production trois mois après notre reprise, dans les délais et dans le budget.

À quoi ressemblent les preuves

Nous préférons montrer des projets plutôt que citer un taux de réussite. Ceux-ci sont publiés avec l’accord des clients :

• OPO Oeschger : un projet Sales et Service Cloud V2 bloqué chez un autre partenaire. Nous l’avons relancé de zéro : le MVP fonctionnait après deux mois, la phase 1 complète était en production après trois, dans les délais et dans le budget, connectée à S/4HANA, Datasphere et Commerce Cloud.
• Franke : un projet Commerce à l’arrêt. Spadoom a mis en production la plateforme SAP Commerce Cloud en 90 jours, et le projet a reçu le SAP Quality Award « Rapid Time to Value ».
• Nussbaum : Sales Cloud V2 créé de zéro, d’aucun CRM central à une visibilité complète du pipeline en cinq mois.
• intelligentfood : Sales et Service Cloud V2 en production en trois mois, connectés à l’ERP.

Cela ne veut pas dire que chaque projet est simple. Cela veut dire que les pratiques ci-dessous fonctionnent assez souvent pour que nous ne menions plus nos projets autrement.

Des personnes expérimentées dès le premier jour

Le schéma le plus fréquent dans les projets que nous reprenons est un passage de relais. Une équipe expérimentée remporte le contrat puis passe à la présentation suivante, et ceux qui arrivent pour la réalisation découvrent les exigences. Personne ne le fait exprès. C’est ainsi que beaucoup de grandes sociétés composent leurs équipes.

Chez nous, il n’y a pas d’équipe de vente séparée de l’équipe de réalisation. Ceux qui cadrent votre projet le réalisent, et ils ont déjà livré des projets V2. Chez OPO Oeschger, cela a voulu dire que l’équipe qui a analysé le projet bloqué l’a aussi reconstruit, sans deuxième courbe d’apprentissage.

Un périmètre fait de livrables

« Mettre en place le CRM » n’est pas un périmètre. « Configurer la gestion des opportunités avec quatre étapes spécifiques, un pipeline pondéré et des notifications automatiques » en est un. La différence entre ces deux phrases est celle entre un projet qui passe en production et un projet qui s’enlise dans des mois de renégociation.

Chaque projet reçoit un document de périmètre avec livrables et critères d’acceptation. Il protège les deux parties. Quand une nouvelle exigence apparaît, nous ne la refusons pas : nous disons ce qu’elle coûte et ce qu’elle change au calendrier, et vous décidez avant que le travail commence.

Intégration et données réelles dès le début

La plupart des mauvaises surprises tardives viennent de la frontière avec l’ERP : un prix que le devis ne parvient pas à déterminer, une commande qui ne se comptabilise pas, des données clients qui ne concordent pas. C’est pourquoi nous concevons l’intégration avant le premier écran et chargeons des données réelles dans un système de test dès les premières semaines. Un problème qui apparaît à la quatrième semaine coûte peu. Un problème qui apparaît au sixième mois est déjà intégré à tout le reste.

C’est aussi là qu’une seule équipe pour l’ERP et le CX fait la différence. Comme nous livrons S/4HANA Public Cloud autant que Sales Cloud V2, l’interface entre les deux est une décision de conception au sein d’un projet, et non une négociation entre deux prestataires. Nous décrivons l’architecture dans S/4HANA Public Cloud et Sales Cloud V2 comme un seul stack.

Une réalisation itérative aux progrès visibles

Nous travaillons par courtes itérations selon SAP Activate :

• Premières semaines : confirmer exigences et intégrations, mettre en place les systèmes, charger les données de test.
• Premiers sprints : les utilisateurs clés voient un système qui fonctionne avec leurs propres données.
• Toutes les deux semaines : une démonstration avec les utilisateurs clés, qui testent et donnent leur avis, et nous ajustons.
• Avant la mise en production : tests d’intégration, contrôles de migration, tests d’acceptation et préparation de la bascule.

Le nom de la méthode importe peu. Ce qui compte, c’est que les problèmes deviennent visibles tant qu’ils sont encore petits.

Savoir dire non

Cela nous coûte des contrats, et c’est sans doute l’habitude la plus importante. Si un prospect veut Sales Cloud V2, Service Cloud V2, Commerce Cloud, SAP Engagement Cloud et CDP dans un seul projet de six mois avec une équipe de quatre personnes, nous disons que ce n’est pas réaliste et proposons un enchaînement qui l’est. Si une entreprise veut reconstruire dans le cloud, champ par champ, son CRM vieux de quinze ans, nous expliquons pourquoi c’est le mauvais objectif. Une première phase plus modeste qui passe en production vaut mieux qu’une grande qui n’y arrive pas.

Ce que nous voyons dans les projets repris

Dans les projets qui nous arrivent après s’être enlisés ailleurs, on retrouve toujours les cinq mêmes problèmes :

• Un périmètre flou qui a grossi sans ajustement du budget.
• Du code spécifique là où la configuration standard aurait suffi.
• Aucun test d’intégration avant les dernières semaines.
• Aucune implication des utilisateurs jusqu’aux tests d’acceptation, quand l’équipe commerciale a rejeté le système.
• Une mise en production big bang sans plan de repli.

Les cinq sont évitables, et aucun n’est un problème technologique. Si vous évaluez des partenaires, notre guide comment choisir un partenaire SAP CX transforme ces schémas en questions à poser dès le premier rendez-vous. Les raisons des dépassements de budget sont traitées dans pourquoi les projets SAP CX dépassent leur budget.

Questions fréquentes

Tous vos projets passent-ils en production à la date prévue ?

Nous ne publions pas de pourcentage global, car un chiffre unique cache plus qu’il ne montre. Nous publions des projets nommés avec leurs délais, dont OPO Oeschger, Franke, Nussbaum et intelligentfood. Demandez-nous des références sur votre produit et appelez-les.

Comment gérez-vous les exigences qui changent ?

Avec un périmètre écrit et un processus de modification transparent. Chaque modification est estimée et approuvée avant le début du travail. Si une modification devait décaler la mise en production, nous le signalons tôt et vous décidez d’ajuster le calendrier ou le périmètre.

Pouvez-vous reprendre un projet SAP bloqué ?

Oui. C’est ainsi qu’ont commencé les projets OPO Oeschger et Franke. Nous commençons par une brève analyse de l’existant, décidons avec vous ce qui est conservé et ce qui est reconstruit, et fixons un nouveau plan avec des personnes nommées. Nous ne rafistolons pas un vieil échafaudage si un redémarrage propre est plus rapide.

Où travaillez-vous ?

Depuis Zoug, Zurich, Monza et Tallinn, avec des projets surtout en Suisse, en Allemagne, en Autriche et en Italie. Nous avons accompagné des déploiements internationaux pour des entreprises dont le siège est en Europe. Nos consultants travaillent en allemand, français, italien et anglais.

Comment vérifier vos résultats ?

Lisez nos témoignages clients et demandez-nous des références sur le produit que vous achetez. Posez directement la question à la référence : le projet est-il passé en production comme prévu, le budget a-t-il tenu, les mêmes personnes sont-elles restées jusqu’au bout ? Si vous préparez aussi un passage ERP, commencez par notre évaluation de préparation S/4HANA ou contactez-nous.