itil les bonnes pratiques

38
La pratique Centre de services et processus associés Création : novembre 2008 Mise à jour : août 2009

Upload: karimtika

Post on 29-Jun-2015

584 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: ITIL les bonnes pratiques

La pratique

Centre de services et processus associés

Création : novembre 2008 Mise à jour : août 2009

Page 2: ITIL les bonnes pratiques

2

A propos

A propos du document Ce document pratique est le résultat de la mise en oeuvre du référentiel ITIL et d'autres référentiels dans des directions informatiques en France au travers des missions qui me sont confiées depuis 2004. Il est mis à la disposition de la communauté francophone ITIL pour diffuser quelques conseils et notes sur le passage souvent délicat de la théorie à la mise en pratique de ces référentiels. Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).

A propos de l'auteur Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en oeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production. Ces projets requièrent :

la connaissance des différents métiers du développement et de la production informatique

la pratique de la conduite de projets techniques de la direction informatique

la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter les méthodes de travail au sein de la direction informatique

A propos de mission et de formation

Si vous pensez que l’expérience de l’auteur sur le référentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, n’hésitez pas à le contacter pour toute question ou demande :

par mail : [email protected]

par téléphone : +33 (0)6 61 95 41 40 Quelques exemples de mission :

Modélisation simple des processus de gestion des changements, des projets et des mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances

Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL

Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL

Page 3: ITIL les bonnes pratiques

3

Sommaire 1 La situation sans centre de services ............................................................................................................... 6

1.1 Sans centre de services ni processus : le chaos ..................................................................................... 6 1.2 Situations courantes vue des utilisateurs et clients .................................................................................. 6 1.3 Situations courantes vue des équipes informatiques ............................................................................... 6

2 Objectifs, périmètre, activités, valeur ajoutée .................................................................................................. 7 2.1 Objectifs ................................................................................................................................................. 7 2.2 Le fournisseur de services dans son ensemble fournit des services ........................................................ 8 2.3 Périmètre du centre de services............................................................................................................ 10 2.4 Activités de base .................................................................................................................................. 10 2.5 Valeur ajoutée ...................................................................................................................................... 11

2.5.1 Pour le fournisseur de services ..................................................................................................... 11 2.5.2 Pour les utilisateurs et clients ........................................................................................................ 11

3 Modes réactif et pro-actif ............................................................................................................................... 11 3.1 Traitement en mode réactif ................................................................................................................... 11 3.2 Traitement en mode pro-actif ................................................................................................................ 12

4 Les différents types de centres de services ................................................................................................... 12 4.1 Les structures possibles de centre de services ..................................................................................... 12

4.1.1 Les différentes appellations du contact central .............................................................................. 13 4.1.2 Maturité d’un centre selon son appellation ..................................................................................... 13

4.2 Le centre de services local ................................................................................................................... 13 4.3 Le centre de services central ................................................................................................................ 14 4.4 Le centre de services virtuel ................................................................................................................. 15

5 Le centre de services et la gestion des incidents ........................................................................................... 16 5.1 Le processus de gestion des incidents .................................................................................................. 16 5.2 Pourquoi une classification des incidents ? ........................................................................................... 16 5.3 Assignation à un groupe de support ...................................................................................................... 16

5.3.1 Etape 1 : Identifier l’équipe de support concernée ......................................................................... 17 5.3.2 Etape 2 : Identifier le délai de résolution global .............................................................................. 18 5.3.3 Etape 3 : Identifier le délai de résolution interne (groupe de support) ............................................. 18

5.4 Escalader au niveau 3 .......................................................................................................................... 19 5.5 Indicateurs de performance de la fonction centre de services................................................................ 20

6 Le centre de services et l'exécution des requêtes .......................................................................................... 21 7 Le centre de services et la mise en place des SLA et OLA ............................................................................ 21

7.1 Approche préconisée ............................................................................................................................ 21 7.2 Partir aussi des SLR pour établir les OLA ............................................................................................. 22 7.3 Elaboration des OLA pour confrontation avec les SLR .......................................................................... 22

8 L'outillage du centre de services, le Self-Help................................................................................................ 23

8.1 Les technologies utilisées dans un centre de services........................................................................... 23

Page 4: ITIL les bonnes pratiques

4

8.2 Bénéfices d'un centre de services outillé ............................................................................................... 23 8.3 Stratégie de libre-service (Self-Help) : les facteurs critiques de succès ................................................. 23

9 Implantation .................................................................................................................................................. 24 9.1 Points clés à vérifier ............................................................................................................................. 24 9.2 Problèmes potentiels ............................................................................................................................ 24 9.3 Lignes de conduite ............................................................................................................................... 24 9.4 Facteurs critiques de succès................................................................................................................. 25 9.5 Support 24/24 ou mondial ..................................................................................................................... 25 9.6 Profil du personnel de support .............................................................................................................. 25 9.7 Attitude du personnel de support .......................................................................................................... 25 9.8 Sous-traiter le centre de services .......................................................................................................... 26

10 Indicateurs et rapports .............................................................................................................................. 26 10.1 Tous les jours : (état des incidents/problèmes vs SLA).......................................................................... 26 10.2 De manière hebdomadaire :.................................................................................................................. 26 10.3 De manière mensuelle .......................................................................................................................... 26 10.4 Sur demande et pro-activement ............................................................................................................ 27

11 Liste des sous-projets identifiés ................................................................................................................ 27 11.1 Processus simplifié de gestion des incidents ......................................................................................... 27 11.2 Processus de gestion du catalogue de services .................................................................................... 27 11.3 Processus d’exécution des requêtes ..................................................................................................... 27 11.4 Processus de gestion des niveaux de service ....................................................................................... 27 11.5 Processus de gestion des problèmes : définition simplifiée ................................................................... 28 11.6 Mise en place du centre de services ..................................................................................................... 28 11.7 Formation/sensibilisation des utilisateurs : promotion du centre de services .......................................... 28 11.8 Formation/sensibilisation en interne : promotion du centre de services et des processus associés ........ 28 11.9 Transfert de compétences du Help Desk actuel vers l’interne ou un autre sous-traitant ......................... 28

12 Le processus de gestion des incidents ..................................................................................................... 29 12.1 Le processus ITIL ................................................................................................................................. 29 12.2 Synoptique simplifié du processus ........................................................................................................ 29 12.3 Activité : Réceptionner et enregistrer la requête .................................................................................... 30 12.4 Activité : Classifier la requête ................................................................................................................ 30 12.5 Activité : Fournir le diagnostic initial et rétablir le service ....................................................................... 30 12.6 Activité : Clôturer la requête .................................................................................................................. 31 12.7 Activité : Communiquer l’état d’avancement de la requête..................................................................... 31 12.8 Communiquer des informations relatives aux services et niveaux de service ......................................... 31 12.9 Activité : Superviser la gestion des requêtes et escalader ..................................................................... 32 12.10 Description de l’organisation actuelle ................................................................................................ 32 12.11 Rôles et organisation ........................................................................................................................ 32

13 Le processus d'exécution des requêtes .................................................................................................... 33 13.1 Synoptique simplifié du processus ........................................................................................................ 33 13.2 Activité : Valider la demande de service ................................................................................................ 33

Page 5: ITIL les bonnes pratiques

5

