Pourquoi les projets SAP CX dépassent leur budget (et comment y remédier)

Les projets SAP CX dépassent rarement leur budget à cause du logiciel. Ils le dépassent à cause de la façon dont ils sont délimités, staffés, planifiés et intégrés, et la plupart de ces causes sont visibles avant la signature du contrat.

Ce n’est pas un problème propre au CX. BCG a interrogé plus de 1’000 entreprises : pour plus de deux tiers des grands programmes technologiques, une livraison dans les délais, le budget ou le périmètre prévu n’est pas attendue (BCG, 2024). Les schémas derrière ce chiffre sont ceux que je vois dans les projets SAP CX.

En bref : les projets SAP CX dépassent leur budget pour cinq raisons prévisibles : un périmètre jamais vraiment défini, trop de consultants juniors, une planification en cascade pour un logiciel cloud, une intégration ERP sous-estimée et une gestion du changement reléguée à la fin. Un modèle tarifaire qui récompense les retards aggrave les cinq. La checklist en sept points à la fin de cet article vous permet de vérifier l’offre d’un partenaire sur chacune d’elles avant de signer.

Raison 1 : le périmètre n’a jamais été vraiment défini

Il ne s’agit pas de dérive du périmètre, mais de brouillard. Le périmètre n’a jamais été assez clair pour pouvoir dériver.

Beaucoup de projets démarrent avec un cahier des charges de 40 pages qui ressemble à une liste de souhaits. « Le système doit prendre en charge tous les processus de vente actuels. » Qu’est-ce que cela signifie ? Personne n’est d’accord. Le partenaire chiffre selon son interprétation, le client attend autre chose, et au bout de trois mois l’écart devient visible. Et coûteux.

Ce qui fonctionne : définissez le périmètre au niveau des processus, pas des fonctionnalités. « Configurer la conversion des leads en opportunités avec attribution automatique des territoires pour les marchés DACH, y compris un circuit d’approbation pour les affaires de plus de CHF 50’000. » Voilà un élément de périmètre. « Prendre en charge les processus de vente » n’en est pas un. Atteindre cette précision avant qu’un partenaire ne chiffre quoi que ce soit, c’est le rôle du conseil métier avant l’implémentation SAP.

Chez Spadoom, les projets commencent par un atelier de cadrage qui aboutit à une liste fixe de livrables. Ce qui n’y figure pas ne fait pas partie du projet ; si le client veut ajouter quelque chose, c’est chiffré séparément. Le projet Nussbaum montre à quoi ressemble cette discipline en pratique : d’abord le pipeline, le reste ensuite.

Raison 2 : trop de consultants juniors

C’est le secret de Polichinelle des grands cabinets de conseil : ils vendent le projet avec des architectes seniors dans la salle, puis le confient à des consultants qui ont 18 mois d’expérience et apprennent SAP Sales Cloud V2 sur votre budget.

Une tâche qui prend deux jours à un senior peut en coûter cinq à un junior, plus deux autres pour corriger ce qui n’allait pas. Les juniors construisent des contournements au lieu d’utiliser la configuration standard et prennent des décisions d’architecture qui ne se révèlent problématiques qu’en phase de test. À ce moment, vous êtes à trois mois de projet et personne ne veut repartir de zéro. Le tarif journalier « avantageux » finit par coûter plus cher.

Ce qui fonctionne : demandez à votre partenaire qui, exactement, travaillera sur votre projet. Exigez des noms, des CV et des certifications SAP. Demandez combien de projets V2 ces personnes ont menés à terme (pas V1 : l’architecture est différente). Si la réponse est vague, c’est votre réponse. La liste complète des questions figure dans notre guide pour choisir un partenaire d’implémentation SAP CX.

Nous nommons l’équipe dans notre offre, et les personnes que vous rencontrez en atelier sont celles qui configurent votre système.

Raison 3 : une planification en cascade dans un monde cloud

Les produits SAP CX sont des logiciels cloud avec des versions régulières. Configurés, pas développés de zéro. Pourtant, de nombreux projets sont encore planifiés en phases rigides : trois mois de conception, trois mois de réalisation, un mois de tests, mise en production d’un seul coup.

