Lost In Legacy?

Lost In Legacy?

Source photo : "Lost in Translation" de Sofia Coppola

Traiter itérativement sa dette technique grâce à l’Obeya

Ce n’est pas la suite du fabuleux film de Sofia Coppola mais plutôt le récit d’une DSI sous tension et confrontée au poids du « legacy » de son patrimoine IT ralentissant ses transformations. Décidée à tenir ses engagements, elle implémente alors une « Obeya pilote » de programmes IT.

L’histoire se déroule dans une compagnie d’assurance dont le SI de gestion opérationnelle des contrats couvre plutôt bien l’ensemble de ses besoins métier. Il s’est construit au fil de la croissance de la société par une suite de fusions-acquisitions successives. Après quinze ans, la cartographie applicative de la gestion opérationnelle s’apparente à un assemblage complexe de strates logicielles, héritage issu des entités d’origine.

Chacune des cinq entités juridiques du groupe possède son propre SI de gestion des contrats client répondant  aux exigences spécifiques de cinq catégories d’offres d’épargne (prévoyance, retraite supplémentaire, prévoyance individuelle, épargne individuelle, rentes retraite individuelle) comme présentée sur la figure #1:

Figure #1 : cartographie simplifié du SI Gestion des contrats client

Par ailleurs, pour corser une situation déjà complexe, le domaine Banque-Assurance subit l’accélération des réglementations comme celles relatives à la gestion des contrats en déshérence et de la recherche de leurs bénéficiaires. La conjonction de ces deux contextes a mis en exergue l’hétérogénéité des couches applicatives dédiées à la gestion des données des personnes et la complexité de leur intégration dans un écosystème IT global.

Chief engineer, j’ai d’abord commencé par comprendre la valeur réellement attendue par les utilisateurs impliqués :

« Comment retrouver immédiatement et simplement la trace d’un bénéficiaire d’un contrat dans ce méli mélo ? Pourquoi un gestionnaire d’une entité ne pourrait-il pas accéder aux informations bénéficiaires des autres silos ? »

La « core team » a ensuite réfléchi à construire la solution correspondante par petites itérations, de façon modulaire et évolutive.

A/ Le point de vue du client : Comment développer la polyvalence inter-entités et redonner de la sérénité aux utilisateurs en  modifiant étape par étape le « legacy » informatique ?

L’affichage de l’existant applicatif dans l’Obeya a rendu visible le cloisonnement des gestionnaires par entité d’origine. Ces derniers font remonter que les notaires se plaignent que trois mois c’est trop long pour retrouver un bénéficiaire. Les gestionnaires passent leur temps à s’échanger des mails car  ils n’accèdent qu’aux contrats de leur silo par le logiciel correspondant. Comme le montre de façon schématique la figure#2, deux options informatiques sont finalement étudiées :

  • Option A-1 : les contraintes de l’héritage patrimonial informatique freinent le développement des capacités à gérer des dossiers client issus d’autres entités.
  • Option A-2 : en participant à la réalisation de la vision d’entreprise avec l’aide des métiers, le patrimoine informatique s’aligne sur les nouvelles exigences utilisateur et évite de se transformer en dette technique.

Figure #2 : 2 options pour gérer les bénéficiaires en cassant les silos

L’Obeya a aussi permis d’obtenir l’approbation des  Top Managers en seulement une semaine et d’opter pour un référentiel commun (figure #2, option A-2) centralisant les informations de tous les bénéficiaires indépendamment des applications en silos. En mutualisant les données bénéficiaires issues des processus métier, en deux mois, ce choix a permis aux utilisateurs :

  • De concrétiser la valeur attendue la plus importante : « on met enfin des outils qui nous permettent vraiment de travailler en transverse »,
  • De collaborer dans la sérénité, de partager en temps réel, d’apprendre ensemble, de standardiser et d’unifier les diverses pratiques des gestionnaires,
  • De réduire les temps de recherche des bénéficiaires de 3 mois à 1,6 mois en moyenne en démultipliant les chances de les retrouver.

En outre, cette nouvelle plateforme de management des bénéficiaires a constitué le M.V.P. (Minimal Viable Product) tout en donnant de la visibilité sur le nouveau SI cible de gestion opérationnelle visant l’unicité de l’occurrence de la donnée plutôt que son éparpillement.

B/ Le point de vue de la DSI sur le Produit : faut-il créer un nouvel outil ou converger vers un outil modernisé ?

La plateforme « bénéficiaires » appartenant à la classe des bases personnes (BPO sur la figure #2), la « core team » constituée de quatre experts fonctionnels et techniques a d’abord commencé par évaluer ensemble en Obeya ces cinq BPO existantes. Leur redondance engendre un nouveau niveau de complexité dans l’étude de ces BPOs disparates.

Trois options aux architectures techniques concurrentiels ont alors été dessinés, affichés et analysés dans l’Obeya :

B-1) La création d’une nouvelle BPO et d’une nouvelle couche applicative s’appuyant sur les technologies cibles

B-2) La création d’une nouvelle instance dans la BPO de l’entité #1(BPO la plus robuste) et upgrade de deux couches techniques associées

B-3) La création d’une nouvelle instance dans la BPO de l’entité #1 sans upgrade.

La solution B-2) a été sélectionnée selon:

  1. La satisfaction utilisateur : elle répond exactement aux besoins produit des utilisateurs des 5 entités
  2. La réutilisabilité, maintenabilité et évolutivité du S.I.: elle était mise en œuvre simplement en s’appuyant sur la mise à niveau de la BPO de l’entité #1 en cohérence avec l’architecture cible fondée sur des « Master data » essentielles au pilotage transverse des processus métier.
  3. Le délais de mise en place : elle nécessitait une mise en place de six semaines au lieu trente deux semaines pour B-1 ou 4 semaines pour B-3
  4. Le coût de la solution : elle occasionnait un investissement inférieur au « target cost » sans engendrer un cout de maintenance supplémentaire

En capitalisant sur la valeur du périmètre BPO du  S.I. de l’entité #1 et sur la mise à niveau technique des versions de middleware et SGBD, le MVP a valorisé les exigences client et soutenu la modernisation, la robustesse, la maintenabilité et l’évolutivité du patrimoine technique. Ce n’est pas qu’une question d’obsolescence technique mais aussi de compréhension de la véritable valeur du service attendue par les utilisateurs. Dans cette perspective, l’Obeya factualise les réflexions et guide les actions des experts métier et techniques en  travaillant ensemble, en levant ensemble un par un les obstacles pour concevoir et  livrer à temps le meilleur produit. En bref, elle permet de construire une connaissance dynamique, commune et partagée de la situation actuelle du legacy jusqu’au produit cible .

Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous avec le formulaire ci-dessous !


Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s