Les systèmes mutualisés : enjeux et risques

Cet article est le premier d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé et les enjeux d’un tel système, donner nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance****.

Les systèmes mutualisés : définition

Un système mutualisé est un système implémentant des processus et des fonctions communes à plusieurs entités. Ainsi, des systèmes multi-entité, multi-pays, multicanal de distribution à destination de populations d’utilisateurs différentes et multi-ligne de marché sont des systèmes mutualisés. Par exemple, les systèmes suivants sont des systèmes mutualisés :

• En assurance : un système multi-ligne de marché de gestion des remboursements santé pour les assurances individuelles et les assurances collectives
• En banque : un système multi-pays de gestion des contrats commun à la France, l’Espagne et la Pologne
• En distribution : un système multi-ligne de marché et multi-pays d’encaissement, commun à des petites, grandes surfaces et magasins discount et installés sur l’ensemble de l’Europe
• En télécommunication : un système multicanal de souscription de contrat utilisé en boutiques, par les conseillers téléphoniques et par les internautes
• En industrie : un portail client multi-ligne de marché et multi-pays, commun à l’ensemble des divisions d’un grand groupe industriel

La problématique des systèmes mutualisés a déjà été abordée par OCTO lors de l’Université du SI : Les SI multi-entité.

Dans cette série d’articles nous partons du principe qu'un système mutualisé implémente des processus métier. Nous n’aborderons pas la problématique des briques « techniques » : par exemple, un reverse proxy commun ou un serveur d’application (ré) utilisé pour toutes les applications du SI est une brique technique mutualisée, mais pas un système mutualisé.

Enjeux des systèmes mutualisés

Pour ne pas se tromper lors de l’étude d’opportunité précédant un projet de mutualisation, il convient de définir clairement les objectifs et le périmètre d’une telle brique et de mesurer les risques de sa mise en place. Le but principal poursuivi est de réduire des coûts par la rationalisation des moyens SI et l’uniformisation des processus.

Le premier enjeu associé à la mise en place d’un système mutualisé est bien évidemment la convergence des processus et patterns métier. Ainsi nous ne préconiserons jamais le démarrage d’un projet de système mutualisé s’il n’existe pas une volonté forte de faire converger et d’unifier les processus métier ou à minima de fédérer des patterns fonctionnels.

Le but est la rationalisation et la réduction des coûts, cependant la mise en place d’un système mutualisé doit s’appuyer sur une stratégie métier et SI favorable qui ne peut se réduire à un objectif de diminution des coûts informatiques.

Par exemple, HSBC s’est appuyé sur sa stratégie métier (nous pourrons nous limiter au slogan « Votre banque, partout dans le monde » pour nous en convaincre) pour mettre en place un système multi-pays de gestion des comptes clients. Ce système mutualisé – au-delà de la simple réduction des coûts – permet à ses client d’effectuer leurs opérations bancaires dans n’importe qu’elle agence de la même façon qu’à l’agence dans laquelle ils ont ouvert leur compte.

Si la volonté de faire converger les processus métier existe et que cette convergence est réalisable, encore faut-il s’assurer d’obtenir :

• Une vision partagée du système que l’on souhaite construire. Cette vision doit permettre de comprendre pourquoi on souhaite faire ce produit, de le « vendre » aux entités et de fédérer les acteurs du projet
• Un périmètre métier clair. On pourra par exemple commencer par identifier et classer les processus et patterns fonctionnels communs, pour ensuite identifier le périmètre dans lequel la mutualisation est possible.
• Un sponsor, porteur et garant de la vision produit. Ce sponsor doit disposer d’un poids politique important au sein du groupe et auprès des entités et d’un leadership fort. Il doit posséder un réel intérêt pour le produit et l’enjeu de mutualisation des processus métier
• Une équipe compétente et stable pour définir et réaliser le cœur du système. Ce pré-requis à la réussite d’un projet de mutualisation sera détaillé dans un article à venir.
• Une gouvernance adaptée à un système multi-entité, avec notamment une capacité d’arbitrage forte. Cela fait également l’objet d’un article à paraître.
• Un système d'incitation (par exemple rémunération et bonus lié à des objectifs) aligné sur les objectifs de la mutualisation.

Risques associés aux systèmes mutualisés