Quand la conception est terminée, la plateforme a reçu de nouvelles versions et les exigences ont évolué. Les utilisateurs ne voient rien de fonctionnel avant le sixième mois. Quand c’est enfin le cas, les retours arrivent sous forme d’avalanche de demandes de modification.

Ce n’est pas une dérive du périmètre. C’est un problème de méthode.

Ce qui fonctionne : SAP Activate, la méthodologie d’implémentation de SAP elle-même, existe pour une bonne raison. Livraison itérative, un système fonctionnel tôt, des retours utilisateurs toutes les deux semaines et des corrections de trajectoire tant qu’elles coûtent peu.

Nous travaillons généralement en sprints de deux semaines avec une démonstration à la fin de chacun ; les problèmes apparaissent ainsi tôt, quand le budget peut encore les absorber.

Raison 4 : l’intégration ERP est sous-estimée

« Il suffit de le connecter à notre ERP. » Peu de phrases ont coûté plus cher aux projets SAP.

Connecter SAP Sales Cloud V2 à SAP S/4HANA signifie mettre en correspondance des modèles de données, synchroniser les données de base, résoudre les conflits, gérer des fréquences de mise à jour différentes et prévoir la gestion des erreurs pour la nuit où le middleware s’arrête. S’y ajoute le middleware lui-même, généralement SAP Integration Suite, avec sa propre conception, sa propre surveillance et des personnes qui le maîtrisent.

Les projets CX échouent rarement dans le CRM. Ils échouent à la jonction avec l’ERP : la commande qui ne se comptabilise pas, le prix que l’offre ne trouve pas, le client qui existe deux fois. Quand le partenaire CX et le partenaire ERP sont deux entreprises différentes, cette jonction devient une ligne dans deux contrats dont personne n’est responsable. Spadoom livre le cœur ERP et la pile CX avec une seule équipe ; c’est pourquoi nous traitons cette jonction comme une partie du projet et non comme l’interface de quelqu’un d’autre. Nous expliquons la différence dans le meilleur partenaire SAP pour Cloud ERP et CRM en Suisse.

Ce qui fonctionne : budgétez l’intégration séparément. Pas comme une ligne parmi d’autres, mais comme un chantier à part entière, avec son propre calendrier et sa propre phase de test. Chaque interface reçoit une conception technique avant le début de la configuration et est testée isolément avant les tests d’intégration système. Notre article sur l’architecture d’intégration entre Sales Cloud V2 et S/4HANA Public Cloud montre ce que couvre une telle conception.

Raison 5 : la gestion du changement arrive en dernier

Vous pouvez construire la SAP Sales Cloud V2 la mieux configurée du monde. Si votre équipe de vente ne l’utilise pas, chaque franc est perdu. Le schéma est connu : un système propre, peu de connexions et, trois mois après la mise en production, les commerciaux sont revenus à leurs tableaux parce que personne n’a investi pour qu’ils se sentent à l’aise avec le nouvel outil.

Une bonne partie de ce qui apparaît comme un dépassement de budget, ce sont des coûts cachés après la mise en production : gestion de crise parce que les utilisateurs rejettent le système, le contournent ou submergent le support. Le projet était « terminé ». Le travail, non.

Ce qui fonctionne : intégrez dès le premier jour la formation des utilisateurs finaux, les ateliers pour les key users et le suivi de l’adoption dans le périmètre du projet, comme un vrai chantier avec son propre budget et non comme ce qui reste à la fin.

Le problème du modèle tarifaire

Au-dessus de ces cinq causes s’en trouve une structurelle : les contrats en régie (time and materials).

En régie, le partenaire gagne davantage quand le projet dure plus longtemps. Nous ne prétendons pas que quiconque ralentisse volontairement, mais ce modèle supprime la pression à être efficace, et le risque de chaque erreur d’estimation reste chez vous.

