Gérer le processus de gestion des incidents comme un pro des opérations informatiques

Identifier un incident et le consigner

Un incident peut avoir de multiples causes. Un employé peut vous appeler pour le signaler, ou il peut littéralement tomber du ciel, si votre hub réseau n'est pas au point. (Non pas que nous parlions d'expérience… *hum*)

Quelle que soit la source, les deux premières étapes sont simples : une personne identifie un incident et une autre le consigne.

Si l'incident qui vous est communiqué est déjà consigné par votre centre de services, vous pouvez ignorer ces deux premières étapes. Si vous recevez un appel téléphonique ou si l'incident est signalé par e-mail, par SMS ou par pigeon voyageur, l'équipe du centre de services doit le consigner correctement dans votre centre de services.

Ces journaux d'incident (c.-à-d. les tickets) comprennent généralement ce qui suit :

• le nom de la personne qui signale l'incident ;
• la date et l'heure de signalement de l'incident ;
• une description de l'incident (le composant en panne ou qui ne fonctionne pas correctement) ;
• un numéro d'identification unique assigné à l'incident, pour le suivi.

Catégorisez votre incident

Les deux étapes suivantes (catégorisation et priorisation) sont à la fois critiques et souvent négligées. Elles séparent aussi les centres de services les plus « sains » avec lesquels je travaille depuis… pas tellement longtemps en fait.

Tout d'abord, vous devez assigner une catégorie logique et intuitive (et une sous-catégorie, selon les besoins) à chaque incident. Si vous ne le faites pas, vous limitez votre capacité à analyser ultérieurement vos données et à rechercher des tendances et des schémas, ce qui constitue un élément essentiel de la gestion efficace des problèmes et de la prévention des incidents futurs.

Par conséquent, n'oubliez pas d'assigner. En outre, optez pour une solution de centre de services informatique qui vous permet de personnaliser facilement les catégories d'incident.

Hiérarchisez votre incident

Ensuite, chaque incident doit se voir assigner une priorité.

Pour prioriser un incident, commencez par évaluer son impact sur l'entreprise. Tenez compte du nombre de personnes qui seront touchées et des répercussions potentielles de l'incident en termes de finances, de sécurité et de conformité. Vous pourrez ainsi déterminer les conséquences de l'incident et l'urgence avec laquelle l'entreprise doit le régler.

La bonne pratique consiste à définir vos niveaux de gravité et de priorité avant qu'un incident ne se produise, ce qui simplifie l'évaluation de la priorité pour les gestionnaires d'incident.

Lorsque vous avez des doutes sur le niveau de priorité, optez pour le niveau le plus élevé. Mieux vaut prévenir que guérir.

Une fois que vous avez défini ces priorités, traitez tous les incidents en cours par ordre de priorité. La plupart des organisations établissent des accords de service clairs autour de chaque niveau de priorité, afin que les clients connaissent les délais de réponse et de résolution. Je recommande vivement cette pratique.

Répondre

Le terme de réponse aux incidents a une acception large. Décomposons-le et analysons les étapes que vous êtes le plus susceptible de suivre lorsque vous aurez identifié, catégorisé et hiérarchisé un incident.

Diagnostic initial
Ce diagnostic s'apparente au tri effectué par un hôpital sur les nouveaux patients. L'employé du centre de services formule rapidement une hypothèse sur le problème, afin de pouvoir s'attaquer à sa résolution ou de suivre les procédures appropriées et compiler les bonnes ressources pour le résoudre.

Dans ce contexte, les bases de connaissances et les manuels de diagnostic constituent également des outils utiles.

Si l'agent du centre de services en première ligne est en mesure de résoudre l'incident en fonction de ses diagnostics initiaux et des connaissances et outils disponibles, l'incident est résolu. Sinon, faites remonter l'incident.

Remontée de l'incident
Le terme « remontée » peut sembler péjoratif, mais ce n'est pas le cas.

Votre équipe de support de première ligne devrait être en mesure de résoudre un grand nombre d'incidents les plus fréquents sans remontée. Pour les autres, l'objectif est de rassembler et de consigner les informations adéquates pour aider l'équipe de support de niveau 2 et 3 (plus technique) à les comprendre rapidement afin de les résoudre dans les meilleurs délais.

