ManITIS, le pilotage du SI

Pour définir le retour sur investissement de la mise en place d'une organisation d'architecture d'entreprise adaptée au SI, il convient dans un premier temps de définir quelles sont les actions spécifiques à réaliser pour mener à bien ce projet:

Qu'est-ce que l'architecture d'entreprise?:

L’architecture d’entreprise est un mode de management de la transformation de l’entreprise. L’AE permet de savoir où nous en sommes, ce que nous avons et où nous voulons aller afin de construire les systèmes et processus créateurs de valeur pour l'Entreprise. Elle doit donc être considérée comme un support à la réalisation de la stratégie de l’entreprise.
L’AE sert de lien entre tous les acteurs et partenaires du système d’information, depuis le client jusqu’au équipes d’exploitation et de support client.
Pour réaliser ces objectifs, L’architecture d’entreprise doit proposer une vision fiable des différents maillons de la chaine, depuis l’analyse des besoins clients jusqu’aux contraintes de production et de support.
Les différents métiers d’une entreprise possèdent tous un ou plusieurs processus fonctionnels, qui doivent interagir entre eux pour assurer la bonne marche de la société. Chacun de ces processus est évalué, de façon formelle ou non, pour assurer l’optimisation des résultats. Les indicateurs de performances sont fréquemment utilisés pour identifier les apports et les faiblesses des actions commerciales par exemple.
Si l’on considère les métiers de la DSI par exemple, plusieurs méthodes sont en vigueur afin d’évaluer, modéliser, procédure les activités des différentes fonctions et services : PMI, PRINCE2, P3O, Scrum pour les projets, CMMI, P3M3, OPM3 pour l’évaluation, UML pour la modélisation, ITIL pour la gestion des services…Toutes ces méthodes proposent les meilleures pratiques pour la mise en œuvre et le pilotage de leurs activités de référence. Alors pourquoi ajouter l’architecture d’entreprise dans une liste déjà longue de bonnes pratiques ?
Malheureusement, Malgré l’existence des méthodes et bonnes pratiques, force est de constater que l’échec ou le retard de nombreux projets, la survenance d’incidents récurrents, sont fréquemment dus à une mauvaise communication entre les processus du SI, même dans les organisations dont la maturité dans l’exploitation des processus est avérée.
Les fonctions d’architecture d’entreprise sont définies pour permettre une d’apporter une cohérence dans les différentes pratiques, méthodes, outils, processus, afin de garantir la continuité de traitement et d’usage sur l’ensemble de la chaine.
Les différentes étapes ou modèles définis dans un cycle d’architecture TOGAF sont déjà définies dans la plupart des méthodes précitées.

La méthode TOGAF propose un modèle basé sur 3 dimensions complémentaires :

Un cycle de développement:

• Le cycle en 8 étapes permet de définir l’instruction de l’architecture, la gestion des exigences et la gouvernance de réalisation.
  

Un cadre de contenu d’architecture, référentiel qui va permettre de partager :

• Les normes et règles d’architecture de l’entreprise
• La connaissance des systèmes existants
• Les composants normalisés qui doivent être utilisés prioritairement
  

# Un cadre des capacités de l’entreprise permettant d'identifier :

• Les compétences disponibles
• Les instances de gouvernance existantes
• L’organisation existante.
  

Comment évaluer les gains apportés par l’architecture d’entreprise ?

Le fonctionnement d’une structure d’architecture d’entreprise transverse à l’ensemble des métiers, ne nécessite pas le recrutement d’une nouvelle équipe ou de nouveaux processus.

Les indicateurs de performance de l'activité d'architecture d'entreprise vont donc être à déterminer par rapport aux gains estimés sur chacun des processus métiers qui feront l'objet d'une transformation.

Le retour sur investissement de la mise en pratique dans l’organisation d’une méthodologie d’architecture d’entreprise porte donc essentiellement sur le ROI apporté par l’amélioration des processus métiers concernés.

Si, par exemple, nous évaluons les gains apportés aux projets, il faudra prendre en compte les différents KPI permettant d’évaluer les délais, couts, qualités, mais aussi les KPI appliqués à la phase de production de l’application en termes d’incident et de satisfaction utilisateur.
La méthode d’’architecture d’entreprise va permettre cette évaluation sur l’ensemble de cycle de vie.
Les ressources qui vont être nécessaires à cette organisation seront principalement transverses, de par la nécessité de disposer de compétences opérationnelles fortes sur chacun des métiers.

Les besoins en outil outils sont également déjà définis dans les différentes méthodes de pilotage ou de gouvernance (portefeuille projet, Cmdb, plan qualité…) il convient donc de fournir une extension de ces différents référentiels de manière à disposer d’une information unifiée.

Il n’y a donc pas de nouveauté spécifique à l’architecture d’entreprise, mais uniquement un cadre et une organisation fédérateurs à tous les métiers, processus et usages de l’entreprise.

L’évaluation du ROI d’un projet de mise en œuvre de l’architecture d’entreprise sera donc relative au travail à accomplir pour cartographier l’existant et identifier les améliorations à apporter sur les processus.

Une des fonctions de l’architecture d’entreprise est ensuite de définir le roi des différents chantiers à lancer pour définir les priorités de la transformation.

Alors que la mise en oeuvre d'un produit industriel fait appel en général à une méthodologie avancée, le système d'information reste, pour de nombreuses entreprises, une ressource immatérielle mise en oeuvre par des experts qui vont pouvoir répondre à tous les besoins et assurer un fonctionnement à moindre côut.

Qui imaginerait, dans un projet de construction, se passer de ou des architectes, des urbanistes?
Qui laisserait le client rajouter un escalier alors que le projet est a moitié terminé?
Qui ouvrirait le service au public avec un ascenseur sans sécurité ou un balcon sans rampe?

C'est pourtant ce qui arrive tous les jours dans les projets SI...

il est souvent reproché la lourdeur des méthodes de gouvernance, de pilotage ou d'analyse (PMI, PRINCE2, ITIL, Togaf, UML, merise...).

C'est surement vrai.

Ces méthodes engendrent également un contrôle fin de l'activité des différents acteurs du projet, chose plutôt inhabituelle jusque récemment dans nos métiers et plutôt mal perçue.

Il semble donc qu'un projet SI soit composé d'une somme d’intérêts divergents, que seul une organisation rigoureuse peut permettre de faire converger:

• Le client qui souhaite qu'on puisse répondre à son besoin, mais qu'il ne souhaite pas exprimer trop précisément, afin de pouvoir le faire évoluer au fil de l'eau.
  

• Le DSI qui souhaite réaliser l'opération dans le budget qu'il a présenté, mais qui subit la pression pour répondre aux besoins business...
  

• Le chef de projet a qui on impose de terminer dans les délais coute que coute.
  

• Le technicien qui souhaite réaliser les opérations comme il l'entend, mais qui ne veux pas que l'on puisse se passer de lui.
  

• le support technique qui va récupérer les plaintes utilisateurs en production, qui au final va retourner le constat d’échec...