Service ingénierie du développement Marc Nectoux 01 44 50 26 16 Le point sur le projet «Pilotage à l Université Paris 5» Marc Nectoux et Philippe Lafage (DSI) - juillet 2004 Ce document fait le point sur les travaux engagés par notre équipe sur le thème du pilotage. Il se compose de deux parties : une partie assez générale : «Présentation des travaux et des recommandations» et une partie plus technique, jointe en Annexe : «Mise en place du système de pilotage à l Université Paris 5». Présentation des travaux et des recommandations 1. Nos entretiens au sein de l Université : - Tout au long des derniers mois, nous avons rencontré différents acteurs et services impliqués dans la démarche de pilotage (voir liste en Annexe). Les points principaux qui se dégagent de ces entretiens* sont les suivants : 1.1. Ces entretiens donnent lieu à une expression spontanée des dysfonctionnements, des évolutions nécessaires et des attentes de ces acteurs vis-à-vis des 3 grandes applications nationales : APOGEE, HARPEGE et JEFYCO. Nos interlocuteurs attendent une plus grande réactivité de la part des développeurs pour répondre à leurs demandes. Au cours de ces entretiens, nous avons pu établir une liste relativement précise des thèmes des améliorations demandées : Nécessité d une formalisation écrite des demandes précises de transformation et d amélioration des logiciels nationaux. Nécessité de préciser les mécanismes de remontées de ces demandes et d informer sur leur suivi. 1.2. La vision «pilotage» n est pas encore une préoccupation majeure des interlocuteurs des services qui sont pris dans la gestion quotidienne et les problèmes à régler dans le court terme, ce qui est bien entendu nécessaire. La distinction entre l approche fonctionnelle et l approche décisionnelle n est pas encore clairement établie et validée : Nécessité d un travail d explication et de pédagogie pour convaincre les acteurs de l utilité de la vision «pilotage» et des changements qu elle implique.
1.3. Nous avons constaté qu ils existent déjà différentes équipes qui travaillent dans l Université autour de la notion de pilotage : Cellule de contrôle de gestion et d aide au pilotage, Relations internationales, DSI, etc., sans que leurs actions soient fortement corrélées : Il y a sans doute un besoin, de notre point de vue, de fédérer ces efforts et de mettre en place une collaboration plus formelle, pour bien identifier qui fait quoi, avec quel degré de légitimité et quel calendrier. * Les comptes-rendus de ces entretiens sont tous disponibles sur l intranet de l Université (répertoire Gestion et pilotage). 2- Nos contacts avec l AMUE : Nous avons assisté à différents séminaires de l AMUE sur le pilotage, sans être un partenaire officiel de l AMUE sur ce thème. Nous en avons tiré les réflexions suivantes : 2.1. Il nous me semble que le soutien de l AMUE pourrait être moins technique qu organisationnel, dans le cadre d une participation à une «formation-action» : obligation de structurer une équipe de projet, de définir un mandat précis, de respecter un calendrier et d engager fortement l équipe de direction de l Université. 2.2. Des présentations des 5 Universités engagées dans la construction de tableaux de bord sur les «Relations Internationales», nous retenons que : - Ces équipes n ont pas utilisé le logiciel recommandé par l AMUE «DataStage», mais uniquement des extractions APOGEE, des tableaux Excel et du reporting avec BO. - Elles ont insisté sur l importance de la fiabilité des informations contenues dans les bases nationales et notamment dans APOGEE. - Les indicateurs sélectionnés ne sont pas révolutionnaires (flux des étudiants étrangers, mobilité des enseignants et chercheurs, etc.) mais solidement construits. Certaines équipes ont développé des bases spécifiques pour pouvoir calculer les indicateurs choisis (par exemple, sur les ordres de mission, les stages à l étranger, etc.). 2.3. La préoccupation de pilotage est somme toute assez récente. On en parle beaucoup, mais il y a encore peu de réalisations concrètes. Pour le moment notre Université n est pas en retard sur ce thème, mais nous devons en quelque sorte «passer à la vitesse supérieure» pour être toujours en phase avec les développements actuels. 2.4. Il y a nécessité d une collaboration avec des équipes en charge de ce même projet au sein des autres Universités, ce qu une collaboration spécifique avec l AMUE peut favoriser.
3. Notre approche du «pilotage» : 3.1. Ce que n est pas le pilotage : - Tout tableau statistique ne relève pas du pilotage. Il doit être synthétique et s inclure dans une démarche décisionnelle. - Il y a une distinction forte à faire entre les informations utiles à l approche fonctionnelle et celles utiles à l approche décisionnelle. 3.2. Ce qu est le pilotage : - Pilotage = Indicateurs synthétiques + Détermination de seuils de réaction + Actions correctives. - C est une approche multi-applicative, «transversale métiers», à destination unique des décideurs. - Nous fournissons en annexe une schématisation du processus de pilotage et de la dynamique du projet. 4. Développement de la «maquette de l hypercube décisionnel» : 4.1. Mme Grimaud a fait un travail important de débroussaillage des indicateurs les plus pertinents pouvant alimenter la démarche «pilotage» dans son document «Le répertoire des 54 indicateurs 01/06/2002». Nous avons repris en partie ce document et sélectionné au cours de nos réunions un certain nombre d indicateurs à construire en priorité pour notre maquette d hypercube décisionnel (MDH), première étape de l élaboration d une base de données décisionnelles. - Dans un premier temps, les descripteurs suivants ont été sélectionnés : APOGEE : - individu, sexe, âge - inscription administrative - version d étape - étape (cycle) - composante - groupe de bac - origine géographique des primo entrants HARPEGE : - individu, sexe, âge - enseignant/iatos titulaires en fonction à l Université - corps, catégorie - fonction (BAP?)
JEFYCO : - montant recettes par composante (ressources propres, dotations globales de fonctionnement, contrat quadriennal) - montant des dépenses par composante (fonctionnement, personnel, investissement) - Ces descripteurs devront permettre la construction des indicateurs suivants, selon la nomenclature du répertoire des 54 indicateurs : Les étudiants : - Répartition de l effectif étudiant par sexe, cycle et composante - Répartition de l effectif étudiant par origine géographique et composante - Répartition de l effectif étudiant par série du bac et composante Les enseignants : - Effectif enseignant par discipline et composante - Effectif enseignant par sexe, âge selon les corps - Nombre d enseignants par corps et UFR Les IATOS : - Nombre d agents dans chaque corps et chaque catégorie - Effectif IATOS par sexe - Nombre de IATOS par fonction de gestion - Rapport du nombre d agents ITRF sur le nombre d ASU - % des IATOS de catégorie A - Nombre d agents ayant plus de 55 ans et plus de 60 ans Les moyens : - Répartition des types de ressources (fonctionnement, ressources propres, contrat quadriennal) par composante - Taux de ressources propres - Répartition recettes/dépenses 4.2. La technologie de développement choisie et les développements effectués pour la construction de la maquette sont abordés en détails dans l annexe technique n 1 établi par Philippe Lafage. 4.3. Développements futurs : Il sera possible de construire d autres indicateurs en croisant les descripteurs du MHD, notamment des indicateurs «mixtes» c est-à-dire multi-applicatif, comme le taux d encadrement du personnel enseignant par composante, le taux d encadrement IATOS par composante, etc. Il s agit là d une première étape de la réalisation des tableaux de bord décisionnels. - Pour cela il sera nécessaire, entre autres, de construire des tables de correspondance des structures administratives de notre Université entre les trois applicatifs (en cours).
5. Conclusions et recommandations Outre les points évoqués plus haut, il nous semble que : 5.1. La qualité des données dans les bases nationales est essentielle, puisque nos indicateurs de pilotage sont et seront construits à partir de ces informations. Il y a sans doute un compromis à tenir entre «le réel» (les données jugées fiables de ces bases) et «le souhaitable» (les indicateurs nécessaires pour le pilotage) pour construire notre outil décisionnel : construire les indicateurs à partir des = déterminer les indicateurs nécessaires seuls éléments fiables des bases nationales et souhaitables pour le pilotage 5.2. Il serait utile de faire acte de candidature auprès de l AMUE pour la prochaine «formationaction» dans le cadre du pilotage (pour 2005?). 5.3. Indépendamment de cette candidature, il nous semblerait aussi utile, dès maintenant, de désigner une équipe de projet «pilotage» avec un comité de suivi, ayant un mandat défini, un portage politique et un calendrier. 5.4. Enfin, il nous semblerait utile de poursuivre le travail commencé dans ce cadre redéfini, notamment le développement de la maquette de l hypercube décisionnel. Soulignons encore que ce projet est un projet de long terme, qui demande une persévérance dans la démarche.
Le point sur le projet «Pilotage à l Université Paris 5» Annexes Annexe n 1 Mise en place du système de pilotage à l Université Paris 5 (document technique établi par Philippe Lafage) Annexe n 2 Liste des entretiens effectués et des comptes-rendus des réunions «Tableaux de bord» Annexe n 3 Schématisation du processus de pilotage Annexe n 4 La dynamique du projet
Annexe n 1 Mise en place du système de pilotage à l Université Paris 5 (document technique établi par Philippe Lafage) Les principales étapes nécessaires à la réalisation du futur système de pilotage que la DSI propose mettre en place sont rappelées dans cette partie. 1. Phase d analyse : 1.1. Définir le timing du Système d Information décisionnel - L une des premières décisions d importance consiste à définir, en concertation avec les parties concernées, les dates d arrêt des bases de donnés opérationnelles, en vue de leur utilisation pour le système de pilotage (ex : janvier pour les domaines Scolarité, Personnel, Financier) : - Problème des mises à jour incessantes de la part des agents opérationnels Exemples : arrêté rétroactif de nomination ou de progression de carrière, pb des résultats en scolarité qui prennent jusqu à 6 mois pour être mis à jour - Ceci s oppose en retour à la nécessité croissante d une information stable, fusse au détriment d une parfaite exactitude. En effet, aucun corps de métier ne pourra fournir une information parfaite à une date synchrone. - La caractéristique du pilotage est de dégager des tendances et des évolutions et non pas de définir des valeurs exactes à l unité près : Ex : nb d étudiants ayant réussis / nb d étudiants réellement inscrits à corréler à terme avec le nb de personnel IATOS et nb d enseignants ou le taux d engagement de crédits L expérience a montré que la mise à jour constante des données opérationnelles empêchait les responsables de construire des tableaux de bord qui utilisent les données de référence pendant plus de 2 mois, de bâtir des ratios fondés sur le même référentiel, ce qui les oblige bien souvent à recommencer leur calcul 1.2. Définir les principaux rendez-vous d utilisation des tableaux de bord (TBB) - Scolarité : - Enquête SISE en janvier - Livret Enquête étudiants - Personnel : - Enquête annuelle exercice civil - Bilan social - Futur système de gestion prévisionnelle des RH
- Finances : - Suivi budgétaire mensuel? - Consolidation annuelle exercice comptable 1.3. Définir une mécanique de pilotage - Construire avec les utilisateurs (les utilisateurs clés et politiques) des scénarii : Mettre au point une mécanique en 3 étapes : - Etape 1 : Indicateurs avec des chiffrages synthétiques ayant du sens Ex : des valeurs croissantes positives pour un phénomène devant être perçu de façon favorable. - Etape 2 : Définir si possible des seuils d alerte Ceci permet de mettre en place du «color coding» qui alerte rapidement le décideur. - Etape 3 : Anticiper en mettant au point avec les utilisateurs clés les scénarii de réaction ou d action en cas de franchissement des seuils, sans attendre que ces franchissements aient lieu Les opérationnels doivent suggérer des actions administratives d actions sans attendre que le système de pilotage soit réellement mis en place de façon à pouvoir mette au point futur système en quasitemps réel. Ces actions en cas de franchissement de seuil doivent être validées à froid par les autres parties prenantes avant la mise en exploitation et donc l application en urgence. 1.4. Identifier les éléments au sein du référentiel de données - Identifier les clés primaires, étrangères Nous devrions récupérer ces clés Clé étrangère à remplir dans les tables éviter null Confectionner parfois des valeurs de regroupement = classe Ex : classes d âge pour le personnel tous les 5 ans, plus annuel pour les personnels à partir de 55ans - S assurer de la bonne compréhension de la sémantique des bases métier - Vérifier la correspondance des informations partageables inter-bases applicatives Etablir des tables de correspondance entre les bases quand cela est possible. Ex : les composantes ne sont pas identifiées de la même manière dans les 2 bases de gestion. 1.5. Choix des technologies de stockage - Outils Microsoft/Datastage Préconisé par l AMUE mais en fait pas utilisé
- Cube en technologie MOLAP /ROLAP /Hybrid Tant que le besoin de réactivité ne l impose pas, préconisation du choix du stockage en Molap. Cette technologie privilégie le stockage de tous les agrégats internes (donc augmentation du volume occupé sur le serveur final) au profit d une plus grande rapidité d accès pour l utilisateur final. Inconvénient : plus long à mettre en route en cas de changement fréquent du référentiel des bases de données. 1.6. Choix des technologies de restitution (reporting) - Etudier les opportunités offertes par l arrivée des «Reporting services» - Maintien des licences Business Objects? : Formation plus poussée des principaux utilisateurs Extrêmement séduisant au départ mais peu de réappropriation par les utilisateurs :concept avantageux d objet métier mais peu transférable sur son Excel final. 2. Transfert des données : 2.1. Rapatriement des données de bases OLTP figées - Voir les éléments évoqués plus haut sur le moment approprié pour copier les bases de données opérationnelles dans un nouveau référentiel qui ne changera pas pendant une certaine période. 2.2. Ecritures des règles de DTS (transformation de données) - Voir les apprentissages des universités participantes du groupe pilotage de l AMUE. C est le principal apport qu l on devrait tirer des groupes de travail du projet pilotage de l AMUE que de partager les mêmes techniques d enrichissement et de regroupement des donnés. 2.3. Vérification de la cohérence du data-mart intermédiaire - Le «data-mart» est une base de donnée relationnelle éventuellement «dénormalisée» à partir de laquelle seront construits les bases de données multidimensionnelles. 2.4. Chargement des données grâce à l ETL (Extract, Treatement and Loading - Une fois le data mart stabilisé, le remplissage des cubes peut être envisagé. A terme ces travaux peuvent être déclenchés de nuit. La création des cubes ne peut être réalisée de façon instantanée. Plus le cube élabore d agrégation plus les utilisateurs en disposeront rapidement.
3. Construction des cubes : 3.1. Construction des cubes - Calcul de la volumétrie - Principe univocité par clé + concaténation du libellé court lisibilité pour l utilisateur final) Ceci permettra de nous assurer de l univocité des informations utilisées et de les rendre explicite pour l utilisateur final. 3.2. Réalisation de «membres calculés» - Avantage : Formules générales permettant d afficher des parts relatives du phénomène ou des variations Ex : % de filles par cycle, composantes, année universitaire Ex : variation du nb d étudiants inscrits dans telle composante - Intérêt : formule puissante marchant pour tous les niveaux hiérarchiques - Inconvénient : langage ensembliste puissant réservé à des spécialistes informaticiens 3.3. Localisation des serveurs 3.4. Définition des rôles des acteurs du système d information de pilotage - Définir les droits d accès, de vue, d agrégation, de pivotage Les bases multidimensionnelles permettent de limiter la vision de certaines informations selon les rôles des acteurs qui consultent le système de reporting de pilotage ; ainsi on peut, à terme, permettre à un responsable de cycle de consulter les statistiques qui relèvent de sa compétence, permettre à un directeur d UFR de voir des statistiques consolidées pour son UFR et au Président ou la Secrétaire générale d avoir connaissance de ces agrégats pour toutes les UFR. 4. Diffusion des indicateurs : 4.1. Diffusion des TBB sur client léger (web) - La tendance actuelle consiste à diffuser dans les organisations les tableaux de bord à travers l intranet en format XML lisible à partir d un simple navigateur d internet. - Inclusion dans le portail de Pars 5? 4.2. Diffusion dans le client riche (bureautique) - Tableaux croisés dynamiques d Excel Intérêt : laisse les utilisateurs concernés atteindre les informations directement du cube (qui lui-même est alimenté par les bases de données de production) sans
apprentissage d outils nouveaux. Cela permet à chacun de faire tous les calculs ou les graphiques souhaités. 4.3. Information et formation des utilisateurs clés (key users) - C est une étape à ne pas négliger : l objectif avec le cube est de préparer d avance le maximum de demandes d indicateurs potentiels. Un utilisateur ne devrait être concerné que par une partie de ceux-ci. Ceci devrait à terme permettre de réduire le nombre des demandes de requêtes spécifiques formulées à la dernière minute aux informaticiens responsables des bases de gestion. - Il faut en revanche permettre à l utilisateur de s y retrouver au départ. L expérience montre que lorsque le spécialiste de la fonction détecte un fait de synthèse anormal, il cherche à comprendre les raisons de ce phénomène en faisant appel à d autres axes d analyse. C est alors que la technologie des bases multidimensionnelles montre sa puissance. 5. Cycle post implémentation : 5.1. Analyse des erreurs des agrégations 5.2. Analyse de l insuffisance du reporting 5.3. Redémarrage du cycle d analyse pour amélioration 5.4. Extension avec un chantier de Data Mining - Eventuellement recherche d informations plus fines à l aide des technologies de Data Mining. 6. Préconisations techniques du groupe de travail pilotage de la DSI : 6.1. Programme des travaux : - Etapes réalisées : - Accès aux bases Oracle nationales - Arrêt des bases - Transfert en ODBC en SQL server - Reconstitution de clés - Compléter les valeurs nulles des clés étrangères des tables - Structurer des classes et des hiérarchies - 3 niveaux de candidats tables de faits - Entrer dans OLAP Analysis - Restituer dans Excel - Valider l approche
- Etapes en cours : - Construction du premier cube fondé sur APOGEE, orienté sur les statistiques Etudiants - Construction du premier cube fondé sur HARPEGE, orienté sur les statuts du personnel - Construction du premier cube fondé sur JEFYCO, orienté sur le taux d engagement budgétaire par composante - Validation du contenu des cubes - Développements futurs : - Cube virtuel intersection des 3 premiers cubes de base - Reporting services - Validation 6.2. Travaux spécifiques pour le développement de la maquette (fin juin 2004) : Utiliser un produit de Microsoft disponible à la DSI : SQL Server 2000 - Ce produit comporte à la fois un gestionnaire de base de données relationnelle, un ETL, un générateur de cube, un outil de Data Mining et un langage d extraction : le MDX (Multi Dimensional expression). Ce produit permet de fournir les tableaux de bord de façon à ce qu un utilisateur final puisse les lire. Etudier l opportunité de recourir au nouveau produit Microsoft Reporting services La maquette est réalisée à partir d un poste local Si l approche est validée, l ensemble sera transféré sur un serveur de puissance moyenne pour être accessible à des utilisateurs «béta testeurs» (Mono processeur ou mieux bi pro et 512 eg RAM ou mieux 1 giga) 6.3. Les prochains travaux (rentrée 2004) : Présenter la maquette aux principaux utilisateurs concernés Déployer les cubes (3 mois) Améliorer les temps de réponse pour qu en moins d un mois le nouveau cube du pilotage 2004 soit présenté en début février 2005.
Annexe n 2 Liste des entretiens effectués et des comptes-rendus des réunions «Tableaux de bord» - Réunion «Tableaux de bord» à la DSI 02/04/2003 - Réunion «Tableaux de bord» à la DSI 26/05/2003 - Réunion «Tableaux de bord» avec Mme Sarda 17/06/2003 - Réunion «Tableau de bord» avec Mme Grimaud - 28/05/2003 - Réunion «LMD et tableaux de bord» avec Mme Cartron 03/11/2003 - Réunion «Tableaux de bord» avec le P. Coslin 21/11/2003 - Réunion «Tableaux de bord» avec Mme Dagault 05/12/2003 - Réunion «Tableaux de bord étudiants» avec M. Cardinet 19/12/2003 - Séminaire formation pilotage de l AMUE 06/01/2004 - Réunion «Tableaux de bord» avec Mme Sarda 26/01/2004 - Réunion»Tableaux de bord» avec Mme Pardon et son équipe 10/02/2004 - Réunion «Tableaux de bord» à la DSI 16/02/2004 - Réunion «Tableaux de bord» avec M. Guatel et son équipe 30/04/2004 - Séminaire pilotage de l AMUE 10/06/2004
Annexe n 3 Schématisation du processus de pilotage DIRECTION Objectifs Résultats Le processus du pilotage Les indicateurs Base des données décisionnelles Informations externes Geisha Apogée Harpège Jefyco Papaye Autres bases Domaine Offre de formation Domaine GRH Domaine GFC Autres sources d information Annexe n 4 (page suivante) La dynamique du projet
Le réel des applicatifs et des pratiques - APOGEE Pratiques : EXCEL- - - - HARPEGE ACCESS - JEFYCO - GEISHA, etc. BO? Autres réflexions et pratiques : - AMUE - Autres Universités : Strasbourg, Lyon, Poitiers Projet Tableaux de bord existants : «Données de pilotage» - Scolarité - Bilan social - Personnel - Indicateurs - Financier - Coût de l étudiant,.. La matrice des besoins : Présidence Chefs de S CT LT ème 7 étage et demi Télécopie : 01 42 96 34 97