Comment créer un plan de bascule ERP
Comment créer un plan de bascule ERP pour une mise en production SAP, Oracle, Dynamics 365 ou NetSuite : répétitions, gel du système historique, chargement et réconciliation, critères go/no-go, retour arrière, hypercare.
Un plan de bascule ERP est le runbook du week-end où l'entreprise passe de l'ancien système au nouveau : ce qui s'arrête, ce qui est chargé, qui signe et ce qui se passe si tout dérape.
En bref
- Répétez la bascule au moins une fois avec des données proches de la production et chronométrez-la.
- Gelez le système historique avant l'extraction finale et dites ce qui est gelé.
- Chargez les données de base avant les transactions ouvertes, puis réconciliez les deux.
- Convenez à l'avance des critères go/no-go et du plan de retour arrière.
- Terminez l'hypercare sur des critères de sortie et non sur une date.
Planifier les points de passage et pas seulement les tâches
Un plan de bascule commence généralement comme une liste de tâches, et cette liste détaillée compte : plusieurs centaines de tâches avec responsables, durées et dépendances. Mais une mise en production échoue rarement parce qu'une tâche manquait. Elle échoue parce qu'un point de passage était flou. Personne n'avait convenu de ce que « réconcilié » voulait dire, les critères go/no-go ont été décidés dans la nuit, ou le plan de retour arrière n'existait que sous la forme d'une phrase sur une diapositive.
Planifiez donc d'abord les points de passage. Dessinez la bascule comme un flux de processus qui contient les points de décision : objectifs de répétition atteints, réconciliation signée, go ou no-go, sortie d'hypercare. Convenez des critères de chacun avec le comité de pilotage plusieurs semaines avant la mise en production. Construisez ensuite la liste détaillée des tâches sous chaque phase.
L'exemple ci-dessous est une bascule ERP générique qui vaut pour SAP S/4HANA, Oracle Fusion, Dynamics 365 ou NetSuite. Il montre les points de passage et les chemins qui s'enclenchent quand l'un d'eux échoue.
Une bascule ERP avec ses points de passage
Du runbook figé au passage de relais. Observez les quatre décisions : répétition, réconciliation, go/no-go et sortie d'hypercare.
Répéter jusqu'à tenir dans la fenêtre
La bascule à blanc exécute le vrai runbook sur une copie de la production et est chronométrée. Si elle manque les objectifs de durée ou d'anomalies, le runbook est corrigé et la répétition recommence. Deux ou trois répétitions sont normales pour une grande mise en production.
Geler, extraire et charger
Les transactions métier et les modifications de données de base s'arrêtent dans le système historique, les soldes et les postes ouverts finaux sont extraits, les données de base sont chargées avant les transactions, et l'équipe technique bascule les interfaces, les traitements par lots et les habilitations.
Réconcilier et signer
C'est le métier, et non l'équipe données, qui réconcilie les volumes d'enregistrements et les soldes avec le système historique, puis signe. Les écarts retournent à l'équipe données pour correction et rechargement. Cette signature est le point de passage le plus important du plan.
Go ou no-go
Le comité de pilotage décide sur la base de critères convenus à l'avance. Un no-go déclenche le plan de retour arrière et une nouvelle date, ce qui est une issue prévue et non un échec du projet.
Ouvrir le système et lancer l'hypercare
Les utilisateurs se mettent au travail, l'équipe de support trie les tickets chaque jour, et l'hypercare s'achève lorsque les critères de sortie sont atteints, ce qui inclut généralement la première clôture mensuelle dans le nouveau système.
Comment cela fonctionne
Dessiner d'abord les points de passage
Commencez par un flux de processus des phases de la bascule et des décisions qui les séparent : objectifs de répétition, validation de la réconciliation, go/no-go et sortie d'hypercare. Convenez-en avec le comité de pilotage avant d'écrire les tâches.
Rédiger le runbook détaillé
Sous chaque phase, listez chaque tâche avec son responsable, son prédécesseur, son début prévu, sa durée et la personne qui confirme qu'elle est terminée. Incluez les tâches métier comme les inventaires de stock et la dernière facturation, pas seulement les tâches techniques.
Définir ce qui est gelé et quand
Notez quelles transactions et quelles données de base s'arrêtent dans le système historique, à partir de quelle heure, et ce que fait le métier entre-temps, par exemple des commandes manuelles ou des expéditions sur papier.
Planifier le chargement des données et la réconciliation
Ordonnez le chargement (données de base, puis postes ouverts et soldes), définissez les états de réconciliation de chaque objet et nommez le responsable métier qui signe chacun.
Convenir des critères go/no-go et du plan de retour arrière
Écrivez des critères mesurables et le dernier moment où le retour arrière reste possible. Répétez les étapes du retour arrière comme celles de la bascule.
Répéter et affiner
Menez au moins une bascule à blanc complète avec des données proches de la production, chronométrez chaque tâche et mettez le plan à jour. Recommencez jusqu'à ce que la bascule tienne dans la fenêtre avec de la marge.
Erreurs à éviter
Des critères décidés dans la nuit
Si les critères go/no-go ne sont pas convenus à l'avance, la décision devient une négociation sous pression. Convenez-en plusieurs semaines avant.
Un plan purement technique
Les plans de bascule rédigés par la DSI oublient des tâches métier comme les derniers inventaires de stock, les commandes d'achat ouvertes et la communication aux clients. Chaque domaine métier a besoin de ses propres tâches dans le runbook.
Aucune répétition
Une bascule jamais chronométrée ne tiendra pas dans la fenêtre. La première répétition dure presque toujours plus longtemps que prévu.
Un retour arrière pensé après coup
Un plan de retour arrière jamais testé n'est pas un plan. Connaissez le point de non-retour et répétez les étapes qui le précèdent.
Ouvrir le flux de bascule ERP
Ouvrez le flux de bascule comme votre propre schéma, écrivez vos critères go/no-go sur la décision et envoyez-le au comité de pilotage pour approbation.
Guides associés
Questions fréquentes
Que contient un plan de bascule ERP ?
La liste chronométrée des tâches pour passer du système historique au nouvel ERP, avec responsables et dépendances, le gel du système historique, l'extraction, le chargement et la réconciliation des données, le basculement technique des interfaces et des traitements, les tâches métier comme les inventaires, les critères go/no-go, le plan de retour arrière, la communication et les dispositions d'hypercare.
Combien de temps dure une bascule ERP ?
La fenêtre de bascule elle-même dure en général d'un week-end à une semaine, selon les volumes de données et le nombre de sites qui démarrent en même temps. La planifier et la répéter demande plusieurs mois, à partir de la phase de construction.
Quels sont les critères go/no-go habituels ?
Une réconciliation des données validée par le métier, aucune anomalie de sévérité 1 ouverte, une liste convenue de problèmes connus de moindre sévérité, des utilisateurs formés, un support et une hypercare pourvus en personnel, des interfaces testées de bout en bout, et la confirmation que le retour arrière reste possible.
Qu'est-ce que l'hypercare après la mise en production ?
Une période de support intensif juste après la mise en production, en général de quatre à huit semaines, avec un tri quotidien des tickets, l'équipe projet disponible et des corrections rapides. Elle s'achève lorsque les critères de sortie convenus sont atteints et que le support passe à l'équipe d'exploitation courante.