Un tel changement va conduire les entreprises à réorganiser leurs processus de pilotage: certaines tirées par une dynamique interne et désireuses d’obtenir des différentiateurs de marché, d’autres tirées principalement par les contraintes  réglementaires. Quel que soit le point de vue adopté, il va entrainer des transformations métier majeures et, pour certaines entreprises, une recombinaison via fusions/acquisitions afin d’optimiser leurs portefeuilles.

Heureusement, la plupart des acteurs ont lancé des programmes de transformation et, comme le précise l’enquête de Deloitte de 2011, plus de 52% des companies britanniques en étaient à la phase de mise en œuvre en 2011 avec 75% chez les plus grandes. Par ailleurs le même rapport indique que les budgets devraient être compris entre 1,2 m et 12m d’euros, les montants plus élevés étant le fait des très grandes organisations.

Mais, si les comités exécutifs semblent être conscients des nouvelles responsabilités et opportunités, les projets et programmes ont encore beaucoup d’incertitudes et de questions:

• sur les méthodes de calcul du capital qui doivent encore être affinées et, pour certaines complètement spécifiées
• sur les données qui doivent être collectées, traitées, vérifiées et validées pour chaque méthode de calcul
• sur l’organisation qui doit définir les responsabilités pour chaque sous-processus et définir comment ils entendent les assurer
• sur le management qui doit préparer les collaborateurs et demander les investissements pour les ressources

Au final, les transformations subissent deux forces opposées: les dépendances entre les différents aspects de Solvabilité II et les forces de la fragmentation engendrées par la démarche de projet adoptée pour faire face à la complexité  : d’ordre technique (actuaire, informatique, affaires, …) et sociale (acteurs, la gouvernance, l’influence, … ). La fragmentation technique provient de la nécessité d’adopter, même partiellement, une approche analytique. La fragmentation sociale vient du climat relationnel, de la culture business et de la compétition interne.

Tout ceci crée un réseau de questions à plusieurs facettes dont certaines sont tricotées avec les unes avec les autres. Par exemple, dès que les programmes commencent à envisager les données, ils doivent rapidement répondre aux questions posées par les modèles de risques et les processus métier. Doivent-ils affiner les modèles de risques qu’ils doivent aussi instruire la stratégie, le management des risques et la qualité des données. Il résulte qu’une incertitude à propos d’un aspect du sujet devient une incertitude pour tous les autres aspects.

Ainsi les programmes Solvabilité II ne sont pas en mesure de définir une cible précise, mais juste une vision de scénarios associés à des règles et des directions. Ils créent des feuilles de route composées d’étapes qui tendent vers un ou plusieurs scénarios. Plus les étapes sont partagées par les feuilles de route, plus les programmes ont des options devant eux et sont flexibles. Évidemment, ces plans comprennent les activités IT, les développements de plates-formes et les déploiements sinon les transformations pourraient avoir à faire face à une fragmentation sociale encore plus forte qui pourrait sérieusement entraver leur réussite.

Le démarrage d’une dynamique de changement Solvabilité II ne se révèle donc pas une chose aisée.

Les transformations touchent:

• les services financiers qui doivent réduire drastiquement le délai de production de la balance et, pour cela, remodeler leurs processus,
• les départements d’actuariat qui doivent changer radicalement leur mode de travail,
• les dirigeants d’entreprises qui doivent réviser leurs processus de décision pour prendre en compte le coût du risque
• les top managers qui doivent revoir  le système de gestion des performances et mieux récompenser une meilleure gestion des risques.

Comment ne pas impliquer tous ces acteurs dans la spécification et la gestion de la transformation s’ils doivent s’entendre sur les gains rapides au démarrage des feuilles de route et sur les objectifs finaux à atteindre ? Pour faire face à l’incertitude, les programmes doivent mettre en place une structure de management solide, capable de décider tout au long de l’exécution des feuilles de route. En effet, les meilleures approches de transformations sont agiles et pilotées par les risques.

Les transformations doivent envisager 2 types de risques:

• L’instabilité des exigences due à une publication tardive des directives réglementaires et à la difficulté de trouver une solution efficace pour produire le reporting Solvency II dans le temps  requis, 14 semaines.
• Les difficultés d’intégration dues à des pratiques et des processus existants fondés sur des outils d’utilisateur ni spécifiés, ni standardisés et très peu intégrés à cause de nombreuses procédures manuelles

Si les technologies de l’information n’étaient pas apparues critiques au démarrage, elles deviendront rapidement un sujet, car la plupart des risques proviennent du traitement des données et des calculs associés qui se font souvent dans des feuilles de calculs Excel ou avec d’autres solutions d’utilisateur comme SAS PC ou d’autres SGBD  sous Windows. Ces solutions qui permettent de corriger rapidement les données d’entrée et les règles de calcul sont apparues extrêmement flexibles.

