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

Un nombre surprenant de projets SAP CX ne sont jamais mis en production. Les estimations du secteur suggèrent que 20-30 % des implémentations CRM d’entreprise sont soit annulées, « mises en pause indéfiniment », soit arrivent en production si tard et si au-dessus du budget que personne ne qualifie cela de succès.

Nous avons livré des projets SAP Sales Cloud V2, Service Cloud V2 et Commerce Cloud pour des fabricants, retailers et distributeurs à travers l’Europe. Chacun d’entre eux à été mis en production. Pas éventuellement. À la date à laquelle nous nous étions engagés.

Ce n’est pas un argument commercial. C’est un historique que nous protégeons farouchement — car le jour où nous échouons à livrer, notre réputation est perdue. Nous ne sommes pas une entreprise de 5 000 personnes qui peut absorber un projet échoué. Nous sommes une équipe focalisée où chaque projet compte.

Voici ce que nous faisons différemment.

Des consultants seniors dès le premier jour

Quand un grand cabinet de conseil remporte un deal SAP CX, l’équipe qui l’a vendu est rarement celle qui le livre. L’équipe commerciale avait 20 ans d’expérience. L’équipe de livraison en à 20 mois.

Nous n’avons pas d’équipe commerciale et d’équipe de livraison séparées. Les personnes qui cadrent votre projet sont celles qui le construisent. Chaque consultant d’un engagement Spadoom à livré plusieurs implémentations SAP V2. Ils savent où la configuration de la plateforme s’arrête et où le développement custom commence. Ils savent quelles intégrations sont simples et lesquelles vont absorber trois semaines de votre planning.

Quand nous avons livré SAP Sales Cloud V2 pour Franke en 90 jours, le même architecte qui à animé l’atelier de cadrage configurait le système dès le premier jour. Aucun transfert. Aucune perte de connaissances. Aucune période de montée en compétence.

Nous savons dire non

C’est peut-être la chose la plus importante que nous faisons. Nous disons non aux projets que nous ne pouvons pas livrer.

Si un prospect souhaite implémenter SAP Sales Cloud V2, Service Cloud V2, Commerce Cloud, Emarsys et CDP en un seul projet de 6 mois avec une équipe de quatre, nous lui disons que ce n’est pas réaliste. Si une entreprise veut reproduire fonctionnalité par fonctionnalité son CRM on-premise vieux de 15 ans dans un système cloud, nous expliquons pourquoi c’est la mauvaise approche.

Certains partenaires disent oui à tout parce que la valeur du contrat est trop attractive pour la laisser passer. Puis la réalité frappe au mois 3.

Nous préférons perdre un deal que compromettre notre historique de mise en production. Chaque fois que nous disons non, nous protégeons les 10 prochains clients qui ont besoin que nous soyons disponibles et concentrés.

Périmètre fixe, pas espoirs fixes

Chaque projet Spadoom à un document de périmètre fixe. Pas un aperçu de haut niveau — une liste détaillée de livrables avec des critères d’acceptation.

« Configurer la gestion des opportunités avec 4 étapes personnalisées, pipeline pondéré et notifications automatisées » est un livrable. « Mettre en place le CRM » ne l’est pas.

Cela protège les deux parties. Le client sait exactement ce pour quoi il paie. Nous savons exactement ce que nous devons livrer. Quand quelqu’un demande quelque chose hors du périmètre, nous ne disons pas non — nous disons « oui, voici ce que ça coûte et comment ça affecte le planning. » Gestion transparente du changement au lieu du brouillard de périmètre.

L’implémentation SAP Sales Cloud V2 de Nussbaum à pris 5 mois. Pas parce que nous avons précipité — parce que le périmètre était clair dès la première semaine. Aucune surprise. Aucune découverte de dernière minute. Aucun « nous avions supposé que c’était inclus. »

Livraison itérative avec SAP Activate

Nous suivons la méthodologie SAP Activate. Pas parce que SAP le dit, mais parce que ça fonctionne.

Voici à quoi cela ressemble en pratique :

• Semaine 1-2 : Phase Discover — valider les exigences, confirmer les intégrations, mettre en place l’environnement de développement.
• Semaine 3-4 : Premier sprint — les utilisateurs voient un système fonctionnel avec les fonctionnalités de base.
• Toutes les 2 semaines ensuite : Session de démo avec les utilisateurs clés. Ils testent. Ils donnent leur retour. Nous ajustons.
• 2-3 dernières semaines : Tests d’intégration, validation de la migration des données, recette utilisateur, préparation à la mise en production.

La différence critique : les problèmes émergent en semaine 4, pas au mois 6.

Accès direct aux décideurs

Dans de nombreux cabinets de conseil, il y à un gestionnaire de compte entre vous et les personnes qui font le travail. Besoin de changer une priorité ? Parlez au gestionnaire de compte. Question technique ? Le gestionnaire de compte va « se renseigner et revenir vers vous. »

Chez Spadoom, vous parlez directement aux architectes et consultants qui construisent votre système. Besoin d’escalader ? Notre CEO décroche le téléphone. Il n’y à pas de couche bureaucratique entre une question et une réponse.

Cette rapidité compte. Une décision qui prend 2 jours dans un grand cabinet prend 2 heures chez nous. Sur un projet de 5 mois, cette différence se cumule en semaines de temps économisé.

Cadrage honnête

Avant d’écrire une proposition, nous animons un atelier de cadrage. Typiquement 2-3 jours, selon la complexité. Nous cartographions les processus métier, identifions les points d’intégration, évaluons la qualité des données et évaluons la préparation organisationnelle.

Parfois le résultat de cet atelier est : « Vous n’êtes pas prêt pour ce projet. » Peut-être que les données maître nécessitent un nettoyage d’abord. Peut-être que les processus métier doivent être validés en interne avant que quiconque configure un système.

Dire à un prospect d’attendre nous coûte du revenu à court terme. Mais cela prévient un projet échoué — ce qui nous coûterait à tous les deux bien plus.

Ce que nous avons appris des projets hérités

Certaines de nos meilleures leçons sont venues de projets que nous n’avons pas démarrés. Nous avons été appelés pour sauver des implémentations SAP CX bloquées chez d’autres partenaires. Les schémas sont constants :

• Périmètre vague qui à grandi de 50 % pendant le projet sans ajustement budgétaire correspondant.
• Équipes juniors qui ont construit du code custom là où la configuration standard aurait fonctionné, créant une charge de maintenance.
• Aucun test d’intégration jusqu’aux dernières semaines, quand des problèmes critiques de mapping de données ont émergé.
• Aucune implication utilisateur jusqu’à la recette, quand l’équipe commerciale à rejeté le système parce que personne ne leur avait demandé ce dont ils avaient besoin.
• Mise en production big-bang sans plan de repli, sans déploiement progressif, sans groupe pilote.

Chacun de ces problèmes est évitable. Pas avec une meilleure technologie — avec une meilleure discipline projet.

Notre historique

Taux de 100 % de mise en production. Chaque projet. À chaque fois.

Ce chiffre ne reste à 100 % que parce que nous sommes sélectifs sur ce que nous acceptons, honnêtes sur ce qui est réaliste, et disciplinés dans notre façon de livrer.

Nous ne sommes pas l’option la moins chère. Nous ne sommes pas le plus grand cabinet. Mais quand votre projet SAP CX doit absolument être mis en production dans les temps et dans le budget, l’historique compte plus que les présentations PowerPoint.

Parlez-nous de votre projet — nous serons honnêtes sur le fait que nous sommes le bon partenaire où non.