Gestion des incidents ITIL

Atelier
Gestion des incidents
Mardi 9 Octobre 2007

2
Bienvenue …
Le thème
La gestion des incidents
Le principe
Echanger et s’enrichir mutuellement de nos expériences réussies ou
en-cours, de nos difficultés.
Confronter la théorie à des situations vécues, des contextes
particuliers.

3
Notre Objectif
Que chacun reparte avec au moins
une idée,
un élément,
une action
applicable dans son contexte

4
L’agenda
Découvrir (plénière – 30 minutes)
Retour d’expérience du groupe de travail de la gestion des problèmes
Un peu de théorie...
Expérimenter (par groupe – 1 heure 30)
Travail en groupes (5 ateliers)
(Désignation d’un « rapporteur » et d’un « secrétaire » par groupe)
Pause – (15 minutes, vers 16H45)
Restituer et synthétiser (plénière – 1 heure)
Restitution des groupes par chaque « rapporteur » (10 minutes par groupe)
Synthèse par l’expert ITIL et questions-réponses (30 minutes)
Échanges informels (Cocktail – à partir de 18h00)

5
L’équipe
Philippe HUMEAUCoordinateur
Dominique BOULAY (1)
François MALISSART (2)
Nicolas RICHARD (3)
Hervé GUERIN
Olivier CHAUVEAU
Animateurs des
ateliers
Emmanuel DIDIERExpert ITIL
Régis DE SAINT ALBINPrésident

6
L’agenda
Découvrir
Retour d’expérience du groupe de travail de la gestion
des problèmes
Expérimenter
Pause
Restituer et synthétiser
Échanges informels

7
Objectifs de la création du
groupe d’échange
Le groupe d'échange sur la gestion des problèmes a été créé
avec les objectifs suivants :
Fournir une opportunité de partage d'expérience entre personnes
en cours d’implémentation ce processus, ou en phase de
l’implémenter
Capitaliser des informations jugées utiles par ces personnes pour
les mettre à disposition des adhérents itSMF qui aborderont un
jour à leur tour l'implémentation de ce processus. Il s'agit en
particulier des informations complémentaires à ce que peuvent
apporter des formations ou du consulting.
Favoriser le renouvellement du groupe avec des nouveaux
membres au fur et à mesure que les membres existants quittent le
groupe lorsqu'ils ont été au bout des bénéfices qu'ils pouvaient en
retirer

8
Fonctionnement du Groupe
Le groupe d'échange a fonctionné sur environ 18 mois
7 personnes, avec très peu de mouvements
2 à 4 heures de réunion tous les 3 mois environ
Réunions se tenant dans les diverses entreprises
représentées

9
Quelques constats pouvant
être capitalisés par d’autres
Il ne faut pas attendre de solution « miracle »: les moyens de mise en œuvre sont
propres à chaque entreprise
Le groupe a bien fonctionné car chacun mettait en œuvre dans sa société : ce qui a
permis de présenter la démarche entreprise par entreprise
Il est nécessaire de venir avec une problématique à traiter
La diversité des entreprises représentées ou le degré d’avancement dans la mise en
œuvre du processus n’est pas un frein: chaque expérience apporte un éclairage
différent et complémentaire
La capitalisation peut se faire par les CR. Mais nous ne souhaitions pas divulguer
des informations sur nos sociétés ou sociétés clientes en dehors du groupe de
travail
Il faut avoir des membres confrontés « au terrain »
Le groupe dans sa composition n’a pas évolué. C’est difficile d’intégrer un nouveau
membre
Les fondamentaux ITIL doivent être connus
Le Groupe doit avoir une durée de vie limitée dans la temps: une réunion tous les 2
mois pendant 1 an semble un bon rythme
Il faut un minimum de formalisme: animateur, ordre du jour, compte-rendu, mais les
rôles peuvent changer à chaque fois

