Fusion-acquisition : Comment réussir la migration du Système d’Information ?

La migration du SI est l’une des étapes clefs du processus de fusion-acquisition dans la mesure où elle vise à ne retenir pour les deux parties fusionnées qu’un seul système d’information, à unifier les processus, les postes et les méthodes de travail et contribue, in fine, à la mise en œuvre d’une stratégie unique et cohérente pour l’entreprise résultante. 

Le projet consiste à migrer les données de l’entité source vers les référentiels et les bases de données du SI de l’entité cible, et à former les utilisateurs de l’entité source aux outils et aux processus « cibles ». La migration du système d’information d’un établissement bancaire ou assurantiel est un projet complexe, long et donc onéreux. Ainsi, lorsqu’elle n’est pas obligatoire (cas d’un SI obsolète ou développé par un cédant qui ne souhaite pas le maintenir au-delà d’un délai contractuel de quelques années) la migration du SI doit répondre à des objectifs précis et mesurables. Dans tous les cas la migration contribue pour beaucoup au rapprochement entre les entreprises fusionnées. S’il n’est pas nécessairement délicat d’un point de vue technologique, un projet de migration informatique est toujours très vaste puisqu’il concerne toutes les applications et processus informatisés, et donc tous les Métiers et finalement la quasi-totalité de l’activité et des personnels de la banque ou de la compagnie d’assurance « source ». L’étendue du périmètre d’un projet de migration de SI induit un niveau de complexité qui ne peut être abordé qu’avec une méthodologie rigoureuse et bien rodée. La plupart du temps un accompagnement externe sur le long terme est nécessaire pour la gestion de projet complexe, l’expertise fonctionnelle de la cible (architecture et métier), la validation fonctionnelle et la conduite du changement.

La migration du SI est un projet structurant aux bénéfices du moyen voire long terme

De nombreuses situations peuvent conduire à une migration de système d’information. Un SI aux technologies obsolètes, difficile et cher à maintenir, à l’architecture vieillissante qui rend chaque évolution risquée et longue à mettre en œuvre, un SI peu compétitif pour la fonction commerciale, inadapté pour les nouvelles réglementations ou les nouvelles technologies, etc. Une fusion acquisition appelle, quant à elle, une migration exhaustive du SI et des processus qu’il supporte. Seules les infrastructures (réseaux, data center, postes de travail) pourront être éventuellement réutilisées dans le nouveau système d’information. L’ampleur de ces modifications nécessite un effort de conduite du changement à déployer pour toute une entreprise avec un soin particulier donné au devenir de la DSI et aux équipes techniques du SI migré.

La contrepartie doit être de taille. La migration doit aboutir à une rationalisation des technologies utilisées, à l’uniformisation des processus et des traitements informatisés : on estime en moyenne qu’une migration de SI doit générer une économie d’environ 25% des coûts informatiques en mode Run. Elle doit permettre des économies d’échelles sur les investissements et le fonctionnement de l’informatique et des télécommunications, de tirer des bénéfices des synergies entre toutes les fonctions supports (et pas seulement IT). Ces gains doivent être mesurés et suivis. En harmonisant les postes et les méthodes de travail, la migration informatique contribue aussi à un objectif bien au-delà de la fonction informatique sur la fusion des entreprises ou le développement de coopérations Métier. Cet investissement très important, en effort de formation, notamment, contribue à l’embarquement des équipes vers la cible et à l’émergence d’une identité renforcée selon un principe « un plus un font plus que deux ».

