Francis Jacq

Système : cas Système d'information Air France/1999

L'évaluation économique des projets d'évolution du système d'information

La problématique économique

L'évaluation économique des projets poursuit plusieurs objectifs :

- Faire apparaitre un différentiel pour le métier

- Mesurer le projet, mais surtout l'ouvrage (Couts, gains, rentabilité)

- Affecter judicieusement les ressources (Humaines, financières) et rationaliser ce choix.

- Vers les projets qui ramènent le plus d'argent (VAN maximum).

- Vers les projets qui rentabilisent le mieux chaque franc dépensé (TRI maximum).Pour que les 'petits' projets très rentables puissent passer !

- Vers les projets qui ramènent le plus vite de l'argent (Pay Back mini). On minimise ainsi le risque dans une situation très évolutive ! La concurrence peut se placer entre des projets de natures différentes : lancer une campagne de pub, réaménager une réception client ou réaliser un logiciel.

- Rechercher au travers de l'affectation budgétaire l'adéquation besoins/ressources. Optimiser l'emploi des n ressources disponibles et anticiper leur évolution en + ou -. Cet exercice peut influer sur la faisabilité du projet, ou sur son économie.

- Créer les conditions d'un double engagement (couts, résultats).

L'évaluation économique des projets permet d'aller vers une logique de portefeuille de projets visant a répartir les risques.

Quand évaluer un projet ?

L'évaluation économique du projet s'effectue :

- En début de projet, afin d'en permettre le lancement

- A chaque Comité d'Investissement et chaque Revue budgetaire

- En fin de projet, au moment ou l'équipe projet se dissout : ré actualisation des couts

- Par sondage, après un certain temps d'exploitation de l'ouvrage : réactualisation des charges et recettes différentielles

Objectifs induits

Identifier clairement les gains et les couts d'un projet donne l'occasion :

- De se poser des questions qui feront avancer la définition de ce que l'on veut obtenir. On pourra ainsi élaguer et prioriser les demandes. En particulier, on éliminera tot les demandes peu utiles qui coutent cher.

- D'enrichir la liste des conséquences d'un projet et apporter des ordres de grandeur.

- D'impliquer concrètement les responsables, qui seront amenés à prendre la mesure des éléments sur lesquels ils s'engagent.

 

Présentation d'une méthode et d'un outil

Téléchargez la présentation préparée par Francis Jacq et Patrick Mac Grégor : Evaluation économique des projets SI à Air France

L'informatique comme une ville

Aujourd'hui, les systèmes informatiques - ce que l'on appelle le "Système d'information" - sont devenus les "lieux de rencontre" par excellence. L'espace d'une entreprise devient une enveloppe qui englobe, via les données informatiques, ses clients, ses fournisseurs, ses distributeurs, ses partenaires, et bien sûr ses collaborateurs. L'entreprise se rédéfinit par les règles qu'elle impose aux différentes modalités de rencontre (rencontre d'achat d'un produit par un client, rencontre d'achat d'un produit à un fournisseur, etc.) et d'autre part, selon les différents niveaux d'accès des acteurs aux bases de données qu'elle constitue.

Il existe des dispositifs informatiques dits place de marché ou communauté qui facilitent les rencontres et les transactions résultant de ces rencontres. La société qui gère une place de marché, sans même avoir de produits en propre, impose ses propres règles à l'ensemble de ses pratiquants et constitue une masse d'information qui est distribuée sélectivement. Par contre, on notera qu'elle garde la propriété de la consolidation de cette information .. Voici la carte Internet de ces places de marché en 2007 :

Un système informatique peut être considéré comme une ville. Sur l'entrelac des réseaux techniques s'ajoute les réseaux de contractualisation entre acteurs. Puis s'y ajoutent les réseaux éphémères constités à l'occasion d'une transaction ou d'un échange. Enfin, des réseaux de consolidation de l'information apparaissent pour traiter l'historique de ces réseaux éphémères. Internet est devenue telle une Ville Globale, où se sont créés des places, des quartiers, des avenues, des rues et enfin des édifices.

Vous êtes Directeur d'une entreprise. Lorsque vous considérez votre informatique, les frontières sont difficiles à tracer. Ou finit "l'édifice entreprise" et commence "la rue" ? Dans cette "rue" qui mène à une "place de marché", qui cotoyez-vous ? Vous avez du mal à positionner ce qui vous est propre :

- dans les diverses communautés où vous proposez vos produits et où vous achetez vos composants

- dans les services communs qui, par exemple, indiquent l'éligibilité d'une personne à payer par carte bleue, ou font les intermédiaires de paiement

