Gestion des incidents ITIL

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



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







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 problèmes

V2V3*


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



� Expérimenter

� Pause



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



� Expérimenter

� Pause � Restituer et synthétiser


30

L’agenda



� Expérimenter

� Pause

� Restituer et synthétiser � Échanges informels

Quels sont les éléments indispensables pour commencer ?

Groupe n° 1

32

Expérimenter


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


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


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


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

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

57

Merci à tous !

http://www.itsmf.fr - [email protected]

Gestion des incidents ITIL

Technology

Transcript of Gestion des incidents ITIL