Bâtir un système homogène mais utilisable par plusieurs entités, dans plusieurs pays, impose des règles précises. Pour éviter que les coûts ne dérapent et que le spécifique ne prenne le dessus sur un système « core ».
Une entreprise internationale est composée de dizaines de filiales qui ont nécessairement des activités en commun. Avec, souvent, chacune leur propre système d’information et leur propre budget IT. Au niveau global, on se doute que cette configuration est inflationniste.
L’une des voies pour réduire à la fois la complexité et les coûts consiste à mutualiser en développant un système multi-entités, capable de fonctionner dans le contexte de plusieurs organisations.
« De plus en plus d’entreprises s’orientent vers des systèmes d’information multi-entités, qui ont trois objectifs : rationaliser, rationaliser et rationaliser », résumait Ludovic Cinquin, directeur général adjoint d’Octo Technology, lors de la dernière Université du système d’information organisé par le cabinet de conseil.
Cette rationalisation se traduit par une homogénéisation des pratiques, pour réduire les coûts. « Ce n’est clairement pas un vecteur d’innovation mais, mettre en place une stratégie pour identifier les bonnes pratiques et les généraliser crée de la valeur », ajoute Ludovic Cinquin, qui rappelle quelques chiffres clés, issus d’études menées par le Standish Group : 60 % des projets de moins de 500 000 euros sont des succès mais seulement 2 % des projets de plus de sept millions d’euros sont des succès, c’est-à-dire qu’ils se terminent sans dépassement de coût et de délais.
« Le coût des systèmes croît de façon exponentielle par rapport à leur taille, plus précisément, une augmentation de 25 % en taille produit une augmentation de 100 % du coût », rappelle Ludovic Cinquin. C’est là le paradoxe des systèmes multi-entités : « Construire un système multi-entité c’est faire plus gros pour dépenser moins en augmentant le risque de dépenser plus », estime Ludovic Cinquin.
BNP Paribas Securities Services (BP2S), spécialiste de la gestion des titres (900 clients, 6000 collaborateurs) a initié, dès 2001, l’élaboration d’un système d’information multi-entités (le projet AceTP), compte tenu de plusieurs contraintes techniques : des applications multibranches, un traitement massif de messages et l’intégration de plus de 70 systèmes, avec plus de 100 formats différents.
« Sur le plan stratégique, il s’agissait d’accompagner le développement du métier et de rationaliser l’organisation opérationnelle. Sur le plan fonctionnel, l’objectif était de refondre le système de compensation-règlement, cœur de notre métier, avec un système core à 75 % », explique Frédéric Beaudrée, responsable de l’équipe de développement BNP Paribas Securities Services.
Un projet à dimension internationale : le système a été déployé en Allemagne (Francfort) en 2005, en Italie (Milan) en 2006, en Pologne (Varsovie) et en Hongrie (Budapest) en 2008, 2009 étant l’année du déploiement en Asie. La stratégie de BP2S a reposé sur trois axes. D’abord, il s’agit de démarrer le plus simplement possible : « Il faut identifier une première entité dotée d’un périmètre fonctionnel significatif et d’une masse critique pour montrer que tout fonctionne correctement », conseille Frédéric Beaudrée.
Ensuite, il importe de généraliser au plus tôt : « Nous avons démarré une deuxième branche, Milan, avant la fin des développements à Francfort, au moment de la phase de recette, avec les mêmes équipes de développement », ajoute Frédéric Beaudrée. Enfin, il s’agit de « conquérir de nouveaux territoires, nous ajoutons deux pays par an ».
L’étape suivante consiste à entamer un mouvement de convergence : « Le principal enjeu concerne les modèles de données et, avec la phase de recette, il nous a fallu un an pour converger les deux branches sur un système core », rappelle Frédéric Beaudrée.
Intégrer les différences culturelles
Si les difficultés techniques, voire organisationnelles, peuvent être levées, les différences culturelles, si elles sont mal prises en compte, se révèlent un frein : « L’intégration des différences culturelles diminue les impacts négatifs sur les applications et les équipes », assure Frédéric Beaudrée.
BP2S a ainsi créé, au sein des équipes informatiques, des postes de relais : « Ils jouent le rôle de médiateur et d’avocat pour relayer les demandes de la branche ou pour les challenger, et ils se rendent sur le terrain pour mieux comprendre et rassurer les opérationnels, détaille Frédéric Beaudrée. Ils sont en outre présents dans les moments importants, par exemple pour la livraison d’une version en production ou la migration d’un gros client. »
L’enjeu est, bien sûr, de conserver la cohérence du système « core » pour éviter que des spécificités locales, toujours justifiées de la part des utilisateurs qui ont leurs propres méthodes de travail et processus. « Si l’on ne connaît pas les utilisateurs, on ne peut jauger l’importance de leurs demandes, précise Frédéric Beaudrée.
Dans certaines entités, ce n’est pas parce que l’on vous assure que que tout va bien… que tout va bien ! Et inversement. Dans d’autres entités, on ne vous dira rien du tout… ». Pour Ludovic Cinquin, gérer les aspects culturels revient à « aller voir sur le terrain comment les utilisateurs travaillent, et à ne pas « payer trop cher les premières victoires » en évitant les lourdes concessions à la première petite entité, sinon le spécifique reprend le dessus et si le pays est petit, le retour sur investissement sera nul. »
Cela suppose de combiner un niveau d’expertise technique, pour être capable de vendre des points très techniques en matérialisant le bénéfice pour le métier, et un niveau d’expertise fonctionnelle afin de comprendre et de proposer des solutions alternatives, de qualifier les besoins et les écarts pour le déploiement d’un nouveau pays.
Complexe ? Certes mais jamais impossible. « Savez-vous comment dévorer un éléphant ? Bouchée par bouchée », avance Ludovic Cinquin.
L’erreur est de vouloir être trop gourmand au départ : « Un système complexe qui fonctionne a toujours évolué à partir d’un système plus petit qui fonctionnait : les systèmes conçus à partir de rien ne fonctionnent jamais et ne peuvent pas être patchés. Il s’agit donc de penser grand et de commencer petit, selon trois principes ».
Le premier : « Se souvenir qu’un composant réutilisable est trois fois plus complexe à construire qu’un composant à usage unique », rappelle Ludovic Cinquin. Deuxième règle : « éviter le « sur-design » en amont qui parie sur une réutilisation future. L’expérience montre que l’on réutilise rarement ce qu’il était prévu de réutiliser, cela recoupe l’un des principes du Lean : le stock est du gaspillage. »
Troisième principe : « Spécifier en amont un système multi-entité est coûteux, complexe et, au mieux, inefficace, dans le pire des cas c’est un échec : mais on peut toujours défier les lois de la gravité ! », insiste Ludovic Cinquin. Un système multi-entités doit donc être aisément mutualisable. « C’est d’abord un pari politique, prévient Ludovic Cinquin, qui consiste à définir une stratégie multi-entité de long terme (claire, communiquée à tous, stable) et à se forger la conviction que la généralisation des bonnes pratiques métier apporte de la valeur. Il importe également d’être prêt à assumer la mutualisation, sur la base d’au moins 70 % des fonctions core, au-delà la complexité devient ingérable. » Dès lors que le spécifique redevient prépondérant, il est plus efficace de créer plusieurs systèmes au lieu de mutualiser…
BP2S a instauré un processus de contrôle sous la forme de forums de deux jours, lieux d’échanges entre les utilisateurs : « Le nombre de versions est fixé a priori (quatre par an) et à mi-parcours, nous mettons en place le forum utilisateurs afin de déterminer le contenu de la prochaine version, explique Frédéric Beaudrée. Nous indiquons notre capacité de développement et les utilisateurs font part de leurs demandes d’évolutions fonctionnelles. » Un responsable de processus (« process owner »), doté d’une bonne connaissance du métier et des applications, est également de la partie : « Avec la multiplication des branches, sa fonction s’est imposée pour faciliter, orienter, arbitrer et optimiser les processus et animer les espaces de discussion avec les utilisateurs. »
Reste à assurer une transcription claire de la stratégie au niveau budgétaire. Chez BP2S, les coûts du système « core » sont partagés par les différentes branches au moyen d’une clé de répartition, les coûts spécifiques sont intégralement supportés par la branche à l’origine de la demande. « Nous ne pénalisons pas les plus petites entités : la clé de répartition est en partie fonction du volume d’affaires réalisé au sein de chaque branche », assure Frédéric Beaudrée. Les utilisateurs n’ont plus d’excuses pour entrer dans le « core » !
Quatre principes de gouvernance
- Faire payer les pollueurs : ceux qui demandent sont ceux qui financent, limiter les enveloppes pour les fonctions non « core ».
- Trouver les bonnes clés de répartition : ne pas pénaliser les petites entités et favoriser la collaboration pour financer une évolution.
- Adopter un rythme de livraison fixe, sans dérogation (sauf si la survie de l’entreprise est en jeu), avec un rythme raisonnable (tous les deux à quatre mois).
- Aligner tous les acteurs sur le contenu et la priorisation des évolutions, par exemple avec des forums utilisateurs.