TIERCE MAINTENANCE APPLICATIVE

Transcription

1 Notre expertise au cœur de vos projets TIERCE MAINTENANCE APPLICATIVE SERVICE LEVEL AGREEMENT

2 Sommaire 1. Terminologie Définitions Abréviations Missions & Objectifs Missions Objectifs Gestion du Document SLA Limitation du périmètre Organisation Organisation du «Fournisseur» Organisation du «client» Comités et réunions de travail Comité de pilotage : COPIL Comite qualité Prestation Nature des maintenances Matrice de services Pénalités de retard Gestion des événements perturbant le projet Respect des normes Organisation de service - TMA au forfait Prise en compte du besoin Processus de prise en compte Description du processus Procédure de déclaration d une demande d assistance Traitement d une demande d assistance Processus de traitement d une demande d assistance Description du processus de traitement d une demande d assistance Maintenance corrective Support applicatif Maintenance évolutive mineure Organisation de service - TMA sur bon de commande Processus de conduite de projet Description de la conduite de projet Spécification technique des besoins Découpage du projet...20 Page 2/14

3 Suivi du projet Maintenance évolutive Découverte des nouvelles applications Gestion de la documentation Le dossier de projet La Documentation technique La documentation des demandes d assistance Phase de réversibilité Objectifs Tableau de charge Moyens et services concernés Lieu Les moyens techniques Les moyens humains Répartition des demandes d assistance Délimitation de la prestation Engagements du «Fournisseur» Conditions commerciales Prix et financement Bases économiques Termes et conditions de paiement...26 Page 3/14

4 1. Terminologie Ce chapitre correspond à un glossaire lié à ce document. Les définitions qui suivent ne sont ni universelles, ni exhaustives, mais sont celles utilisées pour ce document et son périmètre d application Définitions «Client» Définition présente dans les Conditions Générales de Vente (CGV) «Fournisseur» Définition présente dans les Conditions Générales de Vente (CGV) «Key user» Personne appartenant à l organisation du «client» autorisée à réaliser et à valider les tests applicatifs sur une application donnée. «Composant technique» On entend par «composant technique» tout dispositif ou correctif logiciel mis en place dans l application. «Module spécifique» Il s agit d'un composant technique constitué d un programme exécutable développé par le «fournisseur» conformément au Cahier des Spécifications préalablement accepté par le «client» et ayant fait l'objet d'une recette définitive, à l issue des tests prévus, attestant que tous les objectifs fixés entre les deux parties ont été atteints. «Documentation de description» Il s agit d un document décrivant la composition d une version de l application, par un inventaire exhaustif des composants techniques entrant dans sa composition. «Documentation d utilisation» Il s agit d un document décrivant l usage d une version de l application, par une description du rôle et du mode opératoire de chaque fonction. «Documentation d exploitation» Il s agit d un document décrivant les opérations courantes nécessaires au fonctionnement régulier d une version de l application, par une description du rôle et du mode opératoire de chaque procédure d exploitation ainsi que par sa planification. «Anomalie» C'est au sein d un lot une erreur de programmation, de paramétrage ou d installation, ou un défaut de réalisation par rapport au référentiel documentaire applicable. Les sources émettrices d anomalies précisent les caractéristiques de l anomalie en distinguant son type (Bloquant, Majeur et Mineur) et en la classifiant selon un critère de fréquence (Fréquent, Systématique, Aléatoire). «Anomalie bloquante» C'est une anomalie rendant le logiciel indisponible du fait de l'impossibilité de son utilisation ou de celle d'une fonctionnalité jugée critique ou essentielle. Une anomalie bloquante concerne essentiellement un problème technique (plantage, arrêt des traitements). «Demande d évolution» Souhait de faire évoluer le logiciel par rapport à son référentiel documentaire applicable. Cette demande est formalisée par le biais d une demande écrite (Fiche de fait technique). «Solution de contournement» Solution apportée à une anomalie permettant la poursuite des traitements mais sans résolution de la cause réelle de l anomalie, exemples : utilisation d une autre procédure de l application permettant d aboutir au résultat désiré, modification ponctuelle d un programme pour traiter spécifiquement un ensemble de données, modification ponctuelle d un fichier qui permet la poursuite des traitements ; «Solution définitive» Correction apportée à la cause réelle d une anomalie. Page 4/14