Mais elles augmentent les risques d’erreurs, les risques d’intégrité et de confidentialité des données. Elles ont ralenti l’intégration car tous les échanges d’informations se font manuellement et sont spécifiques à chaque acteur. Changer cela est difficile car la flexibilité s’avère souvent un avantage métier inestimable.

Pourtant, les activités de préparation, de collecte, de vérification des données, de calcul des provisions, de réconciliation avec les données comptables, d’analyse vont être totalement remaniées par Solvabilité II car la méthode des flux futurs de trésorerie actualisés nécessite des données au grain le plus fin et car les règles Solvabilité II exigent un haut niveau de  qualité et une auditabilité  complète des données. Le reporting Solvabilité II peut être comparé à une cascade de données qui contient non seulement des données opérationnelles détaillées, mais aussi des données d’organisation, de coût, des données financières et de perspectives économiques.

Dans ce contexte, toute démarche de datawarehouse entrainerait un grand nombre de spécifications d’objets métier stables ou devrait s’appuyer sur une technologie d’interface capable de soutenir de fréquentes évolutions.

À ce stade, il semble que certains programmes Solvabilité II ont fait une erreur en se précipitant sur la modélisation afin d’être en mesure de fournir rapidement des indications sur les tendances de charge en capital. Il aurait été préférable de gérer tous les aspects en même temps et d’aspirer à une progression équilibrée.

Certains éditeurs ont développé des solutions qui peuvent aider à faire face aux problèmes dus aux tableur Excel:

• CIMCON Software (XLAudit and XLRisk)
• Prodiance (Spreadsheet IQ)
• ClusterSeven (Enterprise Spreadsheet Manager)
• Finsbury Solutions (EUC Enterprise)
• ComplyXL from Lyquidity.com

Les transformations Solvabilité II ont le choix entre trois types d’organisation:

• une organisation centralisée qui prépare des plans pour tous les acteurs et gère leur exécution. Elles pourraient bientôt buter sur des questions de conception puisque personne ne maîtrise au démarrage de la transformation, la méthode de calcul de flux futurs de trésorerie actualisés, par exemple. Et lorsque les transformations suivent leur cours, elles peuvent être rapidement désalignées avec les attentes des acteurs et générer des risques importants.
• une organisation décentralisée qui soutient les acteurs pour la préparation des plans et la gestion de l’exécution. elles pourraient bientôt faire face à des questions d’intégration, à une fragmentation des points de vue et à des objectifs divergents. Dans ce contexte, la décision de mettre en œuvre une plate-forme partagée peut arriver en retard, entraver l’efficacité du reporting et générer des risques de délai et de qualité.
• une organisation mixte qui dessine un cadre de conception commun dans laquelle chaque partie prenante doit développer ses propres étapes de la feuille de route. Ce cadre permet de garder la cohérence de tous les points de vue et crée une autonomisation des acteurs qui sont alors capables de trouver des optimisations locales et de réduire la résistance au changement.

Il est difficile d’identifier le périmètre détaillé de la transformation lorsqu’on doit normaliser les processus et les données dans un contexte où les acteurs aspirent d’abord à partager des plates-formes de traitement. Cette décision peut s’avérer délicate car prise trop à l’avance, elle peut conduire à un désalignement, surtout quand les éditeurs et les entreprises n’ont pas en leur possession toutes les exigences réglementaires. Si elle est prise trop tard, elle peut causer l’inefficacités des processus. Pour ces raisons, certaines entreprises ont décidé de commencer avec des prototypes.

Ce document montre que les questions métier et les questions de technologies de l’information sont étroitement imbriqués dans les transformations Solvabilité II. Elles doivent être gérées de conserve pour éviter toute fragmentation nuisible. Les métiers contribuent à diriger le programme et, dans le même temps,  doivent être soutenus pour définir leur nouveau rôle.

Pour réussir, il faut créer ou accroître l’empathie entre métiers et informaticiens : ils doivent travailler main dans la main pour concevoir les  feuilles de route et prendre les bonnes décisions en temps opportun. Tout cela fait pencher la balance vers l’adoption d’une organisation de programme de type mixte.

Enfin, les programmes de transformation trouveront un appui favorable et déterminant dans la démarche d’architecture d’entreprise car elle donne les bases pour construire le cadre de conception partagé par les acteurs, IT et non IT, et toutes les conditions qui leur permettront d’être efficaces.

