Ce qui doit être sur la table au lendemain de la phase de définition
La définition d'un CRM se mesure à l'aune des livrables exploitables, et non par le nombre de réunions. Si, à la fin de cette étape, le chef de projet ne peut toujours pas établir un plan de travail, le développeur ignore encore quel objet gère le processus et le gestionnaire de données ne sait pas d'où provient le client, alors la phase de définition n'est pas achevée, même si la présentation a été approuvée.
Ce guide identifie sept livrables. Chacun est associé à un critère de maturité : une question simple à laquelle on peut répondre par oui ou par non. Quiconque répond « à peu près » à plus de deux de ces critères s'engage dans la phase de construction avec un niveau de risque déjà quantifiable. Une vue d'ensemble des étapes post-définition est disponible dans le guide d'implémentation Salesforce.
Livrable 1 : Carte des processus décisionnels
Il ne s'agit pas d'un diagramme de flux détaillant chaque clic, mais d'une cartographie des points de décision : qui décide, sur la base de quelles informations, ce qui se passe dans chaque branche, et ce qui arrive en l'absence de décision. La plupart des échecs des projets CRM ne résident pas dans le cheminement standard, mais dans les ramifications – une transaction gelée, un client qui revient après deux ans, une sollicitation ouverte par le mauvais client.
Critère de maturité : Il est possible de prendre une transaction réelle du mois dernier et de la suivre sur la carte de bout en bout sans rencontrer de lacune.
Livrable 2 : Glossaire métier
C'est le livrable le plus souvent sous-estimé, et l'absence le plus lourdement payée. Le terme « client » a une signification différente pour la finance que pour les ventes. Un « projet actif » n'est pas interprété de la même manière par les opérations et la direction. Tant que les définitions ne sont pas formalisées, chaque rapport génère un débat.
Le glossaire doit inclure, pour chaque terme : une définition en une phrase, l'entité Salesforce qui le représente, le champ qui détermine son statut, et le département responsable de sa définition.
Livrable 3 : Modèle de données centralisé validé
La phase de définition n'a pas pour objectif de construire un diagramme entité-relation (DER) complet, mais de valider quatre questions dont la modification ultérieure est coûteuse :
- L'activité commerciale repose-t-elle sur des Opportunités, un objet personnalisé, ou une combinaison des deux, et quelle est leur relation ?
- Le « Compte » représente-t-il une entité juridique, un site physique ou un groupe d'achat, et comment gérer sa hiérarchie ?
- Quel est l'identifiant unique qui lie un client entre Salesforce et les systèmes principaux ?
- Quelles données historiques seront intégrées au système et lesquelles resteront à leur source ?
Critère de maturité : Il est possible de schématiser sur un tableau les cinq objets principaux et leurs relations sans ouvrir de fichier.
Livrable 4 : Modèle d'autorisations et de visibilité
Le modèle d'autorisations est déterminé par la question « qui ne doit pas voir quoi », et non par « qui doit voir ». Bien que ces deux questions semblent similaires, elles conduisent à des architectures opposées. Une bonne définition établit la valeur par défaut pour chaque objet principal, le mécanisme d'extension et les cas nécessitant une visibilité exceptionnelle.
| Question | Ce qui est vérifié dans la définition | Pourquoi est-ce coûteux à modifier par la suite |
|---|---|---|
| Valeur par défaut de l'objet | Privé, Lecture publique ou Lecture/Écriture | Affecte l'ensemble du mécanisme de partage en amont |
| Structure hiérarchique | La hiérarchie des rôles reflète-t-elle la gestion ou la géographie ? | Un changement nécessite un recalcul d'accès sur tous les enregistrements |
| Visibilité inter-unités | Équipes partagées, partage manuel ou critère | Détermine la nécessité d'une logique dédiée |
| Données sensibles | Quels champs sont restreints et à qui ? | Une modification ultérieure expose des informations déjà consultées |
Livrable 5 : Carte des systèmes et sources de vérité
Chaque entité centrale doit avoir une source de vérité unique et déclarée, ainsi qu'une direction de synchronisation claire. Une définition qui laisse deux systèmes « se mettant mutuellement à jour » crée des conflits qui ne se révéleront qu'en production. La carte doit également inclure la fréquence et la tolérance aux délais : un processus de vente peut tolérer une synchronisation de cinq minutes, un contrôle de crédit généralement non.
Livrable 6 : Critères d'acceptation pour les processus clés
Ceci établit le lien entre la définition et les tests. Pour chaque processus clé, trois à cinq critères d'acceptation doivent être formulés comme un résultat observable : « Après la clôture d'une transaction, une commande est créée dans le système principal dans les cinq minutes, avec le même identifiant client. » Une telle formulation est à la fois une exigence, un script de test et une définition de l'achèvement. Sans cela, la phase d'UAT se transforme en une série de retours sur la conception.
Livrable 7 : Métriques de base avant le changement
Il est impossible de prouver une amélioration sans une mesure effectuée au préalable. Dans la phase de définition, sélectionnez trois à cinq métriques et mesurez-les de manière concrète dans l'état actuel, même si la mesure est manuelle et approximative. Le choix des métriques et la manière de les lier au bénéfice commercial sont détaillés dans le guide ROI et métriques de succès Salesforce.
Exemple illustratif : Chaîne de cliniques privées
Le scénario suivant est hypothétique et uniquement à titre d'illustration. Une chaîne de cliniques avec huit succursales a lancé un projet CRM pour centraliser les demandes des patients. Lors de la phase de définition, il a été constaté que deux succursales définissaient le terme « demande de retour » différemment : l'une comptait chaque appel, l'autre uniquement les demandes concernant un nouveau sujet. La différence semblait sémantique, mais elle déterminait si le système devait utiliser un seul objet Case avec une hiérarchie ou deux objets distincts, et elle influençait tous les rapports de charge de la direction.
L'équipe n'a pas résolu la divergence dans le document. Une décision ouverte a été notée, un propriétaire au niveau du directeur des opérations a été désigné, et une date limite a été fixée avant le début de la construction. La décision a été prise en deux semaines, et le modèle a été construit une seule fois. Si la décision avait été reportée, elle aurait été découverte lors de la phase d'UAT, après que des écrans et des rapports aient déjà été bâtis sur une hypothèse erronée.
Signaux d'alerte d'une définition superficielle
- Le document décrit des écrans et des champs mais ne spécifie pas ce qui se passe lorsqu'un processus échoue.
- Aucune décision documentée n'indique qu'une exploration d'alternatives a été menée.
- Toutes les exigences sont classées comme de haute priorité.
- Aucun nom de personne n'est associé à un processus, seulement un nom de département.
- Le nombre de champs demandés sur un seul écran dépasse vingt-cinq sans que personne n'ait vérifié qui les remplit.
Le lien entre une définition superficielle et les schémas d'échec rencontrés ultérieurement dans le projet est détaillé dans le guide des erreurs courantes d'implémentation CRM, et son impact sur le calendrier est expliqué dans le guide de la durée d'un projet Salesforce.
Lors du remplacement d'un système existant
Lorsqu'un projet remplace un CRM existant, la définition se voit confier une mission supplémentaire : décider ce qui ne sera pas transféré. Un système ancien a accumulé des champs, des automatisations et des rapports que plus personne n'utilise, et leur copie aveugle importerait l'ancienne dette technique sur la nouvelle plateforme. L'ordre des opérations recommandé pour une telle transition est détaillé dans le guide de remplacement de CRM par Salesforce.
Comment savoir s'il est possible de commencer la construction
Passez en revue les sept livrables et posez la question de maturité pour chacun d'eux. Si six sur sept répondent affirmativement, il est possible de commencer la première vague tout en gérant le septième écart comme un risque documenté. Si trois ou plus répondent « à peu près », il est préférable de prolonger la phase de définition de deux semaines plutôt que de découvrir l'écart après trois mois de travail basé sur une base erronée.
L'étape suivante naturelle consiste à traduire les livrables en un plan par vagues, avec une décision explicite sur ce qui est inclus dans la première vague et ce qui est sciemment reporté.