COPIL PESI Comité de Pilotage du PESI Difficultés et propositions

Présentation au sujet: "COPIL PESI Comité de Pilotage du PESI Difficultés et propositions"— Transcription de la présentation:

1 COPIL PESI Comité de Pilotage du PESI Difficultés et propositions
Ministère de l’Economie et des Finances République du Bénin COPIL Portail WEB : (espace privé : login PESI, mot de passe BENIN) COPIL PESI Comité de Pilotage du PESI Difficultés et propositions DOIP / AT PESI Cotonou, 12 août 2014

2 Introduction L’étude PESI a diagnostiqué de nombreuses défaillances dans le « système » informatique du MEF avant 2011. Les principales défaillances étaient (1) que les activités informatiques étaient réalisées au gré des crédits accordés, (2) de ne pas disposer d’un portefeuille partagé des projets informatiques, (3) de ne pas avoir d’organes de pilotage informatique, Depuis la mise en œuvre du PESI en 2012, et la création des CMOSPI et COPIL, il y a eu d’importants progrès. Nous dressons ici une liste de difficultés persistantes en 2014, et proposons des solutions pour y remédier. L’objectif ici n’est pas de dresser la liste des améliorations mesurées depuis 2 ans.

3 Difficultés rencontrées
Causes (1) Aucune sanction prévue lorsqu’il n’est pas fait, (2) aucun bénéfice prévu pour cet « effort », (3) CdP ne perçoit pas l’intérêt de planifier des activités alors que leur réalisation ne dépend que partiellement d’eux Constat n°1 Les chefs de projet ne mettent pas à jour le plan d’action de leur projet (Ceci a pourtant formellement été demandé par le COPIL, le CMOSPI, le DOIP à plusieurs reprises au chefs de projets depuis près d’un an) Conséquences Un projet sans plan d’action / planning n’est pas un projet. Pas de suivi rigoureux possible des activités Pas de maitrise des délais, des résultats et des budgets Pas d’évaluation objective possible des résultats Pas de raisons objectives pour un chef de projet de « tout faire » pour réussir son projet Augmentation du risque d’échec du projet

4 Difficultés rencontrées
Causes (1) Ils n’y sont pas contraints; (2) ne participer qu’à un seul projet n’est financièrement pas intéressant ; (3) Le CdP n’est pas formé à la gestion de projet ; (4) Le CdP n’a pas d’équipe dédiée Constat n°2 La majorité des chefs de projet consacre moins de 50% de leur temps à la conduite de leur projet Conséquences Un projet pour lequel le chef de projet ne prend pas au quotidien des décisions, ne suit pas le planning, le budget, l’avancement des activités réalisées par son équipe, n’anticipe pas les risques, ne gère pas le changement, ne communique pas, etc. échouera

5 Difficultés rencontrées
Causes Le texte de création du COPIL ne prévoit pas de telles mesures Constat n°3 Aucune mesure incitative ou coercitive n’est prévue pour que le COPIL exerce son autorité sur les projets informatiques Conséquences Les chefs de projets ne perçoivent pas l’importance ou l’intérêt de rendre des comptes au CMOSPI ou COPIL. Ils rendent plus naturellement compte à leur Direction, celle qui leur octroie des budgets Les recommandations du COPIL ou CMOSPI sont peu suivies d’effets Le MEF ne « gouverne » pas son SI Le SI évolue aléatoirement au gré de la seule volonté des informaticiens Rien ne garantit que le SI correspond aux besoins « métiers » de l’administration Le MEF ne peut pas savoir si le budget alloué à l’informatique est utilisé de façon optimum

6 Difficultés rencontrées
Causes Les services informatiques des Directions sont hiérarchiquement et financièrement indépendants de la DOIP Constat n°4 Aucune mesure incitative ou coercitive n’est prévue pour que la DOIP exerce son autorité sur les activités informatiques Conséquences L’informatique du MEF évolue librement au sein de chaque Direction Rien de garantit la cohérence globale de l’informatique du MEF et son interopérabilité (technologique, méthodologique, procédurale) Risque de doublons de projet

7 Difficultés rencontrées
Cause Il n’existe pas de textes pour formaliser des projets, autonomes, dotés d’un budget propre (à part pour les PIP, mais non adaptés pour les projets plus petits). Il n’existe que des lignes de crédit qui financent indifféremment les activités « classiques » et des « projets ». Constat n°5 Les projets sont principalement perçus par la majorités des agents comme des lignes de crédits. Conséquences Difficile de démarrer un projet non crédité Difficile de terminer un projet crédité ! On profite du crédit affecté à un projet pour financer d’autres activités d’autres « projets » Un projet se résume trop souvent à ses acquisitions et primes versées plutôt qu’à la qualité des résultats obtenus On est très éloigné de la gestion de projet.