De même, on constate que les budgets informatiques ont tendance à augmenter année après année. C’est inexorable tant que de nouveaux projets développeront de nouvelles fonctions qui devront être maintenues. Pour faire face à cette situation, les DSI ont installé un processus de gestion de portefeuille de projets : ils évaluent les projets selon plusieurs points de vue – technique, métier, risques, stratégie … – et établissent des priorités. Il en résulte que les projets de priorité basse sont reportés.

Passé quelque temps, les projets reportés s’empilent comme du sable et deviennent prioritaires. Ainsi, les budgets informatiques contiennent aussi des projets de faible priorité qui sont devenus prioritaires pour l’année budgétaire.

Finallement, les Directions métier considérent le processus de portefeuille de projets  comme un moyen de report au bénéfice de la Division IT. Celles-ci ne tiennent pas compte du fait qu’elles sont les principales sources des projets qui occasionnent la croissance du budget IT. En outre, si elles se plaingnent des coûts informatiques supplémentaires, si elles ne sont pas questionnés sur les gains espérés des projets pourtant mis sous leur responsabilité par les business case.

Quand un projet est retardé, les coûts augmentent généralement en proportion du temps. Ainsi le budget courant contient les dépenses en capital des projets passés en retard mais aussi leurs dépenses opérationnelles car ils ont déjà déployé des plates-formes.

Comme le budget courant contient le flot de projets passés retardés, il reste de moins en moins de place pour les nouveaux projets. Michel Volle a montré que la croissance est exponentielle. Les négociations avec les Directions métier deviennent alors de plus en plus difficiles. Les projets techniques sont examinés et souvent reportés ou refusés si ils ne présentent pas une forte économie de coûts ou une forte rentabilité. Il en va de même pour les composants techniques de projets métier qui ne semblent pas être nécessaire, même s’ils sont hautement souhaitables. Comment dans ces conditions construire une architecture ?

Il ressort que la planification et la budgétisation sont de véritables casse-têtes. Dans une telle situation, même les meilleurs CIO ne pouvent pas éviter d’être considérés comme cause de retards et cause de coûts. L’exécution difficile de la stratégie d’entreprise provient de la lourdeur de l’informatique que les DSI ne traitent pas (“trop lent, trop lourd, trop cher”). Cela a a conduit Directions IT divisions à rationaliser leurs opérations par l’adoption d’ITIL et l’orientation service qui les ont transformés en fournisseurs de services internes. Les applications informatiques sont clairement gérés comme provenant d’une demande des directions métier des entreprises.

Dans le même temps, les forces autour des Directions IT continuent d’évoluer : Les directions métier recherchent encore plus de réactivité, plus d’agilité et davantage d’autonomie pour les optimisations locales et les transformations. 2012 serait un point tournant. Le Cloud se développe poussé par le marché des PME. Il devient plus attrayant pour certaines applications non critiques des grandes entreprises. les Intégrateurs se sont transformés en offreurs de Business Process clé en main. Ils ont en capacité de traiter directement avec les Directions métier qui remettent en cause leur fournisseur interne. Pour les grandes opérations métier, la Direction informatique est déjà hors du coup, car les Directions métier sont devenus les principaux prescripteurs de solutions. Au final, il lui reste la maintenance des systèmes et certains projets technologiques touchant les systèmes de messagerie, les réseaux ou les infrastructures.

Les dés sont-ils déjà lancés et  la prévision de Gartner ne sera-t-elle qu’une estimation du facteur d’une tendance inexorable lorsqu’il dit: «En 2015, pour 35% des entreprises les dépenses IT seront gérés hors du budget de la Directions IT. Les DSI verront certains de leur budget actuel réaffectés tout simplement à d’autres secteurs de l’entreprise. Dans d’autres cas, les projets informatiques seront redéfinis comme des projets métier sous le contrôle de Directions métier de l’entreprise.”?

Si les technologies de l’information apparaissent de plus en plus intégrées dans le métier, l’inverse est également vrai. Les Directions métier voudraient être sures que la Direction informatique travaille principalement à leur bénéfice. Or, comme le métier est devenu de plus en plus complexe en raison de la personnalisation, de la concurrence, des coopérations industrielles, de l’intégration, … il est impératif qu’elles coordonnent leurs actions vis à vis de l’informatique. Pour s’en convaince, on peut par exemple lire le livre d’Yves Caseau.

La Direction informatique, pour sa part, devrait être plus orientée métier, avoir des collaborateurs pluricompétents, en informatique et sur le métier, elle devrait prendre de nouvelles responsabilités, par exemple celles de processus métier clefs en mains et/ou en superviser certains. Cela ne pourra se produire que dans un contexte favorable résultant d’une nouvelle vision coordonnée et de nouveaux liens établis avec l’informatique. Certains analystes Forrester qualifient cela de «changement copernicien» : un changement radical dans les mentalités des Directions Informatiques.

