Eléments de contexte

1. Comité de coordination du contrôle de gestionMaîtrise des coûts informatiquesGouvernance et analyse des coûts en lien avec la performance des programmes18 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 PolitiquesPubliques • 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érentiels Mê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 au business Cobit Framework Val IT Framework Prince 2 IT Scorecard AFAI Val IT Business Case ITIL CMMI Modèle IGSI Coût IT Rentabilité projet SI AFAI MOA projets SI AFAI Source: AFAI aux bonnes pratiques de mise en oeuvre

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) • Origine • COBIT 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 SI • COBIT regroupe 34 processus SI organisésen 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 forts • Recommandé 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 entreprises • Seul 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égique • Bon 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 informatiques Ce 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 Cycles de gestion (budget, tableaux de bord, revues mensuelles…) - Management par les objectifs - Processus d’évaluation et de gestion des carrières Activité Hommes Pilotage Projets d’amélioration Ressources financières Optimisation de l’utilisation des ressources • MAREVA • Méthodologie de gestion de projet

12. Interpré-tations Bénéfices constatés Pour les Chefs de projet(s) Pour les Décideurs (DSI, R Prog) • 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 • 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

13. Proposition / Définition du projet Évaluation ex-ante Suivi et évaluation continue pendant la réalisation Évaluation ex-post Sélection de projets Lancement du projet Arbitrage / recalage Bilan du projet Retour d’expérience A quelle phase du projet conduire l’analyse de la valeur ? 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 • Rentabilité du projet pour l’Etat • L’absence de risque majeur (inverse du niveau de risque) • Les bénéfices pour l’usager (« externalités ») • Les bénéfices pour les agents (« internalités ») • 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. Le Gain Récurrent est l'économie maximale annuelle dégagée par la nouvelle application ou infrastructure Gain Récurrent ValeurActuelleNette Le ROI se mesure comme une Valeur Actualisée des gains quantifiés dans le temps, Nette des coûts du projet Flux annuels Délai de Retour Valeur cumulée actualisée Le Délai de Retour indique à partir de quel moment les gains réalisés ont permis de rembourser » les coûts du projet La lecture du calcul du retour sur investissement se traduit par l’interprétation de 3 indicateurs Le Taux de rendement interne peut être interprété comme le taux de rendement de l'investissement initial

17. DEFINITION Axe 2: Inverse du degré de risque Maîtrise du risque Les 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 • 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…

18. DEFINITION Externalités Axe 3: Externalités Le terme d’externalité désigne les bénéfices quantitatifs ou qualitatifs du projet pour l’usager • 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

19. DEFINITION Internalités Axe 4: Internalités Le terme d’internalité désigne les bénéfices quantitatifs ou qualitatifs du projet pour les agents et pour les services publics • 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

20. DEFINITION Axe 5: Nécessité du projet Nécessité du projet Le 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 • 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…)

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 RENTABILITE – SPHERE ETATIQUE B NECESSITE DU PROJET MAÎTRISE DU RISQUE ILLUSTRATION B C B A INTERNALITES EXTERNALITES

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é