Atelier Gestion des incidents. Mardi 9 Octobre 2007

Transcription

1 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. 2

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

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) 4

5 L équipe Président Expert ITIL Animateurs des ateliers Coordinateur Régis DE SAINT ALBIN Emmanuel DIDIER Dominique BOULAY (1) François MALISSART (2) Nicolas RICHARD (3) Hervé GUERIN Olivier CHAUVEAU Philippe HUMEAU 5

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 6

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 7

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 8

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 9

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 10

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 11

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. 12

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 13

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 14

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

16 Gestion des incidents Rappel de l état de l art 16 ORSYP 2006 Confidential

17 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 les caus e s de dé fa illance du SI qui ont un impact Sur le bus iness

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 18 Mettre en place une vrai politique pro active sur la fiabilité Amélioration de Qualité globale du SI

19 La gestion des incidents 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. 19

20 La gestion des incidents c est quoi? INCIDENT 20 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 incidents 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 21

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

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 23 Incident Model, Problem Model, Request Model

24 MERCI Emmanuel DIDIER Directeur de mission ORSYP 24

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 25

26 Expérimenter Nous nous répartissons dans les groupes prévus : Groupe n 1 : Quels sont les éléments indispensables pour commencer? Animateur : Dominique BOULAY Groupe n 2 : Comment classifier les incidents pour garantir la performance du processus? Animateur : François MALISSART Groupe n 3 : Comment articuler la Gestion des Incidents et la Gestion des Problèmes? Animateur : Nicolas RICHARD 26 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... 27

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

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 29

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 30

31 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? 32 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 Groupe n 1 : Quels sont les éléments indispensables pour commencer? 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? 33

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. 34

35 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? 36

37 Gérer les priorités comment gère-ton 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) 37

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 38

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 39

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 40

41 Comment classifier les incidents pour garantir la performance du processus? Groupe n 2 a

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? 42

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 43

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 44

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) 45

46 Gérer les priorités L urgence Définir un nombre de niveau pertinent Exploitable, restreint et parlant pour tous 46

47 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 48

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 49

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. 50

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 51

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

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).. 53

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é, ) 54

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. 55

56 56 Nos partenaires 2007

57 Merci à tous! info@itsmf.fr