1

Comité de coordination du contrôle de gestion

Maîtrise des coûts informatiques

Gouvernance et analyse des coûts en lien avec la performance des programmes

18 septembre 2007

2

Eléments de contexte

Un cadre interministériel pour soutenir l’utilisation des technologies de l’information et de la communication au service de la performance des politiques publiques : le schéma directeur administration électronique

Une opportunité historique pour actualiser les contenus et la gouvernance des systèmes d’information de l’Etat :

— Synchronisation avec la Révision Générale des Politiques Publiques

— Actualisation de la circulaire de 1996 relative aux schémas directeurs ministériels des systèmes d’information et des télécommunications (circ. 16/09/1996 – NOR : PRMX9601677C)

3

Un enjeu : la performance des programmes

3 leviers :— Organisationnel : disposer de processus internes permettant de maintenir le

système d’information « aligné » sur la stratégie— Financier : maîtriser les coûts informatiques et mesurer leur contribution à la

réalisation des politiques publiques— Décisionnel : outiller la prise de décision en analysant la valeur des projets

informatiques

Une approche : utiliser des référentiels éprouvés sur chacun des leviers

Des acteurs : responsables de programmes/maîtrises d’ouvrage, contrôleurs de gestion, responsables des systèmes d’information

4

Référentiels de place pour la gouvernance des SI et l’analyse des coûts informatiques

5

Référentiels informatiques

Définition: Ensemble de règles: « exigences » ou « recommandations » Qui s’appliquent à une personne, à une activité ou à une structure. Seul le respect des « exigences » est vérifié lors de l’audit qui conditionne la certification.

Propriété:Organisme de normalisation ou association

Catégories:Gouvernance des SI, sécurité des SI (ex: COBIT), gestion des Si (ex: COBIT), gestion de projet (ex: AFITEP, Hermes - utilisé depuis 30 ans par l’administration suisse et repris au Luxembourg, Prince 2 au Royaume-Uni), maturité des processus SI (ex: CMMI, COBIT)La plupart des référentiels couvrent une partie seulement des activités de la DSI (ex: ITIL, développé dans l’administration britannique, ne couvre que l’exploitation).

Du bon usage des référentielsMême si l’on n’a pas la certification comme objectif, les référentiels peuvent constituer une bonne source d’inspiration pour organiser la fonction SI, décomposer les processus et les coûts, déterminer les étapes nécessitant une formalisation écrite (« livrables») et proposer un format standard pour ces documents…

(voir site qualité informatique DGI sur Eole pour exemples de « livrables »)

6

Référentiels informatiques (suite)des référentiels de

contrôle

aux bonnes pratiques de mise en oeuvre

au business

Cobit Framework Val IT Framework

Prince 2

ITIL CMMI

IT Scorecard

AFAI

Val IT Business Case

Modèle

IGSI Coût IT

Rentabilité projet SI

AFAI

MOA projets SI

AFAI

Source: AFAI

7

Le référentiel COBIT* •Control Objectives for Information and Related Technologies (Gouvernance, contrôle, et audit de l’information et des technologies associées)

OrigineCOBIT a été crée en 1996 par l’ISACA (Information Systems Audit and Control Association) et a été repris par l’IT Governance Institute. Sa version 4 date de fin 2005. Il doit une grande partie de son succès à la loi Sarbane Oxley

Contenu: gouvernance, gestion et sécurité des SICOBIT regroupe 34 processus SI organisés en quatre domaines :1.Planification et organisation (10 processus)2.Acquisition et mise en place (7 processus)3.Distribution et soutien (13 processus)4.Surveillance (4 processus)Pour chacun, le référentiel propose une série de contrôles à effectuer dans une perspective de certification mais aussi un guide de gestion, des outils d’évaluation, des indicateurs clés de succès et de performance