10
Capitalisation sur la Gestion
des Problèmes
Même si on parle de bonnes pratiques, il y a des impacts organisationnels
qui nécessitent une implication forte de la direction
Le besoin de raisonner en terme de services impacte l’organisation (ex:
équipe gestionnaires de problèmes).
L’aspect transversal d’ITIL est à intégrer:
o Il faut savoir dans quel ordre mettre en place le processus.
o La gestion des incidents est un pré requis à la réflexion sur les problèmes
o Le processus problème est aussi lié au processus de la gestion des changements: il met
en lumière le besoin de traiter ensuite la gestion des changements
o Une gestion de problème sans une CMDB minimum n’est pas possible. Par contre une
CMDB complète paraît difficile à mettre en œuvre.
La façon de mener le projet empirique n’est pas forcément à préconiser car
la formalisation n’a pas été suffisante.
Il faut le traiter comme un projet organisationnel et pas seulement un projet
autour d’un outil
Il faut une organisation connue de tout le monde, et un outil unique
transverse à plusieurs processus qui devient structurant

11
Gestion des Problèmes –
Gestion d’Incidents
Avant de mettre en place la Gestion des Problèmes, la Gestion d’Incidents
doit être opérationnelle, utilisée et optimisée:
o Opérationnelle: malgré quelques adaptations, la Gestion des Problèmes va s’appuyer sur
les mêmes procédures (organisation, circuits, outillage …)
o Utilisée: si la Gestion d’Incidents ne fonctionne pas, il est illusoire de vouloir mettre en
place une Gestion de Problèmes
o Optimisée: si la gestion d’Incidents nécessite des calages, il vaut mieux les solutionner,
plutôt que de reporter les anomalies à la Gestion des Problèmes.
Il vaut mieux réfléchir au processus avant l’outillage, mais ensuite, il est quasi
indispensable que l’outillage soit le même entre les 2 processus. Il faut donc
s’assurer que l’outillage choisi supportera d’autres processus ITIL.
Idem pour l’organisation
Une Gestion d’Incidents efficace est la 1ère
étape de la mise en place d’une
Gestion de Problèmes

12
Points de satisfaction ou
d’insatisfaction
Les échanges au sein du groupe ont été sincères et ouverts
L’apport d’expert ITSMF « de terrain » apporte un éclairage important sur
des points précis du processus ex: erreur connue
Un expert trop théorique n’apporte pas beaucoup : nous attendons des
réponses pragmatiques
Le fait de se déplacer dans les diverses sociétés a permis de découvrir
des pratiques, des méthodes, des modes de fonctionnement
Il ne faut pas oublier de se poser des questions sur les pré requis à la mise
en œuvre (ex : base de connaissance) et les liens avec les autres
processus ITIL
Le point indicateur sur la qualité du processus n’a pas beaucoup été
travaillé : comment suivre l’amélioration de la qualité de service ?
Il ne faut pas attendre de solutions toutes faites. C’est un échange.
Chacun capitalise en fonction des besoins.

13
Support itSMF
A permis la création du Groupe
itSMF a su mettre des moyens pour aider le Groupe quand cela a été nécessaire
La disponibilité des experts a été appréciée
Le dynamisme d’ ItSMF ouest est ressenti
Nous n’avons pas eu besoin de relation plus forte. Nous étions autonomes.
Nous avions besoin d’être libre dans notre mode de fonctionnement
itSMF ne devait pas « juger » notre production, mais nous avions un devoir de
restitution de cette expérience
Les bénéfices retirés par les membres du groupe auraient été moindres
sans le soutien d’itSMF Ouest et France. itSMF a été un appui, tout en
laissant le Groupe fonctionner de manière autonome

14
L’agenda
Découvrir
Retour d’expérience du groupe de travail de la gestion des
problèmes
Expérimenter
Pause
Échanges informels

15
Un peu de théorie…
Emmanuel DIDIER
Directeur de mission
ORSYP

16 © ORSYP 2006 • Confidential
Rappel de l’état de l’art

17
incident & problème
La différence
Garantir le retour au
travail de l’utilisateur
Corriger les causes de
défaillance du SI qui ont un
impact Sur le business
Garantir le retour au
travail de l’utilisateurGarantir le retour au
travail de l’utilisateur

18
incident & problème
Les avantages de différencier
Concentrer les efforts court terme sur le rétablissement du service :
Amélioration de la satisfaction des utilisateurs
Réduire l’indisponibilité et l’impact business des incidents
Meilleure gestion des niveaux de service
Améliorer la productivité des utilisateurs
Amélioration de l’efficacité du Service Desk et de la gestion des incidents (récurrence,
base de connaissance, solutions de contournement…)
Optimiser l’utilisation des ressources techniques
Améliorer la productivité des équipes de support
Réduire le volume des incidents
Apporter plus souvent des solutions permanentes
Disposer d’une vue globale sur les incidents et les requêtes
Se concentrer sur l’essentiel
Mettre en place une vrai politique pro active sur la fiabilité
Amélioration de Qualité globale du SI

