Architecture d’entreprise et transformation du système d’information

Le comité d’innovation du cabinet de conseil Arismore a publié la synthèse de ses travaux sur l’architecture d’entreprise et la transformation des systèmes d’information. Et décrit les meilleures pratiques à mettre en place à partir de retours d’expériences de grands groupes.

La question de la transformation des systèmes d’information fait référence à des exigences d’agilité. Telle est la base de l’architecture d’entreprise, objet des travaux du comité d’innovation du cabinet de conseil Arismore qui vient d’en publier les principaux enseignements, auxquels ont contribué, entre autres, Benoît Frémaux, directeur des flux et DSI de Monoprix, Hervé Gouëzel, directeur des opérations d’intégration au sein de la direction générale de BNP Paribas, Richard Lalande, directeur général adjoint de SFR, Jean-Luc Lucas, directeur des plates-formes de services d’Orange et Jacques Vannier, directeur général de Mijava.

« L’architecture d’entreprise identifie les changements à opérer pour aligner les processus et les SI sur les objectifs de l’entreprise », résume Eric Boulay, président-directeur général d’Arismore. Le document de synthèse, produit par le comité innovation et issu des échanges entre les membres du groupe de travail, part d’un constat que l’on ne peut que partager : « Les entreprises font le constat depuis plusieurs années des difficultés de compréhension mutuelle et de coopération entre les parties prenantes du SI : la direction générale qui fixe des objectifs et des moyens financiers, les directions métiers qui les déclinent en évolution opérationnelle de leur métier et la direction des systèmes d’information qui maintient et fait évoluer les SI pour répondre aux attentes de la DG et des directions métiers. »

Pour Hervé Gouëzel, directeur des opérations d’intégration au sein de la direction générale de BNP Paribas, qui pilote actuellement le rapprochement de BNP Paribas et de la banque belge Fortis, « il s’agit d’une problématique stratégique pour nos entreprises pour adresser leur problème majeur : gérer le cœur de métier de manière à devenir plus intelligent. »

La capacité de transformation d’une entreprise repose ainsi sur trois piliers. D’abord, un référentiel d’architecture, dans lequel on trouve des modèles descriptifs des processus, des systèmes d’information et des règles de l’entreprise. « C’est sur la base de ce référentiel décrivant la situation actuelle et la cible que l’on étudie la trajectoire d’évolution », soulignent les experts du comité innovation.

Ensuite, un processus de gouvernance. Objectif : faire passer un message clair sous forme d’une gouvernance partagée par toute l’organisation pour décider, puis exécuter, les transformations requises. Enfin, le troisième pilier réside dans la formation : « Il s’agit ici d’un enjeu d’éducation et d’attractivité qui va permettre de développer ces compétences d’architecte au sein de l’entreprise. »

Ce point apparaît fondamental pour Hervé Gouëzel : « Il faut certes un vocabulaire commun et des règles communes, ainsi qu’un dispositif de gouvernance, mais, surtout, insister sur la notion d’équipe. L’architecte d’entreprise génial qui sait tout faire tout seul, cela n’existe pas ! » Autrement dit : « Parler métier, développer le savoir-être, privilégier une équipe pluridisciplinaire d’architectes orientés métier, technique ou entreprise, plutôt que rechercher l’architecte d’entreprise omniscient », résume le document de synthèse.

Benoît Frémaux, directeur des flux et DSI de Monoprix, voit dans l’architecture d’entreprise, et la transformation du système d’information qui en résulte, la nécessité « de s’adapter aux nouvelles offres proposées avec nos partenaires, de prendre en compte les évolutions technologiques comme le cloud computing et, de façon plus générale, la numérisation de la société ».

Plus précisément, pour un groupe de grande distribution comme Monoprix, il s’agit de reconfigurer le système d’information pour accompagner « le développement du multicanal, les transformations de la relation avec les fournisseurs et les clients et la montée du nomadisme », résume Benoît Frémaux. Il s’agit d’ailleurs, pour ce dernier, d’une rupture fondamentale : « L’époque où le DSI contrôlait tout ou espérait contrôler l’ensemble des technologies de l’information dans l’entreprise est révolue. La DSI va se transformer de manière rapide et brutale, et il faut savoir gérer le temps court et le temps long, dans un contexte où il n’existe plus de cible fixe pour le système d’information. Et la dimension technologique va progressivement s’effacer au profit d’une complexité de déploiement. »