La transparence sur ses objectifs précis et mesurables (SMART pour Spécifique, Mesurable, Acceptable et Ambitieux, Réaliste et Temporellement défini) permet de tordre le cou à une résistance courante des communautés informatiques qui qualifient volontiers les migrations de SI de « la même chose plus chère ». Cependant force est de constater que les projets de migration informatique accusent très souvent des dépassements de délais et de budget ! Imaginés comme de simples migrations de données (qui en réalité ne sont jamais simples) ils sous-estiment souvent les aléas inévitables d’un projet long et de large périmètre. La phase de recette est rarement appréhendée dans toute sa complexité fonctionnelle et technique. Le chantier de conduite du changement est limité à la formation et aux procédures alors que son volet communication (« newsletter », plénière, forum, etc.) doit entretenir la mobilisation des équipes tout au long du projet. En réalité, la migration de données statiques et la validation fonctionnelle de cette migration représentent en moyenne 50% du projet. Le reste de la charge comprend le paramétrage, la conduite du changement et la formation des équipes, la validation du fonctionnement sur la cible, la refonte des procédures et processus associés, les plans de sauvegarde et le suivi de projet.

L’initialisation d’un projet de migration

Le projet débute par la constitution d’une équipe de migration comprenant des experts fonctionnels de la source et de la cible, des représentants des Métiers pour la validation des spécifications et des recettes, un architecte et la maîtrise d’œuvre en charge de réaliser les développements ad hoc. La première étape opérationnelle consiste à réaliser une étude « As Is » et un « gap analysis » pour décrire dans le détail les écarts fonctionnels entre source et cible.

Lorsque sur une fonctionnalité donnée, la cible est plus riche que la source, il n’y a pas de nouvelle tâche pour la migration elle-même. Cependant, post-migration, un enrichissement des données migrées est à prévoir, pour qu’elles puissent bénéficier des nouvelles fonctionnalités de la cible.

À l’inverse, lorsque la source, amenée à disparaître, est plus riche fonctionnellement que la cible une étude détaillée est à mener. Les équipes Métiers doivent proposer différentes possibilités (développement spécifique sur la cible, intégration sur la cible d’un logiciel spécialisé, interfaçage avec la source, etc.) pour reprendre les fonctionnalités de la source inexistantes sur la cible, et estimer le coût et les délais de mise en œuvre pour chacune de ces possibilités. Cette reprise de fonctionnalité est souvent partielle, ou dégradée sous forme de contournement plus rapide et moins cher à déployer qu’une solution à l’identique de la source. L’étude doit également préciser les volumes et les caractéristiques business concernés. L’ensemble de ces éléments doit permettre au comité de pilotage de la migration de statuer sur la reprise ou non de ces fonctionnalités. Les abandons de service sont à instruire, avec le Métier concerné, au sein du chantier de conduite du changement pour tous les aspects de communication et de compensations éventuelles (avec, par exemple, la gratuité d’un produit de la cible inexistant sur la source) pour les clients pénalisés. Le comité de pilotage devra aussi prioriser entre elles, les fonctionnalités de la source qu’il décide de reprendre sur la cible, pour faciliter de futurs arbitrages, si nécessaire.

Habituellement, pour une migration de SI dans le cadre d’une fusion-acquisition, la maxime « adopter sans adapter » prévaut et l’effort consenti pour reprendre sur la cible certaines fonctionnalités de la source est bien moindre que celui nécessaire pour le chantier de reprise des données. Dans tous les cas, à l’issue de la phase d’étude d’écart qui dure de 1 à 3 mois, on doit parvenir à donner une vision complète de la transformation à mettre en œuvre. L’ensemble des chantiers et des sous-projets du projet de migration doit être clair, leurs coûts finement évalués, et le tout priorisé et ordonné dans le calendrier global du projet. Les équipes techniques doivent aussi avoir défini les moyens nécessaires à la réalisation du projet en termes d’infrastructures, d’environnements de développement, de recette et d’homologation, de logistique et de locaux.

Macroplanning et contenu d’un projet de migration classique :

Du big bang à la migration de multiples services