13.3 Activité : Identifier et exécuter la procédure appropriée ......................................................................... 34 14 Le processus de gestion des problèmes ................................................................................................... 34

14.1 Synoptique simplifié du processus ........................................................................................................ 34 14.2 Activité : Superviser les problèmes et les erreurs .................................................................................. 34 14.3 Activité : Traiter le problème ................................................................................................................. 34 14.4 Activité : Traiter l’erreur ......................................................................................................................... 34 14.5 Activité : Gérer pro-activement les problèmes ....................................................................................... 35

15 Rôles et profils identifiés et liens avec l’organisation ................................................................................. 35 15.1 Récapitulatif des rôles identifiés ............................................................................................................ 35 15.2 Démarche de regroupement des rôles en profils et associations avec l’organisation ............................. 35 15.3 Profil de responsable du centre de services .......................................................................................... 35 15.4 Profil de technicien du centre de services ............................................................................................. 35

16 Catalogue de services - Exemple/Modèle de fiche service ........................................................................ 36 17 Catalogue de services - Exemple de fiche demande de service ................................................................ 38

Page 6: ITIL les bonnes pratiques

6

1 La situation sans centre de services

1.1 Sans centre de services ni processus : le chaos

Les symptômes d'un fonctionnement sans centre de services comme point d'entrée unique de la direction informatique ni les processus dans lesquels intervient le centre de services sont les suivants :

Des points d'entrée multiples, les utilisateurs ayant appris à connaître les numéros de poste des personnes qui peuvent les renseigner et les aider (il existe même parfois des échanges entre utilisateurs de ce type d'information, une personne de l'informatique ayant "gentiment" résolu un incident peut ainsi connaître une certaine notoriété)

Des échanges entre équipes informatiques non formalisées empêchant de reproduire un enchaînement d'actions ayant conduit au résultat demandé (niveau 0 de CMM-I : le chaos)

La communication vers les utilisateurs est aussi désordonnée et provient de multiples sources à l'informatique (chacun ayant besoin de communiquer une information aux utilisateurs dans le cadre de ses activités le fait sans se poser de question)

1.2 Situations courantes vue des utilisateurs et clients Manque de confiance du client, mauvaise image

Mode « pompier » permanent

Répétitivité des incidents similaires

Incapacité à soutenir les évolutions du métier

Mauvaise qualité des réponses et délais

Pas de point de contact clair

Moyens de contourner ce point de contact

