Architecture d'entreprise et performance économique IT

Les outils de pilotage pour les DSI

Le principal outil peut-être le plus important par les temps difficiles actuel, c’est le pilotage financier de la DSI. Nous avons longuement évoqué à travers différents articles, la nécessité d’avoir une compréhension de l’économie de la DSI. Celle-ci est grandement facilitée par la mise en place d’un modèle économique. Il ne s’agit pas de simplement établir et suivre un budget, chose indispensable par ailleurs à minima, mais bien de se doter d’outils qui éclaire sur les mécanismes de construction des couts des missions et des services proposés par la DSI.
Le pilotage financier s’adosse à d’autres outils de gouvernance complémentaires qui ensemble apportent un éclairage sur l’écosystème DSI et qui aident à garder le cap vers les objectifs stratégiques.
Le pilotage des systèmes d’information est complexe car l’objet SI est lui-même très complexe. Pour mieux le comprendre, il convient d’abord d’avoir recours à un principe réductionniste (par opposition au principe holiste). En tant que tel, le SI incarne un objet protéiforme dont l’analyse et la mise en évidence des problématiques changent selon les partie-prenantes. Il convient donc de réduire l’objet SI en plusieurs objets plus fin qui correspondent aux préoccupations d’une population donnée (métier, étude, sécurité, opérations, …). Le principe réductionniste guide les cadres d’architecture d’entreprise. Ils proposent un découpage du SI, concept monolithique difficile à appréhender en tant que tel, en plusieurs concepts distincts. Nous nous appuierons sur les principes de découpage des cadres d’architecture d’entreprise pour identifier les perspectives d’analyses propre à chaque strate et verrons les interactions entre les outils d’un cadre d’architecture et l’apport d’un modèle économique des SI.

Cadres d’architecture d’entreprise

Un cadre d’architecture d’entreprise peut être défini comme un métamodèle comprenant un ensemble de vue et de représentations possibles d’un système d’information. Il donne les règles de construction des modèles, établis les relations possibles entre les objets des modèles. C’est aussi un outil de production, de documentation et de maintenance des architectures. Il définit également les processus et les instances de gouvernance. Parmi les cadres d’architecture d’entreprise les plus célèbres, nous pouvons citer le TOGAF ou le CEISAR.

Les points de vue sur le SI

Afin de faciliter l’étude des SI, un principe convenu est de diviser un problème complexe en autant de problèmes plus simples (le principe réductionniste évoqué ci-dessus).
Il faut donc maîtriser la complexité du SI en se donnant les moyens de construire une vision plus simple à travers 2 artefacts issus de la modélisation, les vues et les modèle (Les définitions de vue, préoccupation et partie-prenante sont tirés de la norme ANSI/IEE Std 471-2000).

Les Vues

Une vue est une représentation d’un système depuis la perspective d’une ensemble apparenté de préoccupations. Une vue va donc comprendre un ou plusieurs modèles choisis de façon à démontrer aux partie-prenantes concernées que leurs préoccupations sont bien correctement adressées.

Les modèles

Un modèle est un moyen de représentation de la réalité en une fiction contrôlée. On convient d’une représentation simplifiée mais somme toute réaliste d’une réalité. Les modèles sont des diagrammes composés d’objets nantis de symboles graphiques. Les objets sont en relations les uns avec les autres. L’ensemble objets et relations compose un modèle  (ou un diagramme) de représentation. Cette méthode permet de construire une représentation consensuelle du SI partagée par les différents protagonistes. L’architecture d’entreprise décompose le SI en 4 vues :

• La vue métier : C’est la vue des processus métiers. On y décrit les activités fondamentales des principaux métiers de l’entreprise. Les processus sont composés d’activité. L’analyse des processus métiers permet de mettre en évidence les informations métiers (étape préliminaire pour la gouvernance des données) et les opérations sur ces informations.
• La vue fonctionnelle : C’est le plan d’occupation des sols. Elle propose une structuration en zone fonctionnelle cohérente et homogène des fonctions métiers de l’entreprise. Elle structure les attentes et les responsabilités des acteurs autour de zones fonctionnelles bien délimités.
• La vue applicative : C’est la vue qui décrit le patrimoine applicatif de l’entreprise. Le recensement des applications, leurs rôles, les flux entrants et sortants de chaque application sont à titre d’exemple les éléments décrits dans cette vue. La vue applicative peut être mappée sur la vue métier en mettant en relation les tâches métiers et les services applicatifs. De même les informations métiers peuvent être codées par des données structurées manipulées à travers les applications. Ce travail permet de faire une cartographie des relations entre processus et applications, entre services applicatifs et activités, entre informations métier et données.
• La vue technique : Cette vue a pour vocation de décrire les composants logiciels et matériels qui supportent les applications. On y trouve d’une part les composants de la couche logicielle, ceux qui de par les agencements respectifs les uns par rapport aux autres décrivent la chaine de liaison logicielle d’une application et d’autre part les composants matériels qui sont les fondations du système informatiques.

