Comment créer un processus de gestion des incidents
Comment concevoir un processus de gestion des incidents où la gravité évalue tout en aval : classer avant de diagnostiquer, tracer une reclassification en tant qu'itinéraire et transférer la cause dans un enregistrement distinct.
Un processus de gestion des incidents restaure un service sur un chemin adapté à la gravité de l'incident, puis transmet la question de cause sans réponse à un enregistrement de problème distinct une fois le service rétabli.
En bref
- La priorité est calculée à partir des champs d'admission, et non à partir de la gravité de l'incident.
- Un chemin pour chaque incident est trop lourd pour les petits et trop calme pour les plus graves.
- L'augmentation ou la diminution de la gravité au milieu d'un incident nécessite son propre itinéraire tracé, que la plupart des graphiques omettent.
- Restaurer le service et l'expliquer sont deux processus avec un transfert entre eux.
- La fermeture nécessite la confirmation du journaliste, pas la confiance de l'ingénieur.
La gravité n'est pas un domaine, c'est le processus
La gestion des incidents rétablit un service et rend ensuite compte de ce qui s'est passé. La version que la plupart des organisations utilisent en premier est un chemin unique (enregistrer, diagnostiquer, réparer, fermer) et elle échoue dans les deux sens à la fois. C'est trop cérémonial pour l'imprimante que personne ne peut atteindre, alors les gens arrêtent de lever des tickets et appellent plutôt un collègue, et c'est beaucoup trop calme pour la panne qui aurait dû réveiller trois personnes.
La priorité est définie en fonction de l'impact et de l'urgence avant que quiconque ne sache ce qui est cassé, et tout ce qui suit est dimensionné en fonction de cet appel unique : qui est appelé, à quelle fréquence les parties prenantes ont de vos nouvelles, à quelle heure le correctif est mesuré. La classification est donc l'étape porteuse, et elle est effectuée sur des informations partielles, elle sera donc parfois erronée, ce qui signifie que la reclassification appartient à la carte comme un itinéraire tracé plutôt que comme une modification discrète d'un champ.
L'exemple présente un incident sur cinq phases et quatre voies, et la ligne qui mérite d'être examinée est « Enquêter et diagnostiquer » : un incident majeur déclaré et un ticket de première ligne n'ont pas pu régler les deux terrains dans la même case. La gravité décide qui est appelé et quelle horloge fonctionne, et non pas qui fait finalement le diagnostic : c'est la limite honnête de la proportionnalité du graphique. Notez également que « La cause première est toujours inconnue ? » est demandé au même endroit pour chaque gravité, c'est pourquoi un P1 et un P4 laissent derrière eux les mêmes preuves.
Comment cela fonctionne
Écrivez la matrice des priorités avant le graphique
La priorité est l'impact par rapport à l'urgence, et les deux nécessitent des niveaux définis : combien d'utilisateurs, quel niveau de service, si l'argent ou la sécurité est impliqué, à quelle vitesse les dommages augmentent, si une solution de contournement tient. Acceptez-les d'abord, car une matrice inventée lors de la cartographie décrit le dernier incident plutôt que le suivant.
Décidez ce qu’un incident majeur change réellement
Énumérez ce que la déclaration achète : un propriétaire nommé, un pont, des mises à jour sur une horloge fixe, l'autorisation de contourner l'approbation normale des modifications. Si rien ne change sauf l’étiquette, la branche est décoration. L'exemple passe deux étapes entières, ce qui représente la quantité honnête de travail impliquée.
Tapez l'admission et la classification sous forme de lignes
Chaque ligne de QueryChart est une boîte. Placez le déclencheur dans la colonne de texte de la zone, puis l'étape de journalisation, puis l'étape de catégorisation, et pointez chaque ligne vers la suivante dans la colonne Ligne vers. Après trois lignes, la carte a fait valoir son argument : la priorité sur la ligne 3 est calculée à partir de ce que la ligne 2 a capturé, ce qui fait de la ligne 2 une décision de conception et non un formulaire.
Forkez l'appel de gravité et étiquetez les deux sorties
Remplacez la colonne Forme de la ligne de classification par Décision, répertoriez les deux destinations dans Ligne vers, puis donnez à chaque numéro sa réponse dans Texte de ligne. Le graphique bifurque une fois, à « Incident majeur ? », bien que la matrice comporte quatre ou cinq niveaux, et ces deux étiquettes font plus de travail que n'importe quelle autre paire ici, car elles sont le seul endroit où l'itinéraire change.
Pointez le chemin de réouverture vers un numéro de ligne inférieur
Un correctif que le journaliste rejette remonte au diagnostic : la sortie "Réouvert" de la ligne 15 pointe vers la ligne 7. Une gravité appelée "mal" nécessite le même traitement et l'exemple ne le dessine pas : ajoutez une branche des lignes de diagnostic vers "Catégoriser et définir la priorité". Chacun est un nombre inférieur dans la colonne Ligne vers.
Calibrez la matrice, puis nommez qui déclare
Placez la matrice à un endroit où celui qui enregistre le ticket peut la lire, puis testez-la : donnez à deux personnes travaillant dans des équipes opposées les trois mêmes descriptions et comparez ce qu'elles ont défini. Un désaccord signifie un niveau manquant, pas un collègue négligent. Nommez ensuite la personne de chaque équipe qui peut répondre Oui à la question « Incident majeur ? » avant que le gestionnaire d'incidents ne soit réveillé.
Erreurs à éviter
Classement après le diagnostic
À ce moment-là, l’escalade importante ne s’est pas produite et le champ de priorité enregistre uniquement la gravité de la situation. L’impact et l’urgence doivent être répondus avant la cause, c’est pourquoi la ligne de classification se situe à trois.
La sévérité avec laquelle il est né
L’impact grandit ; la priorité ne l'est pas. Placé une fois dans la voie du Service Desk, il corrige la liste d'appels et l'horloge, et l'itinéraire arrière du graphique réapparaît en dessous. Dessinez une reclassification en tant qu'itinéraire et nommez qui peut l'emprunter.
Réouverture en soulevant un nouveau ticket
L'original se ferme à l'intérieur de la cible, un deuxième ticket démarre une nouvelle horloge et le rapport affiche deux correctifs rapides au lieu d'un échec. Dessinez la réouverture comme un retour au diagnostic sur le même dossier.
Enregistrements problématiques sans propriétaire
« Enregistrer un problème » est une ligne, pas un résultat. Un dossier sans propriétaire, sans date et sans lien avec les incidents qui l'ont produit est un document de clôture, et il est fermé sans être lu lors du prochain rangement. Nommez les deux lorsque vous le soulevez.
Questions fréquentes
Quelle est la différence entre un incident et un problème ?
Un incident est une interruption d'un service ; un problème est la cause sous-jacente d’un ou plusieurs incidents. Ils sont conservés comme des processus distincts car ils fonctionnent à des horloges différentes : la gestion des incidents est mesurée en fonction du temps de restauration, la gestion des problèmes dépend de la suppression effective de la cause, ce qui peut prendre des semaines. Les fusionner signifie que le travail de cause hérite de l'urgence de l'incident et est abandonné au moment du retour du service.
Comment décidez-vous de la priorité des incidents ?
De l'impact et de l'urgence sur une matrice publiée, et non de qui demande. L'impact correspond à l'ampleur de l'impact sur l'organisation : utilisateurs, sites, niveau de service, qu'il s'agisse d'argent ou de sécurité. L’urgence correspond à la vitesse à laquelle les dégâts augmentent et si une solution de contournement tient. La matrice fait de cette paire une priorité, et elle ne gagne sa place que si les chiffres derrière l’appel sont enregistrés à côté d’elle : une priorité que personne ne peut reconstruire ne peut être contestée lorsqu’elle s’avère fausse.
Quand un incident doit-il être déclaré incident majeur ?
Lorsqu'il franchit un seuil convenu à l'avance : un service de premier niveau en panne, un nombre déclaré de personnes incapables de travailler, une exposition réglementaire ou de sécurité, une suspicion de manquement. La déclaration ne gagne sa place que si elle change les comportements : un gestionnaire d'incident nommé, un pont, des mises à jour à cadence fixe. Se déclarer tardivement est un échec courant, et le coût d’une déclaration puis d’un retrait est bien inférieur au coût d’une heure de silence.
Un incident rouvert doit-il être un nouveau ticket ?
Non : rouvrez l'original, car les deux enregistrements répondent à des questions différentes. Un nouveau ticket réinitialise l’horloge de résolution et signale un échec comme deux succès, ce qui est précisément la distorsion qui cache un service instable. La réouverture sur le même enregistrement conserve l'historique au même endroit et rend le taux de réouverture mesurable, et le taux de réouverture est le signal de qualité le plus honnête qu'un processus d'incident produit.