Réponse multiple, non vérifiée (… lorsqu'il y en une !)

1.3 Situations courantes vue des équipes informatiques Appels tous azimuts des utilisateurs

Mécanisme de support absent ou mal structuré

Manque de management des ressources de support

Mode « pompier » permanent

Page 7: ITIL les bonnes pratiques

7

Répétitivité des incidents similaires

Travail haché, interruptions permanentes

Activité trop dépendante des individus

Manque de coordination des changements

Surdimensionnement des équipes de support

Besoins en ressources et budgets peu clairs

Manque d’informations de pilotage, décisions empiriques

Pas de suivi des demandes de service

2 Objectifs, périmètre, activités, valeur ajoutée

2.1 Objectifs Le centre de services et le point de contact unique des utilisateurs (et point de contact des clients) eur permettant de savoir, par exemple :

Quand receront-ils une réponse à leur requête ?

Planning de déplacement ou d'installation de matériel

Date planifiée d'une nouvelle mise en production

Si la demande d'amélioration de service a été acceptée

Où obtenir plus d'informations sur un sujet donné

Si les systèmes seront disponibles les week-ends

Faciliter le retour à la normale d'un service avec un minimum d'impact sur le métier et en accord avec les SLA (Service Level Agreement ou convention de niveau de service) négociés et les priorités d'affaires

Enregistrer et gérer toutes les données sur le TCO (Total Cost of Ownership ou coût total de possession) et les besoins des utilisateurs

Le centre de services est une fonction et non un processus. Ceci veut dire que les personnes du centre de services jouent un rôle dans les activités de certains processus. Par exemple, un "gestionnaire d'incidents" intervenant dans le suivi des incidents dans le processus du même nom peut faire partie du centre de services (la question : "dois-je d'abord mettre en place un centre de services ou le processus de gestion des incidents" n'a pas de sens, le centre de services étant le principal acteur du processus des incidents). Avec un centre de services et les processus associés : efficacité et efficience :

Page 8: ITIL les bonnes pratiques

8

2.2 Le fournisseur de services dans son ensemble fournit des services

Par le biais d'applications (systèmes d'informations) basées sur des infrastructures informatiques (serveurs, réseaux, bases de données, etc.), le tout hébergé et géré par des infrastructures techniques (salles informatiques avec climatisation, puissance électrique, etc.), le fournisseur de services dans son ensemble fournit des services aux utilisateurs qui les emploient pour faciliter et automatiser certaines opérations métiers. Le fournisseur dans son ensemble est constitué par les équipes internes de la direction informatique et des fournisseurs externes qui gèrent et exploitent les différents actifs de configuration (applications, infrastructures informatiques et industrielles, etc.) pour fournir les services destinés aux utilisateurs (qui y trouveront l'utilité prévue du service par rapport à leurs activités) avec une garantie convenue avec les organisations métiers (niveau de service). Les différentes équipes interviennent sur les actifs de configuration au travers d'activités formalisées par des processus (la plupart sont des processus ITIL) : mises en production, exécution des requêtes (demandes de service, demandes de travaux, etc.), traitement des incidents, projets de changement, etc. :

Page 9: ITIL les bonnes pratiques

9

Face à la complexité des composants des services auxquels les utilisateurs accèdent, et aussi face à la complexité du fonctionnement des équipes et des sociétés extérieures du fournisseur de services, les utilisateurs doivent avoir un point de contact pour demander des renseignements, des actions spécifiques et pour signaler des dysfonctionnements dans les services utilisés. De nos jours, personne (ou presque), ne penserait acheter un produit dans un magasin où aucun service après-vente n'existe et où on ne sait pas à qui demander des renseignements. Il faut la même approche dans son entreprise où je dois pouvoir contacter un S.A.V. à l'informatique dès qu'un souci se présente. Je dois aussi connaître le catalogue de ce qui est fourni par l'informatique (les produits étant immatériels, il n'est pas possible d'aller les examiner dans un magasin ; les sites de vente en ligne sur internet présente un catalogue des produits qu'ils vendent et cela est une bonne image du catalogue des services informatiques). Ce point de contact unique est le centre de services :

Page 10: ITIL les bonnes pratiques

10

Je dois pouvoir le contacter pour tout incident, plainte, remarque, demande d'information, demande de conseil, demande de service (ou de travaux) prévu au catalogue. En retour, j'attends de la part du centre de services qu'il me tienne au courant de l'avancement de mes demandes, des arrêts de service planifiés ou toute information sur des événements (prévus ou non) qui impacte ou impactera mes activités par une indisponibilité des services que j'utilise dans mon travail. Pour que tout cela fonctionne, je dois aussi être au courant du niveau de service proposé (et qui a été convenu avec ma hiérarchie, autrement dit, un client). Ce dernier travaillera avec la direction informatique pour définir les exigences de niveaux de service et négociera avec la direction informatique des niveaux de service effectifs. Ce travail sera fait avec l'équipe informatique chargée de la gestion des niveaux de service, au sein d'une entité que l'on pourrait appeler "Relations Clients" qui engloberait aussi le centre de services :

Lors de tout contact au centre de services, ce dernier se basera sur l'accord de niveau de service (SLA ou Service Level Agreement) pour définir la gestion de cette demande et la coordination des interventions des autres équipes si besoin. Les autres équipes interviennent sous le pilotage des accords de niveau opérationnel (OLA ou Operational Level Agreement) et les contrats de sous-traitance (UC ou Underpinning Contract), en cohérence avec le SLA sur le service concerné par la demande. Ainsi, pour qu'un centre de services fonctionne un minimum, il faut avoir mis en place un minimum du processus de gestion des niveaux de services.

2.3 Périmètre du centre de services Il est le déclencheur naturel du processus de gestion des incidents et, a minima, intègre le premier niveau de celui-ci. Dépendant des moyens mis en œuvre, il peut être global, par métiers, par composantes d'infrastructure, par régions, etc. Dans tous les cas, il est souhaitable d'avoir une structure d'accueil unique qui peut passer le témoin à des centres de services dédiés.

2.4 Activités de base Recevoir les appels et servir de contact clients

Enregistrer et suivre les incidents, requêtes, plaintes,…

Page 11: ITIL les bonnes pratiques

11

Gérer le cycle de vie des incidents, requêtes, plaintes,… incluant leur clôture et la vérification auprès de l’utilisateur de leur résolution ou traitement

Informer les clients de l'avancement des incidents, requêtes, plaintes,…

Incidents : Exécuter le 1er cycle de résolution ou transmettre à qui pourra le faire selon les SLA négociés

Incidents : Suivre et appliquer les procédures d'escalade prévues dans les SLA

Incidents : Superviser les groupes de support de niveau 2 et externes

Communiquer les changements de service et de niveaux de service planifiés et à court terme

Mettre à disposition des données de gestion et faire des recommandations d'amélioration des services

Identifier ou contribuer à l'identification des problèmes

Mettre l'accent sur les besoins de formation et d'apprentissage des clients

Effectuer des enquêtes de satisfaction

2.5 Valeur ajoutée 2.5.1 Pour le fournisseur de services

Meilleure utilisation des ressources humaines : o Flux d’informations optimisés o Pas d’interruptions inutiles o La bonne compétence sollicitée au bon moment

Pertinence des mesures et du pilotage : o Identification des besoins (ressources, formation,…) o Amélioration de la performance des services o Maîtrise accrue des coûts des services

Gestion de l’image de la direction informatique : o Meilleure compréhension des attentes des clients o Réduction des motifs d’insatisfaction o Rationalisation de la communication

2.5.2 Pour les utilisateurs et clients Meilleure utilisation des ressources humaines :

o Moins de temps perdu à chercher des solutions ou informations par soi-même ou auprès des collègues

o Simplicité de la relation avec le fournisseur de services grâce au point de contact unique

Meilleure qualité et rapidité de service : o Toutes les requêtes sont enregistrées et traitées o Meilleur information sur les services et leur disponibilité

Moins de pertes financières : o L’impact des incidents est minimisé o Les délais de résolution tiennent compte des impératifs du métier

3 Modes réactif et pro-actif

3.1 Traitement en mode réactif

Page 12: ITIL les bonnes pratiques

12

Le centre de services est essentiellement réactif :

Réponse à une demande de l’utilisateur : le besoin n’est pas anticipé

Traitement d’un incident signalé par l’utilisateur : l’activité métier est déjà impactée

3.2 Traitement en mode pro-actif

Les incidents remontés par les outils de surveillance ou les applications permettent parfois au centre de service d’être plus proactif :

Résolution de l’incident avant qu’il n’affecte l’activité métier

4 Les différents types de centres de services

4.1 Les structures possibles de centre de services Plusieurs facteurs entrent en ligne de compte dans le choix du type de centre de services, du degré de compétence et de la structure organisationnelle. Même s'il n'y a pas de configuration universelle qui permette de tout faire, il existe trois structures :

Le centre de services local

Page 13: ITIL les bonnes pratiques

13

Le centre de services central

Le centre de services virtuel

4.1.1 Les différentes appellations du contact central Help Desk :

o Gère, coordonne et résout les incidents le plus vite possible et s'assure qu'aucune requête n'est perdue, oubliée ou ignorée

Centre d'appel : o Gère professionnellement de gros volumes d'appels téléphoniques (téléachats, télémarketing)

Centre de services : o Intègre les processus métiers dans la Gestion des Services des TI o C’est un Help Desk étendu à toutes les demandes concernant la gestion des services des TI o Ce qui en fait un point d'entrée unique pour toutes les demandes

Hot line client o Fournit des conseils sur l'utilisation d'un produit / service ou dépanne les utilisateurs / clients

lorsqu'ils ont des difficultés

4.1.2 Maturité d’un centre selon son appellation

4.2 Le centre de services local

Page 14: ITIL les bonnes pratiques

14

Les points importants à considérer pour implanter un centre de services local sont les suivants :

Processus communs sur tous les sites et, si possible, des procédures communes

Compétences locales reconnues par les autres centres de services

Matériel, logiciel et infrastructure réseau compatibles

Normalisation des classifications des requêtes de plus haut niveau afin de permettre un reporting commun sur les composantes de service majeurs

Mêmes processus d'escalade, codes d'impact, de sévérité, de priorité et d'état

Métriques de gestion communs (reporting)

SGBD commun et partagé logiquement

Transfert / escalade des requêtes entre centre de services (automatique idéalement)

4.3 Le centre de services central

Les bénéfices d'un centre de services centralisé sont les suivants :

Réduction des coûts opérationnels

Vue d'ensemble de gestion consolidée

Utilisation améliorée des ressources disponibles

Page 15: ITIL les bonnes pratiques

15

4.4 Le centre de services virtuel

Les points importants à considérer dans l'implantation d'un centre de services virtuel sont les suivants :

Processus, procédures, langage et terminologie communs et approuvé par tous

Nécessité de dialoguer avec un point de contact unique : numéros de téléphone globaux, numéros locaux redirigés vers le centre de services virtuel et une technologie ACD

Présence physique ponctuelle d’un spécialiste ou d’un ingénieur de maintenance

Performances réseaux conséquentes

Outils de distribution des charges de travail : Accès spécialisés. Inclut l'accès aux processus associés et aux données (changements planifiés, actifs et la CMDB, etc.)

Processus de gestion des incidents cohérent, avec des transferts automatisés des incidents et des données pertinentes entre les centres de services locaux

Page 16: ITIL les bonnes pratiques

16

5 Le centre de services et la gestion des incidents

5.1 Le processus de gestion des incidents

Les rôles et responsabilités du centre de services dans le processus sont :

Prise en charge et enregistrement de tous les incidents (même générés automatiquement)

Enregistrement, symptômes et détails

Si demande de service : traitement conforme aux procédures standard

Identification de l’élément de configuration (CMDB) à l’origine de l’incident

Communication du numéro d’identification de l’incident

Tentative de résolution (problème ou erreur connue)

Affectation de la priorité

Escalade et suivi de la résolution jusqu’à clôture

5.2 Pourquoi une classification des incidents ? La classification d'un incident facilite les activités suivantes :

Détermine le service ou le CI lié à l’incident

Fait le lien avec tous les SLA et OLA associés

Sélectionne et identifie le meilleur spécialiste ou groupe apte à traiter l’incident

Définit la priorité et les impacts métiers

Estime la charge de travail

Définit les questions à poser et les informations à vérifier

Discrimine les solutions, les erreurs connues ou les évaluations et investigations

Synthétise et définit l'action finale prise (par exemple, formation à donner car aucune erreur trouvée)

Définit une matrice de reporting de base pour l‘information de gestion

5.3 Assignation à un groupe de support

Page 17: ITIL les bonnes pratiques

17

A qui assigner un incident et quels délais associer à cette assignation ? La réponse est donnée par l’une des activités du centre de services dans le cadre du premier niveau de support de la gestion des incidents. Cette activité fait intervenir des livrables très importants :

la CMDB gérée par la gestion des configurations

les SLA et les OLA / UC gérés par la gestion des niveaux de service Centre de services : à qui assigner un incident et quels délais associer à cette assignation ?

Les différentes tâches de cette activité sont :

Identifier l’équipe de support concernée : o Quel est le service concerné par l’incident ? o Quelles sont les composantes d’infrastructure concernées par l'incident ? o Quelle équipe est responsable du support de niveau 2 du service ou des composantes concernés ?

Identifier la priorité et/ou le délai de résolution global de l'incident : selon les indications du SLA concernant le service ou les composantes d'infrastructure

Identifier le délai de résolution interne (groupe de support) : selon les indications du OLA ou du UC concerné tout en respectant le délai de résolution global

Si un Incident ne peut pas être lié à un service, ce sont les composantes d'infrastructure qui prendront le relai.

5.3.1 Etape 1 : Identifier l’équipe de support concernée

Quel est le service concerné par l’incident ? En fonction des indications données par l’utilisateur et des informations à disposition du centre de services :

Base de données des incidents

Catalogue de services

Page 18: ITIL les bonnes pratiques

18

CMDB, y compris les sous-bases suivantes : DRH, DSL, SLA

Bases de connaissances : Erreurs connues, Solutions de contournement Si la question précédente est restée sans réponse, quelles sont les composantes d’infrastructure concernées par l'incident ?

Si un lien incident-service a été détecté, les composantes d'infrastructure sont déjà connues ; sinon :

L’identification des composantes d’infrastructure défaillantes peut être déléguée à un premier groupe de support (généraliste)

La CMDB permet d'identifier les composantes d’infrastructure concernées par l'incident

Le cas où plusieurs composantes d’infrastructure contribuent à une anomalie doit être pris en compte (cas difficiles à traiter car ils sont susceptibles de générer des effets ping-pong entre les différents groupes de support)

Quelle équipe est responsable du support de niveau 2 (selon le service ou les composantes concernées) ?

En fonction du niveau de support :

L'équipe choisie fera partie de la direction responsable du support du service

ou de la direction responsable du support des composantes d'infrastructure concernées

5.3.2 Etape 2 : Identifier le délai de résolution global Selon les indications du SLA concernant le service ou les composantes d'infrastructure :

L'équipe choisie fera partie de la direction responsable du support du service

La CMDB permet d’identifier le bon SLA à partir de l'identification du service concerné ou, éventuellement, des composantes d'infrastructure concernées

L'équipe choisie fera partie de la direction responsable du support du service

Le Centre de services / IM1 doit suivre le processus de résolution de l'incident en vérifiant le respect du délai convenu de rétablissement du service (ou des composantes d'infrastructure). Ainsi, il assure ses responsabilités de gestion des incidents et de coordination des différentes interventions de support

L'équipe choisie fera partie de la direction responsable du support du service

Dans la version 3 d’ITIL, c’est plutôt la manière de calculer la priorité à partir de l’impact et de l’urgence qui est précisée dans le SLA, ce qui permet d’en déduire le délai de résolution (à moins qu’il ne soit lui-même précisé dans le SLA)

5.3.3 Etape 3 : Identifier le délai de résolution interne (groupe de support) Selon les indications de l’OLA ou de l’UC concerné tout en respectant le délai de résolution global :

Page 19: ITIL les bonnes pratiques

19

La CMDB permet d’identifier l’OLA ou le UC concerné via la structure de support du fournisseur des services de TI

L’OLA et l'UC lient le fournisseur de services en tant qu'entité (organisation informatique) représenté par le centre de services avec un groupe de support identifié d'un des fournisseurs de services internes (OLA) ou externe (UC)

Le centre de services suit les travaux d'investigation entrepris par le groupe de support en surveillant, à la fois, le délai de résolution global (SLA) convenu, et le délai de résolution interne (OLA ou UC) convenu

5.4 Escalader au niveau 3 Voici un exemple de support niveau 2 :

Dans cet exemple, les CI (éléments de configuration) sont exploités soit par l'exploitation (interne à la direction informatique) soit par un mainteneur externe. Si l’incident doit être escaladé au niveau 3 :

Page 20: ITIL les bonnes pratiques

20

Dans cet exemple, le mainteneur externe fournissant un service global, l'escalade au niveau 3 ne nous concerne pas (il s'agit de processus internes au mainteneur et nous voyons cela comme une boîte noire). Seul le résultat compte et tout est conditionné aux termes contenus dans le contrat de sous-traitance (UC ou Underpinning Contract). En interne, la situation est plus complexe car les mécanismes d'escalade sont visibles et doivent être définis dans le processus. Traditionnellement, ce sont les équipes d'experts (systèmes, bases de données, réseaux, etc.) qui font le niveau 3 en intervenant sur les incidents n'ayant pu être résolus par l'exploitation. Il arrive, comme dans cet exemple, que l'exploitation intervienne aussi au niveau 3 pour certaines parties des infrastructures et des systèmes d'informations (cela sera, par exemple, une équipe d'analystes d'exploitation). D’un point de vue global, nous avons la situation suivante :

5.5 Indicateurs de performance de la fonction centre de services Voici quelques points à prendre en compte pour définir les indicateurs de performance :

Temps avant de décrocher le téléphone : Juste milieu qui permet de conserver la satisfaction client

Temps de conversation avec le client : Dépend des ressources disponibles et de leur compétences

Page 21: ITIL les bonnes pratiques

21

Traitement des demandes urgentes des clients : Chaque situation client doit être analysée et prise en compte. La perception de la qualité de service en dépend

Traitement des ruptures de services : En transmettant à la gestion des problèmes, si nécessaire

Traitement des ruptures de services côté utilisateur : Si l’utilisateur est injoignable ou ne peut fournir d'information

Enregistrement des détails de rupture de service : Permet de savoir s'il existe ou non des SLA la couvrant

6 Le centre de services et l'exécution des requêtes La demande de service est d'abord approuvée puis la procédure appropriée est exécutée :

Il est à noter qu'il s'agit de dérouler une procédure déjà définie (intervenants, enchaînement des activités et même délais de réalisation garantis). L'ensemble des informations devant être portées à la connaissance des utilisateurs (liste des procédures avec l'objectif de la procédure, le formulaire de demande, comment faire la demande, à qui s'adresser en rappelant que c'est toujours au centre de services qu'il faut soumettre la demande et les garanties en termes de niveau de service comme le délai de réalisation par exemple) font l'objet d'un chapitre spécifique dans le catalogue des services.

7 Le centre de services et la mise en place des SLA et OLA

7.1 Approche préconisée L'approche préconisée est de définir séparément et préalablement les OLA et UC puis définir les SLA en confrontant et en alignant OLA et UC d'une part et SLA d'autre part. Les OLA sont la confrontation entre les exigences des clients transcrits sur chacun des CI et les possibilités techniques et budgétaires des équipes internes supportant ces CI

Page 22: ITIL les bonnes pratiques

22

7.2 Partir aussi des SLR pour établir les OLA Il est donc plus efficace (et surtout plus réaliste) :

d’élaborer d’abord les OLA que peuvent proposer chacune des équipes

de les confronter avec les SLR rapportées aux CI gérés par l’équipe interne

d’ajuster les deux contraintes sans oublier de mettre aussi à jour les SLA

7.3 Elaboration des OLA pour confrontation avec les SLR Chacune des équipes internes doit d’abord analyser sa manière de travailler sur les CI qu’elle gère afin de recenser les différents niveaux de service interne qu’elle fournit aujourd’hui. Pour des raisons pratiques (et c’est aussi ce que l’on constate dans la réalité), l’analyse débouche très rapidement sur une échelle de niveaux de service, par exemple sur la gestion des serveurs :

pas d’interruption de service (cluster haute disponibilité)

rétablissement du service garanti dans l’heure

rétablissement du service garanti dans les 6 heures

rétablissement du service garanti à J+4 Ces niveaux de service sont quelquefois nommés (par ex., « premium », « gold », « silver », etc.).

Page 23: ITIL les bonnes pratiques

23

Le choix pour chaque OLA d’un niveau de service standard permet d’élaborer ensuite plus facilement les niveaux de service d’un SLA et de confronter et d’ajuster l’ensemble avec les SLR.

8 L'outillage du centre de services, le Self-Help

8.1 Les technologies utilisées dans un centre de services Systèmes d’appui à la gestion des services des TI et à l’exploitation

Systèmes de téléphonie (routage automatique, groupes de recherche, CTI -- Computer Telephony Integration et VoIP -- Voice over Internet Protocol, etc)

Commutateurs ACD

Serveurs vocaux (IVR -- Interactive Voice Response)

Courrier électronique (voix, vidéo, communications mobiles, Internet, systèmes de messagerie - email)

Serveurs de télécopie (avec routage sur des comptes de messagerie électronique)

Systèmes de récepteur d'appel (Pager, SMS)

Outils de gestion de la connaissance, de recherche et de diagnostic

Outils automatisés de gestion des réseaux et de l'exploitation

8.2 Bénéfices d'un centre de services outillé Chacun sait ce qui se passe (requêtes accessibles en consultation)

Efficacité accrue (traitement accéléré des requêtes)

Suivi, escalade et processus de requêtes améliorés

Accès en direct d’informations de meilleure qualité : o Erreurs connues, solutions et historique de la requête o Sources de connaissance externes

Information de gestion plus accessible et plus précise

Plus de requêtes en double, perdues ou oubliées

Ressources et spécialistes mieux utilisés

Tâches de soutien et de calcul complexe facilitées.

8.3 Stratégie de libre-service (Self-Help) : les facteurs critiques de succès

Page 24: ITIL les bonnes pratiques

24

Engagement du management

Volonté de céder le contrôle : Outils et processus = les utilisateurs suivent un parcours choisi

Métriques collectés et utilisés sur les métiers : Suivre l'efficacité d'un service = connaître les services d'aide nécessaires, leur fréquence et leur raison d'être

Maintien des processus de soutien (ni contournés, ni invalidés)

Facilité d'utilisation et qualité du contenu : Sinon l’utilisateur utilisera son téléphone et les équipes des TI devront supporter le libre-service !

Communication : Les utilisateurs doivent connaître les canaux disponibles ainsi que les bénéfices qu'ils retireront de leur utilisation

9 Implantation

9.1 Points clés à vérifier Besoins métiers identifiés et compris

Direction impliquée, budget et ressources disponibles

Solution proposée conforme à la vision et la stratégie de soutien des services des TI

Définition, obtention et communication de résultats rapides

Objectifs et livrables clairs et précis

Mise en place simple en plusieurs phases

Implication et consultation des clients et utilisateurs : surtout ceux à des postes critiques. Pas de jargon.

Vente des bénéfices attendus au personnel de support

Formation du personnel pour le rendre orienté services

Formation et apprentissage des clients et utilisateurs aux nouveaux services et à la réalisation des bénéfices

Promotion, publicité et vente des services.

9.2 Problèmes potentiels La mise en place d’un point de contact unique avec les clients / utilisateurs n’est pas considérée comme

prioritaire

Manque d’engagement de la direction et/ou du management intermédiaire (Middle Management)

Résistance au changement concernant de nouveaux processus de travail.

Ressources et/ou compétences inadéquates ou mal adaptées

Promotion du centre de services mal faite ou inadaptée

Insuffisance des moyens financiers investis pour l’implantation de la fonction

9.3 Lignes de conduite Endroit éloigné des sites d'exploitation : calme, isolé et confortable

Page 25: ITIL les bonnes pratiques

25

Bibliothèque avec la documentation des produits, matériel, logiciels et documents de référence utilisés par les clients

Catalogue produits/services toujours disponible

Télé-conférence et téléphones mains libres

Environnement pour discussions en groupe (en interne) : pas de situations du style « Eux mais pas nous »

Rafraîchissements ou accès à ceux-ci

Localisation et les heures de fonctionnement connues des clients

9.4 Facteurs critiques de succès Coups gagnants pour des bénéfices rapides

Démarrage simple avec une approche par phases

Clients et utilisateurs clés impliqués, surtout ceux à des postes critiques vis-à-vis la qualité des services

Différences perceptibles expliquées aux clients

Fournisseurs de services externes impliqués

Chaque personne impliquée ou concernée sait ce qu’elle a à faire et pourquoi

Bénéfices expliqués au personnel de support afin de réduire la résistance au changement

Personnel et administrateurs formés pour les orienter clients et services

9.5 Support 24/24 ou mondial Systèmes de télécom et commutateurs

Faire les choix suivants concernant les fuseaux horaires : o Support par fuseau horaire inclus dans les SLA ? o Rapports de gestion disponibles dans les fuseaux horaires locaux et distants ? o Support dans la langue locale ? o Nécessité d'un personnel de soutien multilingue ?

Prise en compte des spécificités et de la culture locale

Canaux d'escalade et circuits de reporting clairs et précis

SLA et OLA locaux peuvent être à définir

Centres de services locaux utilisant une gestion des Incidents cohérente avec des transferts automatisés des incidents et des données pertinentes entre les différents centres de services

9.6 Profil du personnel de support Orienté clients et utilisateurs

Méthodique et bon communicateur

Formé aux habiletés interpersonnelles

Multilingue (si nécessaire)

Capable de comprendre et d'accepter : o les objectifs métiers, o que le problème du client affecte les affaires o que sans client il n'y a pas de soutien des services des TI o que le client est un expert dans son domaine

Convaincu qu'il doit fournir un service de première qualité.

9.7 Attitude du personnel de support

Page 26: ITIL les bonnes pratiques

26

Prend soin de bien se présenter pour que la première impression du client soit la bonne

Montre au client que son problème le préoccupe

Utilise des termes que le client comprend et évalue les choses selon le point de vue métier

Fait de l'écoute active : o Écouter ce n'est pas seulement attendre la bouche fermée o Demeurer attentif et intéressé. Se projeter dans l'esprit de l'autre pour voir la situation à travers ses

yeux o Écouter au-delà des mots pour comprendre pourquoi ils ont été prononcés

9.8 Sous-traiter le centre de services Utilisation des outils choisis par l’entreprise. Eviter la formation des acteurs internes à chaque changement de

fournisseur.

Accès complet et à la source aux informations de management.

Capacité à fournir un personnel de management compétent et qualifié pour la couverture des congés et absences de l’équipe principale.

Surveillance continuelle du retour sur investissement.

Contrôler le respect des procédures, la validité et mise à jour des documents,…

Clarté et compréhension des termes du contrat par les deux parties.

10 Indicateurs et rapports La liste proposée est issue des livres ITIL mais elle n'est pas à appliquer telle quelle : il faut sélectionner certains indicateurs correspondant à une problématique actuelle dans l'organisation et ne pas hésiter à en ajouter d'autres (la liste proposée par ITIL n'est pas exhaustive, il peut y avoir des problématiques spécifiques dans votre organisation). Essayer de mettre en place TOUS les indicateurs proposés n'a pas une grande valeur ajoutée car la plupart des rapports édités (ceux portant sur des sujets sur lesquels il n'y a pas de problématique aujourd'hui) n'indiqueront rien d'intéressant à part que tout va bien et à se congratuler. Mais il faut bien séparer les moments où on "boit une chope" et les moments où on travaille sur les sujets qui fâchent. En outre, une édition verbeuse noiera l'information utile sous des pages de rapports inutiles.