Le découpage du SI avec la vue fonctionnelle est une particularité française, les cadres d’architecture comme TOGAF ou FEAF passent de la vue Business directement à la vue Applications ou substitue à la vue fonctionnelle la vue Data.

La notion de roadmap

Les modèles et diagrammes permettent de faire une description du SI. Ils alimentent la réflexion sur le diagnostic du SI dans son état actuel. Cependant pour atteindre les cibles définis, il faut construire une trajectoire entre l’état actuel et la cible. C’est le rôle de la feuille de route ou roadmap en anglais. Une roadmap permet de se doter d’une vision à moyen terme. C’est un exercice utile pour donner de la visibilité sur la trajectoire de la DSI d’ici à 3 ans. Même si les changements sont rapides et brutaux, définir une cible et une trajectoire est préférable à la navigation à vue.
La roadmap définit :
  les cibles, les étapes intermédiaires à atteindre

• Le calendrier,
• L’équipage,
• L’organisation
• Les moyens financiers.

Reprenons chaque vue et voyons en quoi un modèle économique est un atout complémentaire à forte valeur ajoutée.

Vue métier et modèle économique

Les cadres d’architectures d’entreprises proposent une couche métier dont l’objectif est de décrire les processus, les activités, les tâches, les informations et les opérations manuelles ou automatisés. Le but est de voir les axes d’amélioration en éradiquant les tâches inutiles ou les ruptures dans les processus.
Les demandes métiers naissent suite aux constats d’un système d’information inadapté, incomplet ou archaïque.  On définit ici un système d’information comme l’ensemble des processus et des informations nécessaires pour atteindre les objectifs assignés à une organisation. Intrinsèquement un système d’information n’informe en rien sur son niveau d’automatisme : il peut être très efficace et complétement manuel.
De l’expression métiers, un travail de formalisation du besoin et de qualification des meilleures options émergent : Si des outils informatiques sont envisagés alors ils peuvent être obtenus soit par un développement interne soit par acquisition de progiciels.
Dans la phase de diagnostic, un modèle économique constitue la mémoire des efforts informatiques des métiers. Il permet de voir les dépenses comptabilisées par le passé tant en projet qu’en opérations. C’est donc un atout pour prioriser les efforts ; il permet de mesurer précisément les dépenses par métier, par domaine d’activité stratégiques, par segment de marché,… C’est une aide précieuse pour la construction d’un portefeuille de projet, surtout en intégrant les couts récurrents de la production informatique (coût du run) aux couts projets.
Car un modèle économique permet de mesurer les coûts en production informatique des choix des projets métiers. En s’appuyant sur des inducteurs de consommations clair et non polémique (nombre de serveurs, nombre  de Go de stockage, nombre d’incident, …), la DSI se positionne comme un acteur en mesure d’expliquer le niveau de dépenses de certaines prestations informatiques (par exemple les applications utilisées par un métier), comme un acteur en mesure de proposer des actions pour en réduire le cout (par exemple proposer des formations utilisateurs pour baisser le taux de sollicitation du centre d’assistance). La compréhension de la structure de couts des prestations délivrées par la DSI permet de responsabiliser les métiers notamment vis-à-vis de certaines dépenses pour lesquelles la DSI n’est pas redevable (par exemple les couts d’acquisition et de maintenance de progiciel choisi par les métiers mais dont les couts sont supportés par la DSI).
L’historique des couts passés permet de disposer d’abaque permettant de mieux évaluer les couts projets (abaques par activité projet) et les couts de production (en fonction de typologie d’architecture applicative, de la volumétrie, des exigences de disponibilité et de performances, …). Fort de ces acquis, la DSI est mieux armée pour évaluer les retours sur investissement des diverses solutions envisagées pour répondre aux demandes d'évolution métiers.
Afin, l’agrégation des couts projets et des couts récurrents des opérations par métier contribue à une meilleur évaluation de la valeur apportée par les services informatiques. En déterminant pour chaque métier, chaque client, chaque segment de marché, … la quotepart de couts informatiques tant « build » que « run », on apporte à éclairage sur la performance économique de la DSI dans l’atteinte des objectifs métiers. Cela permet d’avoir une connaissance réelle du poids de l’informatique dans le total des dépenses financières d’un métier, d’un segment de marché, .d’un produit…. De là il est plus facile de voir la contribution de l’informatique dans le niveau de performance du métier par exemple en estimant les couts supplémentaires qu’il faudrait engager pour un même niveau de production et qualité équivalente mais sans la mise à disposition des outils informatiques.
La mesure de l’intensité des dépenses informatiques n’a de sens qu’au regard des gains de productivité du métier. En effet, on investit dans des outils informatiques pour qu’un métier, une organisation, une entreprise, … obtiennent des gains de productivité. Donc un modèle économique DSI qui remonte périodiquement les couts Build et Run d’un métier permet de mesurer ses gains en rapprochant le volume produit à ses couts globaux, ceux-ci incorporant sa quotepart de cout informatique. Même si la dépense informatique augmente, on sera gagnant tant que le cout unitaire d’un métier baisse.
Un modèle économique permet de mesurer et de suivre dans le temps la valeur ajoutée de la DSI aux métiers de l’entreprise. Cela permet de positionner la DSI autrement que comme un simple centre de coûts.

