Modèle de diagramme de Gantt d'implémentation client, du lancement à la remise
Un diagramme de Gantt modifiable pour un éditeur qui met en place son produit chez un client : lancement, exigences, configuration, migration, recette, mise en production et hypercare, avec les apports du client en points de passage.
Qu'est-ce que le processus modèle de diagramme de gantt d'implémentation client, du lancement à la remise ?
Quand un éditeur met en place son produit chez un client, le plan n'est qu'à moitié le sien. Vous maîtrisez la configuration, les intégrations et la formation. Le client décide de qui rejoint le projet, de la date d'arrivée de l'extraction de données, du bon fonctionnement des identifiants d'API et de la présence des testeurs. Les plans qui cachent ces apports dans des tâches du fournisseur paraissent sains jusqu'au jour où un fichier client arrive en retard et où personne ne sait quelle tâche il a bloquée. Ce modèle rend le côté client visible dans un groupe à part : la discussion du point hebdomadaire porte alors sur des dates, pas sur des reproches.
Le diagramme compte 22 lignes en cinq groupes : Lancement et exigences, Configuration et construction, Dépendances du client, Tests, formation et mise en production, et Hypercare et remise. Dix-huit sont des tâches et quatre des jalons : « Exigences validées », « Recette validée », « Mise en production » et « Remise acceptée par le client ». « Tenir la réunion de lancement » (1 jour ouvré) est la seule tâche de départ. « Le client désigne l'équipe projet et les validateurs » (2) la suit, et « Animer les ateliers d'exigences » (4) attend cette tâche, car des ateliers sans les personnes qui peuvent décider ne sont qu'une répétition.
La validation des exigences est le point de passage qui libère l'essentiel du plan. « Configurer le produit selon les exigences » (8), « Le client livre l'extraction des données sources » (6) et « Le client fournit les identifiants d'API et l'accès de test » (3) suivent tous « Exigences validées ». Le chevauchement n'est utilisé que là où il est sans risque. « Nettoyer et mapper les données du client » (5) démarre 3 jours après le début de l'extraction : le mapping commence donc sur les premiers enregistrements au lieu d'attendre le fichier entier. « Construire les intégrations avec les systèmes du client » (7) démarre 3 jours après le début de la configuration mais attend aussi les identifiants : l'accès du client peut donc la retenir.
La phase de test est celle où les deux parties se rejoignent. « Lancer la migration de données d'essai » attend la configuration et les données mappées. « Effectuer le contrôle qualité interne » (4) attend la migration d'essai et les intégrations, afin que le client ne découvre pas vos défauts. « Réaliser la recette utilisateur » (6) attend ce contrôle et « Le client réserve les testeurs de la recette » (1), tâche du client à dessein : elle peut glisser alors que le travail du fournisseur est à l'heure. « Former les administrateurs et utilisateurs du client » (4) démarre 2 jours après le début de la recette. « Effectuer la migration finale et la bascule » (2) exige « Recette validée » et la formation avant « Mise en production ».
Après la mise en production, « Assurer le support d'hypercare » (10) et « Remettre les guides d'exploitation et les fiches de configuration » (3) démarrent ensemble, et « Passer la main à l'équipe support » (2) attend les deux avant « Remise acceptée par le client ». Toutes les durées sont indicatives : fixez les vôtres d'après vos implémentations passées. Une frise planifie le travail. Elle ne rend pas une configuration correcte ni une migration complète, et ne remplace ni votre contrat ni votre cahier des charges. Pour une mission de conseil, voyez le diagramme de Gantt de mission de conseil ; pour le déploiement côté acheteur, voyez le diagramme de Gantt de plan de déploiement.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq groupes, Lancement et exigences, Configuration et construction, Dépendances du client, Tests, formation et mise en production, et Hypercare et remise, avec 18 tâches et quatre jalons : « Exigences validées », « Recette validée », « Mise en production » et « Remise acceptée par le client ».
- Des points de passage côté client en tâches : « Le client désigne l'équipe projet et les validateurs », « Le client livre l'extraction des données sources », « Le client fournit les identifiants d'API et l'accès de test » et « Le client réserve les testeurs de la recette ».
- Un chevauchement sans risque : « Nettoyer et mapper les données du client » démarre 3 jours après le début de « Le client livre l'extraction des données sources », et « Construire les intégrations avec les systèmes du client » 3 jours après le début de « Configurer le produit selon les exigences ».
- Une phase de test qui attend les deux parties : « Effectuer le contrôle qualité interne » suit la migration d'essai et les intégrations, et « Réaliser la recette utilisateur » attend aussi « Le client réserve les testeurs de la recette ».
- Une clôture qui attend que le support soit prêt : « Passer la main à l'équipe support » suit à la fois « Assurer le support d'hypercare » et « Remettre les guides d'exploitation et les fiches de configuration ».
Quand utiliser ce modèle
- Vous êtes un éditeur, un partenaire ou une équipe de réussite client qui planifie l'intégration d'un client et devez convenir de dates avec le chef de projet du client.
- Vous voulez montrer au client lesquels de ses apports, comme les données, les accès ou les testeurs, décident de la date de mise en production.
- Vous comparez la date de fin avec celle que le client demande et voulez voir quelle attente la décide.
- Vous voulez un squelette d'implémentation reproductible à copier pour chaque nouveau client et à adapter au produit.
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 | Tenir la réunion de lancement | Lancement et exigences | 1 | |
| 2 | Animer les ateliers d'exigences | Lancement et exigences | 4 | 4 |
| 3 | Exigences validées | Lancement et exigences | Jalon | 2 |
| 4 | Le client désigne l'équipe projet et les validateurs | Dépendances du client | 2 | 1 |
| 5 | Préparer l'environnement du client | Configuration et construction | 3 | 1 |
| 6 | Configurer le produit selon les exigences | Configuration et construction | 8 | 3, 5 |
| 7 | Le client livre l'extraction des données sources | Dépendances du client | 6 | 3 |
| 8 | Nettoyer et mapper les données du client | Configuration et construction | 5 | 7SS+3 |
| 9 | Construire les intégrations avec les systèmes du client | Configuration et construction | 7 | 6SS+3, 10 |
| 10 | Le client fournit les identifiants d'API et l'accès de test | Dépendances du client | 3 | 3 |
| 11 | Lancer la migration de données d'essai | Configuration et construction | 3 | 6, 8 |
| 12 | Effectuer le contrôle qualité interne | Tests, formation et mise en production | 4 | 9, 11 |
| 13 | Réaliser la recette utilisateur | Tests, formation et mise en production | 6 | 12, 14 |
| 14 | Le client réserve les testeurs de la recette | Dépendances du client | 1 | 4 |
| 15 | Recette validée | Tests, formation et mise en production | Jalon | 13 |
| 16 | Former les administrateurs et utilisateurs du client | Tests, formation et mise en production | 4 | 13SS+2 |
| 17 | Effectuer la migration finale et la bascule | Tests, formation et mise en production | 2 | 15, 16 |
| 18 | Mise en production | Tests, formation et mise en production | Jalon | 17 |
| 19 | Assurer le support d'hypercare | Hypercare et remise | 10 | 18 |
| 20 | Remettre les guides d'exploitation et les fiches de configuration | Hypercare et remise | 3 | 18 |
| 21 | Passer la main à l'équipe support | Hypercare et remise | 2 | 19, 20 |
| 22 | Remise acceptée par le client | Hypercare et remise | Jalon | 21 |
Comment cela fonctionne
Nommer les personnes avant les ateliers
Gardez « Le client désigne l'équipe projet et les validateurs » avant « Animer les ateliers d'exigences ». Remplacez les 2 et 4 jours ouvrés par ce dont vos clients ont habituellement besoin.
Traiter la validation comme un point de passage
« Exigences validées » libère la configuration, l'extraction des données et l'accès à l'API. Si votre contrat permet de commencer sur une partie du périmètre, scindez le jalon par module plutôt que de le supprimer.
Fixer avec le client les délais de données et d'accès
Convenez dès le lancement de la durée de « Le client livre l'extraction des données sources » et de « Le client fournit les identifiants d'API et l'accès de test », et notez les dates dans les notes pour que le client voie ce que chacune bloque.
Ajuster les chevauchements à votre produit
Les deux liens début à début portent un décalage de 3 jours, et le lien de formation un décalage de 2 jours. Réglez chaque décalage selon la part de la tâche précédente dont votre équipe a besoin avant de démarrer la suivante.
Tenir les points de passage de test
Gardez « Effectuer le contrôle qualité interne » avant « Réaliser la recette utilisateur » et écrivez les critères d'acceptation dans les notes de la tâche avant « Recette validée ». Dimensionnez l'hypercare d'après le nombre d'utilisateurs et d'intégrations attendu.
Ajouter les responsables, partager et exporter
Indiquez le responsable dans Personnes, partagez le diagramme avec le chef de projet du client, et exportez un PDF ou un CSV pour le dossier du projet quand il vous en faut une copie.
Questions fréquentes
En quoi diffère-t-il du plan de déploiement de l'acheteur ?
Ce plan est écrit par le fournisseur et traite les apports du client comme des points de passage planifiés. Le déploiement de l'acheteur couvre son changement interne, son budget et ses utilisateurs. Pour cette vue, voyez le diagramme de Gantt de plan de déploiement.
Le diagramme montre-t-il quand le client est en retard ?
Il montre ce qu'une tâche client tardive repousserait. Si « Le client livre l'extraction des données sources » dure plus de 6 jours ouvrés, les tâches dépendantes et le jalon « Mise en production » reculent. Mettez la durée à jour et lisez la nouvelle date de fin.
Pourquoi « Le client réserve les testeurs de la recette » est-elle une tâche ?
Parce que les testeurs sont souvent la ressource client la plus rare, et qu'une réservation tardive retarde la recette même quand le travail du fournisseur est terminé. En faire une tâche rend la demande, et sa date, visibles.
Puis-je ajouter une phase pour la seule migration de données ?
Oui. Détaillez « Lancer la migration de données d'essai » en tâches d'extraction, de chargement et de rapprochement, ou utilisez le diagramme de Gantt de migration de données pour un plan centré sur la migration. Pour le volet processus, voyez le processus de mise en place de logiciels d'entreprise.
Puis-je l'utiliser pour plusieurs clients à la fois ?
Copiez le diagramme pour chaque client, car leurs points de passage et leurs dates diffèrent. Pour la méthode de liaison des tâches, voyez le guide sur les dépendances d'un diagramme de Gantt ; pour les étapes d'intégration sous forme d'organigramme, voyez le processus d'intégration des clients.