10.1 Tous les jours : (état des incidents/problèmes vs SLA) Les incidents exigeant une escalade par groupe de support

Les ruptures possibles de services

Les incidents en suspens

10.2 De manière hebdomadaire : Disponibilité des services

Types d‘incident les plus fréquents, sur lesquels le personnel passe le plus de temps et les plus longs à résoudre pour le client

Incidents nécessitant un dossier de problème

Erreurs connues et changements induits

Ruptures de cervices

Satisfaction des clients

Tendances et impacts majeurs sur les métiers

Charges de travail du personnel

10.3 De manière mensuelle Disponibilité des services

Performance globale, réussites et analyse de tendance

Page 27: ITIL les bonnes pratiques

27

Réussites par rapport aux objectifs de chaque service

Perceptions et niveaux de satisfaction des clients

Besoins de formation et d'apprentissage des clients

Performance du personnel, des tiers, des applications et des technologies

Contenu de la liste des revues et du reporting

Coûts de la fourniture et de la défaillance des services

10.4 Sur demande et pro-activement Changements planifiés pour la semaine à venir

Incidents / problèmes / changements majeurs de la semaine précédente avec tout le détail de leur suivi

Incidents client des semaines précédentes non résolus

Composantes d'infrastructure qui ont eu des défaillances au cours des semaines précédentes

