Pourquoi les propositions Salesforce sont presque toujours incomparables
Lorsque l'on compare trois propositions et qu'une différence de plusieurs dizaines de pour cent apparaît, l'instinct est de penser que l'une d'entre elles est gonflée. Dans la plupart des cas, la raison est plus simple : chaque proposition budgétise un projet différent.
Un fournisseur a inclus la migration de trois ans d'historique, l'autre a supposé un an. L'un a inclus six semaines de stabilisation après le déploiement, l'autre a livré et terminé. L'un a compté quatre intégrations, l'autre deux, car il a supposé un rapport quotidien au lieu d'une interface en temps réel. Aucun d'eux n'a trompé – on ne leur a tout simplement pas dit le contraire.
La comparaison commence donc par la normalisation, et non par une grille tarifaire.
Méthode de normalisation en six étapes
1. Définissez une liste uniforme de composants. Onze lignes suffisent : Spécification, Configuration, Développement, Intégrations, Migration, Tests, Formation, Gestion de projet, Stabilisation, Documentation, Transfert de connaissances.
2. Pour chaque proposition, indiquez ce qui est inclus, partiellement inclus et manquant. Ne remplissez pas les montants à ce stade.
3. Évaluez le coût des éléments manquants. Pour chaque composant non inclus dans une proposition, utilisez le coût d'une autre proposition comme estimation et ajoutez-le.
4. Harmonisez les hypothèses. Nombre d'utilisateurs, édition, années d'historique, nombre d'unités commerciales, langues.
5. Harmonisez la période de garantie. Une période différente équivaut à de l'argent. Une différence de deux mois de stabilisation est un coût réel.
6. Calculez le coût horaire moyen et la composition de l'équipe à chaque étape, et non seulement au total.
Ce n'est qu'après ces six étapes que les chiffres peuvent être comparés. Dans de nombreux cas, la proposition qui semblait la moins chère se retrouve en deuxième position.
Les éléments qui disparaissent des propositions – et apparaissent sur la facture
| Composant | Pourquoi omis | Ordre de grandeur relatif |
|---|---|---|
| Nettoyage des données avant migration | Considéré comme la responsabilité du client | Parfois très significatif |
| Deuxième cycle d'UAT | Estime un seul cycle | Faible mais bloque le calendrier |
| Formation par rôle | Budgétisé comme un seul atelier | Moyen |
| Support accru les premières semaines | Non défini | Moyen à élevé |
| Documentation appartenant à l'organisation | Considéré comme acquis | Faible, critique plus tard |
| Traitement des erreurs d'intégration et surveillance | Seul le « chemin normal » est inclus | Moyen |
| Environnements et DevOps | Supposé exister | Faible à moyen |
| Heures de gestion interne de l'organisation | Non inclus dans la proposition | Élevé, et toujours présent |
La dernière ligne est celle qui surprend la direction. Un projet Salesforce consomme un temps significatif des propriétaires de processus et du PMO, et c'est un coût réel même s'il n'apparaît sur aucune facture.
De la comparaison de prix à la comparaison de coût sur trois ans
Une proposition est correctement évaluée sur trois ans, pas seulement sur la durée du projet. Structure de calcul simple :
| Composant | Année 1 | Année 2 | Année 3 |
|---|---|---|---|
| Coût d'implémentation | Complet | — | — |
| Licences | Par nombre d'utilisateurs | Incluant une croissance prévue | Incluant une croissance prévue |
| Maintenance et support | Partiel | Complet | Complet |
| Améliorations planifiées | — | Volume estimé | Volume estimé |
| Coût de gestion interne | Élevé | Moyen | Moyen |
La différence entre les propositions la première année semble importante. Sur trois ans, ce qui est généralement décisif est la facilité avec laquelle le système pourra être modifié sans le fournisseur – c'est-à-dire la qualité de la documentation et du transfert, qui ne sont presque jamais pris en compte dans la décision.
Drapeaux rouges dans une proposition
- La migration de données est budgétisée à un montant forfaitaire sans question sur le volume ou la qualité.
- Il n'y a pas de période de garantie, ou elle est définie comme « gestion des bugs » sans définition de ce qu'est un bug.
- Une proposition qui n'inclut que des heures de développement et aucune ligne de gestion de projet.
- Une composition d'équipe sans noms, ou des noms non contractuellement engagés.
- Un prix particulièrement bas pour la phase de spécification, qui est parfois une porte d'entrée pour un projet qui sera ensuite budgétisé.
- Pas de réductions explicites. Une proposition sans réductions est une proposition qui n'a pas été examinée.
Exemple illustratif : une entreprise d'énergie renouvelable
Le scénario est hypothétique et à des fins d'illustration. Une entreprise a reçu trois propositions. L'écart entre la plus chère et la moins chère était d'environ quatre-vingts pour cent. Le comité penchait pour la moins chère.
Après normalisation, il s'est avéré que la proposition la moins chère n'incluait aucune migration, mais seulement le chargement des enregistrements actifs ; elle supposait deux intégrations au lieu de quatre, car elle pensait que le rapport financier se ferait par exportation manuelle ; et la période de garantie était de deux semaines contre huit semaines dans la proposition la plus chère.
Après avoir complété les éléments manquants avec les coûts des autres soumissionnaires, l'écart s'est réduit à environ dix pour cent. La décision finale n'était pas basée sur le prix, mais sur la question de savoir qui offrait un transfert de connaissances structuré, car l'entreprise n'avait pas d'équipe interne.
Que faire de l'écart restant
Après normalisation, il reste généralement un écart réel. Traduisez-le en questions et non en hypothèses :
- Pourquoi votre estimation d'intégration est-elle inférieure à celle des autres – que savez-vous qu'ils ne savent pas ?
- Que se passe-t-il si l'hypothèse sur la qualité des données est incorrecte ?
- Combien de cycles de tests avez-vous planifiés ?
- Qui de l'équipe présentée accompagnera le projet du début à la fin ?
Les réponses à ces questions distinguent un fournisseur qui a fait une offre à bas prix parce qu'il est efficace d'un fournisseur qui a fait une offre à bas prix parce qu'il n'a pas compris.
Le lien avec la décision finale
Une comparaison structurée ne fournit que l'aspect commercial. L'aspect professionnel est noté séparément, selon des pondérations définies à l'avance, et le prix n'est qu'un de ces éléments – les détails se trouvent dans le Guide de sélection d'une entreprise d'implémentation Salesforce. La compréhension de ce qui compose le coût dès le départ est détaillée dans le Guide du coût d'implémentation Salesforce, et le choix du modèle de contractualisation dans le Guide de tarification des projets.
Ce qui est convenu dans la comparaison doit être inclus dans le contrat avec une formulation précise, sinon cela n'existe pas – les clauses pertinentes sont regroupées dans le Guide du contrat et du scope of work (SOW) Salesforce.
Prochaine étape
Construisez le tableau de normalisation avant d'ouvrir les enveloppes de prix. Celui qui le construit après avoir vu les montants, le construit – involontairement – de manière à justifier la proposition qui lui a déjà plu.