Flux du processus de bascule ERP (de la répétition à l'hypercare)
Flux modifiable de bascule ERP pour une mise en production SAP, Oracle, Dynamics 365 ou NetSuite : bascule à blanc, gel du système historique, chargement, validation de la réconciliation, go/no-go, retour arrière et hypercare.
Qu'est-ce que le processus flux du processus de bascule ERP (de la répétition à l'hypercare) ?
Un plan de bascule est en général un tableur de plusieurs centaines de tâches, et il doit l'être, car le détail compte. Ce que le tableur montre mal, c'est la forme du week-end. Il y a les points de passage où le travail s'arrête jusqu'à ce que quelqu'un signe, et les chemins qui s'enclenchent quand un point de passage échoue. C'est ce que le comité de pilotage doit comprendre avant la mise en production, et ce que l'équipe doit avoir répété.
Ce modèle dessine cette forme. Une bascule à blanc qui peut échouer et reboucler. Une réconciliation que le métier doit signer. Une décision go/no-go dont les critères sont convenus à l'avance, et un chemin de retour arrière qui aboutit à une mise en production reportée plutôt qu'à une course contre la montre. Puis l'hypercare avec ses critères de sortie, pour qu'elle s'arrête sur des preuves et non sur une date.
Il convient à tout ERP, qu'il s'agisse de SAP S/4HANA, d'Oracle Fusion, de Dynamics 365, de NetSuite ou d'un système plus modeste. Renommez les couloirs selon les rôles de votre projet, gardez le runbook détaillé dans votre plan de projet et servez-vous de ce flux pour expliquer et approuver les points de passage.
Ce que couvre cet organigramme
Dans ce modèle
- La référence du runbook de bascule et une ou plusieurs bascules à blanc, avec des objectifs de durée et d'anomalies
- Le gel des transactions et des données de base dans le système historique
- L'extraction des soldes et des postes ouverts finaux, le chargement des données de base et des transactions, et la bascule technique des interfaces et des traitements
- La réconciliation métier des données chargées, avec un chemin de rechargement lorsque des écarts sont constatés
- La décision go/no-go, le plan de retour arrière, l'ouverture du nouveau système et les critères de sortie de l'hypercare
Quand utiliser ce modèle
- Vous planifiez la mise en production d'un ERP et le comité de pilotage doit approuver les points de passage
- Le plan de bascule existe sous forme de liste de tâches et personne ne sait expliquer les points de décision
- Une mise en production précédente n'avait pas de critères de retour arrière convenus et vous voulez les définir à l'avance
- Vous menez un déploiement par phases et il vous faut un schéma de bascule reproductible pour chaque pays ou site
Comment cela fonctionne
Renommer les couloirs selon les rôles du projet
Alignez les couloirs sur le responsable de la bascule, les utilisateurs clés métier, l'équipe de migration des données, les équipes techniques et le comité de pilotage ou comité de mise en production.
Écrire vos critères go/no-go
Placez les critères convenus dans la note de la décision : réconciliation signée, aucune anomalie de sévérité 1 ouverte, support en place, retour arrière toujours possible.
Fixer les objectifs de répétition
Écrivez les objectifs de durée et d'anomalies sur la décision de la bascule à blanc, et prévoyez au moins deux répétitions pour une grande mise en production.
Relier le runbook détaillé
Joignez ou reliez le runbook au niveau des tâches aux étapes concernées pour que le flux reste lisible et que le détail reste à un seul endroit.
Approuver le plan
Envoyez le flux en approbation au sponsor du programme et aux propriétaires de processus. La version approuvée est votre trace de ce qui a été convenu.
Questions fréquentes
Qu'est-ce qu'un plan de bascule ERP ?
C'est le plan détaillé du passage du système historique au nouvel ERP. Il couvre le gel de l'ancien système, le chargement des données finales, le basculement des interfaces et des utilisateurs, et la confirmation que le nouveau système est correct avant que les équipes ne s'y mettent à travailler. Il comprend les responsables, les durées, les dépendances, les points de validation et un plan de retour arrière.
Que doivent contenir les critères go/no-go ?
Les critères habituels sont une réconciliation des données validée par le métier, aucune anomalie de sévérité 1 ouverte et une liste convenue des problèmes connus de sévérité 2, 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 dans la fenêtre de bascule.
Combien de bascules à blanc faut-il mener ?
Au moins une répétition complète avec des données proches de la production et le vrai runbook, et en général deux ou trois pour une grande implémentation. Chaque répétition doit être chronométrée et comparée aux objectifs, et le runbook mis à jour avant la suivante.
Quand l'hypercare prend-elle fin ?
Lorsque les critères de sortie convenus sont atteints, et non à une date fixe. Les critères courants sont un volume de tickets en baisse, aucune anomalie de sévérité 1 ouverte et la première clôture mensuelle réalisée dans le nouveau système.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Processus de mise en œuvre de logiciels d'entreprise.
Précède
- Processus de mise en œuvre de logiciels d'entreprise — Modèle de mise en œuvre de logiciels d'entreprise couvrant la découverte, les exigences, la conception, la configuration, l'intégration, la migration des données, les tests, l'UAT, la mise en service, l'hypercare et le transfert.
- Flux du processus de migration de SAP ECC vers S/4HANA — Flux modifiable de migration de SAP ECC vers S/4HANA : Readiness Check, analyse du code spécifique, fit-to-standard, choix brownfield, greenfield ou transition sélective de données, tests et bascule de conversion.
- Flux du processus de migration de Dynamics AX 2012 vers Dynamics 365 — Flux modifiable de migration de Dynamics AX 2012 vers Dynamics 365 Finance et SCM : analyse Lifecycle Services, choix entre migration et réimplémentation, code en extensions, migration des données, recette et mise en service.