11 Liste des sous-projets identifiés

11.1 Processus simplifié de gestion des incidents La formalisation simplifiée de ce processus intègre les étapes suivantes :

Définir les activités, les livrables et les rôles

Regrouper les rôles pour définir les profils et les rattacher aux équipes Il devra être complété le moment venu par la définition du cahier des charges des outils (ou requalification des outils existants).

11.2 Processus de gestion du catalogue de services Cela comprend les étapes suivantes :

Etablir une première liste de services fournis en partant, soit des processus métiers, soit de ce qui est connu de la direction informatique (applications fournies notamment)

Définir la première version d’un modèle décrivant un service (fiche) : ce modèle sera simplifié et ne reprendra dans un premier temps que les informations qui existent ou qui vont prochainement être mises en place

Pour chaque service identifié dans la liste, faire sa description en utilisant le modèle

Publier cette première version du catalogue (pdf, intranet, etc.) et en faire la promotion

11.3 Processus d’exécution des requêtes Cela comprend les étapes suivantes :

Définir une première liste de demandes de service en analysant chaque service fourni et en établissant une liste de demandes de service existantes ou possibles à mettre en oeuvre à court terme

Définir la première version d’un modèle décrivant une demande de service (fiche) : ce modèle sera simplifié pour permettre une élaboration rapide