Quelques pièges à éviter

  1. Privilégier les projets techniques alors qu’ils sont censés ne pas apporter de valeur métier.
  2. Décevoir les clients des services mutualisés et économiser sur la qualité.
  3. Décider avec une « courte vue » : à un besoin on ne répond que par une seule solution isolée, sans analyser le coût
    associé d’intégration, de déploiement, d’appropriation ou de possession.
  4. Adopter un mode client/fournisseur : la MOA demande et la MOE exécute au moindre coût sans analyse
    d’impacts collatéraux.
  5. Éloigner MOA et MOE dans des organisations différentes lorsque la simplicité du métier ne l’exige pas ou lorsque
    la DSI de l’entreprise dispose de personnes connaissant très bien le métier.
  6. Exprimer des besoins ambigus ou mal compris par les MOE ou des besoins irréalistes, que les propositions
    de MOE (souvent externes) ne «challengent» pas.
  7. Imposer la solution de la MOA et opposer MOA et MOE dans une logique de pouvoir.

Les bonnes pratiques de la transformation des systèmes d’information

  • L’architecte doit présenter la valeur métier de ses contributions et traiter des préoccupations opérationnelles aux côtés des directeurs de projet (sécuriser un projet, prévoir son évolution, etc.).
  • L’architecte doit penser aux utilisateurs du SI et aux clients, en complément des attentes métiers. Il est important de prendre en compte l’ensemble des points de vue, parmi lesquels celui du métier qui peut être différent de celui de l’entreprise, celui des utilisateurs et des clients et celui de la DSIO.
  • Sélectionner ce qui relève du temps long et ce qui relève du temps court. Par exemple, pour le temps long : les grandes directions à partager (nouvelles méthodes, nouveau vocabulaire, nouvelles infrastructures) et la capacité d’évolution d’une organisation (maturité de la capacité d’architecture, nouvelle gouvernance). Pour le temps court : Projets dits « quick win », tels que l’abonnement à un nouveau service informatique que l’on souhaite déployer rapidement.
  • Ne pas sombrer dans la «surdescription» longue et coûteuse de l’existant.
  • Être conscient que la cible est mouvante : choisir le bon grain de description, avec l’objectif premier de mieux communiquer sur des éléments non ambigus et partagés.
  • Toute modification d’objectif ou d’exigence peut donner lieu à une analyse d’impact rapide sur le(s) projet(s) en cours en vue de les réorienter.
  • Rappeler aux MOE et aux directions de projets les conditions de succès d’un projet, et notamment l’importance des phases de qualification, d’intégration et de déploiement, pour lesquelles une analyse pertinente des scénarios de migration est essentielle.
  • Collaborer avec la DRH pour identifier et valoriser les rôles et compétences des architectes, favoriser les parcours professionnels alliant des expériences au sein de directions métiers et de DSI. La mobilité est recommandée, y compris au sein de la DSI entre fonctions transverses, études et production informatique.
  • La DSI doit maîtriser la relation avec les métiers et la modélisation des processus métier et de la stratégie.
  • Renforcer le travail en équipe entre les MOE du SI et les métiers, pour s’assurer d’une bonne compréhension des objectifs et de la stratégie métier par les MOE, et d’une sensibilité accrue des métiers vis-à-vis des conditions de saine gestion des SI.
  • S’attacher à simplifier les SI tout en gardant la possibilité du multisourcing, ainsi qu’à standardiser et réduire le nombre des interfaces entre les «briques» du SI pour améliorer l’interopérabilité.
  • Dans des organisations complexes pouvant compter des dizaines de métiers, il est important que la (les) MOE dispose(nt) des expressions de besoin de toutes les MOA représentant les métiers.
  • Expliquer et mesurer pourquoi une décision centrale doit être appliquée, même si elle peut paraître contraire à une autonomie locale.

Source : Comité Innovation Arismore