- dans vos publicités qui s'activent dans les moteurs de recherche

- dans les publicités des communautés qui drainent les prospects vers vos produits.

Dans cette révolution, le constat s'impose d'un retard culturel de beaucoup de dirigeants. L'informatique est toujours considérée comme une application qui automatise des tâches, afin d'augmenter la productivité. Les questions suivantes sont rarement posées :

- quels sont les standards et protocoles de réseau et de traitement de l'information que mon réseau informatique interne doit partager ?

- quelles sont les places de marché ou les communautés où mon entreprise doit apparaître ?

- quels sont les services communs à utiliser, afin de sécuriser mes échanges et mes transactions ?

- quelles sont mes apparitions, et selon quelle fréquence, sur les moteurs de recherche et les médias ?

- comment puis-je récupérer l'information constituée par l'ensemble des recherches, des transactions et des avis des clients où mon entreprise est impliquée ?

- comment organiser les différents niveaux d'accès aux données considérées comme "données de l'entreprise"

Surtout, ce qui est la ressource fondamentale, "les données Produits, Clients, Fournisseurs, Distributeurs, Partenaires, Consultations, Transactions, Après achat, Opinions .. et leur historique" est ignorée. Les données existent de façon éparse, mais il n'est pas possible de les consolider en une série continue, de leur appliquer des critère communs de tri, de scorer la densité de leur maillage.

Pour caricaturer, l'informatique de beaucoup d'entreprises se résument aux trois actions basiques d'un forain : argumenter le produit sur l'étal, faire payer et rendre la monnaie, faire les comptes de retour à la maison. Pourtant, un forain se pose d'autres questions : qui fréquente le marché ? quels produits seront demandés ? qui sont mes concurrents ? comment créer la fidélité ? Le forain accumule des informations sur la Ville, le Marché de gros, les Marchés de détail, les Tendances. Pourquoi les informatiques des entreprises ne sont-elles pas capables de faire ce que fait un forain ?

Dans ce contexte, l'urbanisation du système d'information donne lieu à deux paradoxes. Alors qu'elle devrait être une gestion clé du système d'information puisque l'informatique fonctionne comme Ville, elle est soit méconnue, soit ignorée. Secundo, parce qu'elle structure une vision globale des échanges et des données, les dirigeants et les informaticiens méconnaissent que l'urbanisation est un art de la petite évolution.

En effet, que se passe-t-il quand une ville possède un Plan d'urbanisation ? Un édifice est construit. Certes, c'est une évolution qui vient modifier la physionomie d'une rue ou d'un quartier et les flux des ressources dans les réseaux urbains. Mais c'est une évolution qui reste minime, car, au global, la ville préserve ses régulations globales.

Dans les paragraphes qui suivent, nous esquissons quelques propositions de démarches d'urbanisation du Système d'information qui concrétisent notre approche. On y verra que l'application perd sa place centrale. Trois innovations :

1/ La notion de processus est mise en avant, non pas "pour subordonner la technique au fonctionnel", mais comme méthode pour identifier les éléments du système. L'élément processus est identifié par rapport à un enjeu de valeur ajoutée.

2/ La délimitation des frontières se fait via un Bus de gestion des messages disposant d'une carte des processus, de règles sur les messages et d'un annuaire des droits d'accès des acteurs

3/ Les données sont structurées, fiabilisées et localisées de façon à faire l'objet de traitements spécifiques dégageant des informations utiles à l'entreprise (ou à une agence publique)

L'urbanisation : structurer pour faciliter les évolutions et l'amélioration des performances

La démarche de l'urbanisme est de faciliter les évolutions d’un système urbain, et par analogie d’un système informatique. Cela veut dire que le système préserve globalement sa structure et son fonctionnement d’ensemble, bien qu’un ou plusieurs éléments du système soient modifiés.
Un système doit être décomposé en éléments, car ce sont les éléments que l’on fait évoluer.

Cependant, il faut distinguer deux parts dans l’élément : une partie stable et une partie évolutive. Du point de vue de la structure du système, l’évolution de la partie d’un élément sera minimisée si cette évolution s’effectue au sein d’une « boite stable ». C’est ce que l’on appelle « l’effet boite noire », car l’évolution au sein de la « boite » n’est pas perceptible par la vue « structure statique ».

Par exemple, l’évolution d’une application sera délimitée au sein d’un processus construisant une nature de valeur ajoutée. L’évolution se fait rapidement et à faible coût du moment que l’application respecte, pour réaliser ses échanges de message avec des applications dans d’autres processus, les « Règles de mise en relation entre processus ».

