Objectifs d'un bon document de demande de propositions (RFP)
L'objectif d'un RFP n'est pas d'obtenir un prix, mais plutôt d'obtenir des propositions comparables et d'identifier le fournisseur qui a le mieux compris le problème. Un document détaillant une centaine d'exigences avec des cases " Prend en charge / Ne prend pas en charge " produit l'effet inverse : tous les fournisseurs cocheront " Prend en charge ", et la décision se résumera au prix.
Différence concrète : au lieu d'écrire " Le système permettra la gestion des opportunités ", décrivez que l'entreprise gère environ quatre cents transactions par mois, que chaque transaction nécessite une approbation de prix, et que cette approbation est actuellement effectuée par e-mail. Les fournisseurs proposeront des réponses très différentes – et c'est précisément l'intérêt.
Les neuf sections d'un document RFP Salesforce
1. Contexte et objectif commercial. Ce que fait l'organisation, quel est le problème, et ce qui sera considéré comme un succès dans un an. Un paragraphe à une page.
2. État actuel. Systèmes utilisés, nombre d'utilisateurs, ce qui fonctionne actuellement et ce qui ne fonctionne pas. Si un environnement Salesforce existe, précisez l'édition, l'ancienneté et le niveau de personnalisation.
3. Processus clés couverts. Trois à sept processus, chacun décrit en un paragraphe : qui exécute, quels sont les points de décision, et ce qui se passe en cas d'écart.
4. Volumes et données. Nombre d'enregistrements pour chaque entité clé, taux de création mensuel, années d'historique à conserver, et état connu de la qualité des données. C'est la partie qui influence le plus la précision des prix et qui est la plus souvent négligée.
5. Intégrations. Pour chaque système : nom, type d'interface si connu, direction, fréquence requise et responsable au sein de l'organisation.
6. Contraintes. Réglementation, sécurité des données, localisation du stockage, langues, accessibilité, délais incompressibles.
7. Attentes envers le proposant. Approche proposée, plan d'étapes (waves), composition de l'équipe avec noms et rôles, hypothèses, risques, et tarification selon une structure prédéfinie.
8. Méthode d'évaluation. Critères et pondérations, publiés à l'avance. Cela conduit à des propositions ciblées et réduit les litiges après l'attribution.
9. Calendrier de l'appel d'offres. Date limite pour les questions, date de réponse, date de soumission, date des démonstrations, date de décision.
Les données indispensables à révéler pour une tarification réaliste
| Donnée | Pourquoi est-elle critique | Ce qui se passe sans elle |
|---|---|---|
| Nombre d'utilisateurs par type | Détermine les licences, la formation et les autorisations | Propositions avec un écart de prix trop important |
| Volume d'enregistrements et historique | Détermine l'effort de migration | La migration est évaluée grossièrement |
| Nombre de systèmes sources | Détermine la complexité et l'intégration | Surprises après la signature |
| Niveau de documentation existante | Détermine l'effort de découverte nécessaire | Les fournisseurs supposent une documentation existante |
| Disponibilité des propriétaires de processus | Détermine le rythme des décisions | Un calendrier irréaliste est convenu par les deux parties |
| Budget ou fourchette | Oriente la solution | Propositions incomparables |
Questions qui distinguent les fournisseurs
Les questions suivantes suscitent des réponses très différentes de la part des fournisseurs, ce qui les rend utiles. Une question à laquelle tous répondent de la même manière ne mérite pas sa place dans le document.
- Quelles sont les trois hypothèses principales sur lesquelles repose la proposition, et quelles seraient les conséquences si l'une d'elles était erronée ?
- Dans quels cas recommanderiez-vous une configuration alors qu'un développement serait plus efficace, et inversement ?
- Décrivez un projet où vous avez dépassé le calendrier. Quelles en étaient les causes et qu'avez-vous changé depuis ?
- Qui seront les membres de l'équipe réelle, et quel pourcentage de leur temps chacun consacrera-t-il à ce projet ?
- De quoi avez-vous besoin de notre part pour réussir, et que ferez-vous si vous ne l'obtenez pas ?
- Comment nous transmettrez-vous la capacité à maintenir le système sans votre aide ?
La dernière question est un bon indicateur de la nature de la relation. Un fournisseur qui l'élude envisage de créer une dépendance.
Quel livrable demander dans la proposition
- Un diagramme d'architecture préliminaire au niveau des blocs, incluant les sources de vérité.
- Un plan d'étapes (waves) avec le contenu de chaque vague, et pas seulement des dates.
- Une ventilation détaillée des prix selon une structure uniforme que vous dictez, par étape et par rôle.
- Une liste explicite des hypothèses.
- Une cartographie des risques avec des stratégies d'atténuation.
- Un exemple de livrable réel d'un projet précédent, avec les noms masqués – par exemple, un document de décision ou un plan de test.
Le dernier point est peut-être le plus différenciant car il démontre un standard de travail et non une simple promesse.
Structure de tarification uniforme – l'outil pour éviter de comparer des pommes et des oranges
Définissez vous-même le tableau que chaque proposant doit remplir :
| Étape | Heures senior | Heures junior | Coût | Qu'est-ce qui est considéré comme terminé |
|---|---|---|---|---|
| Phase d'étude et d'analyse | ||||
| Configuration et développement pour la vague 1 | ||||
| Intégrations | ||||
| Migration de données | ||||
| Tests et UAT | ||||
| Formation et adoption | ||||
| Stabilisation post-lancement | ||||
| Gestion de projet |
Un fournisseur qui refuse de décomposer le prix selon cette structure n'est pas nécessairement cher, mais il est impossible de le comparer, ce qui est une raison suffisante pour exiger cette ventilation.
Exemple d'illustration : une caisse de retraite de taille moyenne
Ce scénario est hypothétique et à titre d'illustration. Une institution financière a publié un RFP qui incluait quatre-vingts exigences fonctionnelles dans un tableau. Les quatre proposants ont coché " Prend en charge " pour presque chaque ligne, et les propositions ne différaient que par le prix et le nombre d'heures.
Lors d'un deuxième tour, le document a été modifié : au lieu du tableau des exigences, il incluait trois processus entièrement décrits, des données de volume réelles, et une demande de résolution d'un scénario lors d'une démonstration. Les propositions reçues différaient de manière significative : l'une proposait un modèle de données complètement différent, une autre identifiait une dépendance à une approbation réglementaire à laquelle personne n'avait pensé.
Le comité n'a pas choisi la proposition la moins chère et n'a pas contesté. Il a choisi celle qui a réussi à expliquer pourquoi la septième exigence du document original n'était pas nécessaire du tout.
Erreurs courantes lors de la rédaction d'un RFP
- Copier un document d'un autre projet sans adapter les volumes et les processus.
- Demander une liste de clients au lieu d'exemples de livrables.
- Formuler les critères d'évaluation après la réception des propositions.
- Un calendrier ne laissant pas de temps pour les questions et réponses.
- Une préférence implicite pour un fournisseur existant, ce qui fait que les autres investissent en vain et nuit à la qualité des propositions futures.
Ce qui se passe après la soumission
Un bon document ne représente que la moitié du travail. L'étape suivante consiste à normaliser les propositions et à les comparer sur la même base, comme détaillé dans le guide de comparaison des propositions Salesforce, puis à les noter de manière structurée selon des pondérations définies à l'avance, comme détaillé dans le guide Scorecard pour la sélection d'un fournisseur.
Les informations nécessaires à la rédaction du document proviennent généralement d'un bref processus de consultation, comme décrit dans le guide de consultation Salesforce, et les critères d'évaluation de l'entreprise sont regroupés dans le guide de choix d'une société d'intégration Salesforce.
Prochaine étape
Avant d'envoyer le document, effectuez une dernière vérification : demandez à quelqu'un dans l'organisation qui n'est pas impliqué dans le projet de le lire et de vous expliquer en une phrase quel est le problème que vous essayez de résoudre. S'il n'y parvient pas, les fournisseurs non plus – et ils se contenteront de vous proposer ce qu'ils ont l'habitude de vendre.