Suivi MOA : Objectif Contrat d Objectifs et SDSI : H Michel /J Fohrer DF / ACP Suivi DSI : J-F Le Bozec Pôle ECSap Approbateur : N. Gandilhon Pôle QTCR DSI Exploitation et maintenance applicative et du système d information administratif Sorgho finances Contrat d objectifs : Objectif 10 «moderniser la gestion de l administration» SDSI : Objectif 1 «faire passer la DSI d une logique de service à une logique de qualité de service.» Le directeur des finances Visa de l agent comptable principal : Le directeur des systèmes d information : signatures Hervé Michel Jean Fohrer Gilles Poncet N de version Date Nature V 1 Version initiale 1. PREAMBULE... 4 2. OBJET... 4 3. PERIMETRE... 5 4. INTERLOCUTEURS... 6 5. PRESTATIONS... 8 6. ENVIRONNEMENT TECHNIQUE... 20 7. ENGAGEMENTS... 22 8. INDICATEURS... 24 9. PILOTAGE... 25 10. DOCUMENTATION... 25 11. OUTILS... 27 12. ANNEXES... 27 ANNEXE 1 PRESENTATION DETAILLEE «INFRASTRUCTURE SYSTEME»... 28 ANNEXE 2 MODALITES DE SUIVI DE LA PRESTATION... 29 ANNEXE 3 OUTILS... 32 ANNEXE 4 MODELES DE DOCUMENT... 33 18/12/08 Page 1 sur 33
TABLE DES MATIERES DETAILLEE 1. PREAMBULE... 4 2. OBJET... 4 3. PERIMETRE... 5 4. INTERLOCUTEURS... 6 4.1. INTERLOCUTEURS AU SEIN DE LA :... 6 4.2. INTERLOCUTEURS AU SEIN DE LA MAITRISE D OUVRAGE :... 7 5. PRESTATIONS... 8 5.1. DEFINITION DES PRESTATIONS... 8 5.2. DISPOSITIF GLOBAL ET ORGANISATION... 9 5.2.1. Description du processus global... 9 5.2.2. Saisie d un ticket dans Request Tracker... 9 5.2.3. Traitement de la demande... 10 5.3. DISPOSITIF ET ORGANISATION DETAILLES... 11 5.3.1. Traitement détaillé d une anomalie bloquante... 11 5.3.1.1. Processus... 11 5.3.1.2. Création d un ticket... 11 5.3.1.3. Analyse du ticket... 12 5.3.1.4. Analyse, recherche et mise en place de la solution... 12 5.3.1.5. Recette... 12 5.3.1.6. Clôture du ticket... 12 5.3.1.7. Entrants/Livrables... 12 5.3.2. Traitement détaillé d une anomalie majeure ou mineure... 13 5.3.2.1. Processus... 13 5.3.2.2. Création d un ticket... 13 5.3.2.3. Analyse du ticket... 13 5.3.2.4. Planification et proposition d une correction... 13 5.3.2.5. Recette... 14 5.3.2.6. Clôture du ticket... 14 5.3.2.7. Entrants/Livrables... 14 5.3.3. Traitement détaillé d une demande d évolution... 15 5.3.3.1. Processus... 15 5.3.3.2. Création d un ticket... 15 5.3.3.3. Analyse du ticket... 15 5.3.3.4. Inscription au PRE... 15 5.3.3.5. Gestion du PRE... 15 5.3.3.6. Planification et proposition d une solution... 16 5.3.3.7. Recette... 16 5.3.3.8. Clôture du ticket... 16 5.3.3.9. Entrants/Livrables... 16 18/12/08 Page 2 sur 33
5.3.4. Traitement détaillé d une demande d assistance... 17 5.3.4.1. Processus... 17 5.3.4.2. Création d un ticket... 17 5.3.4.3. Analyse du ticket... 17 5.3.4.4. Analyse de l assistance... 17 5.3.4.5. Validation de la réponse... 17 5.3.4.6. Clôture du ticket... 18 5.3.4.7. Entrants/Livrables... 18 5.3.5. Traitement détaillé d une demande d administration ou d exploitation... 18 5.3.5.1. Processus... 18 5.3.5.2. Création d un ticket... 18 5.3.5.3. Analyse du ticket... 19 5.3.5.4. Transfert de la demande au SIL... 19 5.3.5.5. Validation de la demande... 19 5.3.5.6. Clôture du ticket... 19 5.3.5.7. Entrants/Livrables... 19 5.4. PERIODES CRITIQUES... 20 6. ENVIRONNEMENT TECHNIQUE... 20 6.1. INFRASTRUCTURE SYSTEME... 20 6.2. CONTINUITE DE SERVICE... 20 6.2.1. Plages d intervention... 20 6.2.2. Disponibilité de l environnement de production... 20 6.2.3. Passage des ordres de transport... 21 6.2.4. Sauvegarde et plan de reprise... 21 7. ENGAGEMENTS... 22 7.1. ENGAGEMENTS GENERAUX... 22 7.2. ENGAGEMENTS DETAILLES... 22 8. INDICATEURS... 24 8.1. QUALITE MESUREE... 24 8.2. QUALITE PERÇUE... 25 9. PILOTAGE... 25 10. DOCUMENTATION... 25 10.1. DOCUMENTATION SORGHO... 25 10.2. DOCUMENTATION TIERCE MAINTENANCE APPLICATIVE SORGHO... 25 11. OUTILS... 27 12. ANNEXES... 27 ANNEXE 1 PRESENTATION DETAILLEE «INFRASTRUCTURE SYSTEME»... 28 ANNEXE 2 MODALITES DE SUIVI DE LA PRESTATION... 29 ANNEXE 3 OUTILS... 32 ANNEXE 4 MODELES DE DOCUMENT... 33 18/12/08 Page 3 sur 33
1. PREAMBULE Afin de moderniser et de simplifier ses activités administratives, l IRD a mis en place en janvier 2005 un progiciel de gestion intégrée fondé sur SAP version secteur public (mysap ERP version 4.7). Ce progiciel couvre les domaines fonctionnels finances (budgétaire, comptabilité), Ressources Humaines (déployé en janvier 2006) et Missions. Ces trois domaines constituent l application Sorgho. Ils sont placés sous la responsabilité de maîtrises d ouvrage distinctes (la direction des finances et l Agence comptable principale, la direction des Personnels, le Service d Administration du Siège). La maîtrise d œuvre est assurée par la délégation aux systèmes d information, gardienne par ailleurs de la cohérence du système d information. Le passage en production puis en régime établi de l application s accompagne de prestations de maintenance. Il conduit à : faire évoluer l organisation adoptée pour la gestion du projet qui n est plus adaptée à sa phase d exploitation/maintenance définir les attentes des maîtrises d ouvrage et des utilisateurs en matière de disponibilité, de fonctionnement et d évolution de l application préciser les services proposés par la DSI en réponse à ces attentes. Dans le cadre de l objectif 5 de la tranche 2 du SDSI qui prévoit le passage de la DSI d une logique de service à une logique de qualité de service, ces éléments doivent faire l objet d une mise sous assurance qualité, notamment en formalisant les relations entre maîtrise d ouvrage et maîtrise d œuvre au travers du présent contrat de services. La démarche participe également à l atteinte des objectifs définis par la direction générale afin d améliorer les conditions de travail des utilisateurs, de tirer le meilleur profit des outils mis en place et de maîtriser les coûts de fonctionnement. L objectif est de présenter et d adapter aux besoins des maîtrises d ouvrage et des utilisateurs l offre de service de la DSI en matière d exploitation et de maintenance de l application Sorgho en précisant les engagements réciproques pour garantir un niveau de service convenu ainsi que les indicateurs partagés permettant de le mesurer, de le suivre et de l ajuster. Cet objectif est désormais accessible après la phase d intégration en mode projet et une période nécessaire de stabilisation de l application et des flux entre les acteurs concernés. 2. OBJET Le présent contrat de services concerne le domaine «finances» de Sorgho (ci-après ). Il est conclu entre le responsable d un domaine fonctionnel, représentant la maîtrise d ouvrage (ciaprès la MOA) et le directeur de la délégation aux systèmes d information, représentant la maîtrise d œuvre (ci-après la ). Le contrat de services fixe : les termes de la relation entre la maîtrise d ouvrage responsable de Sorgho- finances et la DSI, maîtrise d œuvre ; les modalités de fonctionnement de Sorgho- finances en régime établi ; les méthodes et les outils utilisés. Les services offerts par la DSI en matière de maintenance de l application Sorgho- finances doivent permettre : d assurer un fonctionnement régulier, de maintenir ou d améliorer le niveau de performance et de qualité, de répondre aux demandes d évolution et d adaptation. 18/12/08 Page 4 sur 33
Le contrat est conclu pour la durée de vie, en production, des modules concernés. Il est mis à jour dans les conditions de l article 9 ci-après. Il peut être y être mis fin face à des circonstances exceptionnelles instruites par le comité contractuel prévu à l article 9 ci-après. 3. PERIMETRE L exploitation et la maintenance de l application Sorgho- finances s étend : aux fonctions standards et au paramétrage ; aux développements spécifiques ; aux interfaces ; à l administration et à l exploitation SAP Elle ne couvre pas : les projets inscrits au SDSI (par exemple : élaboration budgétaire, dématérialisation des flux comptables et administratifs, portail ) en revanche, les développements et paramétrages mis en œuvre dans le cadre de ces projets ont vocation à être couverts par le présent contrat de services après leur mise en production ; l exploitation système et réseau ; la gestion des ressources bureautiques associées (postes de travail, imprimantes, suites bureautiques, ). Le périmètre applicatif couvert par le contrat de services est le suivant : les fonctions standard des modules suivants du progiciel SAP, complétées par du paramétrage : - FM pour la comptabilité budgétaire, - MM pour la gestion des achats, - SD pour la gestion des recettes, - FI-AP pour la comptabilité fournisseurs, - FI-AR pour la comptabilité clients, - FI-GL pour la comptabilité générale, - FI-AA pour la gestion des immobilisations - FI-SL pour les axes analytiques - CO pour la comptabilité analytique - PS pour la gestion des conventions - TR pour la trésorerie les fonctions développées en spécifique définies dans les spécifications des développements spécifiques ; les interfaces définies dans les dossiers de spécifications détaillées des interfaces ; le progiciel ETAFI, édité par CEGID, interfacé avec SAP pour la production annuelle du compte financier. Le logiciel spécifique de gestion des régies développé par le pôle «études et compétences SAP» de la DSI 18/12/08 Page 5 sur 33
4. INTERLOCUTEURS 4.1. Interlocuteurs au sein de la : Au sein de la DSI, le dispositif de gestion de la maintenance de l application est organisé selon le schéma suivant : Responsable du Pôle études et compétences SAP Jean-François LE BOZEC Responsable TMA Marie-Pierre MERCIER Expert technicofonctionnel FI Dany GROLLEAU Expert technicofonctionnel FI Kenji LLORENS Expert technique Frédéric GONZALEZ Administrateur SAP Expert technique Jean-Claude DJAMDJIAN Experts techniques «Administration des transports» Nathalie BARKA Mouhadou SEYE La DSI organise le système d information de l institut en veillant à l emploi optimal des moyens humains, techniques et financiers et en prenant en compte les besoins exprimés par les directions fonctionnelles. Au sein de la DSI, le pôle «études et compétences SAP» : gère les applications SAP en régime établi en assure l administration technique instruit et met en œuvre les évolutions des applications, assure l interface entre les structures utilisatrices et les prestataires de maintenance applicative et de maîtrise d œuvre des évolutions. Il est l interlocuteur de la maîtrise d ouvrage pour la mise en place des contrats de service avec le pôle «qualité, techniques contractuelles et ressources» de la DSI, qui propose un mode opératoire pour la négociation de ces contrats, participe à leur négociation et à leur gestion. Il prend en charge les prestations de maintenance de l application Sorgho-finances selon les modalités définies au présent contrat de services et en relation avec les correspondants/ contacts listés à l article 4.2 ci-après. Le directeur des systèmes d information Le directeur des systèmes d information assure l exécution du schéma directeur des systèmes d information. Il met en œuvre les compétences et les moyens nécessaires à la réalisation des objectifs qui y sont définis. Au titre de l objectif 5, il est responsable de la formalisation des contrats de services Sorgho en relation avec les maîtrises d ouvrage des domaines fonctionnels. 18/12/08 Page 6 sur 33
Le responsable du pôle «études et compétences SAP» de la DSI Le responsable du pôle «études et compétences SAP» de la DSI organise, coordonne et supervise la réalisation des prestations d exploitation et de maintenance de l application Sorgho comme défini au contrat de services. Il planifie la disponibilité des ressources et veille au suivi de l avancement des prestations. Il participe aux comités contractuel et opérationnel. Le responsable TMA Le responsable TMA est l interlocuteur opérationnel des maîtrises d ouvrage pour le périmètre applicatif SAP Sorgho. Il contribue au suivi et au respect du dispositif qui organise les relations entre les maîtrises d ouvrage et la maîtrise d œuvre. Il élabore les tableaux de bord présentés aux instances de pilotage et de contrat. Il prend en charge le calcul des indicateurs. Il participe aux comités de l article 9. Les experts technico-fonctionnels du domaine finance Les experts technico-fonctionnels du domaine finance analysent les demandes de correction, d évolution et d assistance fonctionnelle dans leurs aspects «paramétrage» et «métier». Ils effectuent les tests unitaires qui incombent à la maîtrise d œuvre et prennent en charge les retours sur recette potentiels. Ils participent à l élaboration et à la mise à jour de la documentation technico-fonctionnelle. Ils prennent en charge les demandes d assistance technico-fonctionnelle et accompagnent la maîtrise d ouvrage le cas échéant pour une assistance spécifique. Ils sont en charge des demandes de passage d ordres de transport pour les évolutions et corrections de leur domaine d expertise. Ils participent aux comités de production. Les experts techniques Les experts techniques interviennent sur l'administration et l'exploitation de SAP avec des fonctions similaires à celles des experts technico-fonctionnels du domaine finance. Ils sont garants de l accessibilité au système SAP Sorgho comme défini au contrat de services. Ils assurent la cohérence technique des différents environnements SAP. Ils participent, si nécessaire, aux comités de production. 4.2. Interlocuteurs au sein de la maîtrise d ouvrage : La direction des finances a pour mission de développer la programmation budgétaire de l Institut, de préparer les demandes budgétaires, d établir les projets de budgets primitifs et de décisions modificatives, d assurer la mise en œuvre du budget, de diffuser l information sur le cadre réglementaire de la dépense publique, de développer et mettre en œuvre un contrôle de gestion par la définition d indicateurs. L agence comptable principale est chargée du recouvrement des recettes et du paiement des dépenses dont les titres et les mandats sont émis par l ordonnateur principal (le Directeur général) après avoir effectué les contrôles prévus par la réglementation de la comptabilité publique. Elle est également chargée de la tenue de la comptabilité de l Institut, de la conservation des pièces justificatives et de l établissement du compte financier annuel. A cet effet, elle centralise, pour les intégrer dans sa comptabilité, l ensemble des opérations effectuées par les agents comptables secondaires. Le directeur des finances et l agent comptable principal ou leurs représentants sont les responsables du périmètre applicatif pour les modules qui les concernent sur les plans 18/12/08 Page 7 sur 33
organisationnels, fonctionnels et techniques. Ils décident des orientations et rendent les arbitrages relevant de leur domaine fonctionnel. Ils participent aux réunions du comité contractuel. Le responsable de la cellule Sorgho de la direction des finances est l interlocuteur opérationnel de la DSI pour le périmètre applicatif (Il donne mandat en tant que de besoin à l agent comptable à cette fin) : Il est habilité à émettre les demandes d évolution, de correction sur les aspects «métier» et de paramétrage, de mise à jour des données de base, d assistance (technique et fonctionnelle). Il assure le suivi des tickets enregistrés dans RT Il organise et prononce les recettes Il pilote l élaboration et à la mise à jour de la documentation «métier» et fonctionnelle, dont les documents de formation. Il participe au comité opérationnel, au comité de production et au comité de pilotage Sorgho Il assure le «reporting» vers les responsables du périmètre applicatif finances L utilisateur est toute personne qui a accès à l application Sorgho-finances aux fins de gestion, de suivi de cette gestion ou de consultation. Il est habilité à exprimer et enregistrer une demande dans RT pour tout besoin relatif à l application Sorgho-finances. 5. PRESTATIONS Pour les applications comprises dans le périmètre fonctionnel, la DSI prend en charge au titre du présent contrat de services : la maintenance corrective la maintenance évolutive l administration et l exploitation SAP l assistance technico-fonctionnelle 5.1. Définition des prestations La maintenance corrective a pour objet le maintien en état de fonctionnement des applications comprises dans le périmètre fonctionnel, en traitant les non conformités soit par la mise en place d une solution de contournement, soit par la mise en place d une solution définitive. Elle traite des dysfonctionnements du système, qui se traduisent soit par : une anomalie : résultat erroné, fin anormale de traitements, non conformité aux documents de spécifications un incident : perturbation du bon fonctionnement d une application, réduction de sa disponibilité ou gêne des utilisateurs. La maintenance évolutive couvre principalement des évolutions qui répondent : soit à des améliorations demandées par les maîtrises d ouvrage ou issues des recommandations de la DSI et/ou de ses prestataires de services : amélioration ou complétude du système d information, évolution de spécifications fonctionnelles ; soit à des modifications consécutives à une évolution du contexte organisationnel ou réglementaire et dont l IRD a décidé l intégration dans le système ; soit à l application de «support packages». L administration et l exploitation SAP couvre la disponibilité du service (hors accès réseau) ainsi que toutes les tâches d exploitation du système Sorgho-finances. 18/12/08 Page 8 sur 33
Elle consiste en la maintenance des environnements (planification et gestion de la cohérence système). Mais également consiste en la gestion des utilisateurs et des habilitations. Il s agit par exemple du passage des ordres de transport, des copies d environnements, L assistance technico-fonctionnelle couvre toute activité de support au domaine fonctionnel. Elle peut se traduire par une assistance métier de niveau 2, par la réalisation de documentation, par la participation à des formations, Sont considérées de Niveau 1, les demandes d assistance métier ou d utilisation de l outil SAP assurée par la DF ou les demandes élémentaires d assistance technique assurée par les services informatiques locaux (SIL) de la DSI. Sont considérées de Niveau 2 les tâches d assistance suivantes : Diagnostic des demandes technico-fonctionnelles non résolues au niveau 1. Escalade au niveau 3 si nécessaire et suivi de l avancement des tâches du niveau 3. Traitement des demandes d assistance technico-fonctionnelles non résolues au niveau 1. Participation en support aux actions de formation. 5.2. Dispositif global et organisation Le processus de traitement global d une demande (MOA vers ou vers MOA) est décrit ciaprès. 5.2.1. Description du processus global Sorgho FI Sorgho DF MOA Emission du besoin par la MOA ticket RT Recette de la solution Recette OK? MOA Sorgho FI Evol Sorgho DF Sorgho FI TMA IRD Sorgho FI TMA IRD Sorgho OT Analyse Qualification et validation du ticket Résolut ion? Analyse de la solution Recette interne ok? Passage en production Clôture du Ticket TMA Sorgho FI TMA UNILOG IRD Analyse et planification et résolution de la solution Sorgho FI TMA UNILOG IRD Correction de l anomalie TMA 5.2.2. Saisie d un ticket dans Request Tracker Afin de s assurer du bon suivi des demandes, celles-ci sont conditionnées par la saisie d un ticket dans l outil de gestion des incidents Request Tracker (ci-après RT cf. annexe 3). La description de toute demande doit présenter au moins les éléments suivants : Pour les corrections : Typologie (anomalie) 18/12/08 Page 9 sur 33
Gravité (bloquant, majeur, mineur) Module(s) SAP concerné(s) ou transaction (ou programme) concerné Conditions d utilisation (Utilisateur, copie d écran, données transactionnelles saisies, ) Message d erreur généré ou description de l anomalie (résultat attendu, ) A ces informations, peut s ajouter tout élément permettant un diagnostic et un traitement rapide de l anomalie. Pour la maintenance évolutive : Typologie (évolution) Criticité (bloquant, majeur, mineur) Module(s) SAP concerné(s) Description succincte de l évolution Un cahier des charges fonctionnel complet (fichier à joindre conforme à l annexe 4) Pour l administration et l exploitation SAP : Typologie (évolution, anomalie, utilisation) Criticité (bloquant, majeur, mineur) Module(s) SAP concerné(s), le cas échéant Environnement (le serveur, le mandant, ) Description de la demande A ces informations, peut s ajouter tout élément permettant la mise en œuvre effective de la demande. Pour l assistance technico-fonctionnelle : Typologie (utilisation) Criticité (majeur, mineur) Module(s) SAP concerné(s), le cas échéant Transaction (ou programme) concerné Description de la demande A ces informations, peut s ajouter tout élément permettant le traitement effectif de la demande. Un ticket ne peut contenir qu une seule demande d évolution ou de correction. 5.2.3. Traitement de la demande Toute demande est analysée puis qualifiée par la. Les tickets sont mis à jour si la typologie, la file RT ou la qualification sont absentes ou incorrectes. La complétude de la description conditionne la prise en charge effective de la demande par la. La recherche de cette complétude fait l objet, si nécessaire, d échanges formalisés entre la et la MOA. pour information La analyse le mode de résolution et transmet le ticket à la TMA Unilog si nécessaire (pour tout développement ou modification de paramétrage). - Si une résolution est possible par le pôle «études et compétences SAP» de la DSI, celui-ci planifie et réalise les corrections, adaptations ou modifications demandées - Si l intervention de la TMA Unilog est nécessaire, le pôle «études et compétences SAP» de la DSI intervient sur la phase de recette. 18/12/08 Page 10 sur 33
Une recette interne (tests unitaires et de non régression) est réalisée par la. Si cette recette est positive, une recette définitive est demandée à la MOA (cette demande de recette se traduit par un changement de file du ticket correspondant dans RT). Si la recette est prononcée par la MOA, la assure le passage en production (demande effectuée par le pôle «études et compétences SAP» de la DSI auprès du pôle «Technique» de la DSI) et le ticket est clos. Si la recette montre des anomalies, le ticket est envoyé à la pour analyse, résolution et tests. Une nouvelle recette est proposée à la MOA. Si une anomalie est détectée relative à un ticket clos, elle fait l objet d un nouveau ticket et suit le processus global. 5.3. Dispositif et organisation détaillés 5.3.1. Traitement détaillé d une anomalie bloquante 5.3.1.1. Processus TRAITEMENT D UNE ANOMALIE BLOQUANTE Utilisateur Final Pôle Sorgho FI - MOA Pôle Etudes - Création d un Ticket dans RT Analyse du ticket (complétude, qualification) Analyse et recherche de correction Non Recette de la solution Mise en place d une solution Recette OK Oui Passage de la correction en production Solution de contourne ment? Oui Non Clôture du Ticket 5.3.1.2. Création d un ticket Le ticket de type «anomalie bloquant»e peut être créé par tout type d utilisateur (utilisateur final, direction des finances, agence comptable principale, pôle «études et compétence SAP» de la DSI) dès qu une anomalie bloquante est détectée. 18/12/08 Page 11 sur 33
Afin d optimiser la réactivité sur les anomalies bloquantes, le responsable de TMA et les experts technico-fonctionnels de la sont destinataires du ticket (un mail leur est envoyé automatiquement). 5.3.1.3. Analyse du ticket Le ticket est analysé par la. La typologie et la gravité ainsi que la complétude du ticket sont revues et/ou validées. Si un des éléments ne permet pas de traiter ce ticket ou si la gravité bloquante n est pas confirmée, ces éléments sont modifiés. Un retour est fait par la auprès de la MOA. 5.3.1.4. Analyse, recherche et mise en place de la solution Afin de solutionner le problème rencontré, toutes les méthodes (développement, paramétrage, solution de contournement) sont proposées par la et sont mises en œuvre dans l environnement de recette. Si la solution proposée est une solution de contournement, les travaux d analyse et de recherche d une solution définitive se poursuivent néanmoins en parallèle. La réalise une recette interne. Si celle-ci est positive, le ticket est passé dans la file MOA afin de permettre la recette de cette correction. 5.3.1.5. Recette La recette de la solution démarre à la livraison (via passage dans la file Sorgho FI). La MOA effectue tous les tests nécessaires d intégration, de qualification et de non régression du correctif. Si la recette n est pas considérée comme satisfaisante par la MOA, les retours sont transmis à la pour adaptation de la solution. Après validation de la recette, la correction est mise en production par la. Si la solution mise en place est une solution de contournement, la reprend ce ticket pour recherche et mise en place d une solution définitive. 5.3.1.6. Clôture du ticket Le ticket est clos lors de la résolution définitive de la correction. Une solution de contournement ne permet pas de clore le ticket. La clôture du ticket est réalisée par la en accord avec la MOA. 5.3.1.7. Entrants/Livrables Les entrants attendus pour un correctif bloquants sont : Un ticket RT Un jeu de test (moyen de reproduire l anomalie) Les livrables attendus pour un correctif bloquants sont : Un ticket mis à jour Les spécifications fonctionnelles mises à jour si nécessaire Les fiches de test 18/12/08 Page 12 sur 33
5.3.2. Traitement détaillé d une anomalie majeure ou mineure 5.3.2.1. Processus TRAITEMENT D UNE ANOMALIE (non bloquante) Utilisateur Final Pôle Sorgho FI - MOA Pôle Etudes - Création d un Ticket dans RT Analyse du ticket (complétude, qualification) Non Non Typologie et complétude validées Validation? Planification et Proposition de solution de correction (ou contournement) Non Oui Lancement de la correction Validation des tests Recette de la solution Recette OK Oui Passage de la correction en production Clôture du Ticket 5.3.2.2. Création d un ticket Le ticket de type «anomalie majeure ou mineure» peut être créé par tout type d utilisateur (utilisateur final, direction des finances, agence comptable principale, pôle «études et compétences SAP» de la DSI) dès qu une anomalie est détectée. 5.3.2.3. Analyse du ticket Le ticket est analysé par la. La typologie et la gravité ainsi que la complétude du ticket sont revues et/ou validées. Si un des éléments ne permet pas de traiter ce ticket ou si la typologie n est pas confirmée, ces éléments sont modifiés. Un retour est fait par la auprès de la MOA. 5.3.2.4. Planification et proposition d une correction Le traitement de la demande est planifié en fonction de la criticité et des priorités de la et de la MOA. 18/12/08 Page 13 sur 33
La informe la MOA sur le diagnostic et la date prévisionnelle de livraison de la correction. Les validations de la solution et de la date proposées sont demandées à la MOA. 5.3.2.5. Recette Une planification de la recette par la MOA sera nécessaire afin de permettre à la d avoir une vision sur la date prévisionnelle de la mise en production. La réalise une recette interne. Si celle-ci est positive, le ticket est passé dans la file MOA afin de permettre la recette de cette correction. La recette de la solution démarre à la livraison (via passage dans la file Sorgho FI). La MOA effectue tous les tests nécessaires d intégration, de qualification et de non régression du correctif. Si la recette n est pas considérée comme satisfaisante par la MOA, les retours sont transmis à la pour adaptation de la solution. Après validation de la recette, la correction est mise en production par la. 5.3.2.6. Clôture du ticket Le ticket est clos lors de la résolution définitive de la correction en environnement de production. La clôture du ticket est réalisée par la en accord avec la MOA. 5.3.2.7. Entrants/Livrables Les entrants attendus pour un correctif sont : Un ticket RT Un jeu de test (moyen de reproduire l anomalie) Les livrables attendus pour un correctif sont : Un ticket mis à jour Les spécifications fonctionnelles mises à jour si nécessaire Les fiches de test 18/12/08 Page 14 sur 33
5.3.3. Traitement détaillé d une demande d évolution 5.3.3.1. Processus TRAITEMENT D UNE EVOLUTION Utilisateur Final Pôle Sorgho FI - MOA Pôle Etudes - Création d un Ticket dans RT Analyse du ticket (complétude, qualification, priorisation) Non Pré-analyse de la demande et estimation de charge Confirmation de l inscription au PRE? Inscription de l évolution au PRE Oui Réalisation de cahier des charges Planification et réalisation de solution Non Recette de la solution Recette OK Oui Passage de la modification en production 5.3.3.2. Création d un ticket Le ticket de type Evolution ne peut être créé que par la direction des finances, l Agence comptable principale ou la. 5.3.3.3. Analyse du ticket Le ticket est analysé par la. La typologie ainsi que la complétude du ticket sont revues et/ou validées. Si un des éléments ne permet pas de traiter ce ticket ou si la typologie n est pas confirmée, ces éléments sont modifiés. Un retour est fait par la auprès de la MOA. 5.3.3.4. Inscription au PRE La demande d évolution doit être validée et donc inscrite au PRE afin de permettre le lancement de la réalisation. Pour cela une pré-analyse est réalisée par la et la MOA afin d estimer au mieux la charge nécessaire à la mise en place de cette évolution. La demande est alors inscrite au PRE par la pour demande de validation lors du comité mensuel Sorgho. 5.3.3.5. Gestion du PRE Les règles de fonctionnement du PRE sont les suivantes : Clôture du Ticket 18/12/08 Page 15 sur 33
Le contenu du PRE est validé en fin d année N-1 par le Secrétaire Général. Des priorités de réalisation définies conjointement entre la et la MOA lui sont préalablement proposées. Les priorités 1 : Les développements sont à lancer au plus tôt Les priorités 2 : Les développements sont à chiffrer et en attente de validation pour lancement des réalisations Les priorités 3 : Les développements sont indiqués à titre prévisionnel et seront statués en cours d année. Lorsque des besoins complémentaires sont identifiés en cours d année N (création de ticket de type «évolution»), le PRE est amendé par la et proposé pour validation lors des comités sorgho. Si la première estimation de charge de réalisation est inférieure à 6 jours, l arbitrage PRE est possible au niveau du comité de production dans la limite de l enveloppe disponible (le comité Sorgho en est informé à l occasion du prochain point fait sur le PRE). 5.3.3.6. Planification et proposition d une solution Apres validation de l inscription de la demande d évolution au PRE et après livraison par la MOA du cahier des charges, le traitement de la demande est planifié. Pour toute demande dont la charge de réalisation est supérieure à 10 jours, des ateliers de conceptions sont organisés entre la MOA et la afin de revoir conjointement le cahier des charges et de s assurer de la bonne compréhension du besoin. Une ou plusieurs solutions sont proposées par la. La MOA signifie via la mise à jour du cahier des charges, la solution retenue et à implémenter. La informe la MOA sur la date prévisionnelle de livraison de cette évolution. 5.3.3.7. Recette Une planification de la recette par la MOA est nécessaire afin de permettre à la d avoir une vision sur la date prévisionnelle de la mise en production. La réalise une recette interne. Si celle-ci est positive, le ticket est passé dans la file MOA afin de permettre la recette de cette correction. La recette de la solution démarre à la livraison (via passage dans la file Sorgho FI). La MOA effectue tous les tests nécessaires d intégration, de qualification et de non régression liée à la livraison de l évolution. Si la recette n est pas considérée comme satisfaisante par la MOA, les retours sont transmis à la pour adaptation de la solution. Après validation de la recette, l évolution est mise en production par la. 5.3.3.8. Clôture du ticket Le ticket est clos après confirmation définitive que la modification correspond aux attentes en environnement de production. La clôture du ticket est réalisée par la en accord avec la MOA. 5.3.3.9. Entrants/Livrables Les entrants attendus pour une demande d évolution sont : Un ticket RT Un cahier des charges (cf. annexe 4) Un jeu de test Les livrables attendus pour une demande d évolution sont : 18/12/08 Page 16 sur 33
Un ticket mis à jour Les spécifications fonctionnelles mises à jour si nécessaire Les fiches de test Le suivi du PRE (cf. annexe 4) 5.3.4. Traitement détaillé d une demande d assistance 5.3.4.1. Processus TRAITEMENT D UNE DEMANDE D ASSISTANCE Utilisateur Final Pôle Sorgho FI - MOA Pôle Etudes - Création d un Ticket dans RT Analyse du ticket (complétude, qualification) Non Typologie et complétude validées Non Oui Analyse de la solution Réponse utilisateur Réponse définitive? Oui Clôture du Ticket 5.3.4.2. Création d un ticket Le ticket de type «assistance» peut être créé par tout type d utilisateur (Utilisateur final, direction) dès qu un besoin d assistance est détecté. 5.3.4.3. Analyse du ticket Le ticket est analysé par la. La typologie ainsi que la complétude du ticket sont revues et/ou validées. Si un des éléments ne permet pas de traiter ce ticket ou si la typologie n est pas confirmée, ces éléments sont modifiés. Un retour est fait par la auprès de la MOA. 5.3.4.4. Analyse de l assistance Les éléments de réponse à la demande d assistance sont fournis par la sous la forme la mieux appropriée (fonction du type de demande). 5.3.4.5. Validation de la réponse La validation de la réponse fournie est faite par le demandeur. 18/12/08 Page 17 sur 33
5.3.4.6. Clôture du ticket Le ticket est clos après confirmation définitive que la réponse fournie correspond aux attentes du demandeur. La clôture du ticket est réalisée par la en accord avec la MOA. 5.3.4.7. Entrants/Livrables Les entrants attendus pour une demande d assistance sont : Un ticket RT Tout élément permettant de comprendre le besoin Les livrables attendus pour une demande d assistance sont : Un ticket mis à jour 5.3.5. Traitement détaillé d une demande d administration ou d exploitation 5.3.5.1. Processus TRAITEMENT D UNE DEMANDE D ADMINISTRATION OU D EXPLOITATION Utilisateur Final Pôle Sorgho FI - MOA Pôle Etudes - Création d un Ticket dans RT Traiteme nt Pôle Etudes? Non Transfert au SIL Oui Oui Analyse du ticket (complétude, typologie, qualification) Non Validation nécessaire? Non Typologie et complétude validées Réalisation de la demande Non Validati on? Oui Clôture du Ticket 5.3.5.2. Création d un ticket Le ticket d administration ou d exploitation peut être créé par tout type d utilisateurs (Utilisateur final, direction des finances, agence comptable principale) dès qu un besoin est détecté. Le type de ticket peut être «assistance», «correctif» ou «utilisation». Cette typologie est fonction du contenu de la demande. 18/12/08 Page 18 sur 33
5.3.5.3. Analyse du ticket Le ticket est analysé par la. La typologie, la complétude ainsi que la qualification du ticket sont revues et/ou validées. Si un des éléments ne permet pas de traiter ce ticket ou si la typologie n est pas confirmée, ces éléments sont modifiés. Un retour est fait par la auprès du demandeur. 5.3.5.4. Transfert de la demande au SIL Si la demande ne peut être traitée par la, elle est transférée au SIL compétent pour traitement. 5.3.5.5. Validation de la demande Même si une demande d administration ou d habilitation peut être faite par tout type d utilisateur, seul le responsable de la cellule Sorgho de la direction des finances est habilité à demander des opérations spécifiques d exploitation système (copie d environnement). De plus une validation hiérarchique est demandée pour toute demande de création de compte ou d extension de droit utilisateur (habilitation). Voici un zoom sur le processus spécifique de demande de création de compte : L utilisateur remplit une demande d ouverture de compte disponible sur l intranet Sorgho à l adresse: http://intranet.ird.fr/sorgho/documentation/technique/procedures.htm Visa du Responsable Hiérarchique Envoi de la demande au SIL par Responsable hiérarchique Le SIL vérifie la connexion sur le poste et l accès à l intranet Sorgho et envoie le document de demande à sorgho@rt.ird.fr Mail au demandeur et au resp. hiérarchique N Validation direction fonctionnelle O Création du compte par Pôle SAP Mail au demandeur et responsable hiérarchique Mail dir. fonctionnelle 5.3.5.6. Clôture du ticket Le ticket est clos après confirmation définitive que la modification correspond aux attentes en environnement de production. La clôture du ticket est réalisée par la en accord avec la MOA. 5.3.5.7. Entrants/Livrables Les entrants attendus pour une demande d administration ou habilitation sont : 18/12/08 Page 19 sur 33
Un ticket RT Le cas échéant le formulaire de création de compte (cf. annexe 4) Les livrables attendus pour une demande d administration ou d habilitation sont : Un ticket mis à jour 5.4. Périodes critiques Pour l exploitation et la maintenance de, les priorités et les points critiques sont les suivants : la préparation à la clôture de l exercice comptable, du 15 novembre au 25 janvier, exige une forte disponibilité du système limitant les mises en production de nouvelles évolutions fonctionnelles aux cas nécessaires à cette clôture. la mise en place des crédits et l ouverture d un nouvel exercice, du 15 décembre au 31 janvier, exigent une forte mobilisation MOA et. 6. ENVIRONNEMENT TECHNIQUE 6.1. Infrastructure système L environnement technique de est résumé ci-dessous et présenté de manière détaillée en annexe 1. 6.2. Continuité de service 6.2.1. Plages d intervention Les heures d intervention de la sont de 9h à 18h du lundi au vendredi (heure de Paris). De plus le personnel de la respecte les règles de fonctionnement définies par l IRD (ex : jours de fermeture des sites). Seules ces plages d intervention sont prises en compte pour le calcul des indicateurs de suivi. 6.2.2. Disponibilité de l environnement de production L environnement de production (PR1) est réputé disponible du lundi au dimanche à l exception de deux coupures programmées (pour sauvegarde Full Off Line) les week-ends aux heures suivantes : Samedi de 4h à 7h (heure Paris) Dimanche de 4h à 12h (heure Paris) Cette disponibilité n est accompagnée d un dispositif d intervention que dans les plages d intervention de l article 6.2.1 ci-dessus. 18/12/08 Page 20 sur 33
Des interruptions supplémentaires peuvent être programmées pour des opérations diverses du type : Sauvegardes complémentaires (2 par an maxi) Application de support package Mise en production de nouveaux modules Travaux d infrastructure. Pour ces interruptions programmées, qui devraient essentiellement intervenir le 1 er lundi du mois, un délai de prévenance ou de consultation est respecté par la. Ce délai est au minimum de 20 jours ouvrés. Néanmoins aucun de ces travaux n est planifié pendant les périodes dites critiques. 6.2.3. Passage des ordres de transport Le passage des ordres de transport de l environnement de recette vers l environnement de production s effectue par lotissement. Les lots sont planifiés du lundi au vendredi aux horaires suivants : Lot 1 - à 10h30 (heure de Paris) Lot 2 - à 14h30 (heure de Paris) Des demandes exceptionnelles de passage d ordres peuvent être faites auprès du responsable TMA qui analyse leurs pertinence et impacts avant validation. 6.2.4. Sauvegarde et plan de reprise Comme indiqué à l article 6.2.2 des sauvegardes Full Off Line sont réalisées à un rythme hebdomadaire. A cela s ajoutent des sauvegardes On-line réalisées de façon journalière. Ces sauvegardent permettent d assurer un temps maximum d indisponibilité (corruption de base incluse) de 24 heures. Les périodes de sauvegarde «machine» pour les opérations d administration / sauvegarde sont les suivantes : Date (heure de Sauvegarde Durée Sauvegarde NV Type Durée Paris) SAP Dimanche 23H On Line 1H10 Lundi 1H00 Incrémentale 1H20 Lundi 23H On Line 1H10 Mardi 1H00 I Mardi 23H On Line 1H10 Mercredi 1H00 I Mercredi 23H On Line 1H10 Jeudi 1H00 I Jeudi 23H On Line 1H10 Vendredi 1H00 I Samedi 04H Off Line 2H30 Samedi 08H00 Full 1H50 Dimanche 4H00 Arrêt SAP Relance à 12H Export à 8H00 Export 3H00 Un plan de reprise d activité global et détaillé, basé sur un dispositif de bascule du site central de Bondy vers le site d Orléans est en cours d élaboration. Il sera spécifié précisément à l occasion d une future mise à jour du présent contrat. 18/12/08 Page 21 sur 33
7. ENGAGEMENTS 7.1. Engagements généraux La s engage sur un niveau de service exprimé en terme de : charge de travail (PRE), nature et disponibilité des ressources (jours, horaires ) seuil à atteindre et à ne pas dépasser pour les anomalies, délais de traitement des demandes (temps de réponse ) diffusion des informations sur les événements qui auront une incidence sur la disponibilité et ou le fonctionnement de l application. La MOA s engage à : appliquer le dispositif mis en place pour la gestion de la maintenance de l application Sorgho- FI, en particulier en matière d expression des besoins et de recettes des prestations former les utilisateurs directement placés sous sa responsabilité ou qui font appel à ses compétences fonctionnelles pour l application. s assurer de la mise à jour régulière de leurs connaissances afin de faciliter l appropriation et la mise en œuvre de l outil. 7.2. Engagements détaillés Les tableaux qui suivent spécifient les engagements contractuels quantifiables ainsi que les moyens mis en œuvre pour en mesurer le respect. Ces engagements tiennent compte des engagements contractuels liant la DSI à ses propres fournisseurs. Engagements relatifs à l assurance d un fonctionnement régulier : Libellé Respect des processus de traitement (cf. article 5) Complétude des tickets RT Respect et exhaustivité des livrables Délai de création de compte Sorgho Délai de mise à jour de compte Sorgho Partie engagée MOA & MOA & Niveau de l engagement respect de processus respect de processus respect de processus Indicateur de respect de l engagement Manuel au travers des CR des différents comités (cf. article 9) Manuel au travers des CR des différents comités (cf. article 9) Manuel au travers des CR des différents comités (cf. article 9) 2 jours ouvrés Automatique calculé via RT 2 jours ouvrés Automatique calculé via RT 18/12/08 Page 22 sur 33
Engagements relatifs au maintien ou à l amélioration du niveau de performance et de qualité : Libellé Délai de mise à disposition d une solution de contournement pour une anomalie bloquante Délai de résolution d une anomalie bloquante Délai de résolution d une anomalie majeure Délai de résolution d une anomalie mineure Délai de recette de la résolution d une anomalie bloquante Délai de recette de la résolution d une anomalie majeure Délai de recette de la résolution d une anomalie mineure Partie engagée Niveau de l engagement Indicateur de respect de l engagement 2 jours ouvrés calculé via RT 7 jours ouvrés Automatique calculé via RT 11 jours ouvrés Automatique calculé via RT annoncer un délai et le respecter Automatique calculé via RT MOA 1,5 jours ouvrés calculé via RT MOA 3 jours ouvrés calculé via RT MOA 8 jours ouvrés (si livraison conforme au planning) calculé via RT Taux de retour sur recette 15% calculé via RT Nombre moyen de retour en cas de retour sur recette 1,5 calculé via RT Engagements relatifs à la réponse aux demandes d évolution et d adaptation : Libellé Délai de réalisation d une évolution Délai de recette d une évolution Taux de retour sur recette Nombre moyen de retour en cas de retour sur recette Partie engagée MOA Niveau de l engagement Annonce et respect du délai Si livré dans les temps : 3 semaines calendaires si durée < 1 mois calendaire sinon 7 semaines calendaire Sera déterminé après les 6 premiers mois d application du contrat Sera déterminé après les 6 premiers mois d application du contrat Indicateur de respect de l engagement manuel calculé via RT et le tableau de bord du PRE manuel calculé via RT et le tableau de bord du PRE calculé via RT calculé via RT 18/12/08 Page 23 sur 33
8. INDICATEURS 8.1. Qualité mesurée Au-delà de l ensemble des indicateurs spécifiés à l article 7 ci-dessus pour mesurer le respect des engagements contractuels, les indicateurs suivants sont mesurés pour le suivi de l activité et l ajustement des moyens. Elément mesuré Indicateurs producteur Source Volumétrie Stabilisation Mensuel : Nombre de tickets ouverts / mois Idem, limité aux tickets «anomalie bloquante» Idem, limité aux tickets «anomalie majeure» Idem, limité aux tickets «anomalie mineure» Idem, limité aux tickets «évolution» Idem, limité aux tickets «assistance fonctionnelle» Idem, limité aux tickets «administration & exploitation» Mensuel : Tickets clôturés / tickets ouverts, dans le mois sur Idem, limité aux tickets «anomalie bloquante» Idem, limité aux tickets «anomalie majeure» Idem, limité aux tickets «anomalie mineure» Idem, limité aux tickets «évolution» Idem, limité aux tickets «assistance fonctionnelle» Idem, limité aux tickets «administration & exploitation» Disponibilité Taux de disponibilité Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique calculé via RT Automatique via dispositif ad-hoc 1 1 Dispositif de calcul du taux de disponibilité : Depuis un serveur de supervision du réseau et des applications situés sur le site central de Bondy, les actions suivantes sont effectuées automatiquement toutes les 5 minutes, 24h/24, 7j/7 : tentative de connexion à l application SAP (environnement de production), tentative de connexion aux routeurs de périphérie des centres et représentations (équipements permettant à ces centres et représentations d accéder à internet). Ce dispositif permet d établir les durées d indisponibilité propres à chaque élément testé et par conséquent de calculer leur taux de disponibilité respectif. Le taux de disponibilité global est obtenu par le produit des taux de disponibilité de chacun des éléments testés, pondérés en fonction de nombre d utilisateur Sorgho s agissant de la connectivité des centres et représentations. 18/12/08 Page 24 sur 33
Remarques importantes : la disponibilité les réseaux locaux des centres et représentations n est pas mesurée à ce stade, la panne éventuelle du serveur de supervision suspend les mesures et n est pas assimilable à une indisponibilité de Sorgho, l indicateur sera produit à compter de septembre 2007. 8.2. Qualité perçue Afin de comparer le niveau de service mesuré à la perception qu en ont les utilisateurs, une enquête de satisfaction est réalisée annuellement par la MOA auprès de ces utilisateurs. Le contenu de l enquête est arrêté conjointement entre la MOA et la. L analyse des résultats se fait également conjointement en comité opérationnel. 9. PILOTAGE Le pilotage et le suivi de la prestation entre la MOA et la s appuient sur des instances communes présentées en annexe 2. Ces instances sont les suivantes : le comité contractuel à vocation de suivi du contrat de service, de ses évolutions et d arbitrages le comité opérationnel à vocation de suivi de l exécution du contrat de services le comité de production à vocation de suivi opérationnel des demandes traitées par la Pour mémoire, le comité de pilotage Sorgho intervient notamment dans l arbitrage du PRE. Il n est cependant pas un acteur de pilotage du présent contrat. 10. DOCUMENTATION 10.1. Documentation Sorgho Les modèles de documents utilisés pour la gestion du contrat de services sont présentés en annexe 4 10.2. Documentation tierce maintenance applicative Sorgho La documentation est divisée en deux parties : La documentation «projet», documentation concernant la mise en place du projet Sorgho. Cette documentation est sauvegardée sur un répertoire bureautique accessible depuis le site de Bondy. Une mise à disposition de cette documentation sur la plateforme collaborative est en cours. La documentation «TMA», documentation liée à la phase TMA, reprenant la liste des entrants et livrables et tout document nécessitant un partage entre la MOA et la. Cette documentation est attachée à chaque ticket RT. Une mise à jour de cette documentation sur la plateforme collaborative est en cours. 18/12/08 Page 25 sur 33
Règles de codification de la documentation : Cahier des charges fonctionnel (CDC) Structure CDC_Code domaine_code sous domaine_description_vxx.doc exemple CDC_FI_AR_EXTOURNES_V01.doc (BPML Finance client) Spécification fonctionnelle et technique (SFT) Libellé Nom du fichier SFT domaine SFT_Code domaine_code sous domaine_description_vxx.doc SFT_FI_AR_EXTOURNES_V01.doc (BPML Finance client) BPML Domaine Libellé BPML domaine Nom du fichier BPML_DOMAINE_sousdomaine.xls Fiche de Tests Unitaire Structure fiche de test Exemple FTU_Code domaine_code sous domaine_xx.doc FTU_FI_ar_01.xls (fiche de test unitaire Finance comptabilité client) Comptes-rendus des Comités o Codification des comptes-rendus des comités de production : o CRCRP _jjmmaa _nn (nn=n du document) o Codification des comptes-rendus des comités opérationnels: o CRCO _jjmmaa _nn (nn=n du document) o Codification des comptes-rendus des comités contractuels : o CRCC _jjmmaa _nn (nn=n du document) 18/12/08 Page 26 sur 33
11. OUTILS Les outils utilisés pour le suivi de la prestation sont : RT, pour la saisie de toute demande de maintenance effectuée au titre du contrat de services La plateforme collaborative Le tableau de suivi du PRE Ces outils sont présentés en annexes 3 et 4. 12. ANNEXES Annexe 1 : Présentation détaillée «infrastructure système» Annexe 2 : Modalités de suivi de la prestation Annexe 3 : Outils Annexe 4 : Modèles de document 18/12/08 Page 27 sur 33
ANNEXE 1 Présentation détaillée «infrastructure système» Architecture générale L architecture générale est représentée comme suit : SAP Walldorf Ass. technique Aide en ligne PC utilisateur INTERNET isole SAP Router [en DMZ] agathe ITS Dev. ITSQua. W-Gate A-Gate [en DMZ] sapgate ITS Prod. W-Gate [en DMZ] quinoa couscous sorgho agatha Développement Sorgho Recette Sorgho SAP : RR1 Production Sorgho ITS Prod. A-Gate SAP : DR1 Production Eleusine SAP : PR2 SAP : PR1 PC utilisateur Paysage des mandants SAP Système SAP Mandants Rôle Mise à jour Développement DR1 100 Référence paramétrage Paramétrage direct 120 Tests unitaires Sorgho Transport RR1 200 Référence paramétrage Transport 250 Référence paramétrage Transport PR1 Production 100 Production Transport Pré-production 100 Pre-prod FI Copie + transport 110 Pré-prod RH Copie + transport 120 Pré-prod RH Copie + transport 130 Divers Copie + transport 18/12/08 Page 28 sur 33
ANNEXE 2 Modalités de suivi de la prestation Le pilotage et le suivi de la prestation entre la MOA et la s'appuient sur des instances communes, listées ci-dessous : - Le comité contractuel à vocation «gestion du contrat de services et arbitrages», - Le comité opérationnel à vocation «suivi opérationnel de l avancement du contrat de services», - Le comité de production à vocation «production informatique», Le comité contractuel Le comité contractuel a pour rôle : L examen des tableaux de bord fournis par la (engagements et indicateurs) et des enseignements à en tirer, qu il s agisse de la mise à jour du présent contrat ou de l évolution des contrats de la avec ses propres fournisseurs. L identification des points de risque, Le suivi qualité, L instruction des arbitrages majeurs. Le secrétariat est assuré par la. Participants : Pour la : o Le responsable du «qualité, techniques contractuelles et ressources» de la DSI, qui assure la présidence du comité, o Le responsable du pôle «études et compétences SAP» de la DSI. o Le responsable TMA Pour la MOA : o Le directeur des finances o L agent comptable principal o Le responsable de la cellule Sorgho de la direction des finances Périodicité : annuelle, ou à tout moment à l initiative de la MOA ou de la. Documents en entrée : Compte rendu de la réunion précédente, tableaux de bord mensuels de suivi d activité, Documents en sortie : Compte rendu rédigé par la et remis pour approbation au représentant de la MOA dans un délai de 5 jours ouvrés après la réunion. En l absence de remarques dans les 5 jours ouvrés suivants, ce compte rendu est réputé approuvé. Après approbation, ce compte rendu a un caractère contractuel. Le comité opérationnel Le comité opérationnel a pour rôle : Le suivi opérationnel avec examen des difficultés ; La coordination et l organisation des travaux ; Le secrétariat est assuré par la. Ordre du jour : Estimation des évolutions, Congés, absences, Gestion des ressources, 18/12/08 Page 29 sur 33
Arbitrages éventuels, Questions diverses, Examen des tableaux de bord Date de la prochaine réunion. Participants : Pour la : o Le responsable du pôle «études et compétences SAP» de la DSI qui assure la présidence du comité, o Le responsable TMA Pour la MOA : o Le responsable de la cellule Sorgho de la direction des finances Périodicité : trimestrielle Documents en entrée : Compte rendu de la réunion précédente, tableaux de bord mensuel de suivi d activité, point d'avancement, demandes d intervention, fiches événements (incidents, non-conformités...). Documents en sortie : Compte rendu rédigé par la et remis pour approbation au responsable de la MOA dans un délai de 5 jours ouvrés après la réunion. En l absence de remarques dans les 5 jours ouvrés suivants, ce compte rendu est réputé approuvé Le comité de production Le comité a pour rôle, notamment : Le suivi de la production ; La définition des priorités d intervention pour les corrections ; Une première analyse des demandes d évolution demandées par les utilisateurs ; Le suivi des ordres de transport sur la machine de production ; L évaluation de la réactivité de l assistance utilisateurs. Le secrétariat est assuré par la MOA. Ordre du jour : Suivi des corrections, Suivi des demandes non planifiables, Suivi des demandes planifiées (ou lots) : réalisation, tests, livraisons, Congés, absences, Arbitrages éventuels, Questions diverses, Participants : Pour la : o Le responsable de la TMA qui assure la présidence du comité, o Les experts technico-fonctionnels du domaine finance o Les experts techniques SAP. Pour la : o La cellule Sorgho de la direction des finances Périodicité : tous les 15 jours (à Bondy ou en visioconférence). 18/12/08 Page 30 sur 33
Documents en entrée : Compte rendu de la réunion précédente, tableaux de bord RT, indicateurs de qualité. Documents en sortie : Compte rendu rédigé par la et remis pour approbation au responsable de la MOA dans un délai de 3 jours ouvrés après la réunion. En l absence de remarques dans les 3 jours ouvrés suivants, ce compte rendu est réputé approuvé. 18/12/08 Page 31 sur 33
ANNEXE 3 Outils Request Tracker guide_utilisateur_rt_ v3.doc La plateforme collaborative Plateforme_collab_p our_docs_sorgho_v1_2.doc 18/12/08 Page 32 sur 33
ANNEXE 4 Modèles de document Cahier des charges IRD_CDC_V2.doc Fiche de tests IRD_FICHE_TEST_V3.doc Demande de création de compte form_user_modele V2.doc Tableau de suivi du PRE et des évolutions Modele suivi PRE.xls 18/12/08 Page 33 sur 33