Points fortsRecommandé par l’AFAI (Association Française des Auditeurs Informatiques. La plupart des cabinets d’audit se sont adossés à ce référentiel pour attester de la qualité des données comptables issues des systèmes d’information des entreprisesSeul référentiel à offrir une vision globale des SI en intégrant les autres (ex: ITIL sur exploitation) Surtout, sa version 4permet de faire le lien entre les objectifs opérationnels de l’entreprise et les systèmes informatiques, et de vérifier ainsi leur alignement stratégiqueBon niveau de « maille »

8

Référentiel IGSI de benchmarking des coûts SI

Présentation de l’IGSI:L’Institut de la Gouvernance des Systèmes d’Information a été crée conjointement par l’AFAI (Association Française des Auditeurs Informatiques) et le CIGREF (Club Informatique des Grandes Entreprises Francaises), dont font partie la Poste, Areva…

Référentiel de benchmarking des coûts informatiquesCe modèle publié en 2006 est accessible gratuitement sur internet propose une analyse des coûts informatiques par destination, ainsi que des ratios d’analyse.

Ses briques de base sont les suivantes:Mise à disposition des PC; Mise à disposition des imprimantes; Mise à disposition des autres périphériques; Mise à disposition des applications; Maintenance évolutive; Projets

Ce référentiel permet ensuite de comparer les ratios d’une direction/ d’un ministère à l’autre.

En élaborant les budgets, puis le réalisé selon cette grille, on analysera mieux les sources d’écart. Elle peut servir de point de départ à la mise en place d’un système de suivi des temps.

Ce référentiel est compatible avec COBIT

9

L’analyse multi-critères de la valeur des projets

10

L’analyse multi-critères de la valeur des projets

La « valeur » renvoie à deux types de définition :

Une approche financière :

— La valeur économique d’un bien correspond à son prix. Cette valeur économique est une notion complexe qui intègre :

• Des calculs financiers de valorisation, tenant compte des flux financiers, des moyens financiers immobilisés et du temps

• La valeur potentielle du bien pour l’investisseur qui le finance

Une approche qualitative :

— La valeur accordée à un bien dépend également de l’appréciation de ses éléments qualitatifs qui peut différer selon les points de vue

11

L’analyse de la valeur s’inscrit dans un dispositif de pilotage de la performance des programmes auxquels les SI contribuent

Activité

Hommes

Ressources financières

Projets d’amélioration

Pilotage

Cycles de gestion (budget, tableaux de bord, revues mensuelles…)

- Management par les objectifs- Processus d’évaluation et de gestion des carrières

Optimisation de l’utilisation des ressources

-MAREVA-Méthodologie de gestion de projet

12

Bénéfices constatés

•Identification amont des points durs du projet réalisation d’arbitrages

•Support d’échange et de dialogue avec les décideurs (MOA métier, DSI…) et la MOE à chaque étape du projet sur la base d’éléments factuels

•Mise en valeur de la rentabilité et des bénéfices qualitatifs du projet

Pour les Chefs de projet(s) Pour les Décideurs (DSI, R Prog)

•Méthode commune d’évaluation des projets arbitrages

•Engagement de la Direction projet sur des résultats

•Engagement de la MOA métier sur des objectifs de gain

•Suivi de l’évolution de la valeur du projet au fil du temps

•Identification des éléments qualitatifs du projet

Interpré-tations

13

A quelle phase du projet conduire l’analyse de la valeur ?

Proposition / Définition du

projet

Évaluationex-ante

Suivi et évaluation continue

pendant la réalisation

Évaluation ex-post

Lancement du projet

Arbitrage / recalage

Bilan du projet

Retour d’expérienceSélection de

projets

Etude allégée au stade du lancement de l’étude préalable

Etude complète avant le lancement de la réalisation

Mises à jour en fonction de l’évolution du reste à faire

14

Les 5 axes proposés par MAREVA

1. Rentabilité du projet pour l’Etat

2. L’absence de risque majeur (inverse du niveau de risque)

3. Les bénéfices pour l’usager (« externalités »)

4. Les bénéfices pour les agents (« internalités »)

5. Le degré de nécessité du projet eu égard à des contraintes réglementaires, à des engagements politiques, à d’autres projets

15

Axe 1: Rentabilité pour l’Etat

Indicateurs: •ROI•VAN•délai de retour sur investissement•TRI•Investissements évités

Hypothèses à formaliser:

Volet coûts: prévisions annuelles en CP, sur toute la durée du projet depuis sa date de démarrage•des coûts externes •mais aussi des coûts internes (temps passé par la MOE mais aussi la MOA), valorisés par grade

Volet gains: Gains de productivité (ex: ETP) à chiffrer par la MOA

Facteurs clés de succès pour un pilotage efficace de cet axe:

•Budgéter les temps internes sur le projet par grade et par activité•Mettre en place un système de suivi des temps MOE et MOA, internes et consultants, permettant de mettre à jour régulièrement le reste à faire (RAF # Budget CP – CP Consommés)•En cas d’écart significatif entre budget et réel, procéder à une analyse par points de fonction•Suivre en réel les gains obtenus

16

La lecture du calcul du retour sur investissement se traduit par l’interprétation de 3 indicateurs

-40

-20

0

20

40

60

80

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

Gain/coût annuel (non actualisé) en M€

-100

-50

0

50

100

150

200

250Flux actualisés cumulés en M€

Gains (échelle de gauche)

Coûts (échelle de gauche)

Flux cumulés

Flux annuels

Valeur cumulée actualisée

Délai de Retour

Le Délai de Retour indique à partir de quel moment les gains

réalisés ont permis de rembourser » les coûts du projet

Le Taux de rendement interne peut être

interprété comme le taux de rendement de

l'investissement initial

Gain Récurrent

Le Gain Récurrent est l'économie maximale annuelle

dégagée par la nouvelle application ou infrastructure Valeur

ActuelleNette

Le ROI se mesure comme une Valeur Actualisée des gains

quantifiés dans le temps, Nette des coûts du projet

17

Axe 2: Inverse du degré de risque

4 types de risques sont évalués :

— Les risques concernant le déroulement du projet : • Il s’agit des risques inhérents à la gestion de projet (objectifs et périmètre du

projet, équipe projet, contraintes de planning et de financement…)

— Les risques techniques• Ils se mesurent à l’aune du degré de complexité fonctionnelle ou technique du

projet, de son degré d’innovation, de la confidentialité des données

— Les risques juridiques• Ils dépendent de la nécessité de suivre des changements réglementaires, du

recours éventuel à des montages juridiques complexes…

— Les risques de déploiement• Ils concernent les modalités de conduite du changement (nombre d’agents

impactés..), du portage du projet, de la perception interne et externe du projet…

DEFINITIONLes risques sont inhérents à la conduite d’un projet. Ils résultent de la probabilité de la survenue d'un événement perturbateur spécifié et de ses conséquences. Ils sont à évaluer en regard des gains attendus et des moyens mis en œuvre pour les maîtriser

MAREVA évalue l’absence de risques à travers des questions clés

Maîtrise du risque

18

Les éléments permettant d’évaluer les externalités du projet :

— Le nombre d’usagers touchés

— L’existence de gains de temps ou d’argent pour les usagers (bénéfices quantifiables)

— L’amélioration de la qualité de service

— L’impact citoyen (environnement, cohésion sociale…)

— Eventuellement d’autres externalités spécifiques au ministère

Axe 3: Externalités

DEFINITIONLe terme d’externalité désigne les bénéfices quantitatifs ou qualitatifs du projet pour l’usager

Externalités

19

Les éléments permettant d’évaluer les internalités :

— La pertinence du projet eu égard aux objectifs stratégiques des politiques publiques, au Schéma Directeur SI, au fonctionnement des services déconcentrés

— La valorisation et la motivation des agents

— L’efficience du service public

— Au-delà des bénéfices ci-dessus, mesurées pour l’Etat, la rentabilité additionnelle éventuelle pour la sphère publique hors Etat (ex: collectivités territoriales), mesurée selon les mêmes critères que pour l’Axe 1

Axe 4: Internalités

DEFINITIONLe terme d’internalité désigne les bénéfices quantitatifs ou qualitatifs du projet pour les agents et pour les services publics

Internalités

20

Les éléments permettant d’ évaluer la nécessité du projet :

— Nécessité pour d’autres projets (ex : mise en place d'une infrastructure transverse)

— Obligation externe (obligation réglementaire, engagement politique…)

— Efficience de l’action publique (rationalisation d’une situation existante complexe…)

Axe 5: Nécessité du projet

DEFINITIONLe terme de nécessité répond à une obligation réglementaire ou politique, aux besoins des autres projets corrélés mais peut également prévenir un risque à ne pas faire

Nécessité du projet

21

Interprétation et utilisations des analyses MAREVA

22

La restitution globale de l’analyse MAREVA se lit sous la forme d’un radar à 5 dimensions

D

C

B

A

ILLUSTRATION

INTERNALITES

BB

NECESSITE DU PROJET

BB

MAÎTRISE DU RISQUE

EXTERNALITES

AA

BB

CC

RENTABILITE – SPHERE ETATIQUE

23

Quelques principes sur l’interprétation des résultats de MAREVA

La diversité des critères ne permet pas de consolider les 5 sous-résultats pour donner une note globale au projet. L’évaluation globale de la Valeur du projet peut se lire comme l’aire du radar (sur la base des 5 composants)

Un projet ne peut pas être noté « A » sur chacun de ses 5 axes :

— Un projet présentant une excellente rentabilité est souvent risqué

— Un projet d’infrastructure nécessaire pour d’autres projets présente souvent une rentabilité négative…

La forme du radar MAREVA dépend du type de projet :

— Un projet interne à l’Administration présentera des internalités fortes et peu d’externalités

— Un projet d’infrastructure présentera une nécessité forte et une bonne maîtrise du risque, en revanche, la rentabilité sera souvent négative

— Un projet de télé-procédure présentera des externalités fortes et souvent une forte rentabilité