OPUS. Note de cadrage

OPUS Avenant fonctionnel n 2 («OPUS V2») Note de cadrage Document du Ministère de la Culture et de la Communication 2 octobre 2006

2 LISTE DE DIFFUSION Rédacteurs Contributeurs Mathilde Toyon Sylvie Parisot Sophie Etienne Arthur Zappacosta Destinataires Jack Meurisse Anne Fendt Joseph Toscano STATUT DU DOCUMENT Version Date Remarques 1.0 15/09/2006 Création du document M. Toyon 1.1 25/09/2006 Modification du document M. Toyon + Revue du document A. Fendt 1.2 28/09/2006 Propositions de modifications de Sophie Etienne 1.3 02/10/2006 Modifications suite à réunion MOE/MOA du 29/09/2006 M. Toyon

3 SOMMAIRE 1 PREAMBULE... 4 1.1 MODALITES DE REALISATION DE CE DOCUMENT... 4 1.2 DOCUMENTS DE REFERENCE... 4 1.3 POINT D AVANCEMENT... 4 2 PERIMETRE FONCTIONNEL ET ORGANISATIONNEL... 5 2.1 METIERS ET ACTIVITES CONCERNEES... 5 2.2 ACTEURS ET SITES CONCERNES... 5 3 CADRAGE DES BESOINS... 6 4 CRITIQUE DE L EXISTANT AU REGARD DES BESOINS... 8 4.1 ANALYSE FONCTIONNELLE CRITIQUE... 8 4.2 ANALYSE TECHNIQUE CRITIQUE... 8 4.3 ANALYSE CRITIQUE DU NIVEAU ACTUEL DE SECURITE... 9 5 SCENARIO DE MISE EN OEUVRE... 10 6 PROPOSITION D ENGAGEMENT DE MOYENS... 11 7 DECISIONS PROPOSEES... 12

4 1 PREAMBULE 1.1 Modalités de réalisation de ce document Ce document a été formalisé par Melle Mathilde Toyon DAG/MCG chef de projet MOA OPUS, et Mme Sylvie Parisot DSI/BIA, avec la contribution de Mlle Sophie Etienne DAG/DAT et de M. Arthur Zappacosta DSI/BIA. Cette note a été revue par Mme Anne Fendt, Chef de la mission Contrôle de gestion, et M. Joseph Toscano DSI/BIA. 1.2 Documents de référence Cette note de cadrage fait suite à : la note de problématique sur OPUS V2, et l étude fonctionnelle et au cahier des charges de l application «OPUS volet OPUS DRAC», marché attribué en avril 2004 à la société KLEE GROUP. 1.3 Point d avancement La présente note de problématique fait suite à la commande présentée ci-dessus. Elle vise à : présenter le problème, ses symptômes, pourquoi il faut réagir et lancer un projet présenter une analyse des moyens à mettre en œuvre obtenir l autorisation et les moyens de cadrer le projet Un événement survient dans l environnent du MCC Cela créée une nouvelle situation non prévue par l organisation / le SI existant. On évalue alors ses impacts Si le problème est assez significatif pour nécessiter une résolution, on va exprimer les besoins à servir pour résoudre le problème Puis pour répondre aux besoins, on va étudier plusieurs scénarios possibles Pour le meilleur scénario, on va concevoir la solution Problématique Cadrage de la résolution du problème Contractualisation