Face à aux risques d’essoufflement ou d’enlisement d’un projet long et complexe, on distingue deux approches radicalement opposées. La première vise à raccourcir au maximum la durée du projet pour prévenir l’érosion des motivations individuelles. Elle privilégie pour cela une bascule en « big bang » qui comprend le cœur du SI (les clients et les comptes) et les systèmes de gestions des différents produits bancaires ou assurantiels. On minimise les risques liés à une bascule de grande ampleur en effectuant des répétitions (bascule à blanc), en prévoyant et testant un avortement de la migration en cour de route et en organisant une période de production en parallèle pendant laquelle la production nominale reste celle du système source et est comparée à celle du système cible pour s’assurer que ce dernier fonctionne comme attendu. A l’inverse, la seconde approche consiste à lotir la migration du SI en de nombreux projets de migration de moindre ampleur chacun et donc moins risqués individuellement. Le premier lot concerne les clients et les comptes. Comme les systèmes de gestion des produits continuent à fonctionner sur le système source, il faut interfacer source et cible pour que les systèmes de gestion des produits, sur la source, disposent de la position comptable de la cible en temps réel et que les évènements sur les contrats de la source alimentent comptablement la cible. La reprise intégrale et complète de toute ou presque et en particulier selon une taille définie à temps des données contractuelles des différents produits peut ensuite être traitée produit par produit. L’avantage de cette approche est d’être moins risquée et progressive pour la conduite du changement (procédures et formation). Elle est cependant plus longue à finaliser et nécessite le développement d’interfaces « jetables ».

Qu’elle soit globale ou spécifique à un produit, dans le détail, la migration, à proprement parler, consiste à enrichir le système cible des données du système source. La première étape de cette migration de données consiste à analyser la localisation physique et le format des données, sources et cibles, pour établir une liste d’écarts. Une nomenclature peut être plus riche sur la source que sur la cible, ou l’inverse. Une donnée peut ne pas exister sur la source. Une donnée peut être représentée par un enregistrement ici et plusieurs là, etc. La profondeur d’historique à reprendre de la source doit aussi être déterminée. Elle dépend de la réglementation mais habituellement certaines données très anciennes ne sont pas migrées. Cette première étape d’analyse est également l’occasion d’identifier les problèmes de qualité de données sur le SI source pour viser à les résorber avant la migration voire ne pas migrer les données de qualité insuffisante ou qui pourraient créer des doublons.

La deuxième étape consiste à définir les règles de gestion et à écrire les programmes pour convertir les données de la source en données intelligibles et exploitables sur la cible. La bonjour je meuble en blanc pour l’unité migration des données nécessite parfois une renumérotation des identifiants client, des comptes ou des numéros de contrat. Ces renumérotations, lorsqu’elles sont incontournables, doivent être accompagnées par le Métier et la conformité dans un sous-projet du chantier de conduite du changement pour la communication auprès des clients. Il faut ensuite, dans une troisième étape, tester cette conversion avec des cas fictifs aussi variés que possible (embarquant idéalement tous les évènements de la vie du produit) puis avec les données réelles (qui évoluent quotidiennement…). La recette d’intégration et l’homologation consistent, avec le Métier, à généraliser les tests à plusieurs produits et à procéder à une recette dynamique, c’est-à-dire à simuler les traitements de bout en bout pour une journée d’exploitation, un week-end, une fin de mois, etc. A noter aussi que pour de petits volumes et une grande complexité (e.g. certains produits dérivés nécessitent jusqu’à 250 données pour un seul contrat !) il peut être plus efficace de ressaisir les contrats sur le SI cible plutôt que d’automatiser la conversion.

Ci-dessous un exemple de découpage du projet de migration du SI, pour une banque, selon les axes domaines Métiers et chantiers transverses :

Pour une banque, l’ordre de grandeur pour une migration en big bang est de 4 mois de cadrage et d’une dizaine de mois pour écrire et tester la migration des données jusqu’à la bascule. Cette dernière sera précédée d’une ou deux bascules à blanc. Hors licence logiciel, le coût global avoisinera les 15 000 jours homme mais pourra être significativement plus important pour la migration de produits complexes (e.g. produits de marché).

