Organigramme du processus de gestion des incidents
Un organigramme de processus de gestion des incidents interfonctionnels couvrant la journalisation, la priorisation, l'escalade des incidents majeurs, la violation des SLA, la résolution et la clôture.
Qu'est-ce que le processus organigramme du processus de gestion des incidents ?
La gestion des incidents est le processus permettant de rétablir un service normal le plus rapidement possible après une panne. Son objectif est volontairement restreint : remettre l'utilisateur au travail. Trouver et éliminer définitivement la cause sous-jacente est la gestion des problèmes, que ce processus confie plutôt qu'absorbe. Garder cette limite claire est ce qui empêche un centre de services de garder les tickets ouverts pendant des semaines pendant qu'un ingénieur recherche une cause profonde.
La plupart des processus d'incident échouent lors des transferts plutôt que lors du travail technique. Un ticket est enregistré sans suffisamment de détails sur son impact pour lui donner la priorité. Un incident majeur est reconnu avec vingt minutes de retard parce que personne n'a convenu à l'avance du déclencheur. Une remontée vers le niveau 2 n’est pas réclamée. Un objectif SLA n’est pas atteint et le client en entend parler après plutôt qu’avant. Un ticket est clôturé sur parole de l'ingénieur sans que l'utilisateur confirme que le service fonctionne réellement. Dessiner le processus sous forme de couloirs rend chacun de ces transferts visible et lui attribue un propriétaire.
Ce modèle cartographie le flux sur quatre voies : rapporteur/utilisateur, centre de services, gestionnaire d'incidents et niveau de support 2/3. Il inclut les deux branches que les équipes oublient le plus souvent de leur documentation, la déclaration d'incident majeur et l'escalade de la violation du SLA, ainsi qu'une boucle de réouverture lorsque l'utilisateur indique que le problème est toujours là et une branche de fermeture qui génère un enregistrement de problème lorsque la cause est encore inconnue.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre couloirs avec un propriétaire nommé pour chaque étape : rapporteur/utilisateur, centre de services, gestionnaire d'incidents et niveau de support 2/3, répartis en cinq phases, de la détection à la fermeture.
- Détection et journalisation, où « Incident détecté ou signalé » alimente « Enregistrer l'incident avec les détails de l'impact » avant le début de tout tri, afin que le ticket indique le service, la portée et les symptômes concernés.
- Catégorisation et priorisation suivies du message « Incident majeur ? » décision, dont la branche oui exécute « Déclarer un incident majeur » et « Ouvrir le pont et informer les parties prenantes » dans la voie du gestionnaire d'incidents avant de rejoindre le travail technique.
- La répartition entre première ligne et escalade : « Résolu en première ligne ? » soit va à « Appliquer le correctif de première ligne », soit remet le ticket au niveau 2/3 pour « Enquêter et diagnostiquer ».
- Le chemin de violation du SLA : « Résolution dans les limites de l'objectif du SLA ? » envoie un non à « Faire remonter la violation et mettre à jour les parties prenantes », de sorte que le client soit informé avant la fin du temps imparti, puis revient à « Appliquer le service de réparation et de restauration ».
- Confirmation et fermeture de l'utilisateur, y compris une boucle de réouverture à partir de « L'utilisateur confirme la résolution ? » retour au diagnostic initial et une « cause profonde toujours inconnue ? » branche qui génère un enregistrement de problème avant « Incident clôturé ».
Quand utiliser ce modèle
- Rédiger ou actualiser le runbook du centre de services afin que les nouveaux agents puissent voir où va un ticket et à qui appartient chaque étape.
- Convenir à l’avance du déclencheur de l’incident majeur et des délais d’escalade, plutôt que de les improviser lors d’une panne.
- Configuration d'un outil ITSM : les catégories, la matrice de priorités, les minuteries SLA et les règles d'escalade dans le graphique mappent directement sur les champs que vous devez configurer.
- Aligner une petite équipe sur la pratique ITIL sans adopter le vocabulaire complet, en utilisant des noms d'étapes simples que les gens diront à voix haute.
- Exécuter un examen post-incident du processus lui-même, en retraçant où un ticket spécifique s'est bloqué par rapport au chemin prévu.
Comment cela fonctionne
Renommez les voies selon vos vrais rôles
Remplacez Reporter/Utilisateur, Bureau de services, Gestionnaire des incidents et Support Tier 2/3 par les rôles qui existent dans votre organisation. Les petites équipes fusionnent souvent Gestionnaire des incidents dans la voie du Bureau de services ; les équipes avec un CNO ajoutent une voie de surveillance au-dessus du journaliste.
Définissez votre matrice de priorités
Joignez vos définitions d'impact et d'urgence à l'étape « Catégoriser et définir la priorité ». Notez ce que P1 à P4 signifie en termes d'utilisateurs concernés et d'impact commercial afin que la priorité soit dérivée et non négociée par ticket.
Définir le déclencheur de l'incident majeur
Décidez de ce qui constitue un « incident majeur ? » décision oui : un service affectant les revenus en panne, un système critique nommé, un seuil de nombre de clients. Nommez qui peut le déclarer et ce qui se passe immédiatement après, comme ouvrir un pont et démarrer une cadence de mise à jour fixe.
Connectez vos objectifs SLA et signalez les violations
Mettez vos objectifs de réponse et de résolution sur la case « Résolution dans les limites de l'objectif SLA ? » décision, et indiquer qui est informé de la branche de violation et combien de temps avant la date limite. L'objectif de cette branche est l'alerte précoce, et non le reporting après coup.
Accepter les règles de clôture et de gestion des problèmes
Définissez ce qui compte comme confirmé par l'utilisateur, combien de temps un ticket reste résolu avant la fermeture automatique et les critères « La cause première est toujours inconnue ? » qui poussent un incident dans la gestion des problèmes. Les symptômes récurrents et chaque incident majeur sont les déclencheurs habituels.
Parcourez-le avec chaque voie, puis publiez une copie versionnée
Passez en revue le tableau avec les personnes dans chaque couloir et corrigez les étapes qu'elles effectuent réellement. Une fois que cela est accepté, publiez-le dans la version actuelle avec une signature, afin que toute personne qui le lira plus tard sache quelle révision était en vigueur.
Questions fréquentes
Quelle est la différence entre la gestion des incidents et la gestion des problèmes ?
La gestion des incidents rétablit le service. La gestion des problèmes supprime la cause afin que l'incident cesse de se reproduire. Ils fonctionnent selon des horloges différentes : un incident est mesuré par rapport à un SLA en minutes ou en heures, tandis qu'un enregistrement de problème peut rester ouvert pendant des semaines d'enquête. Dans ce graphique, les deux se connectent à la fermeture, où « La cause profonde est toujours inconnue ? » soulève un enregistrement de problème sans laisser l'incident ouvert. Leur mélange est l'échec le plus courant, et il se manifeste sous la forme de tickets qui restent ouverts longtemps après que l'utilisateur ait retravaillé.
Quand un incident doit-il être déclaré incident majeur ?
Lorsque l'impact justifie de rompre la file d'attente normale : un service critique pour l'entreprise n'est pas disponible, un grand groupe d'utilisateurs est bloqué ou il existe un risque en matière de sécurité, de finances ou de réputation. Le déclencheur doit être écrit avant que vous en ayez besoin et être suffisamment objectif pour qu'un agent de première ligne puisse l'appliquer à 2 heures du matin. Une fois déclaré, le processus change de forme au lieu de simplement s’accélérer. Un gestionnaire d'incidents nommé s'approprie, un pont s'ouvre et les mises à jour des parties prenantes sont diffusées selon un calendrier fixe, qu'il y ait ou non des nouvelles.
Que se passe-t-il lorsqu'un incident va enfreindre son SLA ?
La branche de violation est une escalade hiérarchique et non technique. Le travail continue, mais le gestionnaire d'incidents est sollicité pour redéfinir les attentes du client, réaffecter les ressources si nécessaire et enregistrer pourquoi l'objectif n'a pas été atteint. Le détail important est le timing : la succursale doit se déclencher avant l'expiration du délai, sur la base d'un seuil tel que 75 % du temps restant, afin que la conversation avec le client ait lieu avant la violation plutôt que sous forme d'excuses après.
Qui clôture l’incident et qu’est-ce qui est considéré comme résolu ?
La résolution et la clôture sont deux états différents. Un ingénieur marque un incident résolu lorsque le correctif est appliqué et que le service est de retour. Il n'est fermé qu'une fois que le journaliste confirme que le service fonctionne pour lui. C'est pourquoi ce graphique passe par « Confirmer que le service fonctionne » dans la voie du rapporteur et par « L'utilisateur confirme la résolution ? » décision avant la clôture. Si l'utilisateur indique que le problème persiste, le ticket réouvre le diagnostic initial plutôt que d'en démarrer un nouveau. La plupart des équipes définissent également une fenêtre de fermeture automatique, généralement de trois à cinq jours ouvrables sans réponse.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus de remontée du support client (niveau 1 à niveau 2) et passe le relais à Organigramme du processus de récupération du service (restauration de la….
C'est une étape de Gestion des services informatiques.
Étape 1: Organigramme du processus de gestion des incidents Vous êtes ici
Un organigramme de processus de gestion des incidents interfonctionnels couvrant la journalisation, la priorisation, l'escalade des incidents majeurs, la violation des SLA, la résolution et la clôture.
Étape 2: Diagramme du processus de gestion des changements (ITIL)
Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.
Étape 3: Organigramme du processus de publication du logiciel