Pour chaque demande de service : remplir la fiche en définissant les caractéristiques de la demande et écrire la procédure associée (activités, livrables, équipes) ou la démarche à réaliser en interne (certaines demandes de service peuvent être réalisées en mode projet ou s’intégrer dans un processus interne comme l’établissement du budget de l’année suivante).

11.4 Processus de gestion des niveaux de service Compte-tenu du nombre très important des liens entre OLA (accord de niveau opérationnel), UC (contrat de sous-traitance) et SLA (accord de niveau de service), la mise en route du processus cyclique de la gestion des niveaux de service nécessite une approche simplifiée et initialisée sur le point du cycle ayant le plus d’interactions avec les autres :

Définir les OLA (accords internes de niveaux opérationnels) et des UC (contrats de sous-traitance) en fonction de l’existant et avec une approche pragmatique (possibilités techniques et budgétaires)

Page 28: ITIL les bonnes pratiques

28

Collecter les SLR (exigences de niveaux de service)

Proposer des SLA (accords de niveaux de services) répondant au mieux aux exigences et cohérents avec les OLA et UC

Identifier les OLA et UC manquants ou insufisamment alignés sur les SLA pour les établir ou les corriger ; si cela s’avère impossible, revoir avec les organisations clientes leurs exigences (négocier) et les SLA à mettre en place

11.5 Processus de gestion des problèmes : définition simplifiée La définition simplifiée de la gestion des problèmes passe par les étapes suivantes :

Formaliser le processus de manière simple (quatre activités de premier niveau : contrôle des problèmes, contrôle des erreurs, pilotage, analyse pro-active) : activités, livrables, rôles, outillage

Définir exactement la notion d’incident récurrent et d’incident majeur, les deux principales sources du processus des problèmes

Définir le fonctionnement pratique du processus : préciser l’organisation et le pilotage de l’instance de pilotage, associer les rôles aux équipes dans l’organisation.

11.6 Mise en place du centre de services Il s’agit de définir les objectifs, le périmétre de responsabilités, l’organisation et la logistique du centre de services.

11.7 Formation/sensibilisation des utilisateurs : promotion du centre de services

Les utilisateurs devront être sensibilisés à la mise en place d’un centre de services et du catalogue de services :

directement par le biais de toute présentations, posters, « gadgets » (ou goodies) faisant la promotion du point de contact unique

et indirectement par leur hiérarchie (clients), ces derniers seront aussi sensibilisés par la direction informatique (en comité de direction par exemple)

11.8 Formation/sensibilisation en interne : promotion du centre de services et des processus associés

Les équipes internes devront aussi être sensibilisée sur la mise en place d’un centre de services et formés à l’utilisation des processus mis en place en même temps avec les éventuels nouveaux outils ou paramétrages d’outils à utiliser dans ce cadre.

11.9 Transfert de compétences du Help Desk actuel vers l’interne ou un autre sous-traitant

Le contrat actuel de sous-traitance doit avoir prévu une période de réversibilité et précise les actions à entreprendre par le sous-traitant pour transférer les données et connaissances acquises lors de l’exercice du contrat vers le client (la direction informatique interne).