Pour déclencher ce changement, une nouvelle fonction de coordination s’avère cruciale : c’est l’architecture d’entreprise. Relevant de la Direction générale, elle est un appui pour faire sortir la gestion de portefeuille de projets hors du périmètre de la Direction Informatique et en faire le processus de base pour conduire les changements de l’entreprise. Elle installe les processus qui permette d’identifier et de qualifier les projets de changements candidats. Elle soutient le processus de décision et de mise en œuvre. Elle suit le bon fonctionnement.

S’il y a changement radical c’est que les projets ne sont plus des projets de développement de systèmes, mais ils agissent sur des processus métiers ou des aptitudes d’entreprises (capabilities). Les considérations principales sont métier, les projets sont gérés par l’ensemble de l’entreprise, le déploiement et la mise en œuvre sont planifiés en tenant compte des contraintes métier avant celles de nature technique, les objectifs des projets sont les objectifs de l’entreprise.

C’est un déplacement du centre de gravité de la conduite des changements de l’entreprise. Les décisions et la mise en oeuvre seront plus fluides si les acteurs contribuent en proportion de leurs enjeux. La DSI n’est plus un fournisseur de services internes qui exécute les commandes des métiers, mais un partenaire qui contribue positivement aux projets de l’entreprise. Par exemple, la dette technique qui ralentit le changement n’est pas seulement une question à traiter par le DSI, mais par l’entreprise dans son ensemble. Les risques liés aux projets font partie des risques d’entreprise et sont inclus dans le périmètre de la gestion des risques.

Ainsi, lorsque les projets sont en retard et que le planning d’exécution de la stratégie glisse, les priorités sont fixées en fonction des contraintes métier et la replanification se fait en conformité avec un meilleur équilibre des ressources. En 2012, contexte de crise, les entreprises sont plus fragiles, donc réussir le changement est devenu essentiel, voire vital. C’est tous les voeux que je forme pour 2012 à destination des entreprises: “réussir les changements”

• La plupart des front-office des grandes entreprises françaises sont des machines : sites internet, serveurs vocaux interactifs. Et quand ils ne sont pas automatisés, les opérateurs des centres d’appels sont difficiles à jondre, ils n’ont pas le bon niveau de compétence pour répondre aux questions des clients, et les clients doivent payer un surcoût par appel. Dans d’autres cas, la livraison est effectuée par des employés ou des sous-traitants qui ne sont pas en mesure d’endosser le point de vue de leur entreprise.
• .
• L’équilibre recherché se trouve entre l’augmentation du nombre des services offerts aux clients et la maîtrise des coûts de front-end. Toutes les opérations sont des processus exécutables et exécutés à moins qu’un grain de sable ne nécessité l’intervention d’un acteur humain pour rétablir une situtation imprévue qui peut devenir pesante pour un client. (Cf conférence comte de Bougainville )
• .
• Cette situation est souvent rencontrée chez les opérateurs télécoms, les opérateurs ferroviaires et les compagnies arériennes.
• 
  
• Pourquoi ?
• Les grandes sociétés de conseil ont expliqué que connaître son client n’est pas seulement entendre ce qu’il dit, mais savoir de lui ce que lui-même ne connaît pas encore. Cela vient de l’histoire bien connue  de clients affirmant qu’ils aimeraient manger des salades, mais qui en fait ont vidé un bar à snacks.
• .
• Le malaise des front-office ne provient pas d’une incompréhension des besoins des clients, il est le résultat de la mise en oeuvre du seul point de vue de l’entreprise :
  • qui attend avec impatience d’obtenir un retour sur investissement de l’économie d’échelle par rapport au face à face de la relation client
  • qui a une vision bureaucratique de l’organisation qui a câblé les nouveaux processus avec des capacités limitées d’optimisation
  • qui pense que la technologie est le principal attrait pour le client.