Vue applicative et modèle économique

La vue applicative d’un cadre d’architecture d’entreprises se compose de modèles dont le but est de décrire en autres :

• Les utilisateurs de l’application et les responsables
• L'état de maturité fonctionnel de(s) application(s)
• Les fonctions applicatives
• Les composants logiciels, l’infrastructure logicielle (serveur de présentation, bus de message, bases de données, …),
• Les flux synchrones et asynchrones sortant en entrant de l’application avec les données échangées et leurs périodicités.

Il est possible d'établir des liens entre la vue applicative et la vue fonctionnelle pour pouvoir illustrer quelles tâches sont supportés par quels services applicatifs. Cela permet de souligner les opérations métiers qui ne sont pas automatisés ou au contraire celles qui le sont par plusieurs services applicatifs et qu'il convient de rationaliser.
Une tel cartographie permet de mesurer l'’impact engendré par les évolutions des processus ou des applications et constitue de ce fait un élément d'organisation des projets à inscrire au portefeuille de projet.
La cartographie du parc de l’application peut se faire dans le cadre d'un outil APM (Application Portfolio Management) ou plus prosaïquement sur un tableur. Peu importe l'outil mais il est utile de faire l'inventaire du patrimoine applicatif au regard notamment de leur maturité fonctionnel. Cela consiste à positionner chaque application sur un cycle de vie fonctionnel afin d'arbitrer les évolutions à faire et donc les charges à inscrire au PPM (Porfolio Project Management). Il ne s’agit pas du cycle de vie d’un projet (spécification, construction, tests, mise en production,….) mais bien d’un cycle de vie d’une application à l’image du cycle de vie d’un produit (lancement, croissance, maturité, déclin). Une application est bien un produit vue des métiers, c’est d’ailleurs ce qui explique l’approche consumériste en s’approvisionnant notamment si nécessaire en dehors de la DSI.

Cycle de vie d’une application

Une application peut-être :