5 1.2. Abréviations AO : Appel d offre BL : Bon de livraison CDP : Chef de Projet du Fournisseur CGV : Conditions Générales de Vente CP : Conditions Particulières du Contat CPM : Chef de Projet «client» COPIL : Comité de pilotage LORI : Acronyme de Logiciel des Opérations de Résolutions des Incidents. Outil de suivi des demandes d assistance TMA. PVR : Procès Verbal de Réception TL : Temps de livraison UO : Unité d oeuvre TPC : Temps de prise en compte TR : Temps de résolution TRT : Temps de résolution total TMA : Tierce Maintenance des Applications SLA : Service Level Agreement. PAQM :Plan d assurance qualité maintenance. Terme Français correspondant à SLA. 2. Missions & Objectifs 2.1. Missions L'objet du document SLA est de préciser les dispositions prises par le «fournisseur» pour répondre aux exigences de qualité portant sur le service fourni dans la Tierce Maintenance des Applications (TMA) autour des applications confiées. Il contient les modalités d'exécution du service. Ce document décrit ou référence les méthodes, les processus, l'organisation, tant internes au «Fournisseur» que celles avec les interlocuteurs du «client», et plus particulièrement l'ensemble des dispositions prises par le «fournisseur» pour fournir des prestations d'assistance, de maintenance et de nouveaux développements autour des applications Lotus Notes confiées en répondant aux besoins de qualité requis par le «client» dans le cadre du contrat de TMA. Ce document répond aux besoins spécifiques de la TMA. On y trouve regroupées les informations et règles utiles aux intervenants du projet : l'organisation du projet, la démarche de réalisation, les méthodes, outils et règles, les principes liés à la gestion de la documentation, à la gestion de la configuration, les modalités de livraison, les actions de communication, les contraintes minimales de temps de réponses des applications, les dispositions générales et particulières prises dans le cadre du projet pour le respect des normes, cadre réglementaire, normatif ou autres dispositions générales, la définition et les modalités de calcul des indicateurs de suivi de qualité du service Page 5/14

6 2.2. Objectifs Ce document présente l ensemble des procédures minimum à respecter par les prestataires en charge du projet TMA. Ce document répond à un impératif de formalisation : Il permet de définir le rôle des différents intervenants et instances de suivi et contrôle du projet, Il permet de définir le cadre réglementaire, normatif ou autres dispositions générales que le projet et ses livrables doivent respecter, Il décrit les principaux circuits de communication entre les différents intervenants, Il définit les normes de documentation et met à disposition des documents et formulaires types utilisés dans le cadre de ce projet, Il définit le plan de communication afin de garantir la bonne acceptation et le bon usage du projet auprès des différentes familles d intervenants, Il définit les indicateurs de base permettant de mesurer la qualité de la prestation des équipes de réalisation du projet. Ce document a pour objectif de mettre en place les procédures et l organisation nécessaire qui permettra d accomplir les objectifs que s est fixés le «client» sur cette TMA, à savoir : Amélioration de la qualité du processus Amélioration de la qualité des applications Amélioration de la qualité de service Garantie de réversibilité de compétences vers les équipes «client» à tout moment 2.3. Gestion du Document SLA Ce document constitue le Plan d Assurance Qualité ou Service Level Agreement pour la Tierce Maintenance Applicative. Il est identifié par la référence : ADI-SLA- 1.0, Il est proposé par le «fournisseur» qui en est le rédacteur. Toute évolution du Service Level Agreement doit recevoir l accord des deux parties, formalisé par décision du comité de Pilotage ou du comité Qualité. Le document Service Level Agreement peut évoluer sur proposition du «Fournisseur» ou du «client». La ou les évolutions devront être acceptées et validées par les deux parties. Au minimum, une réunion de suivi qualité sera tenue par an. Lors de cette réunion, un point sera fait sur la nécessité de faire évoluer le document SLA ou les conditions particulières du contrat associé. Cette réunion sera planifiée avec l équipe projet du «client» par le Chef de projet du «Fournisseur» Limitation du périmètre Les limitations du périmètre sont définies dans les conditions particulières du contrat. Page 6/14