• Que s’est-il passé ?
• En fait, la plupart des entreprises n’ont pas modifié leur attitude vis à vis des clients, contrairement à ce qu’elles ont dit. Elles continuent à pousser des offres. Pour eux, la valeur est dans la richesse des offres non dans leur utilité réelle. Il appartient au client de faire le bon choix.
• .
• Elles continuent d’avoir une vision d’un client “Quetelet” qui est très loin de la réalité  et de sa diversité. Elles continuent à donner de la valeur aux grandes organisations bureaucratiques ou, si elles sont en difficulté, elles externalisent des activités qui n’auront aucune chance de se comporter mieux.
• Et cela va continuer jusqu’à ce qu’un nouvel acteur arrive avec la bonne approche et une organisation flexible. Si un tel événement se produit, il peut bouleverser le marché. Même si les grandes entreprises croient être trop grosses pour faire faillite, elles trouveront alors, en face d’elles, de nouveaux concurrents dangereux.
• .
• La situation n’est pas aussi tranchée, certaines entreprises ont déjà commencé à changer leur mentalité et ont constaté un nouvel élan dans leurs affaires. Néanmoins, elles ne réussissent pas à créer une relation forte avec leurs clients car leur stratégie est axée essentiellement sur le prix comme principale valeur pour le client. Or, du fait de leur taille, elles ne sont pas en mesure de rivaliser avec les vraies entreprises lowcost, elles ne font que détruire de la valeur.
• .
• En France, ce type de mauvaise stratégie est possible car certaines grandes entreprises ont des positions quasi monopolistiques à partir qui  leur octroie une rente, alors que dans la réalité elles détruisent de la valeur. C’est pourquoi elles craignent tant la concurrence et ont appris à l’éviter.
• .
• Ce que je voudrais?
• Je rêve d’entreprises de service qui vraiment tiennent compte de ce que je suis, de ce que je pense, de ce que sont mes points de vue.
• Au lieu d’offrir un bouquet de services que je paie intégralement, dont je n’utilise qu’une partie avec difficulté, je voudrais avoir un ensemble ordonné de services, intégrée dans mon processus et mon contexte, dont l’utilisation me serait naturelle, pour lesquels je sais pourquoi je paie.
• .
• Par exemple, si ma banque, au lieu de me donner un tas de fonctions pour gérer mon argent, ce qui ne correspond pas vraiment à mon processus de gestion de la trésorerie, m’avait donné de tels outils, j’aurais eu le sentiment qu’elle avait pris soin de moi.
• .
• Si ma banque, au lieu de me facturer et de m’opposer des délais parce que je transfère mon compte d’une région à une autre, avait une gestion de données centralisée et avait mis en place des processus fluide et homogène sur l’ensemble de son territoire afin de me fournir le service que j’attends,  j’aurais eu le sentiment qu’elle avait pris soin de moi.
• 
• Qu’est-il possible de faire ?
• Aujourd’hui, toute la technologie et les démarches nécessaires pour passer d’une logique d’offre poussée à un service orienté un client, existe. Le DesignThinking ( post précédent ) peut être utilisé pour concevoir des services adaptés aux point de vue du client, la virtualisation, le cloud computing, les architectures SOA et BPM peuvent permettre de construire des systèmes d’information souples qui évitent des migrations et des resynchronisation de données qui s’avèrent toujours très complexes.
• .
• Une telle évolution, accompagnée d’une nouvelle approche dans la relation client, aboutirait à une vraie relation de long terme qui, en outre, permettrait de bénéficier de la longue traine, un des modèles business permis par Internet. Surement, elle ferait naître un avantage concurrentiel et un tremplin pour capturer une grande partie du marché.
• .
• Certains font valoir que la menace n’existe pas et qu’aucun changement n’est nécessaire. La menace n’existe pas, parce que les sociétés internet ont du mal à mettre au point un business model rentable qui compense des coûts d’acquisition de produits élevés. Une fois que certaines auront atteint une taille critique pour peser vis à vis des producteurs et pour intégrer une partie de la production comme l’a déjà fait la grande distribution, elles seront en bonne position pour développer une nouvelle approche client.
• .
• Et lorsque cela arrivera, cela bouleversera le marché comme cela s’est passé en 2000 avec la révolution e-business.
• 
  
• Que manque-t-il donc pour évoluer ?
• A l’heure actuelle, les entreprises possèdent très bonnes compétence pour gérer leur système d’information. Chacune d’elles est en mesure d’acquérir, de déployer et de gérer avec succès des applications métier structurantes. Le point d’attention actuel est l’alignement stratégique, c’est à dire le bon usage de la technologie par les entreprises.
• .
• Apporter de nouvelles méthodes aux Directions Informatiques afin d’améliorer leur compréhension du métier n’est pas suffisant pour réussir. En effet, c’est exactement ce qui a été fait ces 10 dernières années en France et cela n’a rien ou insuffisamment changé ce qui concerne la relation des entreprises à leurs clients.
• .
• La solution pour mettre effectivement en oeuvre ce changement est l’architecture d’entreprise, comme processus de changement à grande échelle, conduit par un chef d’orchestre, l’architecte d’entreprise, capable de tirer le métier et la Direction Informatique en même temps. Il facilite la diffusion d’un nouvel état d’esprit aux organisations et aux processus métier, et tire la Direction Informatique vers la fourniture du bon service, à la bonne personne, au coût adapté. A la fin, les Directions métier de l’entreprise auront changé et obtenu tous les avantages de la technologie.
• .
• C’est l’objet même de l’architecture d’entreprise.