• En projet : L’application n’existe pas sur les infrastructures de production néanmoins il est important de la matérialiser dans le catalogue car il est courant d’avoir déjà engagé des dépenses (acquisition de progiciels, maintenance, prestation de mise en œuvre, …). L’application est donc un objet de coûts pour la DSI avant même sa mise en production. Ceci permet de faire prendre conscience aux acteurs que les charges décaissées sont décorrélés de la date de mise en production. C’est aussi pour cette raison qu’il est important de faire les investissements dans un délai le plus proche de la mise en production.
• En croissance : L’application est en production et continue à avoir des évolutions majeures et mineures. Elle élargie son périmètre fonctionnelle. Il est normal d’avoir du budget dans le portefeuille de projet pour des applications en croissance (projets et maintenances évolutives)
• Mature : l’application est stable, seules des évolutions réglementaires sont nécessaires. Dans un cadre de gestion de portefeuille de projet, on sera particulièrement vigilant à contenir les demandes projets aux seules évolutions contraintes. Les couts « Build » des applications matures doivent suivre une tendance baissière. Cependant, les couts Run des applications matures ont souvent tendance à augmenter si on n’est pas vigilant sur les couts de stockage ou de sauvegardes (augmentation naturelle des données).
• En fin de vie : L’application est toujours en production mais son remplacement est programmé. Plus aucun investissement fonctionnel ne doit exister. En toute logique, une application en fin de vie ne doit plus supporter de couts de projet, ni de maintenance évolutive ou corrective (sauf évolutions réglementaires contraintes). Seuls les couts Run perdurent, on doit rester vigilant à contenir stable le niveau de consommation des infrastructures des applications en fin de vie. Fort logiquement, aucune demande métier ne doit être engagée sur des applications en fin de vie. Regardez par exemple s’il n’y a pas des lignes de maintenance évolutive portant sur de telle application. C’est parfois révélateur de quelques économies potentielles !
• A décommissionner : C’est une application qui n’est plus utilisée mais pour laquelle l’effort de démantèlement du SI n’a pas encore été entrepris. Autrement dit bien que plus utilisée, elle est toujours présente sur les infrastructures de production (au cas où). Ces applications coûtent car elles continuent à consommer des infrastructures. Elles sont en général une des explications de la lente mais inexorable augmentation du poids du RUN face au Build. Si on ne fait rien, à budget constant le Run vient asphyxier le Build. Il est donc important d’identifier ces applications et de provisionner des projets techniques pour les sortir du SI. La cartographie des applications avec le cycle de vie instruit donc le portefeuille de projet.
• Sortie : Ce sont des applications qui ne sont plus utilisées et qui ont été sorti du SI. L’effort de décommissionnement a été entrepris. Il ne reste plus rien de ces applications sur les infrastructures. Fort logiquement, il n’y a plus rien en cout build et en cout « run ».

Cycle de vie fonctionnel et technique

Pour chaque application, il est possible de gérer un cycle de vie fonctionnel et un cycle de vie technique. Ci-dessus nous nous sommes polarisés sur le cycle de vie fonctionnel. L’état technique d’une application se mesure au regard de l’état de ses composants logicielles et matérielles vis-à-vis d’une roadmap technique. Ici, il s’agit de renseigner l’état fonctionnel de l’application au regard des attentes des métiers, ce qui signifie qu’à priori seuls ces derniers sont légitimes pour qualifier l’état fonctionnel d’une application.
Ainsi une application qui repose sur des composants logiciels ou matériels qui ne sont plus maintenus peut très bien être satisfaisante d’un point de vue fonctionnel : elle répond pleinement aux enjeux métiers. A l’inverse il peut y avoir des applications qui reposent sur une architecture à l’état de l’art mais complètement obsolète fonctionnellement. L’obsolescence technique des composants d’une application se mesure vis-à-vis de la roadmap techniques ce que nous illustreront dans la couche technique ci-dessous.
En croisant l’état de maturité des applications et le portefeuille de projet, il est possible parfois de mettre en évidence certaines dépenses projets dont la justification peut être remise en cause, par exemple :

• Lignes budgétaire des maintenances évolutives sur des applications matures ou en fin de vie : A priori, une application mature est stable par conséquent elle ne doit plus évoluer. Il ne devrait plus y avoir des couts concernant des projets ou des maintenances évolutives.
• Lignes budgétaires de maintenance corrective sur des applications matures ou en fin de vie : Il peut arriver de constater des taux de maintenances correctives importants sur une application mature. Si une application mature supporte à taux important de cout en maintenance corrective, on s’attachera à voir s’il ne faut pas investir pour réduire le poids du MCO. Il peut parfois être nécessaire de dégager du budget pour réduire par la suite les couts études récurrents d’application de cet acabit.
• Applications à décommissionner et projets techniques : Comme dit précédemment, une application à décommissionner est toujours présente dans le SI. Si rien n’est fait, l’arrivée de nouvelle application s’ajoute aux applications à décommissionner et in fine contribue à l’augmentation du cout du Run qui à budget constant vient asphyxier le Build. Il est donc important de prévoir un montant dans le budget projet afin de décommissionner des applications. Pour tout nouveau projet inscrit au portefeuille de projet, regarder l’impact des  futures applications sur le SI grâce à la cartographie applicative du SI, identifier les cibles à remplacer et provisionner les projets de décomissionnement. Ces projets sont à mettre impérativement dans le calcul de rentabilité des projets sinon la DSI n’aura plus la capacité à relever les nouveaux enjeux métiers à cause de l’asphyxie du build par le Run.

