Cet article est le deuxième d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.
Notre expérience des systèmes mutualisés nous a conduit à deux constats.
Premièrement, nous avons remarqué que les Directions des Systèmes d’Information avaient beaucoup de mal à construire des systèmes multi-entités[1]****. Effectivement, beaucoup de nos clients qui se sont lancés sur cette voie ont rencontré de nombreuses difficultés et le ROI espéré n’était pas au rendez-vous. Malgré la diversité de ces clients en termes de secteurs et de tailles, ils partageaient le fait que, pour construire le système mutualisé, ils avaient adopté la même approche projet que pour les autres applicatifs de la DSI (qui ne sont pas multi-entités). Ce constat nous amène à penser que les modèles classiques de gouvernance des projets SI ne sont pas adaptés à un projet d’application multi-entités.
Deuxièmement, nous avons observé qu’un système mutualisé ressemble plus à un progiciel qu’à une application classique. En effet, comme un progiciel, un système mutualisé a vocation à être utilisé par plusieurs « clients internes »: filiales dans plusieurs pays, différentes directions métier… De plus, il doit gérer, en même temps, les fonctionnalités communes et les spécificités de chaque « client ».
Additionné au premier, ce dernier constat nous amène à la conclusion que la meilleure manière de construire un système mutualisé est d’adopter une posture d’éditeur ce que plusieurs expériences concrètes nous ont permis de vérifier.
Dans la suite de cet article, nous allons vous fournir plusieurs recommandations vous permettant d’aborder un projet de système mutualisé avec une posture éditeur. Ces recommandations sont tirées de nos retours d’expérience et des bonnes pratiques du monde de l’édition logicielle.
Prendre une posture éditeur se traduit par adopter une approche « Produit » au lieu de l’approche « Ressources » habituellement appliquée dans les DSI.
En effet, avec une approche « Ressources », le premier rôle de la DSI est de mettre à disposition des ressources informatiques capables de mettre en œuvre les fonctionnalités demandées. Par conséquent, l’équipe projet possède un rôle assez « passif » consistant à répondre de manière spécifique aux besoins exprimés du ou des clients (voir Figure 1). Par contre, dans l’approche « Produit », l’équipe projet doit avoir un rôle beaucoup plus « actif ». Ce rôle, consiste à définir elle-même des réponses cohérentes aux besoins des clients (voir Figure 2). Ces réponses peuvent prendre plusieurs formes :
Figure 1- Description d'une approche "Ressources"
Figure 2- Description d'une approche « Produit »
Le travers que nous avons observé de l’approche « Ressources » est que l’équipe projet subit la vision que se fait l’entité de l’application. En effet, le rôle de l’équipe projet se cantonne à la mise en œuvre. Lorsqu’il y a un seul client en face, ce travers peut s’avérer peu impactant. Par contre, lorsque l’équipe est confrontée à plusieurs clients, la vision de chacun a toutes les chances de diverger avec les autres. Et cette divergence risque de se traduire par un système mutualisé peu cohérent et juxtaposant une application spécifique à chaque entité. Un tel système ne peut être que très complexe à développer et à maintenir.
Par conséquent, dans les applications multi-entités, il est important de donner un rôle plus actif à l’équipe projet dans la définition de la vision du système final afin qu’elle puisse faire converger les visions des clients en amont et faciliter la tâche de mise en œuvre.
Les principales composantes à mettre en place pour adopter une approche « produit » sont une organisation orientée produit et une roadmap produit. Dans la suite, nous allons détailler chaque élément.
Dans notre approche, 3 points sont à adresser en priorité
Pour traiter chaque point, nous allons nous inspirer des organisations des éditeurs logiciels et nous proposons la mise en place d’une organisation basée sur 3 composantes
Cette équipe doit regrouper de bons experts du système. En effet, son rôle est primordial pour plusieurs raisons
La roadmap produit matérialise la vision du système mutualisé. Elle consiste à définir la stratégie de construction et d’évolution de notre application. La figure 3 décrit notre vision d’une roadmap produit pour un système multi-entités.
Figure 3- Description d’une roadmap produit pour un système mutualisé
Dans cette roadmap, nous distinguons deux grandes phases : la phase d’initialisation du système et la phase de son évolution.
En voulant construire leur produit, certains de nos clients ont voulu concevoir un système multi-entités dès le départ. Ceci conduit presque toujours à des projets trop complexes (contours flous, multiplication des intervenants …) victimes de coûteux effet tunnel.
Exemple : nous sommes intervenus chez un opérateur télécom pour le cadrage d’un projet d’une application de souscription multicanal qui devait être utilisée pour la vente par Internet, par téléphone et dans les boutiques. L’application devait être fonctionnelle pour les trois canaux dès la première mise en production. Ces canaux étant gérés par des départements différents, des représentants de chaque département sont intervenus dans le cadrage. Cette multiplication d’acteurs a rendu l’activité de cadrage très difficile et a induit des retards importants. En effet, chaque département avait ses contraintes propres et sa vision propre du processus de souscription qu’il voulait intégrer dans l’application. Par conséquent, chaque élément du cadrage donnait lieu à un long débat (chacun prêchant pour sa chapelle) qui se terminait invariablement par un consensus mou ne satisfaisant personne. A cause de cela, le cadrage s’est éternisé et le projet a fini par être abandonné.
Par conséquent, comme première étape, nous recommandons de commencer sur un périmètre restreint en se focalisant sur une seule entité pour construire une première application. Pour choisir ce partenaire, il convient de choisir celui ayant les processus métier les plus matures. A défaut, il est possible de choisir celui ayant le plus foi dans la vision du produit. Cependant le fait de se focaliser sur un seul partenaire ne doit pas nous pousser à mettre en place une architecture trop fermée qui serait un handicap pour les évolutions futures. Toute la difficulté de la définition de l’architecture dans cette première étape est de trouver le bon curseur entre une architecture trop spécifique au partenaire qui serait une limitation du système et une architecture trop « générique » qui serait trop complexe à construire et à maintenir.
A la fin de l’étape précédente, nous avons un système qui marche, qui apporte de la valeur métier à la première entité et qui est montrable aux autres. Néanmoins, le produit n’a été conçu que pour un seul partenaire. Par la suite, ayant mis en place les bases fonctionnelles de notre système, le nouvel objectif consiste à trouver un deuxième partenaire avec qui mettre en œuvre l’aspect mutualisation.
Nos retours d’expérience nous amènent à préconiser de réaliser cette mise en œuvre en deux étapes
Cette démarche qui, à première vue, peut sembler lourde, s’avère la plus efficace. En effet, elle permet d’avoir de véritables retours terrain sur les points communs et spécifiques des entités (processus métier, fonctionnalités, architecture…). Ainsi, il est possible de définir et de mettre en place les patterns les plus adéquats pour chaque aspect.
Cette phase est plus étendue dans le temps que la première. Comme pour les logiciels des éditeurs, elle est jalonnée par la mise à disposition de nouvelles versions du système mutualisé. En abordant cette phase deux questions fortement liées se posent : à quel rythme livrer les versions et comment définir le périmètre fonctionnel de chacune d’elles ?
Afin d’éviter l’effet tunnel et de pouvoir délivrer de la valeur rapidement, nous préconisons de structurer la roadmap sur des livraisons de « releases » régulières, rapprochées (l’idéal est tous les 3 mois) et selon un calendrier fixe et connu de tous. Cette cadence possède trois avantages principaux :
Afin de respecter ce rythme, il est important d’être vigilant au niveau de la définition du périmètre fonctionnel de chaque version. Effectivement, un périmètre trop grand ou mal maîtrisé induira des retards de livraison et conduira à la perte des avantages cités précédemment.
Ceci nous amène à traiter la deuxième question.
La définition du périmètre d’une version induit deux activités assez classiques : le recueil des besoins et la délimitation du périmètre d’une version donnée. Dans ce qui suit, nous allons étayer quelques bonnes pratiques permettant de mener ces tâches à bien.
Pour cette activité, les maître-mots sont proximité et échange. Effectivement, la proximité avec les utilisateurs (ou leurs représentants) est indispensable afin de cerner et comprendre leurs besoins. Quant aux échanges, il faut les développer entre l’éditeur et les utilisateurs et entre les utilisateurs eux-mêmes. Ceci aura pour but de favoriser le partage d’expérience et faire émerger de nouvelles idées d’évolution. Dans cette optique, voici quelques bonnes pratiques issues du monde des éditeurs logiciels.
Cette deuxième activité est délicate car elle induit généralement plusieurs arbitrages et la négociation de compromis avec les entités. En effet, chez nos clients nous avons été souvent confrontés au syndrome de « la lettre au père noël ». Ce phénomène se matérialise par une liste sans fin de besoins (plus ou moins importants) que les utilisateurs souhaitent voir apparaître dans la version suivante.
Pour lutter contre ce syndrome, nous conseillons la mise en application de 2 bonnes pratiques de l’Agile qui sont
Dans les arbitrages et les négociations précédemment cités, le responsable produit doit avoir un rôle prépondérant. Effectivement, c’est lui qui est le garant de la vision du produit et de la cohérence fonctionnelle et technique du système multi-entités.
A travers les missions réalisées chez nos clients, nous avons identifié deux grandes catégories de risques qui peuvent mettre en péril un système multi-entités : un risque organisationnel et un risque d’explosion de la complexité de l’application.
Dans la suite, nous allons décrire chaque catégorie de risque et présenter plusieurs recommandations permettant de les mitiger.
Lors de la définition de la roadmap, nous avons souvent observé une lutte d’influence entre les entités afin de faire concorder la roadmap avec leurs intérêts propres. Au cours de nos missions, nous avons rencontré de nombreux projets de systèmes mutualisés qui ont échoué car l’équipe projet n’avait pas un poids suffisant par rapport à une ou plusieurs entités. Par conséquent, la roadmap leur a été imposée et ils ont perdu la maîtrise de leur produit. Il peut alors en résulter un éclatement du produit, par la création de branches qui (faut-il le préciser ?) risquent de ne jamais se rejoindre. Il peut également se produire un effondrement du produit sous son propre poids, car devenu trop complexe, trop riche pour être maîtrisé.
Exemple : nous sommes intervenus chez un acteur Internet pour auditer un portail de services multi-pays. Cette plateforme était utilisée par les différentes filiales régionales pour offrir des services en ligne à leurs clients (Webmail, partage de photos, stockage en ligne …). L’audit a été commandité car, d’une part, les coûts de maintenance croissaient de manière exponentielle et, d’autre part, le délai de déploiement d’un nouveau service d’un pays à un autre devenait trop important. Il s’est avéré que l’équipe responsable de la plateforme était toujours en position de faiblesse par rapport aux filiales qui multipliaient les demandes urgentes. Par conséquent, pour répondre aux demandes dans le temps imparti, l’équipe avait créé plusieurs branches dans l’application. Au début, ces branches étaient supposées être temporaires et l’équipe devait prendre le temps de les faire converger. Malheureusement, les demandes se succédant, le temps n’avait pas été pris et les branches sont restées. Au final, si un bug était détecté sur une branche, il fallait reporter le correctif sur toutes les autres branches et chaque nouveau service devait être mis en place sur chaque branche de manière séparée. D’où l’explosion des coûts et des délais.
Pour lutter contre ce phénomène, voici quelques préconisations permettant de rester maître de sa trajectoire d’évolution.
Il est important que la structure de gouvernance du produit soit la plus indépendante possible de toutes les entités. En effet, si cette structure est rattachée à une entité, ceci pose problème à deux niveaux. D’une part, les arbitrages que cette structure réalisera ne peuvent pas être complètement neutres vues les relations hiérarchiques en place. D’autre part, les autres entités risquent de ne pas vouloir collaborer à ce projet en le considérant comme partisan et ne servant pas leurs intérêts.
Par exemple, dans le cas d’un système ciblant des départements d’une organisation centralisée (ex. département vente par Internet et vente par boutiques) cette structure peut être rattachée à la DSI qui est transverse. Dans le cas d’un système ciblant une organisation décentralisée (organisme régionales, pays …) la structure peut être rattachée à une DSI groupe.
La question du financement est une question importante. Effectivement, un modèle mal pensé peut donner un pouvoir trop important à une entité qui risque d’imposer la roadmap qui sert le plus ses intérêts. Le modèle économique idéal n’existe probablement pas. Cependant, le tableau ci-dessous présente les modèles possibles pour le financement des coûts de « build »[3] du produit avec une liste d’avantages et d’inconvénients pour chacun d’eux.
A ces modèles, nous pouvons ajouter le principe du « pollueur-payeur ». Ce principe impose aux entités qui réalisent des demandes très spécifiques de payer les coûts associés. Ainsi, cette contrepartie financière poussera les entités à vérifier la pertinence de leurs demandes spécifiques.
Tous les experts informatiques s’accordent à dire que plus un système est complexe plus il est difficile à construire et à maintenir. Par conséquent, si nous manquons de vigilance sur cet aspect, notre système mutualisé peut devenir tellement complexe, qu’il n’est plus possible de le faire évoluer avec des coûts et des délais raisonnables.
Nos missions nous ont appris que l’un des facteurs qui impacte le plus la complexité d’une application mutualisée est l’accroissement de la dette technique. En effet, avec la vie du produit, il est inévitable de voir apparaître de la dette technique : obsolescence de technologies, erreurs de conceptions, erreurs de codage, atteinte des limites de l’architecture… Or avec l’augmentation de la dette technique la difficulté de maintenance et d’évolution du système mutualisé augmente. En conséquence, le responsable produit doit résister à la tentation d’allouer toute la charge de l’équipe au développement de nouvelles fonctionnalités et doit accorder du temps pour faire du « refactoring » et des évolutions techniques. D’une manière empirique, nous avons remarqué qu’il fallait accorder 10 à 20% de la charge de l’équipe afin de gérer efficacement la dette technique.
Un système mutualisé est un système très complexe qui doit intégrer les besoins communs et spécifiques de plusieurs clients. Ce type d’application nécessite une gouvernance adaptée qui doit s’inspirer des spécialistes du sujet que sont les éditeurs logiciels. Ceci implique d’adopter une démarche orientée produit : une organisation spécifique, une roadmap et un processus de livraison itératif et incrémental
Cependant pour mener à bien ce genre de projet, il faut accompagner la gouvernance par des pratiques d’architecture et de développement adaptées aux particularités d’un système multi-entités. Cet aspect fera l’objet du dernier article de la série.
[1] Dans cet article, les termes système mutualisé et système multi-entités seront utilisés comme étant des synonymes
[2] Pour plus de détails sur le rôle du responsable produit vous pouvez lire le livre « The Art of Product Management : Lessons from a Silicon Valley Innovator», Rich Mironov
[3] Nous n’allons pas aborder dans cet article la question du financement du « run ». En effet, nous supposons que chaque entité supporte ses propres coûts de « run ».