Dans le chapitre précédent, vous avez déjà déroulé les 2 premières étapes du cycle de vie d’un ticket d’incident : ✅enregistrement des symptômes (la première étape du processus doit être efficace et rapide pour qu’il y ait le moindre impact sur l’activité métiers) et ✅classification (tout premier niveau d’analyse : gravité et composant technologique touché).
Nous allons voir maintenant toutes les étapes suivantes : analyse/diagnostic (l’investigation), résolution/réponse (le rétablissement, et plus particulièrement comment résoudre ou faire résoudre le ticket d’incident en escaladant vers une autre personne ayant la compétence nécessaire au dépannage) ; et enfin la clôture du ticket d’incident.
Résolvez le ticket par vous-même
Le technicien qui enregistre et classifie l’incident représente le niveau 1 de support (N1). Il doit effectuer le diagnostic initial (déterminer exactement ce qui ne fonctionne pas) et tenter de corriger.
Ainsi et si possible, le technicien qui a pris l’appel (N1) résout immédiatement l’incident pendant que l’utilisateur est au téléphone : réparation immédiate (temporaire ou définitive), solution de contournement évidente ou résolution après consultation d’une procédure de rétablissement du service.
Impossible d’avoir en tête toutes les solutions d’incident, mais pour vous aider, vous recherchez dans la base de connaissances de GLPI la procédure standard de dépannage qui correspond à l’incident (si l’erreur est connue ou fréquente), via le Menu Outils > Base de connaissances et dans notre cas, recherche sur le critère Poste de travail
L’incident est résolu par vous-même : vous renseignez alors le ticket dans GLPI comme "résolu" si la solution appliquée est approuvée par l’utilisateur.
C’est le cas dans notre exemple de ticket de panne du poste de travail : vous avez piloté à distance le demandeur pour qu’il vérifie l’alimentation électrique de son poste de travail : il s’est aperçu que sa rallonge électrique était sur OFF…
Dans GLPI, vous accédez au traitement du ticket (via le menu vertical à gauche : onglet Traitement du ticket). Cliquez sur le bouton Solution.
Choisissez le type de solution dans la liste déroulante : Branchement électrique.
Remplissez la description de la solution : « Sans blague, Monsieur Lodez avait marché sur le bouton ON/OFF de sa rallonge électrique et l'a éteinte sans s'en rendre compte !!!! Bref, une fois remis sur ON, le poste de travail a redémarré normalement... »
Et cliquez sur le bouton Sauvegarder.
GLPI se positionne immédiatement sur l’écran d’approbation de la solution par le demandeur (et donc de clôture du ticket). Vous saisissez un commentaire qui montre que le demandeur est d’accord avec la solution apportée : M. Lodez, vexé, me remercie cordialement de l’avoir dépanné. Cliquez sur le bouton Approuver la solution.
Le ticket passe alors en statutClos.
Note sur les types de solution :
la configuration des types de solution se fait dans GLPI via le menu Configuration > Intitulés, dans le pavé Assistance. Chaque entreprise paramètre les types de solution comme elle le souhaite. Voici une autre typologie :
solution de contournement,
solution définitive ;
nous pouvons aussi configurer des gabarits de solution : ce sont des modèles déjà prérédigés qui permettent en un clic de remplir tous les champs liés à la solution (gain de temps de saisie).
GLPI permet aussi de lier des tickets, pour faciliter le traitement d’incidents déclarés par plusieurs personnes.
Lorsqu’un service utilisé par de nombreux utilisateurs est planté, le centre de services reçoit plusieurs appels, plusieurs mails sur l’incident. En tout début d’incident, n’ayant pas conscience qu’il s’agit du même incident, plusieurs techniciens créent chacun un ticket.
GLPI permet de rattacher un ou plusieurs tickets à un ticket parent. C’est un gain de temps pour le centre de services : l’historique des actions menées sur le ticket parent concerne aussi les tickets enfants, sans avoir à mettre à jour chacun des tickets enfants.
Prenons le cas du ticket n° 11 :
Le technicien s’aperçoit que l’incident a déjà été enregistré via le ticket 9, qui est déjà dans un statut « résolu » :
Sur le ticket le plus ancien concernant cet incident (ici le ticket 9), indiquer dans le détail du ticket que le ticket lié est le 11 et sauvegardez le ticket 9.
Lors de la consultation du ticket 11, on voit que celui-ci est lié au ticket 9.
Garantissez la résolution de l'incident
Dans la section précédente, vous avez pu résoudre vous-même l’incident. Ce n’est pas toujours le cas : il faut parfois faire appel à un collègue qui a une compétence pointue (connaissances techniques approfondies), et qui pourra résoudre l’incident dans le délai de résolution défini dans le SLA.
Attribuez le ticket en escalade au niveau 2
Lors de cette escalade fonctionnelle du niveau 1 vers le niveau 2, la première des choses que vous faites est d’informer le demandeur en toute transparence : « Je transfère votre ticket numéro nnn au niveau 2 ».
Prenons un nouvel exemple : l’équipe DSI de développement travaille sur une nouvelle version du site web d’e-commerce et souhaite la passer dans un environnement de tests. Mais l’équipe de développement n’arrive pas à se connecter à la machine virtuelle (VM) de tests pour y déployer la nouvelle version. Madame Lise Javabien envoie un mail au centre de services…
Dans GLPI, vous attribuez le ticket à la personne ou au groupe de personnes de niveau 2. Celle-ci est informée par mail directement envoyé par GLPI (lorsque la configuration des notifications par mail est activée/ paramétrée ; sinon, informer par téléphone). Dans l’exemple, le ticket est attribué à Monsieur Sam Soungue (administrateur système de niveau 2).
Le niveau 2 prend alors en charge le ticket pour le résoudre.
Attribuez le ticket en escalade au niveau 3
Poursuivons l’exemple avec Monsieur Sam Soungue (N2) qui ne parvient pas à trouver de solution (ici, il n’arrive pas à redémarrer la VM).
Dans ce cas, le niveau 2 effectue une nouvelle escalade fonctionnelle, vers le niveau 3 (N3) : dans GLPI, Sam Soungue (N2) attribue ainsi le ticket au N3 : Monsieur Lee Nuxe (ingénieur système de niveau 3).
À noter, les personnes de niveau 3 sont généralement de 2 profils : technique (infrastructure système, réseau…) ou applicatif (pour les incidents de type bug sur application métier).
Le N3, finalement, a rebooté le serveur physique sur lequel est installée la VM. Celle-ci fonctionne maintenant normalement. Il indique la solution dans GLPI. Je reprends la main sur le ticket pour le clore après approbation du demandeur.
L’ensemble des acteurs sollicités sur le ticket est inscrit dans GLPI au niveau de l’historique du ticket : toutes les escalades, les actions sont tracées.
Lorsque la résolution du ticket est tributaire d’un sous-traitant (exemple d’un logiciel de gestion de la paie de la société Passage, utilisé en mode SaaS), vous pouvez dans GLPI indiquer que le ticket est attribué à ce fournisseur.
Au-delà de l’escalade fonctionnelle, lorsque le technicien du centre de services perçoit que le SLA ne sera pas respecté pour l’incident, il doit effectuer une escalade hiérarchique : informez le management, qui peut alors prendre tout dispositif utile pour favoriser plus rapidement la résolution de l’incident (mobilisation de personnes hors centre de services…). Il convient de tracer cette escalade par une action de suivi.
Affectez une tâche et planifiez-la
GLPI vous permet d’affecter une tâche à une personne sur un ticket que vous suivez.
Prenons l’exemple d’un ordinateur portable HS dont le remplacement doit être effectué en 2 temps :
remplacement immédiat par un nouveau PC portable pour permettre l’accès aux applications (ticket attribué à Jean Suissure) ;
planification le lendemain de la récupération des données du disque dur de l’ancien PC portable sur le nouveau (tâche attribuée à Jacques Ady).
Ajout de la tâche planifiée :
Historique des actions menées sur le ticket :
Le statut du ticket devient : En cours (Planifié)
Fluidifiez la résolution des prochains incidents identiques : alimentez et utilisez dans GLPI la base de connaissances
Vous avez résolu un incident pas si simple, faites profiter de votre expérience l’ensemble de la communauté du centre de services : partagez la résolution dans la base de connaissances (wiki) pour qu’un autre technicien (ou vous-même) plus tard, sur le même type d’incident (cas similaires, proches ou identiques), déroule la solution adéquate : les étapes/actions qui ont abouti à la restauration du service.
Les informations de la base de connaissances sont gérées par entité (structuration de l’entreprise) et classées par catégories. Vous trouverez généralement 3 types de catégories :
des procédures : pas à pas à suivre pour résoudre un incident, recueil de réponses, actions, propositions ;
des manuels d’utilisation : informations de type notice ou mode d’emploi ;
des consignes, règles ou méthodes : instructions précises, directives incontournables, arbres de décision.
Les catégories sont gérées de manière hiérarchique et par entité, avec la possibilité d’étendre l’utilisation des catégories aux sous-entités de l’entité courante.
L’objectif :
centraliser l’information qui est souvent dispersée dans la tête de chacun ou à plusieurs endroits (documentation dispersée sur plusieurs serveurs) ;
trouver/accéder de manière efficace (simplement) et rapide (ciblage) à la bonne information au bon moment, pour ne pas perdre de temps à réfléchir à nouveau à une solution déjà éprouvée, et in fine pallier le risque de ne pas respecter les SLA. Ce qui serait chronophage ;
organiser les connaissances par thème, catégorie, mots clés… pour les retrouver plus facilement ;
alimenter au fil de l’eau la base des connaissances pour la construire.
Consultation de la base de connaissances : dans GLPI, lorsque vous traitez un ticket (onglet « Traitement du ticket »), cliquez sur le bouton Rechercher une solution.
Le champ de recherche contenant le libellé du ticket s’affiche. Ce champ est modifiable.
Choisissez l’élément correspondant à la réponse à fournir au ticket en cliquant sur le lien Utiliser comme solution.
La réponse contenue dans l’élément de la base de connaissances vient automatiquement alimenter le champ Description de la solution.
Alimentation de la base de connaissances à partir de la solution : choisir « oui » dans la liste déroulante Enregistrer et ajouter à la base de connaissances :
Rédigez la solution en complétant les champs Type de solution et Description, puis cliquez sur le bouton Sauvegarder.
Le formulaire de saisie des éléments de la base de connaissances s’affiche.
Dans la liste Nom de la catégorie, sélectionnez une catégorie (ici : Sous responsabilité Éditeur de Logiciel) pour classer cette question/réponse dans la base de connaissances.
Validez l’ajout de la question/réponse dans la base de connaissances en cliquant sur le bouton Ajouter.
Il est également possible de rendre cet élément de la base de connaissances directement visible dans la FAQ qui est un ensemble de questions/réponses visible des utilisateurs de GLPI : dans ce cas, choisissez « Oui » dans la liste déroulante « Placer cet élément dans la FAQ ».
Ainsi, toute personne habilitée (dont les utilisateurs) peut voir cette information et l’utiliser directement sans passer par le centre de services.
Lors de l’enregistrement de la solution, le statut du ticket passe dans GLPI de En cours à Résolu.
Clôturez le ticket d’incident après avoir obtenu l’approbation du demandeur
Pour passer du statut Résolu au statut Clos, la solution proposée doit être validée par le demandeur.
L’action de clôture de ticket suit l’étape de solution du ticket : à l’enregistrement de la solution, GLPI invite le technicien à demander la validation du demandeur afin de fermer le ticket :
Puis, cliquez sur Approuver la solution.
Il est également possible de définir une clôture automatique au bout d’un délai prédéfini, via le paramétrage qui se fait dans le menu Administration > Entités, en modifiant la valeur (nombre de jours) du champ Clôture automatique des tickets résolus après.
En résumé
Dans ce chapitre, nous :
avons déroulé le processus complet d’un ticket incident en utilisant GLPI, jusqu’à la clôture du ticket (cycle de vie du ticket de sa création à sa fermeture) ;
nous sommes sensibilisés à résoudre nous-même l’incident pour restaurer le service au plus tôt ;
avons appris à utiliser GLPI pour garantir la résolution de l’incident via les escalades fonctionnelles aux niveaux 2 et 3, ainsi qu’à informer le management par escalade hiérarchique lorsqu’on sait que les SLA ne pourront pas être respectés ;
avons compris l’utilité (alimentation et consultation) de la base de connaissances pour résoudre plus vite des incidents qui ont déjà eu lieu par le passé.
Dans le prochain chapitre, nous suivrons les délais de résolution de l'incident, afin de respecter les accords de service.