Les arbitrages concernant les applications et les conséquences au niveau du portefeuille de projet ne peuvent se faire qu’en croisant les informations sur le cycle de vie des applications et les enjeux financiers qui y sont liés. Pour cela, un modèle économique en affichant les couts des projets et les couts « Run » constitue une aide importante pour les arbitrages projets. Il permet de mieux cibler les projets à inscrire au portefeuille de projets.

Vue technique et modèle économique

La vue technique apporte un éclairage sur l’ensemble des technologies exploitées par la DSI. Elle permet de faire une cartographie des compétences humaines nécessaires pour les administrer, d’anticiper les évolutions liés aux montées de versions ou aux changements technologiques, de préparer les budgets des projets techniques pour maintenir à l’état de l’art le SI. Comment évaluer pleinement les conséquences financières et organisationnelles d’une nouvelle version d’un produit ou d’une nouvelle technologie ? Comment en mesurer l’impact sur les ressources humaines (profil ; nombre d’ETP ; sourcing) et sur les couts d’infrastructure sans avoir au préalable une connaissance précise des couts actuels des principaux centres technologiques (Stockage ; Serveurs X86 ; Mainframe Z/OS ; Réseaux data ; …) ?  C’est justement l’apport d’un modèle économique que de pouvoir connaitre le coût complet d’exploitation d’une technologie. Le modèle de cout du CRIP par exemple récence 21 centres technologiques et propose un modèle d’activité pour en appréhender le cout à travers :

• Une activité d’acquisition de la technologie
•  Une activité d’exploitation / administration de la technologie

Il propose de plus des inducteurs permettant de mesurer le niveau de l’activité en fonction du volume consommé par les services. Ceci est particulièrement intéressant pour les activités humaines car il permet d’avoir un indicateur mesurant le rapport entre la taille d’une équipe et le volume à administrer. Par exemple, le nombre de serveur X86 administré par ETP en supposant que plus il y aura de serveur à administrer et plus la taille de l’équipe devra augmenter. Ceci apporte 3 éléments importants pour la gouvernance des opérations :

• Un indicateur de productivité : le nombre de serveur par ETP renseigne sur le niveau actuel de la DSI et permet de mesurer les progrès dans le temps par l’apport de nouvelle technologie ou par l’apport de nouvelle organisation.
• De mesurer l’intensité capitalistique d’une technologie en capital humain d’une part en capital technique d’autre part : cela permet de prioriser les actions sur les sujets les plus onéreux ; pour rappel au sein d’une production informatique le poids du K humain et du K technique est en moyenne de respectivement 70% et 30%.
• Un indicateur de cout unitaire : Le cout complet d’une technologie ramené au nombre au volume produit (par ex : cout complet X86 / nombre d’OS exploité) permet d’avoir un élément de performance actuel et permet d’anticiper l’impact à la hausse ou à la baisse du nombre d’item à gérer tant sur les couts d’infrastructures que sur les couts humains. C’est ce genre de métrique qui permet de construire des budgets prospectifs en mode BBZ (budget base zéro) pour le « run ».

Avec un modèle économique il est même possible de carotter encore plus en profondeur les couts d’exploitation en remontant sur les natures de comptes. Ceci permet de souligner par exemple :

• La répartition entre interne et externe, mesurer la dépendance à certains fournisseurs, et s’interroger sur les compétences clés à garder (on fait ici le lien avec la GPEC)
• Le montant total des amortissements et le degré d’obsolescence des infrastructures
•    …

Conclusion

En suivant le découpage du SI proposé par les cadres d’architecture d’entreprise, nous avons illustré l'apport des outils d'analyse des SI couplés à un modèle de coût. Ils incarnent ensemble un levier de pilotage de l’écosystème DSI.