ITIL® - L'exploitation des services · ITILﬁ - Exploitation des services A propos du document Ce...

ITIL® - L'exploitation des servicesVersion 1.0A

Mars 2017

1

ITIL® - Exploitation des services

A propos du documentCe document pratique est le résultat de la mise en oeuvre du référentiel ITIL® et d'autresréférentiels dans des directions informatiques en France au travers des missions qui me sontconfiées depuis 2004 ainsi que des formations que j’anime avec création de supportsoriginaux.

Il est mis à la disposition de la communauté francophone pour diffuser quelques conseils etnotes 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'auteurLa transformation d'une organisation informatique en fournisseur de services informatiquesnécessite une réflexion lucide et permanente sur les tactiques à mettre en place pour quel'opérationnel s'aligne naturellement avec les objectifs stratégiques.

Souvent, l'application brutale sans réflexion d'un référentiel de bonnes pratiques comme ITIL®ou d'un logiciel ITSM améliore peu la performance de l'organisation. Les tactiques mises enplace (organisation, processus, etc.) ne sont pas les plus pertinentes à appliquer sur uncontexte spécifique et manquent de relief (prise en compte faible de facteurs telsqu'importance, priorités, gains rapides, etc.).

De plus, face à l'évolution rapide des situations et des contraintes, le format de ces référentiels(mastodontes avec une nouvelle version tous les 3 ans ou plus) est devenu trop statique etn'est plus adapté.

Il est temps de mettre de l'agilité au sein même des référentiels de bonnes pratiques.

L'amélioration continue et le Lean jouent un rôle prépondérant dans cette nouvelle manièrede faire.

Pour partager avec l’auteur : [email protected]

Pour recommander ses compétences sur les réseaux sociaux : http://fr.linkedin.com/pub/pascal-delbrayelle/27/270/634 http://www.viadeo.com/fr/profile/pascal.delbrayelle

2

ITIL® - Exploitation des services

Ce document présente la phase d'exploitation des services du référentiel de bonnes pratiques ITIL®.

Les modules présentés sont les suivants :

Module 1 : principes et définitions

Module 2 : gestion des événements

Module 3 : gestion des incidents

Module 4 : gestion des problèmes

Module 5 : exécution des requêtes

Module 6 : gestion des accès

3

Principes et définitionsITIL® - Exploitation des services

Module

1

Réf. ITSM_M0500-V010-001

4


Module

1

Réf. ITSM_M0500-V010-002

Les équilibres à trouver

La position particulière de l'exploitation dans le cycle de vie des services

L’exploitation des services est très souvent considérée uniquement dans son rôle de gestion quotidienne (opérations) etde gestion technique.

Mais elle s’intègre dans le cadre plus global du cycle de vie des services où elle est responsable :

de l’exécution et de l’aboutissement des processus qui optimisent le coût et la qualité des services

vis-à-vis de l’organisation, de permettre aux organisation d'affaires d’atteindre leurs objectifs

vis-à-vis de la technologie, du bon fonctionnement des composants techniques qui, assemblées, constituent lesservices

5


Module

1L’exploitation des services consiste à trouver une position d’équilibre entre tous ces rôles et à gérer les aspectsquotidiens tout en conservant à l’esprit la perspective plus globale du cycle de vie des services.

Trouver un équilibreL’exploitation des services est plus que l’exécution répétitive d’un ensemble de procédures et d’activités standardisées.

Les fonctions et les processus sont conçus pour fournir des niveaux de services validés et constants … mais ils doiventêtre délivrés dans un environnement en perpétuelle évolution.

Cela crée un conflit entre maintenir un status quo et s’adapter aux changements techniques et d'affaires.

Un des rôles-clés de l’exploitation des services est de gérer ce conflit et de trouver un équilibre entre des prioritéscontradictoires.

Chaque situation conflictuelle représente une opportunité de s’améliorer.

Conflit numéro 1 : la vue interne des TI face à la vue externe affaires

la vue externe affaires ("l’organisation des TI fournit des services") : les utilisateurs et clients ne comprennent pastoujours (voire ne se sentent pas concernés) par le détail des composants techniques utilisés pour fournir cesservices, leur seule préoccupation est que les services soient délivrés conformément à leurs besoins et ce qui aété convenu avec les TI

la vue interne TI ("l’organisation des TI gère des composants techniques") : la complexité croissante destechnologies entraînent souvent que les équipes techniques sont organisées en silos et se concentrent sur desperformances et disponibilité optimales de « leurs » systèmes

Les deux points de vue sont nécessaires pour fournir correctement les services :

trop orientée services sans se préoccuper de la manière dont les composants techniques interviennent dans lafourniture, l’organisation des TI risque de faire des promesses qu’elle ne pourra pas tenir

trop orientée technique sans se préoccuper de la manière dont les services sont construits à partir descomposants techniques, elle risque de fournir des services coûteux sans grande valeur ajoutée

Le risque potentiel de conflit entre ces deux positions dépend de beaucoup de paramètres comme la maturité del’organisation, sa culture, son histoire, etc.

Toutes les organisations se positionnent entre des deux extrêmes.

Conflit n°2 : stabilité contre adaptabilitéSi un service répond fonctionnellement à un besoin et s’il a été bien conçu, cela ne sera pas satisfaisant si lescomposants du service ne sont pas disponibles ou fonctionnent mal.

L’exploitation doit assurer la stabilité des infrastructures tout en s’adaptant aux évolutions d'affaires et technologiquesquelquefois sous une forte pression des organisations clientes (signature d’un gros contrat par ex.).

6


Module

1

Conflit n°3 : Qualité de service contre coût de serviceIl faut :

délivrer en continu les niveaux de service convenus aux utilisateurs et clients et

être au niveau optimal de gestion des coûts et des ressources

Conflit n°4 : Réactivité contre pro-activitéLes deux attitudes à concilier sont les suivantes :

organisation réactive : ne fait rien jusqu’à ce qu’un facteur externe l’oblige à réagir (on constate que les acteursne "s'éclatent" que lorsqu'il y a des incidents importants ou majeurs mais qu'ils ne font rien pour diminuerl'apparition de tels événements)

organisation pro-active : tout le temps en recherche d’amélioration de l’existant au-delà de ce qui est nécessaired'un point de vue VOI (Value On Investment ou valeur sur investissement)

7


Module

1

Réf. ITSM_M0500-V010-003

8


Module

1

Réf. ITSM_M0500-V010-004

9


Module

1

Réf. ITSM_M0500-V010-005

10


Module

1

Réf. ITSM_M0500-V010-006

EvénementChangement d’état significatif pour la gestion d’un service informatique ou de tout autre élément de configuration.

AlerteSignale qu’un seuil a été atteint.

AvertissementNécessite une intervention humaine (le début du processus est très souvent automatisé et géré par des outils desupervision).

IncidentInterruption non planifiée d’un service informatique ou réduction de la qualité d’un service informatique.

Demande de serviceDemande formelle d’un utilisateur et qui n’est pas un incident.

11


Module

1

Réf. ITSM_M0500-V010-007

Gestion des événements Gérer les événements tout au long de leur cycle de vie (supervision)

Gestion des incidents Dépanner les utilisateurs le plus rapidement possible

Exécution des requêtes Traiter toutes les demandes de service

Gestion des accès Traiter toutes les demandes d’accèsS’assurer que les droits d’accès sont correctement octroyés

Gestion des problèmes Traiter les problèmes et erreurs connues tout au long de leur cycle de vie

12

Gestion des événementsITIL® - Exploitation des services

Module

2

Réf. ITSM_M0510-V010-001

13


Module

2

Réf. ITSM_M0510-V010-002

14


Module

2

Réf. ITSM_M0510-V010-003

15


Module

2

Réf. ITSM_M0510-V010-004

16

Gestion des incidentsITIL® - Exploitation des services

Module

3

Réf. ITSM_M0520-V010-001

17


Module

3

Réf. ITSM_M0520-V010-002

Exemples d'incident

application : application non disponible, erreur programme empêchant l’utilisateur de travailler, nombre d'E/Sdisques excessif

matériel : système HS, remontée d’alerte automatique, sortie imprimante bloquée

Extensions de la définition d'un incidentLa version 2 de ITIL® définissait un incident comme « tout événement qui ne fait pas partie du fonctionnementstandard d’un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service. »

Le terme incident est généralement compris comme un dysfonctionnement signalé par un utilisateur. Cependant, deuxextensions à cette définition sont généralement utilisées car elles vont suivre le même processus de traitement que lesdysfonctionnements proprement dits et sont donc assimilés à des incidents :

les demandes pour un nouveau service (ou l’extension d’un service existant) sont considérées comme desdemandes de service mais assimilées à des incidents en pratique (traitement identique dans l'outil de gestion destickets) et traitées dans le cadre de la gestion des incidents (pour ITIL®, il s'agit d'une extension abusive car ellessont traitées par un processus à part)

les remontées d’alertes automatiques (espace-disque saturé par exemple) : elles sont souvent considéréescomme faisant partie de l’exploitation courante ; ces événements sont parfois traités comme incidents dans lecadre de la gestion des incidents même si le service délivré aux utilisateurs n’est pas encore affecté

18


Module

3

Réf. ITSM_M0520-V010-003

Entrées du processusEn entrée du processus, nous retrouvons :

détails des incidents (du centre de services et des différentes sources automatiques)

détails des configurations (gérées par le CMS)

recherches de correspondances (matching) entre incidents et problèmes et erreurs connues

détails de résolution des incidents de nature similaire

retour des demandes de changement en correction d’un incident

Sorties du processusEn sortie du processus, nous avons :

routage des demandes de service

demandes de changement et de demandes de changement standard pour résoudre certains incidents

mise à jour de la base des problèmes et des erreurs connues

communication aux utilisateurs (pendant l’avancement et à la fermeture)

rapports de performance du processus

Séquence des activités du flux de traitement d'un incidentLe traitement d'un incident passe par les étapes suivantes :

1. IdentificationIl s'agit de séparer les incidents des demandes de service ; ces dernières seront redirigées vers le processus d'exécutiondes requêtes.

2. Enregistrement (ou journalisation)Cette étape est simplement la création du ticket d'incident

3. Catégorisation

19


Module

3Cette étape consiste à remplir les données du ticket d'incident, en particulier les catégories pouvant être renseignées àce stade.

4. Définition de la prioritéLe calcul de la priorité de l'incident est destinée à aiguiller le plus vite possible les incidents majeurs vers leur procédurede traitement spécifique et à prioriser le diagnostic et la résolution des différents incidents en cours.

5. Diagnostic initialCela consiste, pour le rôle de support de niveau 1 (joué par le centre de services) à trouver une solution évidente ou àtrouver une solution dans l'ensemble des bases à disposition (documentation de support, incidents similaires déjàrésolus, problèmes en cours, erreurs connues, etc.) ; dans le cas contraire ou après un certain délai, il faudra réaliserune escalade fonctionnelle vers un groupe de support de niveau 2

6. Investigation et diagnosticCes actions sont réalisées par les groupes de support 2 et supérieur (y compris des sous-traitants avec lesquels ont étépassés des contrats de support); le principe est d'identifier le plus rapidement possible une solution pour résoudrel'incident et non pas d'essayer de comprendre tout ce qui s'est passé (voir processus de gestion des problèmes).

7. Résolution et rétablissementIl s'agit d'appliquer la solution définitive ou la solution de contournement la plus rapide pour résoudre l'incident etdépanner l'utilisateur ; certaines résolutions se traduisent par une demande de changement ou une demande dechangement standard.

8. Bilan et clôtureRéalisée par le support de niveau 1, cette activité peut intégrer les tâches suivantes :

confirmer la résolution avec l’utilisateur ou l'initiateur (celui qui a signalé l'incident)

préciser les catégories du ticket d'incident (en particulier la catégorie de la solution apportée) ou corriger celles quisont déjà précisées

compléter l’enregistrement de l’incident

vérifier que les détails de la solution sont clairs et lisibles

vérifier que les codes de refacturation sont renseignés (cost-centre)

vérifier que les temps passés sur l’incident sont renseignés

envoyer un questionnaire de satisfaction à l'utilisateur

créer un problème car l'origine de l'incident n'est pas clairement établie ou n'est pas réglée (ce qui risque de voirrevenir le même type d'incident)

Quelques remarques sur cette séquence d'activités

le centre de services est responsable de l’aboutissement de tous les incidents enregistrés (il est le propriétaire detous les incidents)

le processus de traitement est purement réactif

les incidents ne pouvant pas être résolus dans un délai raisonnable doivent être assignés aux groupes despécialistes (niveaux de support supérieurs à 1, le centre de services

la résolution ou une solution de contournement doit intervenir le plus vite possible pour rétablir le service impacté

Préconisations sur la gestion du ticket d'incidentTout au long du cycle de vie de l’incident, l’enregistrement doit être à jour pour permettre à n’importe quelle personne del’équipe du centre de services de communiquer sur l’incident simplement en consultant l'enregistrement.

Il est nécessaire de conserver la description originelle de l’incident même si la description en cours évolue. Par exemple,un utilisateur signale un incident avec son imprimante (son édition ne s'imprime pas). Après investigation, il s'agit enréalité d'un problème réseau mais, lorsque l'incident est clos, il est préférable que le centre de services préviennel'utilisateur simplement en lui précisant que son souci d'imprimante est réglé plutôt que de lui expliquer le problèmeréseau et sa résolution.

Il faut aussi conserver un historique des modifications sur l’enregistrement de l’incident. Tous les changements d'étatdoivent être tracés (date/heure, personne qui a provoqué le changement, etc.). Ce point est aussi un point imposé par le

20


Module

3processus de gestion des configurations (les tickets d'incidents sont aussi sous le contrôle de ce processus).

Si l’une des équipes n’a pas accès à l’outil de gestion des incidents, il est impératif de bien mettre en place uneprocédure de mise à jour de ces enregistrements à faire lors des interventions de ces équipes (par exemple:maintenance tierce ou support de nuit n’ayant pas accès à l’outil durant la nuit).

21


Module

3

Réf. ITSM_M0520-V010-004

22


Module

3

Réf. ITSM_M0520-V010-005

Les incidents majeursLes incidents majeurs sont ceux pour lesquels le degré d’impact sur l’ensemble des utilisateurs et sur les affaires estextrême.

Devraient être considérés comme incidents majeurs les incidents pour lesquels l’échelle de temps des perturbationsdevient excessif au regard des temps de résolution (SLAs) (même si cela impacte un petit nombre d’utilisateurs).

Le gestionnaire des problèmes devrait être averti (s’il ne l’est pas déjà) afin d’organiser une réunion (ou une série deréunions) avec toutes les parties concernées :

équipes de support internes

équipes de support des matériels/logiciels (et/ou mainteneur)

équipes de gestion des environnements de production

Le centre de services devrait participer à ces réunions et enregistrer dans la base d’Incidents toutes les actions prises etles décisions.

Nous pouvons considérer qu'il s'agit là d'une période de crise qui ne peut pas être décrite de manière exhaustive dansune méthode car l'important est d'agir vite malgré le nombre peut-être important d'intervenants.

Cependant, on peut en déduire en pratique deux points à avoir en mémoire :

le traitement des incidents majeurs est sous la responsabilité du gestionnaire des problèmes

une information à jour et une communication cohérente sont importantes (évolution très rapide des informations etun besoin très fort en informations des équipes opérationnelles impliquées et des clients et utilisateurs impactés) ;ce rôle est rempli par le centre de services qui doit collecter ces informations et les enregistrer au niveau de oudes incidents déclarés.

23


Module

3

Réf. ITSM_M0520-V010-006

24


Module

3

Réf. ITSM_M0520-V010-007

Escalade fonctionnelle et escalade hiérarchique

Escalade fonctionnelleC'est l'escalade traditionnelle et prévue dans le processus pour transférer un incident d’un niveau au niveau supérieur.

Cette escalade peut intervenir dans deux cas :

par manque de connaissance ou d’expertise du niveau en cours

par dépassement d’un délai (à définir avec précaution et ne pas dépasser les délais des accords de niveaux deservice)

Escalade hiérarchiqueCe type d'escalade n'est pas réellement prévue dans le processus. Cependant, en pratique, on constate que cetteescalade existe et est nécessaire au bon fonctionnement du support dans certains cas.

L'escalade hiérarchique peut intervenir à n’importe quel moment dans le cycle de gestion de l'incident lorsqu'il estévident que la résolution interviendra hors-délai ou sera insatisfaisante. Ceci demande un certain recul vis-à-vis duprocessus qui, s'il est suivi à la lettre, peut aboutir dans certains cas à des situations critiques.

Dans l’idéal , l'escalade hiérarchique devrait intervenir avant la fin du délai pour que la hiérarchie ait le temps de réagir.En pratique, on constate que l'escalade hiérarchique est utilisée lorsque les temps de résolution de l'Incident sont horsdélai.

25


Module

3

Réf. ITSM_M0520-V010-008

26


Module

3

Réf. ITSM_M0520-V010-009

Les interactions entre les processus de gestion des incidents et de gestion des problèmes sont complexes mais il estnécessaire de les maîtriser afin de bien séparer ces deux processus dont les finalités sont très différentes.

Dans le traitement d’un incident, les actions suivantes doivent être entreprises :

si l'incident semble avoir une cause inconnue, initier un problème pour déclencher le processus de gestion desproblèmes

étudier une correspondance avec les problèmes référencés et les erreurs connues

étudier une correspondance avec les incidents référencés (similaires résolus ou en cours)

si aucune solution n'a été identifiée, la gestion des incidents a la responsabilité d’en trouver une (définitive ou decontournement) avec l’impact minimum sur l’activité de l’entreprise

Les flux entre la gestion des incidents et la gestion des problèmes sont croisés :

lors de l'analyse de l'incident par la gestion des incidents pour restaurer le plus vite possible le service impacté, siune solution de contournement a été trouvée, l’information doit être transmise à la gestion des problèmes pouranalyse

lors de l'analyse du problème par la gestion des problèmes, une solution définitive ou de contournement à un ouplusieurs incidents est trouvée, la gestion des problèmes met alors à jour la base des problèmes/erreurs connueset met l’information à disposition de la gestion des incidents pour action sur les incidents liés (passage desincidents en résolu par l'application de la solution de contournement)

27


Module

3

Réf. ITSM_M0520-V010-010

28


Module

3

Réf. ITSM_M0520-V010-011

29


Module

3

Réf. ITSM_M0520-V010-012

Voici quelques préconisations utiles et quelques difficultés à prévoir lors de la mise en oeuvre du processus et saplanification.

Séquencement et calendrier

ne pas mettre en place de manière isolée des autres processus et fonctions (centre de services, gestion desproblèmes, gestion des actifs de service et des configurations, gestion des changements, gestion des mises enproduction et des déploiements)

si cela n'est pas possible, il est nécessaire d'implanter au moins en même temps centre de services et gestion desincidents (objectifs rapides ou quick wins à atteindre)

profiter des démarrages de services importants pour les intégrer tout de suite dans une gestion des incidents(même si le nombre d'utilisateurs ou le nombre d'appels ne justifient pas dans ce cas la mise en place d'un centrede services et d'une gestion des incidents)

planification de la mise en place du processus : 3 à 6 mois

mise en place du processus et consolidation : 3 mois à 1 an

choix des outils logiciels : prendre les logiciels conformes à ITIL®

CMS inexistant ou pas mis en place en même temps : intégrer les informations de configuration dans la base degestion des incidents

Difficultés à prévoir

pas d’engagement de la hiérarchie

manque de clarté des besoins d'affaires

méthodes de travail non revues

pas d’informations sur les niveaux de service

manque de connaissances des incidents résolus

manque d’intégration avec les autres processus

résistance au changement

30

Gestion des problèmesITIL® - Exploitation des services

Module

4

Réf. ITSM_M0530-V010-001

31


Module

4

Réf. ITSM_M0530-V010-002

Concepts de base

Les incidents récurrentsPour traiter correctement et rapidement un incident récurrent qui se présente, il est indispensable que les informations(conseils, solution) soient disponibles et accessibles rapidement (pertinence, facilité d’interprétation) ceci dès lespremières phases d’un incident.

Très peu d’incidents arrivant au centre de services sont nouveaux et inédits. Les équipes de support ont déjà rencontréet résolu des incidents similaires par le passé.

L’utilisation optimale de ces informations est de les documenter de telle manière que le support de premier niveaupuisse les utiliser facilement.

Plus que de l’écriture de documentationsL’information doit être indexée de manière pertinente et des examens réguliers de la pérennité des informations auregard des changements de l’infrastructure doivent être menées régulièrement.

Il faut aussi former les équipes qui vont utiliser l’information (accès, interprétation) et avoir un retour des équipes surl’utilisation de l'outil. Il faut en effet utiliser un outil logiciel intégré (transversal sur la gestion des services).

Le référentiel ITIL® suggère aussi l'utilisation de systèmes experts.

"Matières premières" des problèmes et erreurs connuesanalyse des incidents en cours (mode réactif)

analyses statistiques des incidents (mode proactif ou préventif)

analyses de l’infrastructure informatique

consultation de bases de problèmes (externes)

documentations des services (d'affaires ou techniques) mis en production

La gestion des incidents contre la gestion des problèmes ?La gestion des problèmes recherche la cause d’un ou de plusieurs incidents et y remédie.

Souvent, cet objectif est en conflit avec l’objectif principal de la gestion des incidents (redémarrer le service au plus vite).En effet, il arrive que la mise en place d’une solution de contournement soit antagoniste avec la recherche de la cause.

32


Module

4Prenons l'exemple d'un crash système :

la gestion des incidents demandera de redémarrer le système immédiatement afin de minimiser le tempsd'indisponibilité du serveur

la gestion des problèmes demandera à différer le redémarrage du système car ce redémarrage peut supprimerdes fichiers journaux contenant des informations sur l’origine du crash entraînant une perte d'informations pourtrouver la cause du crash (et beaucoup de crash systèmes demeurent mystérieux...)

33


Module

4

Réf. ITSM_M0530-V010-003

Entrées du processus

détails des incidents de la gestion des incidents

détails des configurations des bases de données de la gestion des configurations

toute solution de contournement mise en place par la gestion des incidents

Sorties du processus

génération des erreurs connues

émission de demandes de changement (RFCs ou Requests For Change)

mise à jour des enregistrements de problèmes (incluant une solution définitive et/ou de contournement)

fermeture des enregistrements de problème

34


Module

4réponse sur la correspondance entre incidents et problèmes/erreurs connues

informations de synthèse

Activités principales de la Gestion des Problèmes

Contrôle des problèmesL'objectif du contrôle des problèmes est d'identifier la cause première (élément de configuration défaillant par ex.) et defournir au centre de services des informations sur les solutions de contournement quand elles existent.

Qui définit les solutions de contournement ?

la gestion des incidents en définit dans l’urgence (une ou plusieurs)

la gestion des problèmes étudie ces solutions de contournement (et d’autres) et valide la meilleure

1. Identification et enregistrement du problème

Les différentes sources sont :

enregistrement de nouveaux incidents

analyse des incidents

analyse de l’infrastructure informatique (problèmes pouvant potentiellement générer des incidents)

incident majeur ou significatif nécessitant une solution structurelle

D'autres sources en dehors de l'exploitation des services existent, parmi lesquelles :

la gestion de la capacité

la gestion de la disponibilité

Il est à noter que :

l’organisation peut décider de ne pas lancer d’analyse sur certains problèmes (coût non justifié et classementsans suite)

l’enregistrement du problème est similaire à celui d’un incident (différence principale : pas de reprise des donnéesutilisateurs dans l'enregistrement du problème)

2. Classification du problème

Elle est similaire à la classification d’un incident :

35


Module

4catégorie : groupes de domaines techniques (calqués sur l’organisation des fonctions gestion technique et gestiondes applications)

impact : effet sur les activités d'affaires (utiliser les liens dans la CMDB et codification en relation avec lesorganisations clientes)

urgence : délai maximum que peut supporter la résolution d’un problème

priorité : ordre de traitement d’un élément dans une liste d’attente

Quelques rappels :

Priorité : il s'agit principalement d'une combinaison impact & urgence mais aussi de risques de défaillance et dedisponibilité des ressources ; la priorité est à modifier en utilisant le bon sens et en ayant à l’esprit les activitésd'affaires (ne pas appliquer systématiquement à la lettre ce que donne la combinaison impact & urgence)

Impact : l'une des difficultés est qu'il s'agit d'une classification à un instant donné (elle peut évoluer dans le temps).Par exemple, l'un des facteurs est l'évolution du nombre d'incidents associés au problème en cours de résolution(ce nombre peut devenir préoccupant au fil du temps et peut nécessiter d'augmenter la priorité pour que leproblème soit résolu plus rapidement). C'est pour cela qu'il est intéressant de définir un compteur d’incidentsassociés à un problème et de définir des seuils de dépassement de ce compteur afin d'alerter automatiquementen cas de dépassement de ce seuil

3. Investigation et diagnostic sur le problème

La création d'une erreur connue nécessite d'identifier le ou les éléments de configuration à l'origine des incidents. Siaucun élément de configuration est directement en cause, il peut être intéressant de créer un élément de configurationfactice pour travailler ensuite sur l'erreur connue.

Voici un exemple : beaucoup d'incidents sont liés à un manque général et connu de formation des utilisateurs. Il estpossible alors de créer un élément de configuration « problème de formation » et associer le problème et l'erreur connuesur cet élément factice.

Attention : les spécialistes travaillent souvent sur la résolution des incidents (prioritaire) et la résolution des problèmes etil est nécessaire de bien équilibrer le temps passé sur ces deux processus.

Contrôle des erreursL'objectif est d'éradiquer les erreurs connues en émettant vers la gestion des changements des demandes dechangement (RFCs) et en les suivant jusqu’à leur mise en place effective.

Il faut donc être au courant des erreurs existantes, il faut les surveiller et les éradiquer quand cela est possible etjustifiable budgétairement.

36


Module

41. Identification et enregistrement de l'erreur

Une erreur est identifiée lorsque l’élément de configuration (CI) en faute est identifié.

Le statut d’erreur connue est assigné lorsque :

la cause première du problème est trouvée ET

une solution de contournement a été trouvée

Deux sources d’erreurs connues existent :

celle de l’environnement de production

celle des environnements de développement et de test (livraison d'application avec des erreurs connues)

2. Evaluation de l'erreur et enregistrement de la résolution de l'erreur

L’équipe de gestion des problèmes fait une évaluation initiale de l’erreur. Si nécessaire, elle initialise une demande dechangement (RFC) transmise à la gestion des changements.

Les étapes finales de la résolution (analyse d’impact, évaluation complète, modification de l’élément de configuration,test de validation) sont sous le contrôle de la gestion des changements.

L'enregistrement détaillé de la résolution est essentiel pour la gestion des incidents lors de l'apparition d'incidentsrécurrents.

3. Contrôle des erreurs pour les environnements applicatifs

Le processus est sensiblement le même dans l’environnement de production et dans l’environnement dedéveloppement :

Il y a des échanges cycliques entre la gestion des problèmes des deux environnements.

4. Fermeture de l'erreur et des problèmes associés

Après la mise en place du changement correctif :

préconisation : à la fermeture de l’erreur et des problèmes, utiliser un statut provisoire « Closed pending PIR » ou« Fermé, en attente de validation » (PIR=Post Implementation Review)

5. Surveillance et suivi des erreurs

La mise en place des changements s'effectue sous la responsabilité de la gestion des changements et est suivie par lagestion des problèmes.

En attendant la mise en place effective du changement, il faut surveiller les incidents et problèmes relatifs à l’erreurconnue et déclencher une alerte si dépassement d’un seuil (nombre) défini dans le cadre des accords de niveaux deservice (SLAs). Cela permet de décider d'augmenter la priorité d’une demande de changement par exemple.

6. Quelques remarques générales

Toutes les erreurs connues n’ont pas besoin d’être corrigées pour une raison ou une autre :

37


Module

4résolution trop chère en regard des résultats attendus

résolution techniquement impossible

trop de temps pour résoudre

Globalement, une demande de changement concerne des aspects techniques mais peut aussi adresser desmodifications

de procédures

de méthodes de travail

d’organisation

Gestion pro-active des problèmesL'objectif est d'identifier et de résoudre les problèmes avant que des incidents ne surviennent en conséquence de cesproblèmes, entraînant des perturbations pour les utilisateurs.

1. Analyse des tendances

L'objectif est d'identifier les éléments de configuration qui fragilisent l’infrastructure (impact, risque de panne).

Les sources d'informations sont, entre autres, les suivantes :

base d’incidents, de problèmes et d'erreurs connues

outil de supervision de l’infrastructure et données collectées par le processus de gestion des événements

informations externes (veille technologique)

utilisateurs (enquêtes de satisfaction, groupes de travail, etc.)

Deux types d'actions vont être envisagées selon la catégorie :

identification d’erreurs (isolées) dans l’infrastructure (transmis au contrôle des problèmes et des erreurs pourcorrection)

identification de problèmes plus généraux nécessitant des actions de fond (et traitées dans l'activité proactived'initialisation d'actions préventives)

2. Initialisation d’actions préventives

L'objectif est d'initialiser des actions préventives générales dans les domaines posant le plus de problèmes.

Il peut être utile pour analyser des statistiques de définir un facteur de pénibilité (pain factor) comme, par exemple :

volumétrie d’incidents

nombre d’utilisateurs impactés

la durée et le coût de résolution des incidents

le coût pour les activités d'affaires (en fait, le plus important)

Ceci permet une approche globale sur l’ensemble des incidents et problèmes sans se focaliser a priori sur une catégorieparticulière d'incidents ou de problèmes.

Une fois identifié, une action préventive sera initialisée. Par exemple :

donner un retour sur les tests, procédures, formation, documentations

lancer des actions de formation (utilisateurs, équipes supports)

38


Module

4

Réf. ITSM_M0530-V010-004

En plus du détail précédent, un traitement particulier est accordé à un problème majeur en fin de processus.

Un problème majeur est initié à la suite de chaque incident majeur pour

expliquer l’enchaînement des événements ayant abouti à l’incident majeur

identifier un plan d’actions pour améliorer l’environnement de production pour éviter qu’un incident majeuridentique ne se reproduise

valider et exécuter le plan d’actions

Revue des problèmes majeursL'objectif est de réaliser une réunion et de rédiger un compte-rendu avec les acteurs impliqués dans la résolution del'incident majeur pour déterminer :

ce qui a été fait correctement

39


Module

4ce qui a été fait de manière incorrecte

ce qui pourrait être mieux fait la prochaine fois

comment anticiper le problème pour qu’il ne réapparaisse plus

40


Module

4

Réf. ITSM_M0530-V010-005

41


Module

4

Réf. ITSM_M0530-V010-006

42


Module

4

Réf. ITSM_M0530-V010-007

43

Exécution des requêtesITIL® - Exploitation des services

Module

5

Réf. ITSM_M0540-V010-001

ObjectifL'objectif du processus est de traiter les demandes de service des utilisateurs :

fournir un canal pour les utilisateurs afin de demander les services standard

fournir des informations aux utilisateurs et clients au sujet de la disponibilité des services

acheter et fournir les composants demandés du service standard

assister par des informations générales au traitement des plaintes et des commentaires

44


Module

5

Réf. ITSM_M0540-V010-002

45


Module

5

Réf. ITSM_M0540-V010-003

46


Module

5

Réf. ITSM_M0540-V010-004

47

Gestion des accèsITIL® - Exploitation des services

Module

6

Réf. ITSM_M0550-V010-001

48

Gestion des accèsITIL® - Exploitation des services

Module

6

Réf. ITSM_M0550-V010-002

Réf. ITSM_M0550-V010-003

49

ITIL® - L'exploitation des services · ITILﬁ - Exploitation des services A propos du document Ce...

Documents

Transcript of ITIL® - L'exploitation des services · ITILﬁ - Exploitation des services A propos du document Ce...