(cliquer sur ce lien pour avoir une vue élargie)

Démarche d'Architecture d'Entreprise

Papier publié sur le Hub “Solutions Logicielles” en tant que membre de  l’équipe d’experts

Des unités d’affaires compétentes, hautement spécialisées, qui se développent chacune en suivant les orientations stratégiques de l’entreprise : n’est-ce pas une description parfaite des entreprises que nous connaissons ? Précisément. Car chaque unité d’affaire ou métier vérifie soigneusement les documents ou les informations qu’on lui transmet, les corrige, sans se soucier de savoir si une autre unité d’affaire l’a déjà fait. Elle exécute ses opérations, en contrôle la qualité avec des exigences élevées, et transmets le résultat sous une forme qu’elle estime la plus adaptée. Les systèmes d’information automatisent cette logique.

Au sein de ces organisations, dites en silos, la facture ne suit pas automatiquement la fourniture d’un service au client, on continue de vendre des services à des clients qui engloutissent la marge et on a du mal à établir une vision partagée du chiffre d’affaires.

Pourtant, avec le management par les processus et le Web, nous sommes dans l’ère de l’intégration : les opérations se font en temps réel, la production est tirée par la demande client. L’optimum global n’est plus la somme des optimums locaux.

L’approche SOA ne touche pas suffisamment au métier et à l’organisation pour sortir les organisations de cette logique. L’architecture d’entreprise, en considérant le métier, l’organisation et la technique comme les diverses facettes d’un même système complexe, propose une démarche innovante de management des transformations métier, qui permet aux entreprises de sortir de la phase silo et de réussir leur passage à l’ère de l’intégration. Elle promeut la multidisciplinarité et les approches systémiques, c’est-à-dire qui traitent autant des hommes, des systèmes que des technologies. Elle est nécessaire pour relever les enjeux des innovations futures d’un monde de plus en plus connecté.

La plupart des DSI, comme les managers en général, tiennent comme fondamental d’avoir accru les compétences de leur organisation. Ils ont davantage de chances d’atteindre, voire de dépasser, leurs objectifs et sont plus forts pour résister aux périodes difficiles. De plus, les collaborateurs qui ont progressé, font preuve d’une plus grande loyauté à leur égard et à celui de l’entreprise. Ces managers voient leur taux d’attrition baisser.

Pourtant,  l’architecture et l’architecture d’entreprise pourraient vous surprendre. Bien que vous ayez formé tous vos architectes, vous ne parvenez pas à accélérer le rythme des changements de l’architecture de votre système d’information. Cela parce que les architectes ne réalisent qu’une partie de l’architecture, les choix de conception et les décisions sont faits par les chefs de projet. Certaines entreprises ont même inventé le nom “Les chefs de projet technique” afin de promouvoir leurs architectes à la position de manager. Cela signifie que si vous avez investi pour le déploiement d’un framework comme TOGAF parmi vos architectes, vous pouvez sans doute, manquez votre retour sur investissement.

Ainsi, lorsque vous envisagez un plan pour accroître les compétences de votre organisation sur l’architecture , vous feriez mieux d’analyser “qui réalise l’architecture” et la façon dont cela est fait. Dans tous les domaines de l’Architecture – Niveau entreprises, systèmes d’information, technologique – vous avez 2 types d’architectes: celui qui s’occupe du contexte et des environnements, celui qui s’occupe d’un domaine dmétier ou d’une solution. Si l’architecte est le nom consacré pour le premièr, le second est souvent le chef de projet, ou un expert en solution technique pour la conception de la mise en oeuvre d’une solution. D’autre part, si vous voulez changer la façon dont les projets font l’architecture, si vous ne vous basez que sur les architectes, vous serez à court de ressources rapidement, et, en plus, vous perdrez vos chefs de projet.

Il vaut mieux reconnaître le rôle du chef de projet dans l’architecture de domaine ou de solution. Comme il fait partie du processus d’ensemble , il doit être inclus dans les plans de formation, et devrait rapporter au comité d’architecture pour cette activité. TOGAF 9 n’a pas oublié les chefs de projet dans son cadre de compétences.

