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

Un chiffre qui devrait préoccuper tout CIO : les études du secteur montrent qu’environ 60 % des projets d’implémentation SAP dépassent leur budget initial. Certains de 20 %. D’autres de 200 %.

Les raisons sont rarement techniques. Elles sont structurelles. Et la plupart sont évitables si vous savez où regarder avant de signer le contrat.

Nous avons livré des projets SAP Sales Cloud V2, Service Cloud V2 et Commerce Cloud dans l’industrie, le retail et la distribution. Certains, nous les avons repris en pleine crise, abandonnés par d’autres partenaires. Les dépassements de budget suivent les mêmes schémas. A chaque fois. Sans exception.

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

C’est la cause principale des dépassements de budget. Pas le glissement de périmètre — le brouillard de périmètre.

De nombreux projets démarrent avec un document d’exigences de 40 pages qui ressemble à une liste de souhaits. « Le système devrait supporter tous les processus de vente actuels. » Qu’est-ce que cela signifie concrètement ? Personne n’est d’accord. Le partenaire estime selon son interprétation. Le client attend autre chose. Trois mois plus tard, l’écart devient visible — et coûteux.

Ce qui fonctionne à la place : Définir le périmètre au niveau des processus, pas des fonctionnalités. « Configurer la conversion lead-opportunité avec assignation automatique de territoire pour les marchés DACH, incluant un workflow d’approbation pour les deals supérieurs à CHF 50’000. » Voilà un élément de périmètre. « Supporter les processus de vente » n’en est pas un.

Chez Spadoom, chaque projet commence par un atelier de cadrage qui produit une liste fixe de livrables. Si ce n’est pas sur la liste, ce n’est pas dans le projet. Si le client souhaite ajouter quelque chose, nous le chiffrons séparément. Aucune ambiguïté.

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 ils le staffent avec des consultants ayant 18 mois d’expérience qui apprennent SAP Sales Cloud V2 sur votre budget.

Soyons francs : les consultants juniors prennent plus de temps. Ils font des erreurs architecturales qui ne se révèlent qu’en phase de test. Ils construisent des contournements au lieu d’utiliser la configuration standard. Une tâche qui prend 2 jours à un consultant senior en prend 5 à un junior — plus 2 jours supplémentaires pour corriger les erreurs.

Le calcul est brutal. Vous payez CHF 1’500/jour pour quelqu’un qui travaille à 40 % de la vitesse de quelqu’un qui coûte CHF 2’200/jour. La ressource « moins chère » vous revient de facto plus cher. Comme dit le proverbe : le bon marché coûte cher.

Ce qui fonctionne à la place : Demandez à votre partenaire exactement qui travaillera sur votre projet. Exigez les noms, les CV, les certifications SAP. Demandez combien de projets V2 ils ont livrés (pas V1 — l’architecture est complètement différente). Si la réponse est vague, c’est votre réponse.

Chaque projet Spadoom est staffé avec des consultants seniors ayant livré plusieurs implémentations V2. Aucun junior n’apprend à vos frais.

Raison 3 : Planification en cascade dans un monde cloud

Les produits SAP CX sont basés sur le cloud. Des mises à jour trimestrielles. Ils sont configurés, pas codés de zéro. Pourtant, de nombreux partenaires planifient encore les projets en phases rigides de type cascade : 3 mois de blueprint, 3 mois de build, 1 mois de tests, mise en production big-bang.

Le problème : le temps de terminer le blueprint, la plateforme a reçu deux mises à jour. Les exigences ont changé. Les utilisateurs n’ont rien vu de fonctionnel avant le mois 6. Et quand ils le voient enfin, la boucle de rétroaction crée une avalanche de demandes de changement.

Ce qui fonctionne à la place : La méthodologie SAP Activate existe pour une bonne raison. Livraison itérative. Un système fonctionnel dès le sprint 2. Retour utilisateur toutes les deux semaines. Correction de cap quand c’est peu coûteux, pas après que tout soit construit.

Nous travaillons typiquement en sprints de 2 semaines avec des sessions de démonstration à la fin de chacun. Les clients voient des fonctionnalités opérationnelles dès la semaine 3. Les problèmes émergent tôt. Le budget reste intact.

Raison 4 : La complexité d’intégration est sous-estimée

« Nous devons juste le connecter à notre ERP. » Cette phrase a détruit plus de budgets projet que n’importe quelle autre.