8 Synthèse des difficultés constatées
Les projets informatiques ne sont pas pilotés en « mode projet », c.à.d de façon exceptionnelle et temporaire dans un but bien déterminé et précis, Ils sont pilotés en « mode hiérarchique » comme des activités courantes de l’administration, gérées avec toutes ses contraintes (pas d’échéance, responsabilité diluée, budget aléatoire, pas de démarche systématique, etc.). Ce mode de pilotage augmente considérablement le risque d’échec du projet tel que généralement défini : Tous les résultats fixés au départ ne sont pas atteints Les délais sont dépassés de plus de 30% Le budget initial est dépassé de plus de 30% Il n’y a pas de gouvernance du SI (SI = logiciels + procédures + organisation) Le pilotage global de l’informatique insuffisant

9 Propositions

10 Gestion du budget informatique
Pour renforcer le rôle du COPIL , la gouvernance des SI et le pilotage de l’informatique Gestion du budget informatique

11 Gestion du budget informatique
Le budget informatique global du MEF reste constant, mais est réparti différemment : Budget informatique PIP + Budget DOIP Budget informatique UGR Budget informatique DG = BUDGET TOTAL (constant) Fonctionnement informatique des DG + Fonctionnement global et transversal Equipements informatiques Formation Projets = BUDGET TOTAL (constant)

12 Gestion du budget informatique (suite)
Les budgets informatiques des DG se limitent à financer le fonctionnement informatique courant des DG (petits achats, petites prestations) – 10% du budget global informatique Le fonctionnement informatique global (réseau, data center, petits achats, petites prestations, généralisation PSSI, ITIL, EDI, GED, EAI, intranet, gestion parc, etc.) du MEF est géré par la DOIP – 20% du budget global informatique

13 Gestion du budget informatique (suite)
Le budget informatique des équipements hors projets est exécuté par la DGML (ou UGR ?), ordonnancé par la DOIP. Cet investissement concerne principalement l’acquisition des ordinateurs et autres équipements informatiques, et est géré de façon centralisée (de type « centrale d’achat »). L’objectif est de dégager des économies en faisant des économies d’échelle, et de garantir la cohérence des équipements (selon normes techniques définies par la DOIP) – 10% du budget global informatique Le budget informatique des formations hors projets est exécuté par l’UGR, ordonnancé par la DOIP. Un plan de formation global pour tous les informaticiens du MEF doit être programmé en fin d’année, justifié, approuvé par la DOIP. L’objectif est de garantir la cohérence entre les formations reçues et les méthodes et technologies en vigueur au niveau du MEF – 10% du budget global informatique

14 Gestion du budget informatique (suite)
Le budget des projets informatiques est préparé et piloté par le COPIL, dépenses ordonnancées par les CdP et exécutées par l’UGR (50% du budget global informatique). Il existe 2 sortes de projets : les projets courants, à lancer au fur et à mesure des besoins, et les projets stratégiques. Les projets stratégiques sont identifiés tous les 5 ans lors des schémas directeurs informatiques ou lors des PESI. Processus de préparation du budget informatique annuel des projets: Les CdP défendent leurs propositions de nouveaux projets courants devant le CMOSPI. Pour les projets stratégiques ils définissent les activités qui vont être réalisées dans l’année à venir. Le CMOSPI fait ses observations sur le plan d’action, le budget, la pertinence du projet, et rend un avis consultatif pour le COPIL. Il définit le budget annuel nécessaire pour les projets retenus a priori (projets courants + projets stratégiques). Le COPIL décide des projets et activités éligibles qui lui sont présentés par le CMOSPI et envoie à l’UGR les besoins de financements informatiques pour l’année suivante, le « PTA informatique » (le budget informatique de l’UGR doit uniquement être établi en fonction du PTA informatique du COPIL afin de garantir la cohérence et le poids du COPIL dans la gouvernance du SI). Après arbitrage sur le PTA, l’UGR exécute les dépenses du projet selon le PTA informatique Le chef de projet rend compte des résultats au COPIL, sur la base de ce qui était prévu dans le plan d’action du projet et du PTA. Le COPIL approuve la poursuite du projet, réoriente les activités, ou suspend le projet. Le compte rendu de l’avancement des activités informatiques est communiqué par le COPIL à l’UGR.

