Retour au blogue
Publié le 28 juin 2013
Rédigé par Talan SAP

Capsule #5 : Les principes de base pour la préparation d'un plan de basculement (cutover) (1ière partie)

Le basculement (cutover) consiste en la migration finale de la configuration et des données vers le système productif de votre nouvelle solution. Le premier défi est de bien planifier la transition des principaux processus de l’ancien système vers le nouveau. Le deuxième défi réside dans la reprise dans le nouveau système de l’inventaire de l’ancien à un moment bien précis. Considérant qu’il n’est pas toujours possible pour une entreprise d’arrêter ses opérations pendant une période donnée, le transfert de l’inventaire peut représenter un bon défi puisque durant la transition, il pourrait toujours y avoir des mouvements de marchandises, matières premières, fournitures de production, produits finis, etc.

Voici les principes de base qui, à notre avis, contribueront à orchestrer de main de maître un go live des plus harmonieux


1. Nommer une personne responsable de la coordination

Environ 8 à 12 semaines avant le go live, une personne responsable de la coordination du plan de basculement doit être identifiée. Idéalement, cet individu est le même que celui qui a été nommé responsable de coordonner la conversion de données. Il travaillera donc de concert avec l’équipe de projet ainsi que les départements opérationnels pour bâtir, coordonner et communiquer le plan de basculement (cutover). Celui-ci devra être intégré pour chacun des grands processus et prendre en compte les besoins et les réalités de chacun.


2. Établir des accommodations d’opérations

Environ 8 semaines avant le go live, le coordonnateur commence à rencontrer chacun des départements opérationnels (expédition, bureau de commande, production, achats, comptabilité, etc.) pour discuter des accommodations possibles dans leur département afin de minimiser les mouvements de marchandises et de faciliter la transition des grands processus de l’ancien système vers le nouveau. À cette étape, des joueurs clés (bien souvent des superviseurs) sont identifiés en tant que responsables d’appliquer les accommodations le temps venu.

Un exemple d’accommodation serait de saisir toutes les nouvelles commandes clients comportant une date de livraison requise antérieure au go live dans l’ancien système et de créer les nouvelles commandes clients avec une date de livraison requise après le go live directement dans le nouveau système. Un autre exemple serait d’arrêter la production, les réceptions et les expéditions pendant 2 jours durant lesquels un décompte d’inventaire physique aurait lieu et l’inventaire serait chargé dans le nouveau système.


3. Mettre en place des procédures de contingence

En cas de problème majeur avec le système durant le basculement, il est important que les principaux processus (expédition, réception, mouvement dans l’entrepôt, etc.) puissent opérer en mode contingence. Pour ce faire, il est important de bâtir des formulaires pour prendre en note toutes les informations qui devront être reprises dans le système une fois les problèmes corrigés. Il est pertinent de mentionner que ces formulaires de contingence pourront servir dans le futur en cas d’ennuis avec le système (ex : panne de courant, bug, problème de serveur,etc.). Aussi, il est possible que certains de ces formulaires soient utilisés durant le basculement, particulièrement si des mouvements de marchandises se produisent durant la reprise de l’inventaire dans le nouveau système. Principalement, on souhaite avoir une image fixe à un moment précis dans l’ancien système (legacy). Pour ce faire,  il serait possible de prendre en note les mouvements de marchandises sur les formulaires de contingence et de reprendre les transactions dans le système une fois l’inventaire chargé et réconcilié dans le nouveau système.


4.  Faire une répétition générale

Tel que mentionné dans la dernière capsule #4, réaliser une conversion de données complète au cours d’une répétition générale dans un mandant isolé du système de qualité ou bien dans un système de validation, une ou deux semaines avant le go live, fournira un bon filet de sécurité. Du moins, elle sera nécessaire pour le chargement et la valorisation de l’inventaire. La répétition générale complète permet, entre autres, de valider les prérequis, la séquence et les temps estimés des activités du plan de basculement dans le but de s’assurer que la planification est adéquate.

De par nos expériences passées, nous avons pu constater que dans un projet où il y a beaucoup de passerelles (interfaces) entre le nouveau système et des systèmes existants (ex : MES), il est très payant de pratiquer l’initialisation de ces interfaces durant une répétition générale. Bien souvent, on découvre des embûches qui auraient ralenti voire même compromis le bon déroulement du plan de basculement (enjeu de sécurité sur les systèmes existants, étapes de mise en production manquantes, etc.).  Une bonne répétition générale, faite avec rigueur, diminue considérablement les risques lors du basculement vers le nouveau système. 

Continuez à nous suivre pour en apprendre davantage sur les principes de base de la préparation d’un plan de basculement lors de notre prochaine capsule d’information.

Capsule #1: Introduction à la conversion des données

Capsule #2: Comment bien démarrer une conversion de données

Capsule #3: Les facteurs clés de succès d'une conversion de données (1ière partie)

Capsule #4 : Les facteurs clés de succès d'une conversion de données (2e partie)

Ces articles pourraient aussi vous intéresser
Author slug - talan-sap
Talan SAP
 
Talan SAP
Publié le 16 janvier 2024