Les contrats au forfait sur un périmètre fixe inversent les incitations : les dépassements pèsent sur la marge du partenaire, pas sur votre budget. Ils ne fonctionnent toutefois que si le périmètre est assez bien défini pour être chiffré, ce qui nous ramène à la raison 1. Lorsque le périmètre le permet, nous proposons un forfait ; notre évaluation de préparation S/4HANA de cinq jours, par exemple, a un prix fixe qui est déduit de la transformation si vous poursuivez.

Une checklist budgétaire pratique

Avant de signer votre prochain contrat SAP CX, vérifiez ces sept points :

1. Le périmètre est détaillé. Chaque livrable est décrit au niveau des processus, avec des critères d’acceptation.
2. L’équipe est nommée. Vous savez qui travaille sur votre projet et avec quelle expérience.
3. La méthode est itérative. Vous voyez un logiciel fonctionnel dès le premier mois.
4. L’intégration est cadrée séparément. Avec son propre calendrier et son propre plan de test.
5. La gestion du changement est budgétée. Formation, documentation et accompagnement de l’adoption sont inclus dès le départ.
6. Le prix porte sur un périmètre fixe. Ou au moins un plafond, avec une procédure claire pour les demandes de modification.
7. Les références sont réelles. Vous pouvez parler à des clients qui ont mené à terme des projets similaires.

Si un partenaire résiste sur l’un de ces points, cela vous apprend quelque chose.

L’essentiel

Les projets SAP CX ne dépassent pas leur budget à cause de SAP. Ils le dépassent à cause de la façon dont ils sont planifiés, staffés et pilotés.

Les entreprises qui réussissent traitent l’implémentation comme un projet métier, pas comme un projet informatique. Elles investissent dans un périmètre clair, exigent des équipes expérimentées et une livraison itérative, budgètent honnêtement l’intégration ERP et choisissent des partenaires dont les incitations sont alignées sur une livraison dans les délais.

Si vous préparez une implémentation SAP CX ou devez en redresser une qui a dérapé, parlons franchement de ce qu’il faut.

La plupart de ces dépassements se décident au moment du choix du partenaire. Notre comparaison des meilleurs cabinets de conseil SAP CX en Suisse liste les preuves à demander, et notre page sur le conseil SAP CX en Suisse montre comment nous cadrons et staffons un projet.

Questions fréquentes

Quel est le dépassement de budget moyen des projets SAP CX ?

Il n’existe pas de chiffre fiable propre à SAP CX. Pour les grands programmes technologiques, BCG a constaté que pour plus de deux tiers, une livraison dans les délais, le budget ou le périmètre n’est pas attendue (BCG, 2024). Une étude d’Oxford portant sur 1’471 projets informatiques a montré qu’un sur six présentait un dépassement de coûts d’environ 200 % (Flyvbjerg et Budzier, 2011). Les projets SAP CX suivent les mêmes schémas.

Le forfait est-il toujours préférable à la régie ?

Pas toujours. Le forfait fonctionne le mieux quand le périmètre est bien défini, comme dans la plupart des projets d’implémentation. La régie convient aux travaux dont le périmètre est réellement incertain, comme le conseil ou les preuves de concept. Choisissez le modèle tarifaire selon le type de projet.

Comment savoir si mon partenaire sous-estime l’intégration ?

Si vous connectez un ERP et que l’intégration ne représente qu’une petite part de l’estimation, sans calendrier ni plan de test propres, soyez sceptique. Faites-vous lister chaque interface, le middleware, la gestion des erreurs et l’approche de test. Des estimations d’intégration vagues sont un signal d’alarme.

Faut-il notre propre chef de projet ou celui du partenaire suffit-il ?

Les deux. Votre chef de projet interne répond des résultats métier et des parties prenantes, celui du partenaire de la livraison. Si vous n’avez que celui du partenaire, vous avez délégué la responsabilité de votre propre projet.

Combien faut-il budgéter pour la gestion du changement ?

Assez pour la mener comme un vrai chantier : formation des utilisateurs finaux, ateliers pour les key users, documentation et suivi de l’adoption après la mise en production. La part exacte dépend du nombre d’utilisateurs et de l’ampleur du changement dans leur quotidien, mais elle doit figurer dans le plan dès le départ comme une ligne explicite, et non comme le reste à la fin.