15 Processus ajout projet « courant » au portefeuille
Mois CdP CMOSPI COPIL UGR JANV FEV MARS AVRIL MAI Défend son nouveau projet au CMOSPI Formule ses observations sur nouveaux projets JUIN JUIL AOUT Défend son nouveau projet amendé au CMOSPI Valide la liste des nouveaux projets SEPT Envoie la liste des nouveaux projet documentés au COPIL OCT Arrête la liste des nouveaux projets Etablit le PTA année N+1 Etablit une première version du PTA global N+1 en tenant compte PTA informatique COPIL NOV Arbitre toutes les demandes de financement, établit le PTA définitif et le communique DEC Prépare le démarrage de son projet Publie le PTA informatique sur portail PESI Communique PTA informatique au CMOSPI et CdP ; signe les documents nécessaires au démarrage des nouveaux projets

16 Processus financement projets stratégiques
Mois CdP CMOSPI COPIL UGR JANV FEV MARS AVRIL MAI Présente l’avancement de son projet Formule ses observations sur nouveaux projets JUIN JUIL AOUT Présente l’avancement de son projet et établit les crédits nécessaires pour l’année suivante Valide les crédits demandés en fonction du plan d’action global SEPT Envoie la liste des crédits demandés par projet stratégique au COPIL OCT Etablit le PTA année N+1 pour les projets stratégiques Etablit une première version du PTA global N+1 en tenant compte PTA informatique COPIL NOV Arbitre toutes les demandes de financement, établit le PTA définitif et le communique DEC Prépare l’exécution du budget de l’année à venir Publie le PTA informatique sur portail PESI Communique PTA informatique au CMOSPI et CdP

17 Processus de suivi des projets
Mois CdP CMOSPI COPIL UGR JANV FEV Présente l’avancement de son projet au CMOSPI Fait des recommandations au CdP Publie le taux exécution PTA informatique MARS AVRIL MAI Actualise le point d’avancement des projets à présenter au COPIL Procède aux arbitrages nécessaires sur les projets, formule ses recommandations JUIN JUIL AOUT SEPT OCT NOV DEC

18 Prise en compte des avis utilisateurs (maitrise d’ouvrage)
Pour renforcer le rôle du COPIL , la gouvernance et le pilotage de l’informatique Prise en compte des avis utilisateurs (maitrise d’ouvrage)

19 Pour renforcer la gouvernance
Le COPIL (ou UGR ? Ou DOIP ?) a des correspondants métiers utilisateurs du système d’information, qui sont invités à faire remonter les avis des utilisateurs (c.à.d la Maitrise d’ouvrage) sur : Les dysfonctionnements ou insuffisances du SI actuel Les nouveaux besoins fonctionnels (nouveaux processus à informatiser, nouvelles données à traiter, nouveaux rapport ou statistiques à produire, etc.) La qualité des services informatiques en général (centre de support, prise en compte de leur demande, niveau de disponibilité des applications, du réseau, etc.), si possible selon indicateurs

20 Pour motiver les acteurs des projets
Gestion des primes

21 Pour motiver les acteurs des projets
Accorder une prime projet aux chefs de projet et aux acteurs actifs du projet (équipe projet de 3 et 10 agents max selon taille du projet) Primes projets exclusives et non cumulatives d’autres primes Primes projets nettement supérieures aux primes forfaitaires habituellement accordées Montant de la prime fixé au départ, lors de la formulation de projet, dépend de la durée, du niveau stratégique, de la complexité, du nombre de personnes dans l’équipe projet, du niveau d’implication prévisionnel de chacun. Les « règles du jeu » qui fixent les montants des primes doivent être rédigées, transparente et rigoureuses. Il est le socle sur lequel repose l’édifice projet.

22 Pour motiver les acteurs des projets (suite)
Primes versées par tranche, au fur et à mesure des livrables produits (selon le même principe que les prestataires de services). La validation des livrables revient au COPIL. Attention ! Les agents qui ne figurent pas dans le groupe projet et qui ne perçoivent donc pas de primes projets, doivent continuer à percevoir leurs primes habituelles. En effet, l’équipe projet n’évolue pas seule et de façon totalement autonome au sein du MEF, d’autres acteurs externes au projet interviennent indirectement sur le projet : direction; administrateurs base de données, réseau, data center ; personnes ressources métier, etc. Ces acteurs interviennent également une fois le projet terminé pour gérer la phase d’exploitation (post projet) jusqu’à la fin du produit développé dans le cadre du projet. Il faut donc prévoir un autre mécanisme de sanction / récompense pour ces acteurs externes non géré dans le projet.

23 Fin de la présentation