Connecter SAP Sales Cloud V2 à SAP S/4HANA semble simple. Ce ne l’est pas. Vous devez mapper les modèles de données, gérer la synchronisation des données maître, traiter la résolution des conflits, gérer les différentes fréquences de mise à jour, et construire la gestion des erreurs pour quand le middleware tombe en panne à 2 heures du matin un vendredi.

Ensuite, il y a le middleware lui-même. SAP BTP Integration Suite, iPaaS tiers ou API personnalisées. Chacune possède sa propre complexité. Chacune nécessite un monitoring. Chacune nécessite quelqu’un capable de la configurer correctement.

Ce qui fonctionne à la place : Budgétez l’intégration séparément. Pas comme un poste — comme son propre workstream avec son propre calendrier et sa propre phase de test. Nous avons vu des projets où l’intégration consommait 40 % de l’effort total. Si votre partenaire l’estime à 10 %, posez des questions difficiles.

Nous cadrons l’intégration comme une phase dédiée. Chaque interface reçoit un document de conception technique avant qu’une seule ligne de configuration ne soit écrite. Les interfaces sont testées indépendamment avant le début des tests d’intégration système.

Raison 5 : La gestion du changement est reléguée au second plan

Vous pouvez configurer l’instance SAP Sales Cloud V2 la plus parfaite au monde. Si votre équipe commerciale ne l’utilise pas, vous avez gaspillé chaque franc.

La plupart des dépassements de budget contiennent des coûts cachés : l’extinction des incendies post-mise en production parce que les utilisateurs rejettent le système, le contournent ou submergent le helpdesk. Le projet était « terminé », mais le travail ne l’était pas.

Ce qui fonctionne à la place : Incluez la formation des utilisateurs finaux, les ateliers d’utilisateurs clés et le suivi de l’adoption dans le périmètre du projet dès le premier jour. Budgétez 10 à 15 % du coût total du projet pour la gestion du changement. Ce n’est pas optionnel. Nota bene : la plupart des projets que nous avons « sauvés » avaient économisé exactement ici.

Le problème du modèle tarifaire

Au-delà de ces cinq causes, il y a un problème structurel : les contrats en régie (time-and-materials).

La régie signifie que le partenaire gagne davantage quand le projet prend plus de temps. Des incitations mal alignées. Nous ne prétendons pas que les partenaires freinent délibérément, mais la régie supprime la pression d’être efficient. Et à qui profite le crime, comme on dit.

Les contrats à prix fixe avec périmètre fixe inversent les incitations. Le partenaire est motivé à livrer efficacement car les dépassements impactent sa marge, pas votre budget.

Chez Spadoom, nous travaillons avec des contrats à prix fixe. Le prix dans la proposition est le prix que vous payez. Si nous sous-estimons, c’est notre problème. Cela nous force à cadrer honnêtement — exactement la discipline qui prévient les dépassements.

Une checklist budgétaire pratique

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

1. Le périmètre est granulaire. Chaque livrable est décrit au niveau du processus avec des critères d’acceptation.
2. L’équipe est nommée. Vous savez exactement qui travaille sur votre projet et quelle est leur expérience.
3. La méthodologie est itérative. Vous voyez un logiciel fonctionnel dans le premier mois.
4. L’intégration est cadrée séparément. Avec son propre calendrier et plan de test.
5. La gestion du changement est budgétée. Formation, documentation, support à l’adoption — inclus dès le départ.
6. La tarification est à prix fixe. Ou au minimum, vous avez un plafond maximum avec des procédures claires de demande de changement.
7. Les références sont réelles. Vous pouvez parler à des clients qui ont terminé des projets similaires dans les temps et dans le budget.

L’essentiel

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

Les entreprises qui réussissent traitent l’implémentation comme un projet métier, pas un projet informatique. Elles investissent dans un périmètre clair. Elles exigent des équipes expérimentées. Elles insistent sur une livraison itérative. Et elles choisissent des partenaires dont les incitations financières sont alignées sur la livraison dans les temps.

Nous maintenons un taux de 100 % de mise en production sur chaque projet SAP CX que nous avons livré. Pas par chance — parce que nous refusons de démarrer un projet sans les disciplines décrites ci-dessus.

Si vous planifiez une implémentation SAP CX — ou si vous devez sauver un projet qui a déraillé — entamons une conversation honnête sur ce qu’il faudra.