5 2 PERIMETRE FONCTIONNEL ET ORGANISATIONNEL 2.1 Métiers et activités concernées Bloc fonctionnel impacté : Pilotage (collecte et nettoyage de données, production de tableaux de bord, gestion des requêtes). 2.2 Acteurs et sites concernés Pour la partie Collecte, les entités et acteurs du ministère concernés par ce projet sont : Comme acteurs de saisie : - Les DRAC - Les EP sous la tutelle du ministère - Les SCN sous la tutelle du ministère - Les structures subventionnées par le ministère Comme acteurs de l administration et du paramétrage de l outil : - Les Directions sectorielles d administration centrale - Eventuellement les DRAC Le volume d utilisateurs par service est fonction des choix d organisation des services : centralisation ou déconcentration des saisies. Les premiers mois d utilisation d OPUS en DRAC ont montré que les deux scénarios sont en effet viables. Le nombre d utilisateurs du module Collecte de OPUS ne présente pas de contrainte particulière, une fois le profil utilisateur créé, il s agit pour l utilisateur de se connecter à l application via internet et de saisir ses données dans les champs prévus à cet effet. Ces profils ne nécessitent pas de licence BO. Pour la partie Analyse, toutes les Directions du ministère sont concernées : Les DRAC La DAF La DMF La DDAI La DAPA La DMDTS La DAP La DLL La DGLFLF La DAG L application ayant été prévue dès le départ («OPUS V1») pour être utilisée également par les Directions centrales, la fonctionnalité Formulaires n implique pas de contraintes nouvelles en termes de nombre d utilisateurs. Il n est pas envisagé à ce stade de donner accès aux EP, SCN et autres structures subventionnées par le Ministère au module Analyse. La communication des informations est à organiser par les Directions sectorielles hors outil.

6 3 CADRAGE DES BESOINS L application OPUS, née du projet de tableau de bord des DRAC, a vocation à faciliter la collecte des données et la consultation des indicateurs suivis par le ministère, c est à dire les indicateurs des PAP, des BOP, de gestion interne, et d évaluation des actions et de suivi des politiques culturelles. La mise en place de cet outil, qui constitue l un des éléments du dispositif de mise en œuvre de la LOLF au ministère, a pour objectif de partager l information entre les différentes entités du ministère, de maîtriser les demandes d informations faites aux DRAC et aux structures subventionnées par le ministère, de structurer la production des données et de fiabiliser ces dernières, en en centralisant la collecte et les restitutions dans un outil simple d usage. Développée depuis avril 2004 avec le concours de la société KLEE GROUP, cette application est déployée auprès des services centraux et déconcentrés du ministère depuis avril 2005. Elle est structurée en deux modules distincts sur deux intranets, un module de collecte - Opus Collecte, et un module de production et de restitution des indicateurs et de tableaux de bord - Opus Analyse, qui doit permettre aux utilisateurs de consulter les rapports et tableaux de bord prédéfinis, mais aussi de bâtir eux-mêmes leurs propres indicateurs de pilotage. L application est paramétrée pour les indicateurs suivis en DRAC pour une soixantaine d indicateurs, dont tous les indicateurs des PAP et des BOP (domaine «DRAC»). Les indicateurs des PAP des directions centrales (domaine «LOLF» et un domaine par direction sectorielle) sont en cours de recette et devraient être opérationnels avant la fin 2006. L enrichissement du paramétrage des domaines sectoriels, utiles au pilotage des actions LOLF et des BOP, se fera progressivement, au fur et à mesure de l avancement du développement du dispositif de contrôle de gestion. La première période d utilisation de l application OPUS et les retours des utilisateurs ont démontré la nécessité de développer une fonctionnalité complémentaire de création et de saisie en ligne de questionnaires chiffrés multi-données, à destination des structures subventionnées par le ministère. Les besoins servis par cette fonctionnalité sont les suivants : Rationaliser le processus de collecte des informations par les Directions sectorielles auprès des services déconcentrés et des structures subventionnées par le ministère ; Permettre des gains de productivité grâce à la dématérialisation de questionnaires, qui pourront être traités plus rapidement dans les directions et dont les résultats pourront être mis à disposition plus rapidement ; Assurer la mise en cohérence globale des applications de reporting et de pilotage en évitant que chaque direction crée sa propre base de données sans partage ; Organiser plus finement la consolidation des données des entités du MCC dans la perspective de la production des indicateurs des PAP, puis des BOP et des contrats de performance des EP, grâce à de nouvelles procédures de contrôles associées. Cette demande s inscrit dans l objectif de généralisation de l usage d OPUS, comme outil dédié à l évaluation et au contrôle de gestion : l adaptation de l application aux besoins concrets des utilisateurs doit leur permettre une meilleure utilisation et appropriation de l outil. Ces développements répondent aux enjeux auxquels le ministère est confronté : d optimisation du processus de collecte de traitement des informations en automatisant, accélérant et fiabilisant le traitement des données, et en évitant les ressaisies manuelles liées aux questionnaires papier utilisés actuellement, ce qui doit permettre des gains de productivité ; de rationalisation des demandes d informations auprès des structures, afin qu elles ne soient pas sollicitées plusieurs fois par des directions différentes pour produire la même information ; de mise en cohérence et de partage de l information, les données étant consultables par toute personne agréée (selon les profils utilisateurs), et pouvant être consolidées et comparées entre structures. Il est important de pouvoir disposer rapidement d une version améliorée de l application, afin de (re)lancer son utilisation par les différents services du ministère pour la production des informations les intéressant.