Ces règles de mise en relation sont aujourd’hui implémentées dans un outil de dialogue entre applications, appelé MOM [Message Oriented Middleware].  Il est possible d’aller plus loin en concevant un Bus qui, structure stable, gèrera en son sein les évolutions dans les messageries de données. Grâce à un tel Bus, des messages entre cette application et les autres applications auront une source et une destination définies de façon non technique. Cf. un exemple de spécification d'un tel Bus : Architecture d'un Bus de gestion de message

 

Du point de vue « dynamique des relations », l’évolution sera perceptible car elle modifiera la performance de l’interaction entre les éléments. Par exemple, si une donnée est fournie en 0,01seconde au lieu de 0,1 seconde avec une qualité régulière et une fiabilité intrinsèque, la performance s’exprimera en rapidité de débit.

Les impacts des évolutions sur le système porteront sur la globalité du système : ses performances (capacité, vitesse..), sa lisibilité, ses facilités de contrôle et de maintenance, son économie (coûts récurrents, investissement).

 

Structurer par les processus d'ajout de valeur

La réalité d’une entreprise ou d’une administration est très loin de se présenter comme un système d’ensemble où les composants structurels et leurs relations mutuelles se laissent lire du premier coup d’œil.

Etape n°1 de l’urbanisation : dégager progressivement les composants structurels et leurs relations mutuelles avec les dirigeants de l'entreprise (ou de l'agence publique) de façon à faire apparaître le système. Ces composants seront à identifier par rapport aux potentiels d’évolution. Là où il y a à progresser, c’est dans la construction de valeur par rapport à un type de client ou la maîtrise d’une ressource stratégique. C’est pourquoi, la pratique préconise de se centrer sur l’identification des grands processus d'ajout de valeur.

Un processus est un enchaînement structuré d'ajout de valeur dont le résultat présente une valeur ajoutée globale. Au fur et à mesure que les ajouts sont mises en œuvre, la valeur d'un produit, d'un service ou d’une ressource se construit jusqu'à obtention du niveau du résultat final attendu.

Principe : Un  processus  doit  être  bouclé,  c'est qu'un événement déclencheur aboutit à un résultat effectif, correspondant aux exigences de l'événement déclencheur.

Règle : L’exécution  de  toutes  les  tâches  doit  être vérifiable et vérifiée de la première à la dernière.
Le  résultat  du  compte  rendu  d’une  tâche  élémentaire,  s’il n’est  pas  « OK »,  provoque  la  remontée  d’un  avis  de problème vers un acteur responsable bien identifié.

Règle : Un processus doit être supervisé. 
Pour  détecter  tout  écart  par  rapport  au fonctionnement nominal, les différentes performances (qui font sens par rapport aux enjeux directs et indirects du processus et aux différents acteurs ) sont mesurées. Un historique des déroulements du processus est constitué et archivé. Les différentes mesures, par niveaux de consolidation, sont diffusées aux différents acteurs.

Règle : Un processus doit être piloté. 
Lorsque son fonctionnement s'écarte du nominal, un processus doit être piloté par un acteur pour le ramener dans le fonctionnement nominal, ce pilotage à chaud agissant directement sur les instances de processus en cours d'exécution. C'est par rapport à ce pilotage que l'entreprise ou l'agence publique détermine sa "frontière juridique de responsabilité propre".

Urbanistes et architectes

Dans le système informatique, l’urbanisme précède l’architecture comme dans une ville où les urbanistes travaillent avant les architectes afin de tracer les route, décident des canalisations (les flux dans le Système), des natures d’approvisionnement (eau, électricité, fibre optique, ADSL,…) et aussi des infrastructures communes (les hôpitaux, les stades, la mairie,…). Ces infrastructures communes correspondent dans le Système aux référentiels et aux modules communs fournissant des services.

Les architectes eux travaillent en général à la construction des bâtiments (les applications) qui se raccordent au système d’approvisionnement et aux services communs définis par les urbanistes.

Alors que l'architecture tend à autonomiser les éléments avant de les articuler dans un système, l'urbaniste considère l'impact d'un élément dans les chaînes d'interdépendances de ce Système. L'urbaniste recherche d'atteinte d'une série de qualités d'usages :

• L'exhaustivité et la fiabilité des informations
• La disponibilité et l'ergonomie des outils
• La gestion des accès au système et la sécurité par rapport aux attaques
• Les meilleurs coûts et délais pour satisfaire un nouveau besoin

Etape n°2 : à partir des qualités d'usage souhaitées, des exigences d'évolutivité et d'économie, les urbanistes produisent des règles d'architecture pour la conception des futurs éléments et l’assemblage des "édifices" et des réseaux de transport. Ces règles aboutissent, à l'occasion d'un besoin exprimé par une catégorie d’utilisateur, à la mise au point d'une architecture fonctionnelle qui apporte :