7 3. Organisation Ce chapitre a pour objet de fixer l organisation et les membres des équipes qui évolueront sur le projet Organisation du «Fournisseur» L offre de Support et de Tierce Maintenance Applicative du Fournisseur, est articulée autour de deux cellules : Une cellule de support (ou Hotline) Une cellule dédiée à la TMA du «client» La cellule de support, c est : 15 consultants expérimentés Un guichet unique pour l ensemble des technologies supportées par le «fournisseur» (ex : IBM, Microsoft, VMWare, Citrix, etc.) Un accès privilégié au plus haut niveau de support proposé par chacun des éditeurs et constructeurs 3500 appels par mois La garantie que tous les appels sont traités en temps et en heure La cellule TMA, c est : Une équipe d experts certifiés sur les technologies objet de la TMA L assurance d une réactivité maximum Des outils spécifiques de suivi et de gestion Un guichet unique sur le projet La cellule TMA, s appuie au quotidien, sur la cellule de support & maintien opérationnel pour optimiser la fiabilité des diagnostics en faisant appel à l ensemble des compétences techniques du «Fournisseur» (développement, infrastructure, matériel, etc). Cette organisation assurera au «client» une amélioration de la qualité du processus. En effet, la présence de ces deux équipes disponibles, assureront rigueur et simplicité dans le traitement des demandes d assistance du «client». Le «fournisseur» s engage à mettre à disposition une équipe de base stable et dont les compétences sont en rapport avec les prestations demandées. L équipe du «Fournisseur» est définie dans les conditions particulières du contrat Organisation du «client» Le «client» nomme un chef de projet qui sera l interlocuteur direct et unique du chef de projet «Fournisseur». Le «client» s engage à prévoir la disponibilité des bons interlocuteurs aux dates prévues dans le planning de façon à ce que les engagements contractuels et les objectifs de délais du projet soient tenus. L équipe des interlocuteurs «client» est définie dans les conditions particulières du contrat Comités et réunions de travail Ces différents comités et/ou réunions doivent permettre au «client» de vérifier l atteinte des 4 objectifs majeurs fixés dans le cahier des charges : Amélioration de la qualité des processus Amélioration de la qualité des applications Amélioration de la qualité du service Garantie de réversibilité de compétences vers le «client» à tout moment Page 7/14

8 Comité de pilotage : COPIL Un Comité de pilotage (COPIL) a lieu en fonction de la périodicité définie dans les conditions particulières du contrat. Il gère le contrat et ses évolutions et veille au bon déroulement des prestations. Il a un rôle opérationnel et il est unique pour toutes les Applications. Il veille au respect, par tous les acteurs, de l'ensemble des dispositions définies au contrat, par les conditions générales du contrat par le document SLA et par les conditions particulières du contrat. Son objectif est de garantir : Le bon déroulement des opérations Le respect général du contrat Une visibilité du plan de charge du projet de TMA La résolution des incidents dans une démarche d amélioration et de progrès Il doit répondre à deux attentes majeures du «client» : Amélioration de la qualité des applications Amélioration de la qualité de service Son rôle est de : Contrôler le fonctionnement global de la TMA (activités, risques, incidents, coûts) Définir l'évolution des besoins à moyen terme et la stratégie globale de la TMA Mesurer la satisfaction vis-à-vis de la prestation du titulaire Régler les situations exceptionnelles Prendre les décisions majeures Valider les devis et les avenants éventuels du contrat Analyser les tableaux de bord, graphiques et rapports de synthèse de la période en cours Suivre l avancement des prestations (compte rendu, planning, indicateurs, plan d actions) S assurer de l information et de la coordination des équipes Planifier et mettre en œuvre les changements décidés Préciser les évolutions majeures des applications et produits utilisés Analyser les problèmes rencontrés et aider à les résoudre (solution ou plan d actions) Valider le portefeuille et le planning des corrections issues des demandes et de leur mise en production Effectuer les arbitrages et définir les priorités Il est initialisé (composition et première réunion) suite à la réunion de lancement, lors de la phase d Initialisation. Les livrables : Rapport d activité Compte-rendu rédigé par le CDP «fournisseur». A défaut de réponse dans les 5 jours ouvrés, ce compte-rendu est réputé approuvé par le client. Une fois approuvé, le compte-rendu a un caractère contractuel. Les participants côté «client» Le responsable du marché Le chef de projet Les key users des applications à l ordre du jour Des invités selon l ordre du jour Les participants côté «fournisseur» Le chef de projet Le responsable de compte, si des validations ou présentation de devis sont à l ordre du jour Des invités selon l ordre du jour Lieu Dans les locaux du «client» ou du «fournisseur». Fréquence Page 8/14

