Passer directement au contenu principal

Livre blanc 4 min read

Simplifier la gestion du service informatique – 4ème partie

Dernière mise à jour 28 juin 2021

Pendant toutes mes années dans le secteur de l’assistance informatique, je n’ai jamais compris la différence entre incident et problème. Mes collègues et moi-même utilisions ces termes de façon interchangeable quand nous devions enregistrer des défauts et je pense que de nombreux analystes de l’assistance font de même. Dans Zendesk, les tickets de type Incident et de type Problème sont différents d’un point de vue fonctionnel, et dans les pratiques de la gestion des services informatiques, les objectifs de ces types de tickets sont distincts (bien que les professionnels de ce secteur ne soient pas tous d’accord sur ces objectifs). Même dans les pratiques ITIL™, les définitions de problème et d’incident varient légèrement selon la version que vous consultez.

Il n’est pas compliqué de comprendre pourquoi considérer la gestion des incidents et la gestion des problèmes comme deux processus indépendants peut porter à confusion, mais il est intéressant de persévérer pour les améliorations des workflows que cela peut amener. Dans un service d’assistance informatique de grande taille, vous pouvez même avoir un groupe qui se consacre uniquement à la gestion des problèmes. Nous parlerons des avantages plus tard. Commençons par nous pencher sur la différence entre incident et problème.

En termes simples, un incident est l’interruption du service fourni au client et un problème en est la cause. La gestion des incidents exige que nous rétablissions le service du client le plus rapidement possible. Dans le cadre de l’assistance informatique, un incident peut être quelque chose d’élémentaire, par exemple un membre du personnel qui a besoin que l’on réinitialise son mot de passe pour une application. Pour poursuivre avec cet exemple, si plusieurs membres du personnel ont eu besoin que vous réinitialisiez le même mot de passe, vous pouvez soupçonner qu’il se passe quelque chose d’anormal : un problème sous-jacent. Donc, en tant qu’agent d’assistance, vous allez créer un ticket de type Problème dans Zendesk pour comprendre pourquoi plusieurs employés n’ont pas réussi à se connecter. Pour résoudre ce problème, vous aurez peut-être simplement besoin de fournir des explications ou instructions aux utilisateurs, ou il peut s’agir d’un problème au niveau de l’application ou de l’infrastructure. En capturant cette enquête dans un ticket, vous favorisez un travail efficace et une attribution de responsabilité facile.

Seuls les agents de votre Zendesk doivent ouvrir des tickets de type Problème. Cela permet des rapports clairs et, en reliant les incidents connexes au problème approprié, il vous suffit de mettre un seul ticket à jour pour que votre commentaire apparaisse automatiquement dans tous ces incidents. Et quand un problème est résolu, tous les incidents associés le sont aussi.

Mais un problème ne se résout pas seulement par la recherche réactive d’une ou plusieurs causes, il peut aussi entraîner une correction proactive d’interruptions de service potentielles. Prenez par exemple une panne de disque serveur. Le serveur fonctionne toujours et le service n’est pas interrompu grâce à la redondance du système, mais si les autres disques tombent en panne, les tickets d’incidents risquent d’affluer. Vous pouvez donc ouvrir un ticket de problème pour rechercher la cause de la panne du disque et remplacer ce dernier avant que vos clients ne soient affectés.

Comme je l’ai mentionné précédemment, la séparation des processus de gestion des incidents et des problèmes présente plusieurs avantages. L’objectif de la gestion des incidents étant de rétablir le service de vos clients le plus rapidement possible, il est recommandé de transférer les problèmes à un groupe ou un responsable se consacrant uniquement aux problèmes. Ce groupe ou responsable peut prendre le temps nécessaire pour enquêter sur les causes sans affecter négativement vos rapports d’incident ni détourner des personnes de leurs tâches immédiates, consistant à rétablir le service. Un bon processus de gestion des problèmes peut aussi contribuer à un processus de conduite du changement de qualité.

Certains services d’assistance informatique ne peuvent pas se permettre d’avoir des ressources dédiées, mais au moins, avec une bonne compréhension de la différence entre incident et problème, vous pouvez créer des chemins de remontée et des rapports plus clairs et ainsi fournir une assistance informatique plus axée sur le client.

Ceci constitue la quatrième partie d’une série axée sur l’approche Zendesk visant à Simplifier la gestion du service informatique. Voici le reste de la série.
Première partie : Traitez vos utilisateurs comme des clients
Deuxième partie : Conduite du changement.
Troisième partie : Satisfaction des clients.

En savoir plus sur Zendesk pour l’informatique

Articles associés

Article
5 min read

Comment fonctionne le score NPS ?

Le Net Promoter Score en bref Le score NPS, ou Net Promoter Score, est un indicateur…

Article
8 min read

Les macros Zendesk, pourquoi et pour quoi faire ?

La productivité de votre centre d’assistance dépend de la capacité des agents à répondre rapidement aux…

Article
6 min read

Exemples de scénarios de chatbot en finance

Parce que l’efficacité et la rapidité sont particulièrement cruciales en matière de finances personnelles, le chatbot…

Article
5 min read

Comment établir une analyse de sentiment pour centre d'appel

Les clients sont une incroyable source d’informations pour votre entreprise. Qu’ils soient contents ou mécontents, leur…