Les risques afférents à un système mutualisé sont importants, nous décrivons ici les deux risques majeurs à traiter impérativement dès le démarrage et au cours du projet. Le premier est celui de non adoption ou de refus du système par les entités, lorsqu’il est avéré, il conduit en général à l’arrêt et à l’échec du projet de mutualisation (c'est à dire à l'arrêt du projet, ou à l'utilisation du système par une seule entité). Le second est celui de l'explosion des coûts afférents au système mutualisé : ce risque est – comme nous allons le voir – d’autant plus important lorsque le projet de mutualisation est en succès !

Nous vous proposons de décrire les facteurs de risques aggravants les plus importants et le plus souvent rencontrés lors de nos missions.

• Augmentation du temps et du nombre d’intervenants entre les besoins exprimés et leur concrétisation

Dans un projet de système mutualisé, et au fur et à mesure que le nombre d’entités devient important, les étapes de traitement entre l'expression des besoins par les entités et la réalisation de ceux-ci se multiplient.

Voici un schéma représentant l’organisation simplifiée rencontrée chez l’un de nos clients permettant de réaliser un système mutualisé. Ce schéma ne fait apparaître que deux entités et laisse de côté les besoins de maintenance.

Les étapes de traitement entre expression de besoin et réalisation sont nombreuses et leur nombre s'accroisse avec le nombre d'entités utilisant le système.

Le nombre d’intervenants dans un projet de système mutualisé est important. Cela génère du risque, particulièrement si la vision produit n’est pas partagée ou si le sponsor projet manque de visibilité.

• Intervenants n’ayant pas l’habitude de communiquer/travailler ensemble

Par ailleurs, de part leur nature, les projets de système mutualisé font intervenir et travailler ensemble des intervenants d’entités différentes. Souvent ces intervenants sont de cultures et de langues différentes. Parfois ceux-ci ne réalisent pas de la même façon un projet informatique. Cela nécessite de tenter de stabiliser au maximum les équipes du projet dans les entités et en central.

• Imposition du système aux entités par le groupe

Comme pour la plupart des projets informatiques, il est nécessaire de piloter une phase de changement, particulièrement lorsque la volonté d’unifier les processus métier au niveau groupe impose de faire évoluer les processus et outils de certaines entités.

• Favorisation de l’entrée d’une entité dans le projet au détriment de la qualité du système mutualisé

Pour déclencher l’entrée d’une nouvelle entité dans le projet, particulièrement lorsque celui-ci démarre, il n’est pas rare d’observer une tendance trop importante au clientélisme. Ainsi l’équipe centrale peut, pour accélérer l’adoption du système, accepter l’entrée d’une importante part de fonctionnalités et modifications spécifiques à l’entité dans le cœur du système.

En distribution, nous sommes intervenus auprès d’un grand groupe multi-pays et multi lignes métier qui s’est doté d’une brique mutualisée d’encaissement. La solution s’est rapidement trouvée adoptée grâce à une stratégie SI favorable et à un sponsorship fort. En quelques années la solution était déployée dans une dizaine d’unités répartis dans plusieurs pays. La multiplication des entités disposant chacune de leurs processus métier, et des pays avec – notamment – leurs contraintes réglementaires propres a entrainé :

• La multiplication des versions du progiciel en production

• L’augmentation très forte de la dette technique de l’application (ex : gestion du code spécifique/ gestion du code commun)

• La multiplication des paramétrages possibles de l’application pour répondre aux différents besoins métier

• Et ainsi, l’explosion des coûts de maintenance

• Entités ayant un poids politique différents au sein de l’entreprise

Lorsqu’un système mutualisé est utilisé par plusieurs entités dont l’une est plus « puissante » que les autres au sein de l’entreprise, il n’est pas rare de constater une dérive des besoins communs vers les besoins spécifiques de cette entité.

Ce facteur de risque est réduit par la présence d'un sponsorship fort et une gouvernance adaptée.

• Cadres réglementaires différents

Ce facteurs de risque, rencontré notamment pour les systèmes multi-pays peut mener soit à la non adoption du système par l’entité à la règlementation jugée exotique, soit à l’affaiblissement de la qualité du système qui tenterait d’implémenter dans son cœur des réglementations antagonistes.

Ainsi, lorsque l’on étudie la possibilité de mettre en place un système mutualisé le bénéfice financier attendu est important et les moyens d’y parvenir nombreux. Cependant les écueils possibles le sont également et beaucoup doivent être évités dès le démarrage du projet. Nous allons maintenant vous proposer nos recommandations pour démarrer et maintenir dans la durée un système mutualisé. En gardant à l’esprit que celles-ci ne sont pas adaptées à tous les environnements et tous les projets.