Page 29: ITIL les bonnes pratiques

29

12 Le processus de gestion des incidents

12.1 Le processus ITIL Le processus tel qu’il est présenté dans le référentiel ITIL est le suivant :

12.2 Synoptique simplifié du processus Le processus adapté et simplifié est le suivant :

Page 30: ITIL les bonnes pratiques

30

12.3 Activité : Réceptionner et enregistrer la requête Déclenchement par un utilisateur :

par téléphone : incident, demande de service, demande d’assistance, relance, autres requêtes

par mail : demande d’édition (demande de service spécifique)

par mail au DSI : demande de service (point d’entrée inadapté pour ce type de demande qu’il faudra basculer sur le centre de services)

Déclenchement par une équipe interne :

par mail : incident à traiter, incident en cours de résolution

oralement : incident à traiter, incident en cours de résolution

messagerie instantanée : information (aujourd’hui) ou plus (canal à développer)

(écran de supervision) : information permettant de créer un ticket d’incident Détail de l’activité :

renseigner toutes les données de la demande : utilisateur, nature, données spécifiques Rôle :

Hotliner (pour simplifier, le rôle est directement lié à un profil dans l’organisation) Livrable :

Ticket d’incident

12.4 Activité : Classifier la requête Détail de l’activité :

déterminer la suite du traitement en fonction de la nature de la demande : o incident o incident en cours de résolution o demande de service o relance : à traiter comme un incident o demande d’assistance : à traiter comme un incident o autre requête

s’il s’agit d’un incident à traiter : déterminer l’impact, l’urgence et la priorité de l’incident Pour cela, il est nécessaire d’associer le service interrompu ou dégradé et l’utilisateur au SLA correspondant afin de déterminer si le service est dans un jour normal ou un jour critique. Tous les SLAs associés à des services métiers intègrent deux niveaux de service pour chacun des services : normal et critique avec un calendrier spécifique à chaque service précisant les jours de l’année normaux et critiques. Après identification du type de jour, le SLA précise le calcul de l’urgence et et de la priorité de l’incident. Pour les services communs (bureautique, etc.), le SLA ne contient qu’un seul niveau de service (par de jours critiques sur ces services). Pour plus de précisions, voir la partie du document sur le processus de gestion des niveaux de service. Rôle :

Hotliner Livrable :

Ticket d’incident avec état différent selon la nature de la requête

12.5 Activité : Fournir le diagnostic initial et rétablir le service Détail de l’activité : Il s’agit plus de trouver une solution à l’incident dans les bases d’informations et les documentations que de chercher une solution inédite (sauf si elle est évidente au vu du diagnostic). Pour un incident signalé par un utilisateur, l’activité consiste à prendre la main sur le poste à distance pour réaliser les différentes actions locales :

Effectuer le diagnostic de niveau 1 : reproduction de l’incident, message d’erreur, fichiers trace, etc.

Page 31: ITIL les bonnes pratiques

31

Identifier une solution définitive ou de contournement décrite dans les bases d’informations (incidents, incidents résolus, problèmes, erreurs connues mais aussi bases de connaissances et documentations de support des services fournis)

Appliquer la solution identifiée (et vérifier le résultat) ou escalader au niveau 2 Le déroulement de cette activité ne doit pas dépasser 15 minutes (délai de résolution qui sera indiqué dans l’OLA liant le centre de services au fournisseur de services informatiques). Au-delà, l’incident doit être escaladé. Rôle :

Support niveau 1 des incidents Livrable :

Ticket d’incident complété

12.6 Activité : Clôturer la requête Détail de l’activité :

Demander l’accord de l’utilisateur pour vérifier que, de son point de vue, l’incident est résolu ou le résultat apporté à sa requête le satisfait.

Si la requête est un incident, identifier si l’incident fait apparaître une série d’incidents récurrents et créer un problème dans ce cas

Si la requête est un incident est majeur, créer un problème

Clôturer administrativement la requête et compléter les informations de gestion non encore renseignés (champs codifiés devant être renseignés pour exploitation ultérieure : recherche de solutions d’incident et reporting)

Rôle :

Support niveau 1 des incidents Livrable :

Ticket d’incident complété et clôturé

12.7 Activité : Communiquer l’état d’avancement de la requête Détail de l’activité :

Tenir régulièrement et ponctuellement au courant le demandeur de l’état d’avancement de sa requête, par exemple :

o à chaque changement d’état de la requête o au bout d’un certain délai sans communication

Rôle : Deux rôles ont été identifiés et leur distinction peut être faite avec le modèle RACI (« Réalise l’activité », « est l’Autorité sur la réalisation de l’activité », « Contribue à l’activité » et « est Informé du résultat de l’activité ») :

R (Réalise l’activité) : Hotliner

A (est l’Autorité sur l’activité) : Support niveau 1 des incidents Livrable :

Communication vers l’utilisateur concerné

12.8 Communiquer des informations relatives aux services et niveaux de service

Détail de l’activité :

Informer/communiquer au sens large vers les utilisateurs sur des événements planifiés ayant un impact sur les services ou les niveaux de service fournis comme, par exemple :

o les incidents majeurs en cours o les changements planifiés qui vont entraîner des arrêts de service pendant les plages d’ouverture

d’un service

Page 32: ITIL les bonnes pratiques

32

Rôle :

R (Réalise l’activité) : Hotliner

A (est l’Autorité sur l’activité) : Superviseur incidents Livrable :

Communication vers une population d’utilisateurs

12.9 Activité : Superviser la gestion des requêtes et escalader Détail de l’activité :

Superviser les délais de résolution des incidents et de traitement des demandes de service prévus dans les SLA, OLA et UC

Déclencher et gérer les escalades fonctionnelles (prévues dans le processus et les SLA, OLA et UC) et hiérarchiques

Identifier des problèmes sur les incidents en cours et créer des tickets de problèmes si besoin Rôle :

Superviseur incidents

12.10 Description de l’organisation actuelle La direction informatique est constituée aujourd’hui de 5 cellules, auxquelles il faut ajouter la structure externe de Help Desk :

cellule administrative

cellule exploitation

cellule serveurs/réseaux

cellule micro

cellule développement

12.11 Rôles et organisation Les niveaux de support de la gestion des incidents sont structurés de la manière suivante :

Page 33: ITIL les bonnes pratiques

33

La cellule micro est associée à deux rôles :

diagnostic de niveau 1 (par délégation du centre de services lorsqu’il ne peut trouver suffisamment d’informations pour assigner l’incident à une équipe de niveau 2)

support niveau 2 De même, la cellule développement est associée à deux rôles :

support niveau 2 : support applicatif (interventions qui ne nécessitent pas de corrections dans le code applicatif)

support niveau 3 : lorsque l’incident ne peut être résolu que par une modification du code applicatif Les fournisseurs externes font partie du processus de gestion des incidents et interviennent en support de niveau 3. Leurs interventions sont toujours gérées par une équipe de niveau 2 et jamais par le centre de services qui n’a pas le temps (ni systématiquement les connaissances) pour suivre ces interventions.

13 Le processus d'exécution des requêtes

13.1 Synoptique simplifié du processus Ce processus est une extension du processus de gestion des incidents car :

il est déclenché par ce processus

il est piloté et suivi par ce processus (escalade si dépassement de délai)

