AtelierGestion 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é GUERINOlivier 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� Un peu de théorie...
� 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èmeso 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� Un peu de théorie...
� Expérimenter
� Pause
� Restituer et synthétiser
� Échanges informels
15
Un peu de théorie…
Emmanuel DIDIER
Directeur de mission
ORSYP
16 © ORSYP 2006 • Confidential
Gestion des incidents
Rappel de l’état de l’art
17
incident & problème La différence
Ga ra ntir le re tour a u
tra va il de l’utilis a te ur
Corrige r le s caus e s de
dé fa illance du S I qui ont un
impact Sur le bus ines s
Ga ra ntir le re tour a u
tra va il de l’utilis a te urGa ra ntir le re tour a u
tra va il de l’utilis a te ur
Corrige r le s caus e s de
dé fa illance du S I qui ont un
impact Sur le bus ines s
Corrige r le s caus e s de
dé fa illance du S I qui ont un
impact Sur le bus ines s
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
La gestion des incidentsc’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
La gestion des incidentsc’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
La gestion des incidentsLes 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 incidents
Gestion des problèmes
V2V3*
Gestion des incidents
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 � Retour d’expérience du groupe de travail de la gestion des
problèmes� Un peu de théorie...
� Expérimenter
� Pause
� Restituer et synthétiser
� É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 � Retour d’expérience du groupe de travail de la gestion des
problèmes� Un peu de théorie...
� Expérimenter
� Pause � Restituer et synthétiser
� Échanges informels
30
L’agenda
� Découvrir � Retour d’expérience du groupe de travail de la gestion des
problèmes� Un peu de théorie...
� Expérimenter
� Pause
� Restituer et synthétiser � É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 objectifsOptimiser les moyens de la DSIAméliorer le service aux utilisateursCommuniquer entre acteurs
Définir la cartographieQuels sont les clients ?Quels sont leurs incidents ?Quels sont les environnements ?
Définir le périmètre du processusQuels éléments prend on en charge ?Démarrer sur un périmètre partiel
33
Expérimenter
Groupe n°1 : Quels sont les éléments indispensables pour commencer ?
Base de connaissanceEst-ce vraiment un objectif ?
Les indicateursVolumétrieDélais de résolutions
Organisation minimaUn Responsable de Processus Un Service Desk (SPOC)Des compétencesUn Sponsor ?
34
Expérimenter
Groupe n°1 : Quels sont les éléments indispensables pour commencer ?
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 garantir la performance du processus ?
Groupe n° 2
36
Comment classifier les incidents pour garantir la performance du processus ?
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
Comment classifier les incidents pour garantir la performance du processus ?
42
Comment classifier les incidents pour garantir la performance du processus ?
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
Gérer les priorités � 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
Gérer les priorités � 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.
56
Nos partenaires 2007