9 Défini par les conditions particulières du contrat. Un de confirmation sera envoyé au Responsable de projet «client» par le responsable de projet «fournisseur», deux semaines à l avance avec l ordre du jour et les participants souhaités Comite qualité Un comité qualité aura lieu périodiquement (fréquence précisée aux CP). Le rôle de ce comité qualité est de : Vérifier le respect par les différents acteurs du document SLA Décider des évolutions du document SLA et ou des conditions particulières dans une démarche d amélioration du service Présentation du calcul des pénalités de retard Présentation des enquêtes de satisfaction Mesurer l amélioration de la qualité du processus Vérifier et mesurer la qualité de la documentation afin de garantir la réversibilité des compétences vers les équipes «client» à tout moment Les demandes d évolutions seront présentées par le Responsable Qualité du «fournisseur». Ces demandes devront lui être transmises 15 jours avant la tenue du comité par les différents chefs de projet. Documents en sortie : Nouvelle version du document SLA. A défaut de validation dans les 5 jours ouvrés, la nouvelle version du PAQM est réputée approuvée par le «client». Document de calcul des pénalités de retard Enquête de satisfaction Les participants côté «client» Le chef de projet Le responsable qualité Le responsable du marché, si nécessaire Les participants côté «fournisseur» Le chef de projet Le responsable qualité Le responsable de compte, si nécessaire Lieu Dans les locaux du «client» ou de «fournisseur». Fréquence Au début du 12 ème mois de l anniversaire du contrat. Un de confirmation sera envoyé au Responsable de projet «client» par le responsable qualité «fournisseur». Page 9/14

10 4. Prestation 4.1. Nature des maintenances Ce chapitre présente les différentes typologies de maintenance que l on pourra trouver au cours de la TMA, ainsi que leur champ d application. UO 1 Phase d initialisation L objectif principal lors de la phase d initialisation de la T.M.A. est d assurer la prise de connaissance technique et fonctionnelle de l existant, à savoir les applications décrites dans les conditions particulières du contrat. UO 2 Maintenance corrective / Support applicatif Les prestations de maintenance corrective portent sur des interventions de type correctif dans les environnements de production. Ces interventions consistent à corriger toute anomalie de fonctionnement détectée dans les programmes, la documentation, et autres composants de l'application. Cette UO comporte également les aspects de support applicatif (voir 6.4) que la cellule TMA dispensera aux key users. Cette maintenance se fait de manière forfaitaire. UO 3 Maintenance évolutive Les demandes de maintenance évolutive sont soumises par la remise d un cahier des charges de la part du «client» au «fournisseur». Cette maintenance se fait sur bon de commande. UO 4 - Maintenance évolutive mineure Ce sont les demandes de maintenance évolutive dont la charge de travail est inférieure ou égale au nombre de jours défini dans les conditions particulières du contrat. Cette maintenance se fait de manière forfaitaire. UO 5 Phase de réversibilité Il s agit de définir les conditions dans lesquelles le «fournisseur» organise le transfert de compétences vers toute personne habilitée par le «client», afin de leur permettre de poursuivre la maintenance de l application au même niveau de qualité. Ces différentes natures de maintenance mettent en évidence deux types contractuels de maintenance : TMA au forfait TMA sur bon de commande 4.2. Matrice de services Chaque application peut être dotée d un niveau de criticité. De plus, chaque demande d assistance (DA) fera également l objet d une qualification sur son niveau de gravité. Ces deux paramètres permettent d établir la matrice de service présentée dans les conditions particulière du contrat Cette matrice de service permettra de fixer les différents délais à mesurer de la prise en compte à la résolution totale d un incident dans le cadre de la maintenance corrective. Pour garantir au «client» le respect de ces différents délais et la qualité des réponses apportées, deux organisations de services seront mises en place : Organisation de services pour la TMA au forfait Organisation de services pour la TMA sur bon de commande Page 10/14