il retourne un résultat pour préciser le bon déroulement ou non de la procédure Le processus de gestion des événements est simple car la quasi-totalité des actions effectuées sont décrites dans des procédures spécifiques et le processus, tel qu’il est formalisé, appelle la procédure appropriée à la demande de service un peu comme un logiciel appelle un plug-in tiers. Chaque procédure est associée à une demande de service décrite dans le catalogue des services.

13.2 Activité : Valider la demande de service Détail de l’activité :

Vérifier que le demandeur est habilité à faire la demande

Vérifier la complétude des données de la demande (formulaire complètement rempli et valeurs correctes)

Page 34: ITIL les bonnes pratiques

34

Vérifier que les restrictions de la demande de service n’invalident pas la demande

Approuver éventuellement la demande (budget disponible, contre-indication par rapport à un changement planifié, etc.)

Rôles :

R (Réalise l’activité) : Hotliner

A (est l’Autorité sur l’activité) : Approbateur de demande de service (devra être précisé dans le catalogue de services)

13.3 Activité : Identifier et exécuter la procédure appropriée Détail de l’activité :

Identifier la procédure associée à la demande (information contenue dans la partie non visible des utilisateurs du catalogue de services)

Exécuter la procédure

14 Le processus de gestion des problèmes

14.1 Synoptique simplifié du processus

14.2 Activité : Superviser les problèmes et les erreurs Détail de l’activité :

Examiner l’avancement des problèmes en cours

Affecter des ressources sur le traitement des problèmes et des erreurs en cours

Examiner et valider ou rejeter les nouveaux problèmes soumis Rôle :

Superviseur des problèmes (au travers d’un comité des problèmes)

14.3 Activité : Traiter le problème Détail de l’activité :

Investiguer pour trouver la cause première des dysfonctionnements : établir clairement l’enchaînement des causes et des effets

Rôle :

Gestionnaire de problème

14.4 Activité : Traiter l’erreur Détail de l’activité :

Page 35: ITIL les bonnes pratiques

35

Identifier un ou plusieurs scénarios de résolution possibles

Organiser et suivre la mise en œuvre du scénario choisi par le comité des problèmes ou clôturer en erreur connue si le comité des problèmes a décidé de ne pas mettre en œuvre de solution

Déclencher une demande de changement si un changement sur l’infrastructure est prévu dans le scénario de résolution

Rôle :

Gestionnaire de problème

14.5 Activité : Gérer pro-activement les problèmes Cette activité sera mise en œuvre ultérieurement.

15 Rôles et profils identifiés et liens avec l’organisation

15.1 Récapitulatif des rôles identifiés Les rôles identifiés dans les versions simplifiés des processus dans lesquels intervient le centre de services sont les suivants :

Hotliner

Superviseur des incidents

Diagnostic niveau 1 des incidents

Support niveau 1 des incidents

Support niveau 2 des incidents

Support niveau 3 des incidents

Approbateur de demande de service

Superviseur des problèmes

Gestionnaire de problème

15.2 Démarche de regroupement des rôles en profils et associations avec l’organisation

Une démarche possible est de définir les profils de poste pour chacune des équipes en associant à chaque profil un ou plusieurs rôles de la liste précédente. Cela permet de définir les rôles et responsabilités du centre de services dans les différents processus et de définir les profils de poste des personnes de ce centre de services. Cela permet aussi d’intégrer le futur centre de services (qu’il soit interne ou externe) dans une organisation cohérente avec des profils pour chacune des équipes qui soient cohérents entre eux et conformes aux processus définis préalablement.

15.3 Profil de responsable du centre de services Ce profil jouera, par exemple, les rôles suivants dans les processus :

superviseur des incidents

gestionnaire de problème

hotliner (en cas de débordement du nombre d’appels)

15.4 Profil de technicien du centre de services Ce profil jouera, par exemple, les rôles suivants dans les processus :

hotliner

support niveau 1 des incidents

gestionnaire de problème

Page 36: ITIL les bonnes pratiques

36

16 Catalogue de services - Exemple/Modèle de fiche service

Nom du service

Décrire les principales fonctions de l’application.

Organisation métier : Toutes

Propriétaire métier : Mr Dupont, Directeur

Contacts métiers : Mme Durand, Mr Dubois

Décrire les différents niveaux de services standards proposés avec ce service (pas de recommandations sur leur nombre sauf à ne pas dépasser un nombre raisonnable au-delà duquel cela devient difficile à comprendre). Ce service est proposé avec deux niveaux de garantie :

INCIDENTS Impact : de 1 à 3 Urgence : de 2 à 4 Priorité = formule(Impact, Urgence) Délai de résolution : au mieux

DISPONIBILITE Une interruption ou dégradation de service ne dépassera pas 4 heures.

Le total des indisponibilités dans le mois ne dépassera pas 16 heures. Ne préciser dans chaque niveau de service que les thèmes pour lesquels la direction informatique peut s’engager.

INCIDENTS Impact : de 1 à 3 Urgence : de 2 à 4 Priorité = maximum(Impact, Urgence) Délai de résolution : 2 heures maximum

DISPONIBILITE Une interruption ou dégradation de service ne dépassera pas 2 heures.

Le total des indisponbilités dans le mois ne dépassera pas 4 heures.

SECURITE Garanties de sécurité

CAPACITE Garanties de capacité

CONTINUITE Garanties de continuité

Les demandes de service suivantes peuvent être effectuées auprès du centre de services informatiques :

Demande d'un nouveau poste bureautique : Demande de poste bureautique à

Petite image pour rendre la lecture de la fiche plus conviviale

Quelques chiffres 1 050 postes de travail 5 sites 100 remplacements de postes par an

Préciser ici quelques informations-clés sur le service : volumes, etc.

Page 37: ITIL les bonnes pratiques

37

faire au moins 2 semaines avant la date souhaitée

Réaffectation d'un poste bureautique à un nouvel utilisateur : Demande de poste bureautique à faire au moins 2 semaines avant la date souhaitée

Mutation interne d'un utilisateur : Demande de poste bureautique à faire au moins 2 semaines avant la date souhaitée

Préciser ici la liste des demandes de service associées au service. La description de chaque demande de service se fait dans les pages suivantes du catalogue de services.

Page 38: ITIL les bonnes pratiques

38

17 Catalogue de services - Exemple de fiche demande de service

Demande d’un nouveau poste bureautique

POURQUOI Demande d'installation pour toute arrivée d'un nouveau collaborateur, d'un collaborateur muté ou d'un collaborateur dans l'équipe qui aura besoin d'un poste bureautique.

QUAND 2 semaines au plus tard avant la date souhaitée.

COMMENT Seul un responsable d'équipe ou tout supérieur hiérarchique est habilité à faire la demande.

Pour faire la demande, prendre le formulaire ABC123 disponible sur l'Intranet, rubrique Info/Demandes de service, le remplir et le renvoyer par mail au centre de services. Un technicien bureautique prendra ensuite rendez-vous avec vous ou quelqu'un de votre équipe pour vérifier l'environnement technique du futur emplacement. Un autre rendez-vous sera nécessaire pour procéder à l'installation physique du poste bureautique et à sa connexion au réseau informatique de la mairie.

RESTRICTIONS Valable de 1 à 5 postes.

Pour plus de 5 postes, veuillez contacter le responsable du centre de services pour traitement en mode projet.