19
c’est quoi ?
OBJECTIF
L’objectif de l’Incident Management est de restaurer un service nominal
défini dans le SLA, aussi rapidement que possible, avec le minimum
d’impact sur le business de l’entreprise.
L’Incident Management doit aussi garder une trace de l’ensemble des
événements pour les mesurer et permettre une analyse et améliorer
l’efficacité des processes.

20
c’est quoi ?
INCIDENT
Définition, tout événement qui ne fait pas partie du fonctionnement normal et qui entraîne ou
peut entraîner une interruption de service ou réduction de la qualité de ce service
Un incident est défini par sa priorité qui est calculée en fonction de la pondération
impact/urgence
• IMPACT, mesure de l’impact que provoque un incident sur le business de l’entreprise
• URGENCE, mesure de la rapidité de résolution souhaitée d ’un incident ou d ’un
problème
Incident majeur, sont considérés comme des incidents majeurs, les incidents ayant un
impact extrême sur l’activité des utilisateurs et des clients des services informatiques
• Mise en place d’une cellule de crise (incluant les personnes de la gestion des
problèmes)
• Escalade hiérarchique (information des niveaux supérieurs de management)
• Consignation de toutes les informations dans l’outil
• Communication
• La gestion des incidents concerne tous les
acteurs
• Cependant plus l’acteur qui résout l’incident
est proche de l’utilisateur plus le processus
est efficient

21
Les activités couvertes
Détection et enregistrement
Assurer la détection des incidents au plus tôt
Enregistrer tous les incidents
Classification et support initial
Déterminer une catégorie
Déterminer la priorité
Recherche des incidents connus
Dans la base des incidents
Dans la base des problèmes
Investigation et diagnostic
Recherche d’une solution pour que l’utilisateur
puisse travailler
Résolution et rétablissement du service
Mise en œuvre de la solution afin de rétablir le
service
Clôture de l’incident
Suivi et communication

22
Les nouveautés de la V3
sur la gestion des
incidents
Gestion des problèmes
V2
V3*
Gestion des problèmes
Gestion des
événements
Gestion des accès
réalisation des requêtes
* Attention la traduction officielle des termes n’a pas encore été validée

23
Les nouveautés de la V3
sur la gestion des
incidents
Gestion des évènements Event Management
Processus en charge de la gestion des événements tout au long de leur cycle de vie. La gestion des
événements est une des activités principales de l’exploitation des TI.
Evènement Event
Terme employé pour désigner une alerte ou une notification créée par un service des TI, un élément de
configuration ou un outil de surveillance. Les événements requièrent habituellement un personnel
d’exploitation des TI qui agit ce qui conduit le plus souvent à la journalisation d’incidents.
Alerte Alert
Avertissement qu’un seuil a été atteint, que quelque chose a changé, ou qu’une panne s’est produite. Les
avertissements sont souvent créés et gérés par les outils de Gestion du Système et sont gérés par le
Processus de Gestion des Événements.
Notion de modèle Model
Incident Model, Problem Model, Request Model

24
MERCI
Emmanuel DIDIER
Directeur de mission
ORSYP

25
L’agenda
Découvrir
problèmes
Expérimenter
Pause
Échanges informels

26
Expérimenter
Nous nous répartissons dans les groupes prévus :
Animateur :
Nicolas
RICHARD
Groupe n°3 : Comment articuler la Gestion des Incidents
et la Gestion des Problèmes ?
Animateur :
François
MALISSART
Groupe n°2 : Comment classifier les incidents pour
garantir la performance du processus ?
Animateur :
Dominique
BOULAY
Groupe n°1 : Quels sont les éléments indispensables
pour commencer ?
Expert « volant » : Emanuel DIDIER

27
Expérimenter
Déroulement de chaque groupe :
Tour de table
Désignation d’un « porte-parole »
Échanges et débats
« Visite » de l’expert
Préparation de la restitution
Les règles du jeu :
L’animateur ...
Le porte parole ...
Le secrétaire …
L’expert « volant » ...
Vous ...

28
Rendez-vous dans vos groupes
A tout à l’heure !
Expérimenter