• la fourniture de services satisfaisant le besoin
• une simplification de l'existant
• une amélioration de la flexibilité par le découplage entre la vue logique (stable) et la vue opérationnelle (évolutive)

tout en respectant le pragmatisme de la démarche de projet et de mise en exploitation (clarté du besoin et de son périmètre, maîtrise des coûts, tenue des délais, qualité de l'œuvre, économie de l'ouvrage final).

Les réponses des urbanistes

Voici quatre grandes règles de conception que les urbanistes proposent aux architectes :

• Chaque élément doit pouvoir profiter de la disponibilité de services communs. Les services communs sont conçus de façon à anticiper une série d'évolutions sectorielles.

• Chaque élément spécialisé doit pouvoir offrir des services (services privés ou publics, génériques ou spécifiques) à n'importe quelle partie du système.

• La qualité des données (assurée par les référentiels) et leur mise en format commun (format pivot) ou leur structuration en Objet, permet leur disponibilité dans chaque partie du système

• Les éléments sont regroupés et normalisés de façon à favoriser les évolutions, leur réutilisation et éviter les redondances.

Voici le schéma cible indiquant les composants techniques dont la disponibilité annoncée fait rêver les urbanistes.

 

Etape n°3 : sur la base de ce cadre général,  l'urbaniste produit des règles d'urbanisme orientant les évolutions du Système d'Information (l'urbaniste conseille l'architecte mais ne construit rien par lui-même) :

• règles d'échanges entre les composants de l'architecture du Système interne et avec les Systèmes externes (fournisseurs, partenaires, clients) via des réseaux privés ou public (liaisons privés, Internet)
• règles de construction des processus et de distrisbiution des droits d'accès dans les processus
• règles de gestion des messages entre processus
• règles de construction, de stockage et de cycle de vie des données et des documents
• règles d'utilisation des données et des documents dans les processus
• règles de construction des architectures en lien avec les processus et l'existant informatique : interface utilisateur, applications, structuation des données, accès aux données
• règles de construction de l'architectures des services, du système d'échanges de message et des annuaires associés
• règles de gestion de la sécurité contre les attaques et des groupes de gestion de droits d'accès

L'urbaniste coopère avec les architectes informatiques pour :

• Formaliser les processus et les qualités d'usage demandées au Système, qui sont à considérer comme le Cahier des Charges de l'architecture technique.
• Fournir des critères de regroupement ou d'éclatement des applications.
• Mettre ces applications dans un statut de service, via un ou plusieurs annuaires
• Superviser les choix de standards et protocoles réseaux, de produits d'infrastructure et de production de logiciels de manière à ce que ceux-ci satisfassent aux règles d'urbanisme.
• En particulier, l'urbaniste veille à ce que la structure des processus et les caractéristiques techniques permettent aux utilisateurs et aux concepteurs de disposer naturellement et constamment des degrés de liberté nécessaires aux évolutions à venir du système.

et surtout :

Etape n°4 : structurer les données (dans un Référentiel des données, ou en les structurant dans des Objets) en les rendant indépendantes des procédures de traitement localisées dans les processus. Une donnée doit pouvoir être utilisée avec la même sémantique dans toutes les applications du Système d'Information.

Voici, par exemple, une architecture urbanisée qu'il est possible aujourd'hui de mettre en place, étant donné l'Etat de l'art technique :

Les qualités de cette architecture d'ensemble peuvent être décrites comme..

Un Système ouvert, dont les évolutions sont maîtrisées, plus rapides et moins onéreuses

• Adoptant un modèle architectural ouvert basé sur les protocoles standards des technologies Internet, ce qui facilite son ouverture à de nouveaux réseaux de fourniture et de distribution de services.
• Accessible par tous les médias (internet, mobile, réseau local) et par tous les acteurs (clients, distributeurs, fournisseurs, collaborateurs….), ce qui multiplie les accès aux données, tout en assurant leur sécurité et leur fiabilité.
• Orienté Utilisateur, offrant une vision multi-usages : Documents spécifiques à chaque processus et à chaque valeur ajoutée.
• Dont le coût de fonctionnement propre est minimisé un découplage des applications via un Bus de gestion de messages, par des services communs et des données normalisées valables en tout point du système.
• Développant une architecture de services (gestion d’un Annuaire centralisé des services communs, Annuaires des droits d'accès), ce qui permet une introduction plus rapide des nouveaux services.

Le 16 septembre 2008