Enquête et diagnostic
Beaucoup considèrent cette étape comme propre à ITIL. En réalité, elle apparaît tout au long du cycle de vie de l'incident.

Votre agent de support en première ligne enquête déjà, dans une certaine mesure, lorsqu'il recueille des informations, et peut même diagnostiquer et résoudre l'incident sans qu'il soit nécessaire de le faire remonter.

Dans ce cas, vous pouvez passer aux étapes suivantes : résolution et récupération, et clôture de l'incident.

Sinon, l'enquête et le diagnostic seront réalisés à chaque étape du processus lorsque vous faites remonter un problème à l'équipe de support de niveau 2 et 3 ou que vous impliquez des ressources externes ou d'autres membres du service pour vous aider à le résoudre.

Résolution et récupération
Enfin (et dans l'idéal), dans le cadre de vos accords de niveau de service (SLA), vous établirez un diagnostic et suivrez les étapes nécessaires pour résoudre l'incident. La récupération implique simplement le temps nécessaire pour reprendre le cours normal des opérations, car certaines corrections (comme les corrections de bug, par exemple) peuvent nécessiter des tests et un déploiement, et ce, même après que la résolution appropriée a été identifiée.

Clôture de l'incident
L'incident est ensuite renvoyé au centre de services (s'il a fait l'objet d'une remontée) pour être clôturé. Afin de maintenir la qualité et d'assurer un processus en douceur, seuls les employés du centre de services sont autorisés à clôturer les incidents. En outre, le propriétaire de l'incident devrait vérifier auprès de la personne qui l'a signalé que la résolution est satisfaisante et que l'incident peut réellement être clôturé.

Conclusion : ne sautez pas d'étape

Le processus peut sembler inutilement formel, surtout si vous disposez uniquement de quelques analystes du centre de services. Mais quelle que soit la structure de votre équipe, le cycle de vie de l'incident reste le même.

Supposons que vous disposiez uniquement d'un analyste du centre de services, donc qu'aucun support de niveau 3 n'est a priori disponible. Cela dit, et vous en conviendrez, les incidents qui dépassent les connaissances de votre analyste doivent être signalés, que ce soit à votre ingénieur en chef, à un consultant externe ou à vous-même.

Voilà ! Vous disposez donc d'un support de niveau 2 ou 3 : votre ingénieur ou vous-même.

Conclusion ? Même si ITIL peut sembler se réduire à une question de sémantique, ne vous laissez pas piéger. Recherchez des moyens simples d'adapter votre hiérarchie organisationnelle et vos workflows de processus pour qu'ils s'intègrent dans un framework de gestion des services informatiques simple (déjà évoqué plus haut).

Ce faisant, vous fournirez un meilleur service client et une plus forte valeur ajoutée à votre entreprise. (De plus, votre cerveau arrêtera de s'enflammer, donc c'est gagnant-gagnant !)

Terminons par quelques rappels :

• Consignez chaque incident. Attribuez-lui un numéro unique. Capturez les informations importantes (comme la date, l'heure et la description) dans un système de centre d'assistance centralisé.
• Si le public interne ou externe à qui communiquer les mises à jour des incidents est conséquent, envisagez de créer une page d'état dédiée à la communication des incidents.
• Assignez une catégorie à chaque incident (et une sous-catégorie, selon les besoins).
• Attribuez un niveau de priorité à chaque incident et un SLA à chaque niveau de priorité.
• Définissez clairement les rôles des intervenants en cas d'incident, comme le coordinateur gestion des incidents, le responsable de la gestion des incidents majeurs et le responsable des communications.
• Dans la mesure du possible, fournissez à votre équipe de support en première ligne des articles de base de connaissances et des scripts de diagnostic d'incident pour l'aider à résoudre rapidement les incidents.
• Assurez-vous que le centre de services garde toujours le contrôle de la progression, du routage et de l'état de l'incident.
• Enfin, ne vous contentez pas de capturer les données d'un incident. Analysez-les ! Recherchez les tendances, les schémas et les éventuels problèmes sous-jacents qui peuvent réduire le volume des incidents et atténuer les risques.

À propos de l'auteur