29
L’agenda
Découvrir
problèmes
Expérimenter
Pause
Échanges informels

30
L’agenda
Découvrir
problèmes
Expérimenter
Pause
Échanges informels

Quels sont les éléments
indispensables pour commencer ?
Groupe n°1

32
Expérimenter
Groupe n°1 : Quels sont les éléments indispensables pour commencer ?
Se fixer les objectifs
Optimiser les moyens de la DSI
Améliorer le service aux utilisateurs
Communiquer entre acteurs
Définir la cartographie
Quels sont les clients ?
Quels sont leurs incidents ?
Quels sont les environnements ?
Définir le périmètre du processus
Quels éléments prend on en charge ?
Démarrer sur un périmètre partiel

33
Expérimenter
Base de connaissance
Est-ce vraiment un objectif ?
Les indicateurs
Volumétrie
Délais de résolutions
Organisation minima
Un Responsable de Processus
Un Service Desk (SPOC)
Des compétences
Un Sponsor ?

34
Expérimenter
La connaissance du métier des utilisateurs
Un outil ?
- Ne pas se laisser guider par l’outil mais le mettre en place
rapidement.
Le SLA
- Minima pour commencer, ne pas se mettre des objectifs trop
ambitieux au départ.

Comment classifier les incidents pour
Groupe n°2

36
En d’autre terme : Que signifie classifier un incident ? A quoi cela va-t-il servir ?
•Déterminer une
catégorie
•Déterminer la
priorité
1) À gérer les priorités comment gère-t-on les priorités ?
2) À identifier les typologies / catégories d’incidents
comment catégoriser les incidents pour évaluer leurs
impacts sur les services informatiques ?
3) Pérennité de la classification
4) À identifier les problèmes comment la catégorisation
des incidents peut permettre d’identifier les problèmes ?

37
Gérer les priorités – comment gère-t-
on les priorités ?
Rappel : la priorité est fonction de l’urgence et de
l’impact
Appréciation de l’urgence (par l’écoute de l’utilisateur
puis par la catégorisation ..)
Appréciation de l’impact (par l’écoute de l’utilisateur et
l’interprétation des grilles d’évaluation criticité des
services puis par la catégorisation … )
Maturité augmentant avec existence de catalogue de
service voire de SLA .. (comble de l’évolution dans le
temps de la requalification en fonction des
engagements pris)

38
comment catégoriser les incidents
pour évaluer leurs impacts sur les
services informatiques
Plusieurs approches :
Prise en compte de la qualité de l’utilisateur (sa position de VIP .., son métier de
vendeur, …)
Prise en compte du nombre d’utilisateurs impactés
Prise en compte de la criticité de l’appli, du domaine, du service impacté … avec
pondération en fonction du cycle de vie de l’entreprise (paie de fin de mois, clôture
comptable, …
Corrélation le catalogue de service et les engagements pris dans le cadre des SLA
Parmi les écueils (nombre de catégories trop important)
Parmi les bonnes pratiques :
l’appelant et l’appelé doivent parler la même langue (métier)
les informations fournies par l’utilisateur doivent être conservées

39
Pérennité de la
classification ?
La classification courante peut comprendre des items
inutilisés ou manquants et mérite un entretien régulier
L’augmentation de maturité peut permettre de passer
d’évaluations techniques à des perceptions métiers
Les changements d’organisation et/ou d’outils sont des
opportunités

40
comment la catégorisation des incidents
peut permettre d’identifier les problèmes
Pour permettre l’identification des problèmes la catégorisation des
incidents doit faciliter l’appréciation :
De la récurrence d’un incident
Du coût « business » des incidents
Un critère complémentaire d’élection d’un problème peut-être le
constat de la charge induite par son traitement

Groupe n°2 a

42
En d’autre terme : Que signifie classifier un incident ? A quoi cela va-t-il servir ?
•Déterminer une
catégorie
•Déterminer la
priorité
1) À gérer les priorités comment gère-t-on les priorités ?
2) À identifier les typologies / catégories d’incidents
comment catégoriser les incidents pour évaluer leurs
impacts sur les services informatiques ?
3) À identifier les problèmes comment la catégorisation
des incidents peut permettre d’identifier les problèmes ?

