LE PLAN DE MIGRATION INFORMATIQUE POUR UNE BANQUE

LE PLAN DE MIGRATION INFORMATIQUE

Le rachat d’une banque par un groupe bancaire peut exiger une migration  du système d’information  , d’un environnement d’origine  vers  le nouveau système d’information unique du Groupe bancaire. Doter un groupe bancaire d’un SI unique peut  permettre de réduire considérablement le budget informatique et de disposer d’une organisation et de procédures unifiées.

Par ailleurs, de nombreuses institutions bancaires doivent renouveler leur architecture informatique, devenue incapable de prendre en charge les nouvelles applications  ou le format mobile.

Une migration informatique ne s’improvise pas au risque d’obtenir un désastre.

Attention comme une migration informatique se fait rarement sans accroc et pour éviter que la migration de données vers un nouveau système ne tourne à la confusion générale, Il va falloir une longue et une rigoureuse phase de tests et une formation de qualité pour l’ensemble du personnel.

La durée totale de la préparation à la migration s’étale généralement sur une année complète.

30 étapes clés pour une migration réussie

L’école de la microfinance peut vous accompagner sur site à l’occasion d’une migration informatique.

Merci de cliquer ici pour toute information sur l’accompagnement des banques lors d’une migration informatique

notre adresse mail : contact@ecole-de-la-microfinance.com

Les 30 étapes pour la migration informatique d’une banque

