Diagramme de Gantt de déploiement CRM avec contrôle qualité des données
Un diagramme de Gantt de déploiement CRM modifiable : processus de vente, dédoublonnage avant migration, pipeline et champs, messagerie, agenda et marketing, recette, équipe pilote, généralisation et contrôle d'adoption.
Qu'est-ce que le processus diagramme de gantt de déploiement CRM avec contrôle qualité des données ?
Un projet CRM ressemble à une installation logicielle et agit comme un changement dans la façon de travailler d'une équipe commerciale. Le logiciel se configure en quelques semaines. Le plus lent est autour : s'accorder sur ce que signifie vraiment une étape du pipeline, découvrir combien de comptes en double contiennent les anciens outils, faire fonctionner la synchronisation de la messagerie et de l'agenda, et convaincre les équipes de saisir leurs affaires au nouvel endroit. Un plan de projet générique range tout cela dans une case « configuration » et une case « mise en service », ce qui explique que tant de déploiements CRM finissent à l'heure puis restent ignorés.
Ce modèle compte quatre groupes : Exigences et processus, Configuration et intégrations, Qualité des données et migration, et Tests et déploiement. Il comprend 22 tâches et 4 jalons. « Définir les objectifs et les indicateurs de réussite » est la seule tâche de départ, et elle est placée en premier à dessein, car « Vérifier l'adoption par rapport aux indicateurs » ne peut être jugée en fin de projet qu'à l'aune de ce qui a été convenu au début. « Cartographier le processus de vente, les étapes et les besoins en champs » (7 jours ouvrés) mène au jalon « Exigences validées ». La configuration du pipeline et celle des champs attendent toutes deux ce jalon : personne ne construit donc des étapes que les responsables commerciaux n'ont pas validées.
Le travail sur les données est un point de passage, pas une étape. « Auditer les données de contacts, comptes et affaires » démarre juste après les objectifs, en parallèle de la cartographie du processus, car il n'a pas besoin des exigences pour mesurer l'état des données. « Définir les règles de dédoublonnage et de rapprochement » attend l'audit et les exigences, « Dédoublonner et nettoyer les données sources » prend 8 jours, puis vient le jalon « Contrôle qualité des données réussi ». « Lancer la migration d'essai et corriger les erreurs » ne peut pas commencer avant ce contrôle et la création des champs. C'est la principale différence avec le plan de déploiement ERP : là, les données sont chargées par cycles répétés, alors qu'ici le nettoyage est terminé avant tout chargement d'essai, pour ne pas migrer des doublons puis les réparer dans le CRM.
Le groupe de configuration se chevauche volontairement. « Créer les tableaux de bord et les rapports de prévision » et « Connecter la messagerie et la synchronisation de l'agenda » démarrent chacun 3 jours ouvrés après le début de « Configurer les champs, rôles et droits », car ils ont besoin des noms de champs mais pas des droits définitifs. « Connecter le transfert des leads marketing » démarre 4 jours après le début de « Configurer les étapes du pipeline et les règles d'affaires ». « Réaliser la recette utilisateur » (7 jours) attend la migration d'essai, les trois intégrations et les rapports. « Corriger les anomalies de recette » suit, et « Former l'équipe pilote » démarre 2 jours après le début des corrections. Le jalon « Décision de mise en service du pilote » attend les deux.
Le déploiement se fait en deux vagues. « Mener le pilote avec une équipe commerciale » dure 10 jours ouvrés, « Former les autres équipes commerciales » démarre 5 jours après le début du pilote, et « Déployer auprès de toutes les équipes » attend les deux. « Vérifier l'adoption par rapport aux indicateurs » prend ensuite 4 jours avant le jalon « Revue d'adoption validée ». Toutes les durées sont indicatives : fixez-les d'après vos volumes d'enregistrements, votre nombre d'intégrations et la taille des équipes. Une frise planifie le travail. Elle ne rend ni les données exactes ni l'outil adopté. Côté processus, voyez le processus de pipeline commercial et celui de gestion des leads CRM ; pour l'étape de recette, voyez le processus de recette utilisateur.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre groupes avec 22 tâches et 4 jalons : « Exigences validées », « Contrôle qualité des données réussi », « Décision de mise en service du pilote » et « Revue d'adoption validée ».
- Un contrôle qualité des données : « Dédoublonner et nettoyer les données sources » se termine et « Contrôle qualité des données réussi » est atteint avant que « Lancer la migration d'essai et corriger les erreurs » puisse démarrer.
- La cartographie du processus de vente d'abord : « Cartographier le processus de vente, les étapes et les besoins en champs » alimente à la fois « Configurer les étapes du pipeline et les règles d'affaires » et « Configurer les champs, rôles et droits ».
- Trois intégrations et le reporting en tâches qui se chevauchent : « Connecter la messagerie et la synchronisation de l'agenda », « Connecter le transfert des leads marketing » et « Créer les tableaux de bord et les rapports de prévision ».
- Un déploiement par étapes et un contrôle final : « Mener le pilote avec une équipe commerciale », « Former les autres équipes commerciales », « Déployer auprès de toutes les équipes » et « Vérifier l'adoption par rapport aux indicateurs ».
Quand utiliser ce modèle
- Vous planifiez le déploiement d'un CRM pour une équipe commerciale ou relation client et voulez voir sur une seule frise le nettoyage des données, la configuration, les intégrations et la formation.
- Vos responsables commerciaux veulent une mise en service rapide et vous devez montrer pourquoi la migration attend le dédoublonnage et pourquoi la généralisation attend un pilote.
- Vous remplacez des tableurs ou plusieurs anciens outils et voulez estimer le temps que peut demander le nettoyage des contacts, comptes et affaires avant tout chargement.
- Vous voulez une structure de départ centrée sur les personnes et la qualité des données, en contraste avec un déploiement de système piloté par la finance.
Le plan, tâche par tâche
Toutes les tâches du diagramme avec leur durée en jours ouvrés et ce qu'elles attendent. Une dépendance est un numéro d'étape ; SS signifie début à début, FF fin à fin et +n un décalage en jours ouvrés.
| # | Tâche | Groupe | Jours ouvrés | Dépend de |
|---|---|---|---|---|
| 1 | Définir les objectifs et les indicateurs de réussite | Exigences et processus | 3 | |
| 2 | Cartographier le processus de vente, les étapes et les besoins en champs | Exigences et processus | 7 | 1 |
| 3 | Exigences validées | Exigences et processus | Jalon | 2 |
| 4 | Configurer les étapes du pipeline et les règles d'affaires | Configuration et intégrations | 7 | 3 |
| 5 | Configurer les champs, rôles et droits | Configuration et intégrations | 6 | 3 |
| 6 | Créer les tableaux de bord et les rapports de prévision | Configuration et intégrations | 5 | 5SS+3 |
| 7 | Connecter la messagerie et la synchronisation de l'agenda | Configuration et intégrations | 6 | 5SS+3 |
| 8 | Connecter le transfert des leads marketing | Configuration et intégrations | 6 | 4SS+4 |
| 9 | Auditer les données de contacts, comptes et affaires | Qualité des données et migration | 5 | 1 |
| 10 | Définir les règles de dédoublonnage et de rapprochement | Qualité des données et migration | 4 | 3, 9 |
| 11 | Dédoublonner et nettoyer les données sources | Qualité des données et migration | 8 | 10 |
| 12 | Contrôle qualité des données réussi | Qualité des données et migration | Jalon | 11 |
| 13 | Lancer la migration d'essai et corriger les erreurs | Qualité des données et migration | 8 | 5, 12 |
| 14 | Réaliser la recette utilisateur | Tests et déploiement | 7 | 6, 7, 8, 13 |
| 15 | Corriger les anomalies de recette | Tests et déploiement | 4 | 14 |
| 16 | Former l'équipe pilote | Tests et déploiement | 3 | 15SS+2 |
| 17 | Décision de mise en service du pilote | Tests et déploiement | Jalon | 15, 16 |
| 18 | Mener le pilote avec une équipe commerciale | Tests et déploiement | 10 | 17 |
| 19 | Former les autres équipes commerciales | Tests et déploiement | 5 | 18SS+5 |
| 20 | Déployer auprès de toutes les équipes | Tests et déploiement | 5 | 18, 19 |
| 21 | Vérifier l'adoption par rapport aux indicateurs | Tests et déploiement | 4 | 20 |
| 22 | Revue d'adoption validée | Tests et déploiement | Jalon | 21 |
Comment cela fonctionne
Écrire d'abord les indicateurs de réussite
Modifiez « Définir les objectifs et les indicateurs de réussite » pour dire ce que l'adoption signifie chez vous, par exemple des affaires saisies dans le CRM ou des prévisions lues depuis celui-ci. « Vérifier l'adoption par rapport aux indicateurs » n'est utile que dans la mesure où cette tâche l'est.
Remplacer les durées de nettoyage par le résultat de l'audit
Réalisez l'audit, puis fixez « Dédoublonner et nettoyer les données sources » d'après le nombre de doublons et d'enregistrements incomplets réellement trouvés. Gardez « Contrôle qualité des données réussi » comme seule porte d'entrée de « Lancer la migration d'essai et corriger les erreurs ».
Ajouter une tâche d'intégration par système connecté
Dupliquez « Connecter la messagerie et la synchronisation de l'agenda » pour chaque système relié, et gardez le chevauchement début à début de 3 jours quand les noms de champs sont déjà arrêtés.
Faire de l'équipe pilote un vrai point de passage
Gardez « Décision de mise en service du pilote » en attente de « Corriger les anomalies de recette » et de « Former l'équipe pilote ». Si votre équipe pilote est nombreuse, allongez « Mener le pilote avec une équipe commerciale » plutôt que de raccourcir la formation.
Comparer la date de fin avec la date visée
Lisez la fin de « Revue d'adoption validée » et comparez-la à la date qu'impose votre exercice commercial ou le renouvellement d'une licence. Si elle est plus tardive, regardez d'abord les tâches de données et le pilote.
Ajouter les responsables, partager et exporter
Indiquez le responsable dans Personnes, partagez le diagramme avec les responsables commerciaux et informatiques, et exportez un PDF ou un CSV pour le dossier du projet quand il vous en faut une copie.
Questions fréquentes
Ce plan vise-t-il un produit CRM précis ?
Non. Les noms de tâches sont génériques et conviennent à la plupart des CRM du marché. Renommez les tâches d'intégration et de configuration selon le système que vous utilisez.
Pourquoi dédoublonner avant la migration d'essai ?
Il est moins coûteux de fusionner les doublons dans les fichiers sources que dans le CRM, où des fiches fusionnées peuvent perdre leur historique. Le modèle fait de « Contrôle qualité des données réussi » un jalon : le chargement d'essai ne peut donc pas démarrer trop tôt sans que vous modifiiez la dépendance.
En quoi diffère-t-il du modèle de déploiement ERP ?
Le plan ERP s'organise autour de la construction des modules et de chargements de données répétés. Celui-ci s'organise autour de données nettoyées, du processus de vente, des intégrations et de l'adoption par une équipe pilote, puis par les autres.
Puis-je l'utiliser pour une reprise en masse depuis un autre système ?
Oui, pour les étapes de données. Pour un plan de migration plus détaillé, prenez le diagramme de Gantt de migration de données et remplacez-y les tâches de migration de celui-ci.
Les durées viennent-elles de vrais projets ?
Non. Elles sont indicatives et destinées à être remplacées. Utilisez vos volumes d'enregistrements, votre nombre d'intégrations et la taille de vos équipes.