43
Gérer les priorités
L’impact
Impact => Connaissance et définition avec le métier
Impact sur l'image du service à la demande du client de la
société de service
Impact sur le chiffre d’affaire
Modulation saisonnière (pic d’activité)
Besoin de retour clair des Directions

44
Gérer les priorités L’impact
Recoupement avec PRA et la cartographie des
applications
S’appuyer sur le contrat de service
Les critères informatiques doivent céder la place au
critères métiers

45
L’urgence
Comment définir l’urgence ?
Nombre d’utilisateurs concernés par l’incident
Niveau de blocage des utilisateurs (possibilité de traiter
une autre tache)

46
L’urgence
Définir un nombre de niveau pertinent
Exploitable, restreint et parlant pour tous

Comment articuler la Gestion des
Incidents et la Gestion des Problèmes ?
Groupe n°3 U

48
Groupe 3 : Ouverture
d'un problème
Il n'est pas possible de démarrer une gestion des problèmes
sans avoir une gestion des incidents
Question : relier les incidents aux problèmes déjà connus ?
Comment faire quand on manque de temps au service desk ?
C'est à posteriori qu'on analyse la base pour déterminer les
problèmes à traiter, y compris les problèmes qu'on ne voit
pas. C'est le travail de la gestion des problèmes.
Est-ce qu'on doit ouvrir un problème pour tous les incidents
qui n'ont pas de solution ? En théorie oui, mais on le fait sur
2 critères : récurrences ou impact

49
Groupe 3 : Le lien entre
incidents et problèmes : la
classification
S'appuyer sur la classification des incidents pour
trouver les solutions de contournement est le principe
de base de la gestion des incidents.
Bien penser le référentiel de la classification :
C'est à la gestion des incidents ou à la gestion des problèmes de le
maintenir ? Divergences dans l'assistance, travail en commun voire
même confié au service qualité
Être assez fin pour pouvoir trouver la solution de contournement à
partir de la classification affectée à l'incident
C'est le reporting mensuel qui permet d'identifier les erreurs de
classification du service desk

50
Groupe 3 : Solution de
contournement
Normalement, c'est la GDP qui trouve les solutions de
contournement mais il peut arriver que le service desk
la trouve auparavant dans la gestion des incidents;
dans ce cas, elle doit être validée par la gestion des
problèmes (sauf délégation à la GDI pour certains
logiciels simples type WORD ?)
La solution de contournement est validée par l'expert.
L'expert, c'est celui, où qu'il soit, qui l'a trouvée.

51
Groupe 3 : question à
l'expert (le schéma)
Le partage des ressources entre incidents et problèmes
est possible, mais sur les experts, pas sur le niveau 1

Groupe n°3 P
Comment articuler la Gestion des
Incidents et la Gestion des Problèmes ?

53
De la gestion des incidents
vers la gestion des
problèmes
• Importance de la classification et de la bonne
identification des incidents pour repérer les
problèmes potentiels et trouver les causes:
•En mode réactif,
•En mode proactif.
• La gestion des problèmes découle de la gestion des
incidents.
•Une des bases de mesure de la gestion des
problèmes est la base de gestion des incidents
(Nombre d’incidents)..

54
De la gestion des incidents
vers la gestion des
problèmes
Comment détecter le passage en Problème? Qui décide?
Pas d’organisation pré-définie,
Il faut des rôles clairs et bien identifiés:
– Gestionnaire des problèmes (supervision, classification,
vérification et clôture)
– Exemple du « pilote » de « mini-projet ».
L’outil commun aide énormément à la mise en place d’une
organisation performante (traçabilité, …)

55
Des problèmes vers les
incidents
Fournir des solutions pour améliorer le temps de
résolution des incidents.
Classement de ces résolutions POUR les premiers niveaux, avec
une classification correspondant à la classification des incidents.
Prioritisation des incidents très claire pour
permettre d’activer le traitement des « incidents
majeurs » selon une cartographie des priorités
métier en amont du process.
On est sur du métier et non pas sur de l’outillage.
Cellule de crise à organiser, avec communication
Les « problèmes » interviennent pour faciliter la recherche de la
solution de contournement ET pour pousser à une solution
définitive.

57
Merci à tous !
http://www.itsmf.fr - info@itsmf.fr

Gestion des incidents ITIL

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Gestion des incidents ITIL

Semelhante a Gestion des incidents ITIL (20)

Gestion des incidents ITIL