11 4.3. Pénalités de retard Lorsque la résolution d une demande d assistance ne satisfera pas les objectifs fixés dans la matrice de services, un calcul des pénalités de retard pourra être demandé par le «client» lors d un Comité de pilotage. Le «fournisseur» s engage sur un système de pénalités basé sur le délai de livraison du correctif. Ce délai possède également l avantage de simplifier les responsabilités en cas de dépassement du délai. De plus, cet engagement montre également la volonté du «fournisseur» de s engager fortement dans une démarche de qualité et de respect des engagements dans ce projet de TMA. Ces pénalités sont appliquées par catégorie de pénalité (4 catégories : catégorie 1, 2, 3, 4) selon le tableau ci-dessous : Délai de livraison du correctif ou de la solution de contournement Type d incident Niveau de criticité de l application Bloquante Majeure Mineure Bloquant Majeur Mineur Méthode de calcul : Chaque DA est comptabilisée par catégorie de pénalité Si plus de 80% des DA pour une catégorie de pénalité donnée ont été réalisés en conformité avec la matrice de services alors aucune pénalité ne sera demandée par le client. Le montant de la pénalité par catégorie sera de 2,5 % du montant total HT du contrat (hors montant relevant d heures de télé consulting ou de journées prépayées). Fréquence de mesure : Annuelle Date de début d application des pénalités : Les 3 premiers mois de la TMA seront sans application de pénalités. La 1ère année, il est entendu que la première mesure sera effectuée sur 9 mois à l issue de la période sans pénalité Gestion des événements perturbant le projet Le «fournisseur» a mis en place au sein de sa cellule de support, une mécanique de déclenchement d alerte et d escalade au travers d une fonction : Le manager de supervision. Cette personne a pour fonction, au travers des outils utilisés par la cellule Support et la cellule TMA du «fournisseur», de surveiller l avancement mais surtout le respect des délais sur chaque déclaration d incidents. Cette fonction permet de surveiller en permanence les facteurs qualités afin de garantir le respect des engagements auprès du «client». Cette surveillance, dans le cas de la TMA s opère sur trois niveaux : Le respect du temps de prise en compte d une DA (voir processus de prise en compte) Le respect du temps de livraison d un correctif sur une DA Le respect du temps de correction totale d un DA Ce processus automatique d escalade prévoit les points suivants : Une DA est déclarée par le «client» auprès de la cellule support ; Si bloquante, le manager de supervision affecte directement la DA à une personne de la cellule TMA ; Si majeure ou mineure, le manager de supervision sera alerté automatiquement par si une heure avant l échéance, la DA n a toujours pas été prise en compte. A ce moment-là, c est le manager de supervision qui affecte la DA à une personne de la cellule TMA ; Si personne n est disponible, la DA est affectée au chef de projet ; Page 11/14

12 Si le chef de projet n est pas disponible, une alerte est remontée au Responsable Qualité de la TMA pour action immédiate et information au client de la situation ; Une fois la DA affectée, le manager de supervision prend en charge le suivi des autres mesures ; Comme pour le suivi de la prise en compte de la DA, une escalade à deux niveaux est prévue, une première auprès du chef de projet et une seconde auprès du responsable qualité ; Ces alertes sont déclenchées en fonction des objectifs de la matrice de services ; Le manager de supervision a à sa disposition, un tableau de bord en temps réel qui lui permet de surveiller ces différents objectifs. En complément de ce dispositif d escalade automatique, le «client» pourra à tout moment déclencher une procédure EVENEMENT auprès du Responsable Qualité pour signaler un dysfonctionnement dans le déroulement de la TMA. A réception de cette procédure EVENEMENT, une analyse sera faite par le Responsable Qualité sur le dysfonctionnement signalé. Dans les 2 jours ouvrés suivant le déclenchement de la procédure EVENEMENT, le Responsable Qualité s engage à revenir vers le Chef de projet «client» avec un plan d action visant à corriger le dysfonctionnement. Afin de faciliter le déclenchement de ce type de procédure, un simple du chef de projet «client», mentionnant en objet FICHE EVENEMENT à destination du Responsable Qualité «fournisseur» suffira. Cet devra au minimum contenir les informations suivantes : Dysfonctionnement technique, contractuel ou relationnel Le ou les applications concernées, si nécessaire Une description précise du dysfonctionnement Une description précise de l attente 4.5. Respect des normes Les contraintes concernant le respect de certaines normes devront être décrites dans les conditions particulières du contrat. 5. Organisation de service - TMA au forfait 5.1. Prise en compte du besoin La demande d assistance est matérialisée par une action de la part du «client». Cette action peut se faire sous la forme d un appel téléphonique, de l envoi d un mail à la cellule support ou d une déclaration sur notre outil de suivi LORI au moyen d un accès Internet sécurisé. Le numéro de contrat d assistance devra être précisé quel que soit le moyen utilisé. La demande d assistance sera prise en compte du lundi au vendredi de 8h30-09h00 à 18h00-18h30 selon le niveau de maintenance retenu (hors jours fériés). Page 12/14

