Planning de déploiement : un diagramme de Gantt pour ERP, CRM et logiciels
Construisez un planning de déploiement en diagramme de Gantt : validation de la conception, paramétrage, migration, intégrations, tests, formation, bascule et hypercare, avec une revue de préparation avant la mise en production.
Le déploiement d'un logiciel métier a une date que tout le monde retient : la mise en production. Un diagramme de Gantt montre ce qui doit être vrai d'ici là, et quels flux peuvent avancer en parallèle jusque-là.
En bref
- Utilisez un jalon pour la validation de la conception et un jalon pour la revue de préparation à la mise en production.
- Laissez les flux de paramétrage, de données et d'intégration avancer en parallèle entre ces deux points de passage.
- Utilisez des dépendances début-à-début avec décalage pour le travail qui peut commencer avant la fin de son prédécesseur.
- Faites dépendre la mise en production de la revue de préparation, pour que la bascule ne puisse pas être planifiée avant la décision.
- Incluez l'hypercare et le passage de relais pour que le plan se termine quand le support reprend la main, pas à la mise en production.
Ce qu'un planning de déploiement doit montrer
Les déploiements d'ERP, de CRM et d'autres systèmes métier se composent de quelques flux qui avancent surtout en parallèle : paramétrer le système, préparer et migrer les données, développer les intégrations et préparer les personnes. Ils ne se rejoignent qu'à des points définis, comme les tests et la décision de mise en production. Un bon planning rend ces jonctions visibles, car c'est là qu'un flux en retard retarde tout le reste.
La structure qui fonctionne est une courte suite de points de passage. Les besoins mènent à une conception validée, qui libère les flux de paramétrage, de données et d'intégration. Leur résultat se rejoint dans les tests d'intégration système, puis la recette utilisateur, puis une revue de préparation à la mise en production. Viennent ensuite la bascule, la migration finale des données et une période d'hypercare. La validation et la revue de préparation sont des jalons de durée nulle : ce sont des décisions, pas du travail, et le diagramme doit montrer qui les attend.
Tous les flux n'ont pas à attendre la fin du précédent. Les essais de migration peuvent démarrer quand le paramétrage est à moitié fait, et les supports de formation peuvent s'écrire pendant que le système est encore paramétré. Les dépendances début-à-début avec décalage expriment exactement cela. Elles raccourcissent honnêtement le plan, à condition de nommer le décalage dans la dépendance plutôt que de chevaucher discrètement les barres.
L'exemple ci-dessous est un plan de déploiement complet de seize tâches. Ouvrez le panneau tableur pour voir les dépendances, y compris les liens début-à-début.
Un plan de déploiement du lancement au passage de relais
Seize tâches et trois jalons. Ouvrez le panneau tableur pour voir les dépendances derrière chaque étape.
Lancement, besoins et point de passage de la conception
« Lancement du projet » dure 2 jours ouvrés et « Besoins et analyse des écarts » 10. « Conception validée » a une durée de 0 : c'est un jalon, et le paramétrage, la cartographie des données et le développement des intégrations l'attendent tous.
Des flux parallèles vers les tests
« Paramétrage du système » dure 20 jours, « Cartographie et nettoyage des données » 12 et « Développement des intégrations » 18. « Migration d'essai des données » démarre 10 jours après le début du paramétrage, et « Tests d'intégration système » attend le paramétrage, la migration d'essai et les intégrations avant que « Recette utilisateur » ne suive.
La formation chevauche le développement et les tests
« Supports de formation » est lié en début-à-début au paramétrage avec un décalage de 5 jours. « Formation des utilisateurs » attend les supports et démarre 3 jours après le début de « Recette utilisateur ». « Revue de préparation à la mise en production » est un jalon qui attend les tests et la formation.
Bascule, hypercare et passage de relais
« Migration finale des données » (3 jours) et « Bascule et mise en production » (2 jours) ne peuvent pas démarrer avant la revue de préparation. « Hypercare » dure 15 jours, et « Passage de relais au support » est un jalon qui clôt le plan.
Comment cela fonctionne
Commencer par les points de passage, pas par les tâches
Décidez où le projet a besoin d'une décision : la validation de la conception et la revue de préparation à la mise en production sont les deux habituelles. Ajoutez-les comme tâches de durée 0, ce qui les dessine en jalons.
Ajouter le travail entre les points de passage
Listez les besoins avant le premier point de passage. Entre les deux, listez le paramétrage, la cartographie des données, les intégrations, les supports de formation et les phases de test, chacun avec une durée estimée en jours ouvrés.
Relier les flux
Dans Dépend de, faites pointer le paramétrage, les données et les intégrations vers la validation de la conception. Faites pointer les tests d'intégration système vers les trois, pour que le flux le plus long apparaisse comme celui qui fixe la date.
Chevaucher là où le travail se chevauche vraiment
Utilisez SS et un décalage pour le travail qui peut démarrer tôt, par exemple 4SS+10 pour une tâche qui démarre 10 jours ouvrés après le début de la tâche 4. Vérifiez chacun avec la personne responsable du travail.
Ajouter la bascule et l'après-déploiement
Faites dépendre la migration finale des données et la mise en production de la revue de préparation, puis ajoutez l'hypercare et un jalon de passage de relais. Le plan est terminé quand le support est propriétaire du système, pas quand il est en production.
Activer le chemin critique et partager
Affichage, Chemin critique éclaire la chaîne qui fixe la date du passage de relais. Partagez le diagramme par lien ou exportez un PDF pour le comité de pilotage.
Erreurs à éviter
Traiter la migration des données comme une seule tâche
Une migration d'essai révèle des problèmes que la migration finale ne doit pas rencontrer. Dessinez les deux, et faites dépendre la finale de la revue de préparation.
Planifier la formation en dernier
Une formation qui commence après les tests ne laisse pas de temps pour corriger ce que les stagiaires découvrent. Chevauchez-la avec un lien début-à-début, comme dans l'exemple, et faites dépendre la décision de mise en production de celle-ci.
Laisser la date de mise en production au hasard
Si la mise en production est imposée par un contrat ou une clôture d'exercice, ne fixez que ce début et regardez le conflit signalé. Fixer toutes les tâches masque le vrai problème.
Attendre un suivi des ressources ou des coûts
QueryChart enregistre qui est responsable d'une tâche, mais n'alerte pas sur la surcharge, ne suit pas les coûts et ne compare pas à une référence de base. Gardez budget et capacité dans les outils qui les gèrent.
Planifier votre déploiement
Ouvrez le plan de déploiement comme votre propre diagramme, remplacez les tâches par les vôtres et partagez le planning avec votre comité de pilotage.
Guides associés
Questions fréquentes
Est-ce adapté aux projets ERP et CRM ?
Oui. La structure est la même pour tout système métier : conception, paramétrage, données, intégrations, tests, formation et bascule. Remplacez les noms de tâches de l'exemple par les vôtres.
Comment montrer que deux tâches peuvent se chevaucher ?
Utilisez une dépendance début-à-début avec décalage dans Dépend de, par exemple 4SS+10. La tâche démarre 10 jours ouvrés après le début de la tâche 4, que celle-ci soit terminée ou non.
Puis-je regrouper les tâches par chantier ?
Oui. Donnez un groupe aux tâches et elles sont dessinées en bandes avec une barre de synthèse : paramétrage, données et formation peuvent chacun former une bande.
Puis-je montrer qui est responsable ?
Oui, en ajoutant des personnes à chaque tâche. Le diagramme ne contrôle pas les charges et ne résout pas les conflits.
Puis-je importer depuis Microsoft Project ?
Non. Les fichiers Microsoft Project ne sont pas pris en charge. Vous pouvez copier des lignes depuis un tableur et les coller dans la feuille.