Dans votre organisation vous avez des architectes d’Enterprise métier, architectes d’Enterprise  Système d’information, des architectes d’entreprise  techniques  qui conçoivent ensemble des services partagés pour les domaines et les solutions. Ensuite, vous avez les chefs de projet en charge de l’élaboration de solutions, pour lesquelles ils emploient des architectes de solution – métier, données, applications, techniques -.l’Architecte  d’entreprise en chef encadre tous les architectes d’entreprise, il est responsable des outils, des méthodes et de la qualité des processus de conception et de mises en œuvre, conformes à la stratégie.

Aujourd’hui, la plupart des organisations ont des architectes de solution qui travaillent pour les chefs de projet, et un architecte d’entreprise en chef souvent concentré sur l’architecture technique. Plus rares sont celles qui ont des  architectes d’entreprise en Systèmes d’Information. fréquemment, l’architecture d’entreprise est tenu à l’écart des métiers. L’augmentation des compétences de votre organisation exige, à certains égards, des changements organisationnels, une  réingénierie des processus et un plan de formation personnalisé.

RUP et les autres approches de développement de logiciels utilisent cette définition.

l’IIBA dans le BABOK 2,0 prend un court-circuit et élargit le périmètre de la définition de l’IEEE grâce au mot partie-prenante : “une exigence est (1) Une condition ou une aptitude nécessaire à une partie prenante pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées. (3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

(1) concerne les exigences organisationnelles et métier tandis que (2) concerne les exigences de solution.

Pour le BABOK 2.0 (1) est découpé entre exigences d’entreprises classifient les objectifs globaux d’une organisation et les exigences des parties prenantes qui classifient les besoins des intervenants en particulier. (2) concerne les exigences fonctionnelles et non fonctionnelles.

Il est étonnant de voir comment l’IIBA a ignoré les initiatives d’Architecture d’Entreprise qui visent à renouveler la gestion des exigences au sein du cycle de vie de la transformation de l’entreprise.

Malgré tout, les exigences continuent à être collectées au travers des modèles que nous connaissons depuis les temps immémoriaux: IDEF0 , SADT , UML , BPMN , … avec quelques améliorations sur les exigences non fonctionnelles.

Alors qu’il y -t-il à la table de jeu?

BABOK 2,0 décrit en détail le processus de gestion des exigences, l’Architecture d’Entreprise décrit le cycle de vie des exigences et la gestion des modèles au sein de la transformation de l’entreprise, BISL guide l’organisation pour gérer les exigences du point de vue du métier.

La gestion des exigences est aujourd’hui un enjeu important pour rendre les entreprises agiles, car, au fur et à mesure qu’elles se transforment, leurs exigences changent encore plus vite. C’est pourquoi elles ont besoin de savoir gérer ces changements pour réussir.

Je me demande qui va commencer à travailler sur une vision intégrée, non seulement pour spécifier un nouveau cadre de travail, mais pour alimenter des outils logiciels qui soutiennent le cycle de vie complet des exigences d’entreprise afin de faire émerger une véritable transformation d’entreprise conduite par les modèles.

En effet, les logiciels de gestion d’exigences d’entreprises sont mal intégrés aux logiciels de conception. Cela ne contribue pas à combler le fossé entre architecture d’entreprise et architecture pour régir les programmes et les projets de grande envergure.

Un autre point devant être couvert par les logiciels, est de savoir créer et maintenir les liens entre cibles, existant, écarts, et construire des feuilles de route et des projets, autorisant de multiples scénarios métier et gérant les versions.

Ces 2 points contribueraient grandement à améliorer l’agilité des entreprises et leur capacité à se transformer. Ainsi, quel éditeur de logiciels va se décider à les prendre en compte et à les inscrire sur sa feuille de route ?

Revenons un peu sur le projet d’Urbanisation de Paris…
Le modèle en avait été les quartiers ouest de Londres reconstruits après l’incendie de 1666.
Les idées directrices furent une meilleure circulation de l’air et des hommes et une maîtrise d’éventuels soulèvements populaires. L’homme est au centre du projet.

Le projet a une obsession : la ligne droite autrement appelée le « culte de l’axe ».

S’ensuivirent les transformations que l’on connaît : percements de boulevards et d’avenues, construction des théâtres de la Ville et du Châtelet, ainsi que deux gares – Gare de Lyon et Gare de l’Est -, aménagements de parcs et jardins, création de circuits d’adduction d’eau et d’un réseau d’égouts, annexation de communes limitrophes.

Des règlements imposent des normes très strictes quant à la hauteur et au style des édifices.

Cette transformation a un coût très élevé estimé à 26 milliards d’euros d’aujourd’hui. Au total, on estime que les travaux du baron Haussmann ont modifié Paris à 60 %.

En conclusion, le projet d’Urbanisation de Paris a été mené tambour battant sous la férule d’un Chef de projet volontariste, Haussmann, lequel avait la confiance de son client et supérieur, Napoléon III, qui souhaitait un changement rapide et visible.

La question de l’analogie avec l’Urbanisation des systèmes d’information (SI)
Quel Urbaniste n’a pas un jour rêvé d’être le Baron Haussmann de son système d’information, et d’avoir la même latitude pour réaliser ses transformations : rationaliser les quartiers, développer les référentiels, ordonner la gestion des flux ?

La conduite du projet d’Urbanisation des SI est réalisée au moyen des règlements d’urbanisme, d’un plan d’ensemble et du principe de subsidiarité. Il s’ensuit que l’Urbaniste a la difficile tâche de convaincre les différents projets que suivre un plan d’ensemble, est non seulement bénéfique pour eux-même, mais également pour l’ensemble de l’entreprise. Il a aussi la tâche de convaincre la Direction Générale que le plan d’ensemble qu’il propose mène à l’alignement des SI avec la Stratégie, prérequis pour que l’entreprise tire le meilleur parti de son SI.

Les Urbanistes, ayant souvent du talent, les projets et la Direction Générale sont convaincus par le plan d’ensemble, mais sa mise en œuvre est souvent repoussée à cause d’impératifs opérationnels qui nécessitent de reconduire les pratiques existantes. Les budgets volontaristes de réalisation de grandes infrastructures, c’est à dire non portés par un projet métier, sont extrêmement rares.

L’Urbaniste n’est décidément pas le Baron Haussmann.

Et l’Architecture d’Entreprise dans tout cela ?

Par son objectif affiché de conduire la transformation de l’entreprise, l’architecte d’entreprise n’a pas à convaincre les acteurs de la transformation, comme il globalise les actions et les décisions, il ne butte pas sur l’intérêt de l’un au détriment de l’autre. Il n’a pas à justifier ses plans par le concept d’alignement, très abstrait, puisque sa mission, confiée par la Direction Générale, est simplement de réussir la transformation qui la réalise la stratégie de l’entreprise.

De part sa position dans l’entreprise, la probabilité de rencontrer des Architectes d’Entreprise à l’image du Baron Haussmann, ne peut que croître.

Une cible et une trajectoire partagées en cohérence avec la vision stratégique de l’Entreprise. C’est un objectif habituellement difficile, notamment avec la multiplication des parties-prenantes. L’architecture d’entreprise permet grâce à la gestion des exigences et aux vues d’architecture, d’organiser des cascades depuis le management stratégique jusqu’au management opérationnel, de tenir et créer  la cohérence.

Des business case de projets, réalistes, et soutenus par le management. Les business case de projets ne doivent pas être que financier, mais prendre en compte tous les éléments techniques, organisationnels et stratégiques du projet. L’architecture d’entreprise permet de constituer l’ensemble de ces éléments de manière partagée.

Une processus de prise de décision pour le lancement et le suivi de projets qui mobilise les bonnes personnes au bon moment. L’Architecture d’Entreprise vise à formuler les bonnes questions à la bonne personne au bon moment.

Une implication des responsables fonctionnels et opérationnels tout au long de la vie du projet, et notamment pour la matérialisation de la valeur métier prévue. En considérant dans un même plan, les aspects organisationnels, opérationnels, stratégiques et techniques, l’Architecture d’Entreprise ramène l’intérêt des responsables opérationnels et fonctionnels vers les projets.

Une vision partagée des processus métier permettant la déclinaison des objectifs opérationnels et la mise en cohérence des projets avce ces objectifs opérationnels. En mettant au centre de ses apports les vues d’architecture et le partage, l’Architecture d’Entreprise donne au métier des outils de management opérationnels.

Une gestion de portefeuille de projets adaptées aux enjeux de l’entreprise L’Architecture d’Entreprise appuie la gestion de portefeuilles de projets, notamment en sécurisant les dépendances et les trajectoires.

Un Référentiel d’Architecture d’Entreprise permettant de capitaliser et de partager les pratiques et les services d’entreprise. A condition que le référentiel d‘Architecture soit adapté et déployé en synergie des processus de management existants, dans un esprit lean, c’est à dire juste ce qu’il faut au moment où il faut.

Un leadership permettant de donner un sens à l’ensemble des projets par rapport à des objectifs stratégiques et responsabiliser le management. Dans toute thématique de management, pour réussir,  le leadership est essentiel. L’architecture d’entreprise ne doit pas être un bureau d’étude de plus, mais un levier de leadership.

Voici le lien pour télécharger l’article complet.ArticleGouvSIAE.pdf