13 Processus de prise en compte Page 13/14

14 Description du processus Chaque demande d assistance, téléphonique ou , fait l objet de l ouverture d un dossier d appel (log) dans l outil de suivi des demandes d assistance du «Fournisseur». Ce dossier est affecté ensuite à la cellule TMA. Ce dossier d appel contient : La date et heure de la demande L objet de la demande L urgence de la demande Le nom du demandeur Une fois affecté à la cellule TMA, ce dossier d appel est converti en déclaration d incident dans l outil LORI du «Fournisseur» et affecté immédiatement à une ressource de la cellule, qui devient le responsable de l incident. Le responsable de l incident va : Catégoriser l incident Affecter, à l aide de la matrice de service, un degré de criticité et de priorité. Affecter un statut de prise en compte à l incident. Estimer le temps de correction et de livraison L de prise en compte est alors envoyé au demandeur. L incident rentre alors dans la file d attente de traitement. Afin de faciliter et réduire la charge dans les phases de tests, l incident pourra être intégré à un lot regroupant d autres incidents sur la même application afin de n effectuer qu une batterie de tests lors de la livraison Procédure de déclaration d une demande d assistance Le «client» devra suivre les procédures de déclaration de demande d assistance suivantes auprès du «Fournisseur» Par téléphone : Appeler le (Cellule Support du «Fournisseur») Indiquer à la personne du support son identité et préciser que l appel est dans le cadre de la «TMA» Indiquer le nom de l application pour laquelle il appelle Indiquer de manière claire et synthétique la description de son problème Indiquer si son problème est reproductible (dans le cadre de la maintenance corrective) : Toujours / Parfois sous condition connue / De manière aléatoire / jamais Indiquer la priorité du sa demande (Critique / Majeure / Mineure) NB : Dans la cadre de demande de support, il devra indiquer s il souhaite être rappelé ou contacté par . NB2 : Seuls les Key users (ou leur suppléant) pourront ouvrir des demandes d assistance Par Rédiger un à destination de : tma@grouperdi.com Indiquer en objet, le nom de l application (utiliser les abréviations décrites en page 10) et la criticité (Critique / Majeure / Mineure) de la demande en utilisant la convention suivante : o [nom de l application] criticité de la demande o Ex : [SAV]Mineure Dans le corps de l , indiquer de manière claire et synthétique la description de son problème, y ajouter si possible des impressions écrans ou tous documents pouvant étayer ses explications Indiquer également si son problème est reproductible (dans le cadre de la maintenance corrective) : Toujours / Parfois sous condition connue / De manière aléatoire / jamais NB : Dans la cadre de demande de support, il peut indiquer dans son s il souhaite être rappelé. Si aucune indication n est faite, alors il recevra une réponse par ). Par LORI (Web) : Se connecter à l adresse suivante : Page 14/14

15 NB : Un manuel utilisateur LORI est disponible dans LORI ou sur simple demande par à tma@grouperdi.com 5.2. Traitement d une demande d assistance Processus de traitement d une demande d assistance Page 15/14

16 Suivi des demandes Rapporteur Développeur / Chef de projet Rapporter demande Etat = nouveau Analyser demande Ajout de commentaire client Si besoin compléments Changer l état en En pause Etat = En pause Si ok Etat = en pause Changer l état en pris en charge Changer l état en pause Etat = pris en charge Si ok Si non ok Analyser proposition solution Si ok Changer l état en en traitement Etat = Non résolu Réouvrir demande Si non ok Etat =en traitement Changer l état en livré Etat = livré Tester Changer l état en recette Si ok Etat = recette Changer l état en fermé Etat = fermé Description du processus de traitement d une demande d assistance Page 16/14

