Organigramme du processus de gestion des incidents — Excel
Le processus de gestion des incidents est la séquence suivie par une équipe de service pour restaurer un service informatique perturbé : détecter et enregistrer l'incident, le hiérarchiser, diagnostiquer et faire remonter, résoudre…
Saisissez une étape par ligne dans Excel avec un identifiant unique, une description, l’étape suivante et un responsable. Le processus de gestion des incidents est la séquence suivie par une équipe de service pour restaurer un service informatique perturbé : détecter et enregistrer l'incident, le hiérarchiser, diagnostiquer et faire remonter, résoudre et récupérer, confirmer avec l'utilisateur, puis le clôturer.
En bref
- 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.
Le tableau source: Organigramme du processus de gestion des incidents
Saisissez une étape par ligne dans Excel avec un identifiant unique, une description, l’étape suivante et un responsable. 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.
Associez la description à Box text, la destination à Line to, le libellé de branche à Line text et le responsable à Vertical lane. 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. Vérifiez chaque branche et chaque responsable dans le diagramme à partir du tableau. Voir aussi /fr/guides/structurer-des-donnees-excel-pour-un-diagramme-de-flux.
Comment cela fonctionne
Renommez les voies selon vos vrais rôles
Saisissez une étape par ligne dans Excel avec un identifiant unique, une description, l’étape suivante et un responsable. 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
Associez la description à Box text, la destination à Line to, le libellé de branche à Line text et le responsable à Vertical lane. 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
Parcourez le trajet normal, les refus et les boucles dans le diagramme avant de le partager. 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.
Erreurs à éviter
Connexions manquantes
Une liste de tâches ne devient un schéma de processus que lorsque chaque étape a une destination et chaque décision des résultats nommés. 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.
Questions fréquentes
Puis-je utiliser mon fichier Excel ?
Oui. Adaptez les colonnes à l’éditeur de feuille QueryChart et vérifiez les destinations après tout changement de ligne. 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.