@Thierry : Planning de bascule pour un « Go Live » réussi….. On est pas dans l’opérationnel HR mais dans la gestion de votre projet SIRH ou autre. Un de mes clients m’a demandé de faire une présentation aux équipes de ce qu’est un « Cutover Plan », autrement dit un plan de bascule pour le passage d’un ancien système de gestion vers un nouveau. J’ai essayé de faire simple et compréhensible. Qu’en pensez-vous ?….
Planning de bascule pour un « Go Live » réussi
C’est important pour le succès du projet
C’EST une partie de tout type de projet : implémentation, mise à jour version, rajouts de fonctionnalités,…,
DOIT faire partie intégrante dans la planification globale du Projet,
Doit inclure aussi bien les aspects techniques que fonctionnels et opérationnels métiers.
Objet de la cession :
Découvrez ce qui appartient à votre plan de bascule,
où s’inscrit-il dans le calendrier global,
et obtenez quelques aperçus rétrospectifs.
Qu’est-ce que le Cutover Plan (Plan de bascule) ?
•Le Plan de bascule (ou de transfert) est l’exécution des activités nécessaires pour réussir la migration des opérations de gestion des anciens systèmes vers le nouveau système de production.
Comment se déroule le Cutover ?
• La “Bascule” sera exécutée conformément au “Plan de Bascule » : un ensemble de tâches détaillées et séquencées pour construire le nouveau système de production, convertir et migrer les données, configurer le nouveau système et mettre hors service les anciens systèmes (jusqu’au décommissionnement complet).
• Les “Plans de Bascule simulés” (“Mock Cutover Plan” during “Conference Room Pilot”) sont utilisées pour pratiquer et valider le plan de bascule avant la mise en service et apporter des révisions avant la mise en service réelle (le GoLive). Il s’agit d’un moyen d’affiner le processus et de minimiser les risques avant le démarrage complet en production. On parle parfois de POC (Proof of Concept : Prouver le concept), ou « Pré-GoLive ».
• le “test de fumée” (Smoke Test) est réalisé avant le jour du démarrage du Go Live. Il consiste à vérifier et réaliser quelques opérations de contrôles afin de certifier le GoNoGO (C’est bon on peut démarrer).
Agenda de cette cession
1/ Etre « sûr » que vos données référentielles soient correctes et complètes. Envisager la charge de complétude au regard de la date de bascule envisagée.
2/ Faire le point sur la situation opérationnelle (marchandises à recevoir ou livrer, inventaires, facturation, …, changement de position d’un salarié, validation des congés et absences,…. et prendre une décision sur chaque process.
3/ Les données référentielles peuvent dépendre d’informations gérées en amont ou dans d’autres systèmes…
La situation opérationnelle, et leurs process, est très importante. Concernant la configuration et les listes de valeurs (LOV : List of Values), la base référentielle doit-être dans la mesure du possible figée au plus tôt. Si vous managez des bons de commandes, de livraison, de production et logistique, ou des besoins liés à l’humain (SIRH) vous devez prendre en compte l’impact que pourrait avoir cette migration et prendre en autre des décisions d’organisation liée à celle-ci.
Si votre temps de migration est important ou votre volumétrie, ou la date retenue est en plein milieu d’une semaine…, quelles sont les contraintes que vous devrez gérer et absorber : travailler en 3/8, le weekend, main d’œuvre complémentaire, délais de livraisons et productions,… L’inventaire sera t-il fini à temps? Comment gérer mes entrées sorties de stocks, etc… ne pas hésiter de discuter avec les End Users, ils sont souvent plus au courant que leurs managers (Key Users) des contraintes quotidiennes, des besoins clients et fournisseurs, ou de leurs collègues pour les ressources humaines….. Si vous devez repartir sur des soldes de congés, de RTT, des rdv programmés pour les entretiens annuels, de systèmes de GTA,…, compenser un weekend travaillé, plein de petites choses qui font un métier.
Mettre tout cela Noir sur Blanc, même un simple tableau sous Excel peut convenir. Partager cela avec tous les intéressés. Discuter et mettez à jour ce tableau au fur et à mesure de vos tests, pocs et investigations.
N’oubliez pas que ce plan de bascule concerne aussi bien les opérations à faire avant, pendant ET après. Les recettes à faire, les contrôles, les systèmes adjacents à relancer, les interfaces à activer, les clients à livrer en urgence ou les réceptions de marchandises à faire et contrôler, la qualité… et pour un système RH les compteurs de congés, les demandes en cours, les entretiens annuels programmés, les salaires et charges, interfaces GTA et Paie,…..
Pensez aussi aux opérations visant à stabiliser ou à faire évoluer votre solution. Si vous devez étaler une charge de travail, vérifier les performances techniques opérationnelles, les communications,…
Un bon dessin vaut mieux qu’un grand discours…. (Oui celui-ci est moche et vous pouvez faire mieux LoL)
On ne le dira jamais assez mais plus vous faites de tests, de simulations, de « pré-golive » ou POCS, mieux vous cernerez vos contraintes et diminuerez le temps de migration. Le terme CRP veut dire que vous réunissez toutes les personnes internes et externes dans la même pièce, que vous discutez des besoins, contraintes, plannings, durées,… et prenez en compte les résultats afin de ne rien oublier dans votre planning. Même une répétition à blanc, devant un tableau, fait progresser le dit-plan.
C’est sûr, plus vous aurez fait de tests et vérifications, mieux sera.
Un plan de bascule se prépare et se partage. C’est un vrai planning ou chacun doit trouver sa place et connaitre les tâches qu’il doit exécuter, quand et dans quels délais, et il doit informer des résultats l’équipe dédiée au Plan. Et je le redis par expérience les End-Users sont souvent plus informés que les « chefs » des opérations et contraintes à faire au quotidien….
Autre point très important : Il peut arriver que malgré vos tests, vos préparations, tout ce que vous avez pu penser et imaginer pour arriver au succès, un incident se passe et là catastrophe vous ne pouvez pas annoncer le GoNoGo. VOUS DEVEZ dans vos plannings rajouter un ROLLBACK, un retour en arrière. Prévoir que vous devrez redémarrer sur votre ancienne solution, les conséquences, les actions, les interfaces…. tout ce que vous aviez prévu de migrer doit redémarrer comme avant. OU envisager un démarrage en mode dégradé et toutes ses conséquences…..
Ce point doit être traité de manière sérieuse comme un PRA (plan de reprise d’activités), suite à un incident majeur.
On ne sera jamais d’accord sur l’outil utilisé, les templates, la couleur et autre, mais peu importe. Ce qui est important c’est que celui-ci soit partagé, discuté, mis à jour, versionné… et surtout n’oubliez pas vos sponsors !!!
Bon plan de Bascule
@Thierry : Bon je pense avoir établi une bonne base de travail et de réflexion. Encore « merci » à tous les contributeurs de cet article, (mes clients, collègues, partenaires et les +30 années sur le terrain)
J’ai un petit powerpoint sur le sujet. Si vous souhaitez le récupérer pour l’aménager à votre sauce, contactez moi sur https://www.linkedin.com/in/thierry-graulich