17 Une fois la prise en compte réalisée, le processus de traitement de la demande démarre. Toutes les phases de ce traitement, qui sont décrites dans le processus précédent, sont enregistrées et consultables pour tous les acteurs du projet dans l outil LORI, dont des accès par web seront fournis au «client». Une fois le correctif développé et testé en environnement de développement, l équipe IT du «client» est informée par un de la cellule TMA de la livraison du correctif. Cet fera référence au n de déclaration, à l application concernée et contiendra la procédure d installation. Le key user de l application est ensuite informé de la livraison du correctif sur la plateforme de qualification par l équipe IT du «client». Le key user procède aux tests et en donne les résultats dans LORI. Si les tests sont concluants l incident est fermé. Dans le cas contraire une nouvelle note sera ajoutée dans la déclaration d incident et le key user passera la demande en «Non Résolu». Le fait de marquer chaque étape du traitement des demandes d assistance permettra aux chefs de projet de produire des indicateurs de mesure de la qualité du service Maintenance corrective Les prestations de maintenance corrective portent sur des interventions de type correctif dans les environnements de production. Ces interventions consistent à corriger toute anomalie de fonctionnement détectée dans les programmes, la documentation, et autres composants de l'application. La maintenance corrective consiste à prendre en charge l intégralité des anomalies de fonctionnement de l application et à apporter des solutions adéquates selon le processus suivant. Acteurs Action Temps de résolution Client Qualification par le «client» du niveau de gravité de l anomalie constatée : Bloquant, Majeur, Mineur Client Déclaration de la demande d assistance par le «client» au «fournisseur» Début du décompte du TPC* Fournisseur Confirmation de la prise en compte de l incident et de sa qualification Fin du décompte du TPC Début du décompte du TL** Début du décompte du TRT*** Fournisseur Identification des causes du problème, formalisation d un diagnostic ainsi que d une ou des solutions Fournisseur Mise en œuvre de la correction, test unitaire et de non-régression en environnement de développement Fournisseur Livraison des correctifs et de la procédure d installation. Cette livraison est Fin du décompte du TL assortie d'un PV de réception. Client Installation des correctifs dans l environnement de qualification Client Test des correctifs sur la plate-forme de qualification Client Recette fonctionnelle et validation du correctif (Validation du PVR) Fournisseur Clôture de l incident dans LORI Fin du décompte du TRT Client Installation du correctif dans l environnement de production Fournisseur Conseil et assistance lors des tests dans l environnement de qualification et de production Fournisseur Mise à jour de la documentation technique *TPC : Temps de prise en compte **TL : Temps de livraison *** TRT : Temps de résolution total La prise en charge de l anomalie, la livraison du correctif (1) ainsi que la résolution définitive de l anomalie (1)(2) (en dehors des délais de validation par le «Client») devront respecter les délais liés à la gravité de l anomalie. (1) Hors temps de pause (2) Le délai de résolution définitive hors délais de validation client correspond au délai de dernière livraison. Le décompte du délai imparti au «Fournisseur» pour résoudre une anomalie ne court que pendant les jours et heures ouvrables soit du lundi au vendredi de 9h à 18h. Page 17/14