7 Plusieurs directions sont directement intéressées par la fonctionnalité «Formulaires», dont la DDAI, la DAF, la DMF, la DLL, la DAPA, la DMDTS, et les Directions des EP : collecte en ligne des questionnaires multi-données pouvant correspondre à la partie chiffrée des rapports d activités, reporting des contrats de performance des EP, etc...

8 4 CRITIQUE DE L EXISTANT AU REGARD DES BESOINS 4.1 Analyse fonctionnelle critique Actuellement, l outil ne permet pas la saisie dans un même écran de plusieurs données sur des sujets différents. La fonctionnalité «Formulaires» permettra cette saisie, ainsi que l automatisation du traitement des informations remontées de différentes sources. Il apparaît également nécessaire de modifier certaines fonctionnalités existantes dont certaines indispensables au développement de la fonctionnalité «formulaires», d en créer quelques unes complémentaires, et d améliorer l ergonomie de l outil. Les besoins complémentaires sont donc les suivants : Nouvelle fonctionnalité «Formulaire OPUS» : Il s agit de donner aux utilisateurs la possibilité de créer des formulaires de saisie par paramétrage, afin de pouvoir collecter des informations de nature différente sur un thème donné, faisant l objet d un questionnaire. Actuellement, la saisie des données collectées n est possible que par indicateur. Chaque direction pourra ainsi procéder à la création de formulaires, à l aide de la mission contrôle de gestion ou d un prestataire externe. Améliorations de l ergonomie : Ces améliorations portent sur l ergonomie du module collecte, pour l ensemble des écrans de saisie, ou pour certains écrans spécifiques. Modifications de fonctionnalités existantes : L usage a montré que certaines fonctionnalités devaient être améliorées : - le suivi de l avancement de la collecte de données, - les droits du profil utilisateur «concepteur», - les dates des dernières saisies, - la répartition des données en thèmes et sous-thèmes, - la liste des contrôles, - la saisie des occurrences de dimensions, - et l exploitation des zones «Commentaires» remplies lors de la saisie de données. Ajouts de fonctionnalités : Les fonctionnalités suivantes doivent être ajoutées dans l application : - création et affichage d un dictionnaire des données, permettant notamment de savoir si une donnée est déjà créée dans le système, - mise en place d un tableau de suivi des modifications apportées aux valeurs des données (consultation des différentes valeurs prises par une donnée dans le temps), - création d un statut pour les dimensions («propre au domaine» ou «d ordre public»), pour éviter l alourdissement des listes de dimensions. 4.2 Analyse technique critique La version 1 de OPUS a été développée pour répondre aux contraintes techniques, notamment d une éventuelle ouverture à terme de l application aux établissements extérieurs sous tutelle (EP, SCN). Cette V2 n apporte pas de contraintes supplémentaires.

9 4.3 Analyse critique du niveau actuel de sécurité N/A