Pour une approche progressive, la durée du cadrage complet reste de 3 à 4 mois, mais la bascule du MVP (Minimal Viable Product), c’est-à-dire les référentiels, les clients et les comptes et l’écriture des interfaces dans les deux sens entre source et cible ne prend que 4 mois pour un coût d’environ 8 000 j*h (cadrage et MVP). La migration des produits simples (épargne, cash management, etc.) se réalise (écriture et recette) en 2 mois pour un coût d’environ 1000 j*h par produit. Les produits moyennement complexes (crédits, moyens de paiements monétiques, etc.) nécessitent 3 mois pour 1500 j*h unitairement. La plupart de ces sous-projets peuvent être parallélisés et le coût global sera de l’ordre de 20 000 j*h.

Les clefs du succès

Le premier élément pour assurer le succès d’un projet aussi long et aussi impactant qu’une migration de SI est un sponsor de niveau Comité Exécutif, voire Direction Générale selon la taille de l’entreprise. Le deuxième élément est un pilotage par les Métiers. La migration répond à l’objectif stratégique de la Direction Générale d’unifier les SI mais aussi à l’objectif opérationnel de permettre aux Métiers d’utiliser les mêmes outils et de suivre les mêmes processus.

Au quotidien, le projet doit être mené par une équipe dédiée, stable, si possible, tout au long de la migration. Pour assurer une stratégie de croissance externe, certaines institutions disposent même d’une équipe experte de la cible qui multiplie efficacement les projets de migration… Confier ensuite la responsabilité de la migration à un chef de projet externe à l’entreprise est un gage d’impartialité et de pragmatisme avec le résultat, dans le respect des coûts et des délais, comme seul objectif. L’équipe de migration doit inclure des membres influents de la partie source pour faciliter la compréhension des données à migrer mais aussi rompre les réticences et entraîner dans leur sillage un maximum de personnes vers la cible et donc faciliter la mise en œuvre du principe « adopter sans adapter ».

Comme tout projet d’envergure, la migration doit être pourvue des instances de gouvernances nécessaires pour suivre le budget et prendre les décisions visant à prévenir les risques sur les délais et les coûts, le périmètre et la qualité.

La phase de recette est primordiale. Elle doit, bien entendu, faire l’objet d’une stratégie propre et doit rechercher une certaine industrialisation vis-à-vis du nombre de produits à migrer. L’ensemble des phases de recette doit être coordonné via un calendrier global de recette qui doit embarquer de plus en plus de produits et de fonctions pour chaque cycle. Les phases avancées de la recette doivent se faire avec le Métier et servir à la prise en main des outils du SI cible. La migration et la (les) bascule(s) doivent aussi être décrites dans une stratégie de bascule, suivie, éventuellement, d’une description précise d’une phase de marche en parallèle.

L’investissement dans la conduite du changement doit être proportionné à l’ampleur du projet et donc conséquent. Tout au long du projet pour informer et motiver en toute transparence puis, classiquement pour les procédures et la formation aux nouveaux outils. L’aspect réticence au changement doit être abordé en mettant en avant les bénéfices mesurables attendus de la migration mais aussi sans éluder la perte de certaines fonctionnalités, de certaines automatisations absentes du SI cible et que le comité de pilotage a choisi de ne pas reprendre. Le reclassement des équipes IT de la source est aussi un des enjeux primordiaux du chantier de conduite du changement qui justifie, à lui seul, des moyens spécifiques comme le recourt à une expertise dédiée. Il doit démarrer dès le début du projet avec des objectifs clairs et transparents vise à vis des Instances Représentatives du Personnel.

Enfin, d’un point de vue architecture, un SI cible urbanisé et muni de référentiels (clients, produits, tarifs, organisation et processus, etc.) facilitera grandement l’intégration des données du SI source. En effet, les référentiels prévoient généralement des traitements de masse pour l’intégration de données externes et la détection automatisée des doublons et les architectures ouvertes, faites de web services ou s’appuyant sur un ESB (Entreprise Service Bus) permettent d’intégrer rapidement de nouvelles applications ou de nouveaux flux de données, par exemple pour l’intégration progressive des applications du SI source ou pour une période de marche en parallèle.