1. Constater l’inadaptation ou l’impossibilité d’évoluer du  système d’information actuel ou encore si l’établissement bancaire appartient à un groupe, constater la nécessité de  rendre commun les systèmes d’information pour l’ensemble du groupe.
2. Choisir le nouveau système d’information en fonction des fonctionnalités bien sûr mais aussi des coûts ou encore de l’obligation de s’adapter aux nombreuses nouvelles réglementations concernant la profession bancaire. Un budget global, incluant la formation du personnel est décidé.
3. Décider en Comité Exécutif du choix d’un nouveau logiciel en remplacement d’un système inadapté ou jugé non évolutif. Dès lors la migration est un projet d’entreprise, stratégique et prioritaire qui devra être piloté au plus haut niveau de la banque.
4. Acquérir et mettre en route du nouveau logiciel, commencer à établir le paramétrage et définir les habilitations (géographiques, hiérarchiques, fonctionnelles…).
5. Créer un Comité en charge de la migration. L’équipe dédiée à la migration est constituée d’un pilote de la migration, d’informaticiens et d’experts de la comptabilité, du crédit, des services de traitement (chèques, effets, virements, prélèvements, gestion de portefeuille, cartes bancaires, ordres…) du contrôle de gestion, de la gestion des risques, du marketing…
6. Structurer l’équipe en groupe projets avec à chaque fois désignation d’un responsable du groupe projet.
7. Investir le pilote de la migration de la totale responsabilité du projet et du pilotage permanent des groupes projets. Il veille au respect scrupuleux du planning et peut être amené à demander des renforts complémentaires.
8. Décider de la date de la migration (le premier jour d’un mois ordinaire de l’année, c’est-à-dire ni une fin de trimestre ni une fin d’année) et on établit le retro planning.
9. Recenser l’ensemble des objets de gestion, toutes les éditions informatiques, les écrans mis à disposition
10. Abandonner, sur proposition des groupes projets, certaines fonctionnalités de l’ancien système jugées non nécessaires ou peu performantes,
11. Établir des cahiers des charges pour adapter le nouveau système en cas de fonctionnalités non prévues par le concepteur et jugées indispensables pour la banque ;Valider spécifiquement les accès au SIT, le SEPA (Single Euro Payments Area) en s’appuyant sur la normalisation des échanges interbancaires : utilisation du BIC, de l’IBAN et d’un identifiant du créancier basé sur le SIREN.
12. Mettre à jour tous les référentiels et prioritairement la table calendrier, la table de numéros des agences, la table des produits vendus, la tarification, le plan de compte de la banque.
13. Expliquer aux clients les nouvelles fonctionnalités qui deviennent disponibles. La migration ne doit surtout pas impacter le service à la clientèle, lequel doit continuer comme si de rien n’était.
14. Vérifier les écrans mis à disposition de la clientèle via leur connexion Internet ou EBICS. Une attention particulière lors des tests sur le cas de clients qui pourraient accéder aux comptes d’autres personnes, aux droits acquis sur des comptes d’épargne, aux compteurs fiscaux pour les comptes titres, ou encore à l’indisponibilité des comptes des mineurs, des personnes incapables ou des comptes dormants.
15. Réaliser des tests   dans chacun des groupes projets pour valider la bonne reprise de l’ensemble des données, et des résultats de traitements conformes aux attentes. On vérifie en particulier qu’aucune information n’est perdue dans le nouveau système et que les restitutions sont conformes aux besoins des utilisateurs. Des fiches sont établies en cas de constat d’un écart entre ce qui est attendu et ce qui est recetté.
16. Réunir les groupes projets et dénombrer les taches restant à effectuer. Désigner pour chaque tâche un responsable, et une date de réalisation au plus tard.
17. Mobiliser l’ensemble du personnel autour du projet : la migration est un événement qui va générer de nombreux changements organisationnels pour les utilisateurs et   va aussi apporter de nouvelles pratiques, de nouveaux documents, probablement des regrets de l’ancien système…La communication sur la migration doit donc être extrêmement bien préparée et faire l’objet d’informations précises durant toute la durée des travaux, tant envers l’encadrement qu’envers l’ensemble du personnel.
18. Anticiper les changements issus du nouveau SI qui vont entrainer en particulier la disparition de métiers et de tâches, des modifications de postes. La DRH doit être partie prenante afin de définir un plan global d’évolution des effectifs.
19. Choisir le mode de formation interne ou externe ou un panachage avec des relais de formation. Former des formateurs occasionnels.
20. Identifier de la façon la plus précise les traitements et des données qui vont effectivement être migrés, s’interroger en permanence sur les solutions retenues, sur les compétences nouvelles qui devront être acquises pour la maîtrise du système.
21. Migrer les données source vers le système d’information cible et à partir de ce moment les traitements seront réalisés en double (en réel avec l’ancien système et en test avec le nouveau système).
22. Comparer les résultats systématiquement entre les deux systèmes d’information au niveau quotidien, au niveau mensuel et en test sur une fin d’exercice. Les groupes projets établissent des cahiers de recette pour s’assurer que toutes les fonctionnalités sont bien reprises et fonctionnent.
23. Créer une batterie de test (création d’un client, mise en place d’un crédit, d’une garantie, d’un produit d’épargne.) qui permettront de valider que chaque participant à une action de formation est bien apte à utiliser les futures techniques.
24. Vérifier le contrôle de la traçabilité : la piste d’audit permet de vérifier comment le traitement des informations a permis de passer d’un stade à un autre stade. Il décrit les informations financières et non financières concernant les mouvements et les flux à chaque niveau d’exécution des opérations.
25. Donner après la formation à chaque personne formée un accès à un équipement sur le nouveau système pour ne pas perdre les bénéfices de la formation.
26. Préparer le jour de la migration par une mobilisation générale pendant les dernières semaines sous la forme d’un bulletin d’information associant un maximum de collaborateurs de la banque.
27. Effectuer une première bascule à blanc, pour permettre de faire le diagnostic de ce qui s’est bien passé, des anomalies et  mettre en place des actions correctives. Cette première bascule est essentiellement technique et permet de bien tester qu’on ne perd pas d’informations en allant vers le système d’information cible.
28. La seconde bascule à blanc, qui a lieu généralement un mois après la première,  permet de valider  le process technique, et de vérifier que toutes les anomalies détectées lors de la première bascule ont bien été corrigées.
29.  Définir le jour de la migration pour que rien ne soit laissé au hasard. Tous les documents issus des nouveaux traitements doivent être validés par les utilisateurs finaux. Toutes les équipes de migration seront sur le pont le jour de la migration et pourront devoir valider immédiatement des traitements réalisés de nuit. Ce sont les derniers contrôles après il sera trop tard.
30. Prévoir la création d’une équipe d’accompagnement post bascule afin de répondre aux inévitables questions des utilisateurs et aux anomalies qui ne sont détectées qu’après la bascule.

Le suivi du plan de migration se fait à l’aide d’un diagramme PERT. (où PERT-COST)

Pour vous inscrire à la formation cliquer sur le bouton :

S'inscrireFORMATION : " La migration informatique dans une banque ou un établissement de microfinance ".
Du 13 Mai 2024 au 17 Mai 2024; Nantes (France) à ().