10 5 SCENARIO DE MISE EN OEUVRE Au regard des besoins identifiés, un scénario découpé en deux lots est proposé par l équipe projet : - Lot 1 : Développement et mise en œuvre des modifications de fonctionnalités, des nouvelles fonctionnalités, et des améliorations de l ergonomie - Cadrage des besoins et analyse fonctionnelle détaillée, - Réalisation/paramétrage des nouvelles fonctionnalités ou modifications des fonctionnalités existantes, - Recette (par le ministère), - Mise en production, - Assistance lors de la mise en œuvre. Ce lot peut être découpé en trois sous-lots concernant 1) les modifications de fonctionnalités existantes, 2) les améliorations ergonomiques, 3) les nouvelles fonctionnalités. - Lot 2 : Développement et mise en œuvre de la fonctionnalité «Formulaire OPUS» - Cadrage des besoins et analyse fonctionnelle détaillée, - Réalisation/paramétrage de la fonctionnalité, - Recette (par le ministère), - Mise en production de la fonctionnalité, - Assistance lors de la mise en œuvre. Il ne nous semble pas judicieux de séparer les deux lots, le développement du générateur de formulaires étant dépendant de certaines des évolutions demandées dans le lot 1.

11 6 PROPOSITION D ENGAGEMENT DE MOYENS L élaboration des spécifications et la réalisation technique des besoins identifiés nécessite le recours à un prestataire pour des développements d une durée prévisionnelle (tests compris) de 4 mois, à terminer pour le deuxième trimestre 2007. La charge de travail externe associée à la réalisation du scénario présenté est évaluée à 140 jours homme d un prestataire, pour un coût total estimé à 86 800 euros HT, pour un taux journalier moyen estimé à 620 euros HT, répartie comme suit : Lot 1 Evolutions OPUS : 40 jours homme Lot 2 Générateur de formulaires : 100 jours homme La charge de travail interne pour la réalisation de ce projet est estimée à : - 30 jours homme de MOE, dont 5 pour la phase de contractualisation - 30 jours homme de MOA, dont 5 pour la phase de contractualisation. Les chefs de projet affectés sur ce projet sont : - Sylvie Parisot DSI/BIA, pour la maîtrise d œuvre ; - Mathilde Toyon DAG/MCG, pour la maîtrise d ouvrage. Phases du projet Maîtrise d ouvrage MCG Maîtrise d œuvre DSI Prestataire Cadrage et études amont 14 10 20 Mise en œuvre 8 15 110 Accompagnement 8 5 10 Total 30 30 140 Coûts / besoins en termes techniques à compléter Les licences BO pour une utilisation de OPUS par tous les utilisateurs potentiels, en DRAC et en Directions centrales, ayant été prévues au moment du marché initial (OPUS volet Opus DRAC), il n est pas prévu de coûts de licences supplémentaires.

12 7 DECISIONS PROPOSEES Ce chapitre est similaire pour toutes les notes de cadrage. L équipe projet demande au Comité de pilotage représenté par le commanditaire, la MOA, les représentants des utilisateurs (CPU), le DSI et le HFSI (a minima) de valider que le cadrage est bien exprimé Mention : lu et approuvé Date : Signature : L équipe projet demande au comité de pilotage représenté par le commanditaire, la MOA, le DSI et le HFSI (a minima) de valider que l investissement proposé a une valeur supérieure à son coût. Mention : Investissement accordé sous réserve de disponibilité de ressources Date Signatures des membres du COPIL L équipe projet demande aux responsables de portefeuilles MOA concernées / MOE de bien vouloir mettre à disposition les ressources nécessaires ; en cas d indisponibilité de ressources, de faire procéder aux arbitrages en recourrant ni nécessaire au processus d escalade jusqu au HFSI représentant la MOA stratégique. Mention : Ressources allouées, Date d allocation Date de décision Signatures des parties MOA MOE HFSI