18 S il ne peut être procédé immédiatement à la correction des applications, une solution de contournement peut être proposée au «client» et mise en œuvre avec son accord. Livrable(s) : les composants de la version corrigée de l application documentation d installation PV de réception 5.4. Support applicatif En complément de la maintenance corrective, le «fournisseur» se propose de réaliser un support applicatif de niveau 2 aux équipes en charge de la TMA côté «client». En effet, l expérience du «fournisseur» sur ce type de TMA montre que très souvent les demandes d anomalies sont des «faux», à savoir, plus un manque de connaissance des capacités de l application qu un problème technique nécessitant une résolution. En intégrant ce type de support dans le forfait de la TMA, le «fournisseur» s engage aux côtés du «client» pour aider au mieux les utilisateurs clés du «client» dans l utilisation de ses applications. Ce support peut par exemple : Mettre à contribution un développeur pour réaliser une analyse du code afin de savoir si l application peut répondre à telle ou telle demande. Aider un key user dans des problèmes fonctionnels de validation d étapes sur un workflow. Assister un key user sur la mise en place de nouveaux processus fonctionnels au sein d une application etc. Ce support applicatif, comme la maintenance corrective, sera suivi au travers d indicateurs opérationnels et d indicateurs de pilotage Maintenance évolutive mineure Les demandes de maintenance évolutive mineure sont soumises par la remise d une expression du besoin au CDP. Après étude du besoin et questions éventuelles au «Client», la demande est qualifiée techniquement et quantifiée au niveau de la charge. Si la charge est estimée supérieure au nombre de jours défini dans les conditions particulières du contrat, alors la demande est basculée en Maintenance évolutive. Tous ces éléments sont repris dans un document de spécifications techniques des besoins qui sera envoyé au «client» pour validation. Après accord du STB, les demandes d évolution mineure font l objet d un processus allégé : Définition d un planning de réalisation en accord avec le «Client» Réalisation des développements, test unitaire sur environnement de développement Livraison, tests sur l environnement de qualification par le «client» Recette et validation du PVR par le «client» Installation sur l environnement de production par le «client» Remise de la documentation Eléments pris en compte dans le calcul de la charge : Analyse du besoin Rédaction du STB Développements Tests sur environnement de développement Documentation Page 18/14

19 6. Organisation de service - TMA sur bon de commande Dans cette partie de la TMA, la prise en compte se fait par le chef de projet, lors de la réception d un cahier des charges. Ce cahier des charges fait l objet d une étude par la cellule TMA et le chef de projet envoie au client une proposition commerciale sur la réalisation demandée. L organisation mise en place pour répondre, est une organisation classique de gestion de projet avec des phases claires et précises, du cahier des charges à la réception définitive Processus de conduite de projet Page 19/14

20 6.2. Description de la conduite de projet Spécification technique des besoins Les spécifications techniques des besoins sont un document d interprétation technique de la proposition commerciale réalisée en début de projet. Il constitue un document contractuel d enrichissement de la proposition commerciale. Il permet de : Bien cadrer le projet technique, en accord avec la proposition commerciale Détailler les UO de réalisation Fixer un planning sur le projet C est le document de référence, pour le «client» et pour le «Fournisseur», pour justifier de la bonne réalisation et du périmètre du projet. A l issue des STB, des éléments non détectés dans la proposition commerciale peuvent être identifiés. La conséquence peut être la modification des UO du planning et peut être aussi des modifications du contrat si nécessaire Découpage du projet Le projet est découpé en «Phases», représentant les grandes étapes du projet (Infrastructure, Gestion, Développement). Chacune de ces phases est découpée en «Unité d Œuvre» (UO). Ces UO définissent un ensemble de tâches cohérentes pouvant être recettées ensemble ou indépendamment des autres. Ce découpage permet d avoir tout au long du projet des points de livraisons intermédiaires qui permettent un suivi concret de l avancement du projet. Chaque livraison fait l objet d un PV de réception sur l UO concernée. Exemple : Phase : Développement d'un workflow de demande de congés UO 1 : Développement du workflow UO 2 : Développement du moteur de déversement des congés dans l outil RH UO 3 : Développement d un intranet de consultation des soldes de congés UO 4 : Test et Validation solution finale Suivi du projet Un chef de projet est nommé sur chaque dossier. Il est l interlocuteur unique pour le «client» sur le dossier en question. Il coordonne l ensemble des pôles services du «Fournisseur» amenés à intervenir. Des comptes rendus réguliers sur l avancement du projet seront fournis aux membres du comité de pilotage (document écrit transmit par ), accompagnés de réunions téléphoniques si nécessaire. Des réunions seront effectuées avec le «client». Leurs fréquences seront définies en fonction des besoins de chaque partie et du planning projet (validation UO, besoin spécifique, etc.). Ces réunions seront des comités de pilotage, elles s effectueront en présence du «client». A l issue de chaque réunion un compte rendu sera rédigé par le chef de projet du «Fournisseur» et transmis sous un délai de 3 jours aux membres du comité de pilotage Maintenance évolutive Les demandes de maintenance évolutive sont soumises par la remise d un cahier des charges. Après étude du cahier des charges, et questions éventuelles au «Client», le «Fournisseur» soumet une proposition financière. Les délais de remise de ces devis sont variables selon la complexité des demandes : Evolution simple : sous 2 jours Evolution moyenne : sous 3 jours Page 20/14