L’alimentation de la file de tickets

L’alimentation de la file de tickets

Pour débuter cette partie, il convient de préciser que les différents modes d’alimentation de la file de tickets sont cumulatifs. Chacune de ces méthodes présente des avantages et des inconvénients. Il vous appartiendra ensuite de choisir le ou les modes d’alimentation de la file de tickets selon vos besoins et vos contraintes.

GLPI offre trois modes d’alimentation de la file de tickets :

  • Par le demandeur, dans l’interface (profil post-only ou anonyme sans authentification).
  • Par un technicien (fonctionnement en centre d’appel par exemple).
  • Par la récupération de mails dans une boîte aux lettres en vue de leur conversion en demandes d’assistance.

1. Par l’utilisateur dans l’interface

Il s’agit ici de permettre au demandeur de rédiger lui-même sa demande d’assistance.

Utilisation de l’interface de saisie

GLPI intègre parfaitement ce mode opératoire en proposant un formulaire de saisie des demandes. Ce formulaire est accessible à tous les utilisateurs authentifiés dès lors que le profil post-only leur est attribué. La définition de ce profil est détaillée dans le chapitre Les profils.

Il est bien sûr possible de modifier ce profil ou d’en créer d’autres ayant ce même type de fonctionnement avec des variantes plus ou moins importantes. Dans tous les cas ces profils seront du type Interface simplifiée.

Dans la configuration par défaut, GLPI propose le profil post-only comme profil par défaut. La règle Root des Règles d’affectation d’habilitations à un utilisateur donne par défaut des droits sur l’Entité racine. Ainsi sans modifier la configuration de GLPI, n’importe quel utilisateur authentifié peut déposer une demande d’assistance.

Pour tester ce mode :

 Connectez-vous à GLPI avec un compte utilisateur ayant le profil post-only sur une entité au moins.

Parmi les comptes par défaut, vous pouvez utiliser le login/mot de passe post-only/postonly.

Votre page d’accueil vous présente une synthèse statistique de vos tickets, répartis par Statuts des tickets.

images/07RI01.png

Pour visualiser vos tickets, cliquez sur le menu Tickets.

Vous pouvez également accéder à la liste des tickets ayant un statut donné en cliquant sur le libellé de ce statut dans le tableau de la page d’accueil.

 Pour créer un nouveau ticket à partir de la page d’accueil, cliquez sur le lien Créer un ticket dans le titre du tableau.

images/07RI02.png

 Pour créer un nouveau ticket à partir de la page contenant la liste des tickets, cliquez sur le bouton Ajouter.

L’interface de saisie permet de préciser les champs suivants :

Urgence (Très haute/Haute/Moyenne/Basse/Très basse) : ce champ est très souvent mal utilisé par les demandeurs. Soit ils ne l’utilisent pas et ne pondèrent ainsi pas leur demande, soit ils ont tendance à considérer que leur demande est systématiquement très urgente !

Suivi par courriel (Non/Oui) : ce paramètre permet à l’utilisateur de demander à être informé par messagerie des différentes étapes du traitement de sa demande.

Les messages émis lors des différentes étapes de la vie d’une demande d’assistance sont gérés dans la partie notification de l’application.

Courriel : ce champ est automatiquement rempli si l’email du demandeur est connu dans la base des comptes. Dans le cas contraire, ce champ devient un champ de saisie qui permet au demandeur d’indiquer son email.

Le ticket porte sur : ce champ propose les éléments de l’inventaire en relation avec le demandeur, à propos desquels il va pouvoir déposer une demande d’assistance.

Ces éléments sont définis dans la configuration du profil post-only.

Type (Incident/Demande) : cette distinction est directement issue de l’intégration de ITIL V1 dans GLPI. Pour simplifier la distinction des deux termes, un Incident correspond à un problème ou une panne et une Demande correspond à une sollicitation moins bloquante comme une commande de nouveau matériel par exemple. Un Incident appelle un dépannage alors que la Demande appelle un traitement suivant un circuit différent.

Catégorie : GLPI offre la possibilité de définir des catégories de tickets. Ces catégories sont gérées dans le menu Configuration – Intitulés. Les catégories sont gérées par entité (avec possibilité d’étendre à la sous-arborescence). Il est possible de structurer les catégories de manière arborescente.

Il est possible de rendre ce champ obligatoire. Ce paramétrage se fait dans le menu Configuration – Générale, onglet Assistance.

Cette notion est très importante car elle permet de classifier les demandes d’assistance dès leur création et de leur appliquer des traitements à l’aide de règles. Vous pourrez ainsi assigner automatiquement les tickets relatifs à certaines catégories directement au technicien ou au groupe de techniciens en charge du domaine.

Titre : ce champ est obligatoire. Il définit le nom du ticket dans la liste des demandes d’assistance et un clic sur ce nom ouvre la fiche de la demande d’assistance.

Description : ce champ de saisie permet de décrire la demande. Il peut être rendu obligatoire.

Fichier (16 Mio max) : ce champ permet d’associer un fichier à une demande d’assistance.

 Validez la création du ticket en cliquant sur le bouton Envoyer message.

images/07RI03.png

Ouverture de ticket anonyme

Il s’agit ici d’offrir la possibilité de saisir une demande d’assistance sans avoir à s’authentifier au préalable. Cette méthode fait appel à un formulaire spécifique à l’adresse http://ip_serveur/glpi/front/heldesk.html.

Le formulaire est simplifié et comporte par défaut moins de champs de saisie. La page helpdesk.html est un exemple d’utilisation des demandes en mode anonyme. Ce formulaire peut bien entendu être personnalisé en modifiant le code de la page.

Attention ce formulaire ne contient pas tous les champs disponibles par défaut dans le formulaire de saisie du profil post-only. Ainsi par exemple, si vous rendez la catégorie de ticket obligatoire, la création de la demande d’assistance ne pourra pas se faire nativement car le formulaire ne renvoie pas cette information. Il faudra intervenir sur le contenu du formulaire pour ajouter cette information, ou bien rendre la catégorie de ticket facultative.

Le mode d’alimentation anonyme pose le problème du suivi des demandes d’assistance car ces demandes ne sont nativement pas associées à un utilisateur de la base de comptes ni à un élément de l’inventaire.

images/07RI04.png

2. Par un technicien

Dans ce mode d’alimentation, c’est un technicien qui renseigne les différents champs de saisie. Cette utilisation est liée aux profils de type interface standard.

Ce mode de fonctionnement correspond à une organisation avec centralisation des demandes. Le technicien reçoit les demandes le plus souvent par téléphone, et les saisit dans l’interface.

En tant que technicien vous devez pour cela avoir un profil du type Interface standard. Le profil prédéfini le plus adapté à cette fonction est le profiladmin. Dans la mesure où il n’existe aucun compte par défaut associé à ce profil, vous pourrez utiliser le compte glpi pour découvrir l’interface de saisie des demandes (la différence principale est l’absence d’autorisation de supprimer des suivis pour le profil admin).

 Connectez-vous à GLPI avec le compte glpi (login/mot de passe : glpi/glpi).

 Placez-vous dans le menu Assistance – Tickets.

La liste des tickets non résolus s’affiche.

images/07RI05.png

 Cliquez sur le bouton Ajouter.

 Complétez la fiche de demande d’assistance :

Ouvert le : ce champ permet de spécifier la date d’ouverture du ticket. Le champ est prérenseigné avec la date et l’heure du serveur. La saisie se fait au travers de trois champs de saisie : La date (une fonction de calendrier est disponible pour l’aide à la saisie), l’heure et les minutes.

Echéance : ce champ permet de définir une date butoir de traitement pour la demande d’assistance. Il est calculé automatiquement si une règle associe le ticket à une SLA.

Section Demandeur

Une demande peut provenir :

D’un utilisateur : pour retrouver le demandeur dans la liste des utilisateurs de GLPI :

 Saisissez quelques lettres du nom du demandeur dans le premier champ.

La liste des noms contenant les lettres saisies s’affiche.

 Sélectionnez le nom du demandeur.

Si l’utilisateur possède des droits sur plusieurs entités, précisez sur laquelle porte la demande. Le ticket sera ainsi positionné dans cette entité. Si l’utilisateur n’a des droits que sur une entité, cette action est automatique.

 Renseignez les champs suivants :

Suivi par courriel : lorsque les Suivis par courriel sont activés (menu Configuration – Notifications), il est possible de proposer un suivi du ticket par courriel.

Courriel : ce champ contient l’adresse mail du demandeur. Il est automatiquement renseigné si l’information est présente dans la fiche de l’utilisateur. Dans le cas contraire, il est possible de saisir l’adresse mail du demandeur pour pouvoir utiliser le suivi de la demande par mail.

images/07RI06.png

Si l’utilisateur n’est pas présent dans la base de comptes de GLPI et qu’une connexion vers un annuaire LDAP est définie, cliquez sur le boutonImporter un utilisateur pour accéder à la fenêtre d’importation des utilisateurs à partir d’un annuaire LDAP.

D’un groupe : sélectionnez le groupe demandeur dans la liste déroulante des groupes.

images/07RI07.png

Section Observateur

GLPI propose de désigner des observateurs pour le ticket en cours de création. Un observateur sera informé de la vie de la demande d’assistance sans pouvoir intervenir sur celle-ci. Un observateur peut être un utilisateur de la base de comptes ou un groupe défini dans GLPI. Le principe de saisie est le même que pour le champ Demandeur.

Section Attribué à

Ce champ sert à désigner la personne ou le groupe de personnes qui auront à intervenir sur cette demande d’assistance. Le fonctionnement est le même que pour le Demandeur ou l’Observateur. En revanche, il est également possible d’attribuer une demande d’assistance à un fournisseur externe désigné dans le menu Gestion – Fournisseurs. Il sera ainsi possible d’informer directement un prestataire de service dès lors que son intervention est jugée nécessaire par le technicien qui saisit la demande.

Pour chacune de ces trois catégories d’acteurs, il est possible de cumuler les utilisateurs et les groupes, voire les fournisseurs pour les personnes en charge du ticket. Le formulaire de saisie initiale de la demande permet de ne saisir qu’un utilisateur et/ou un groupe. Lorsque la demande est validée, il est possible de rajouter autant d’utilisateurs et de groupes (voire de fournisseurs pour la dernière catégorie d’acteurs) que vous le souhaitez.

Autres champs

Statut (Nouveau/En cours (Attribué)/En cours (Planifié)/En attente/Résolu/Clos) : ce champ permet de spécifier l’état d’avancement du ticket. Cette liste est une liste finie qu’il n’est pas possible de modifier. Chacune des valeurs correspond à une étape du traitement de la demande. Par défaut la valeur lors de la création d’une demande est Nouveau. Si le ticket est attribué lors de sa création (soit manuellement soit au travers d’une règle), le statut passe alors à En cours (Attribué).

La possibilité de passer un ticket d’un statut à un autre est définie par profil, dans la section Cycle de vie des tickets des profils de type interface standard. Ainsi par exemple seul un profil dédié à la supervision du travail des équipes d’assistance aura le droit de faire passer le statut d’une demande à Clos sans qu’il soit passé par Résolu avant.

Urgence : (Très haute/Haute/Moyenne/Basse/Très basse) : cette valeur est définie par le demandeur. Du point de vue de l’utilisateur, elle remplace la notion de priorité.

Impact : (Très haut/Haut/Moyen/Bas/Très bas) : cette valeur est définie par le technicien. Seule une personne en charge du traitement des tickets est capable de mesurer la portée d’un incident ou d’une demande sur le fonctionnement de la structure.

Priorité : (Majeure/Très haute/Haute/Moyenne/Basse/Très basse) : ce champ est calculé à partir des deux champs précédents. Ce calcul se fait à partir de la matrice définie dans le menu Configuration – Générale, onglet Assistance.

La priorité Majeure n’existe qu’en dehors de la matrice et ne peut donc être accessible que par ce formulaire pour les personnes dont le profil les y autorise.

Type (Incident/Demande) : cette notion est directement issue de ITIL V1. Un incident est quelque chose qui appelle une intervention de dépannage, tandis qu’une demande est quelque chose de moins bloquant.

ITIL prévoit une notion supplémentaire non implémentée dans cette version de GLPI : la notion de problème. Lorsqu’un incident se reproduit au moins deux fois, on ne parle plus d’incident mais de problème. La solution doit alors s’attacher à la cause des incidents afin qu’ils ne se reproduisent plus.

Durée totale : ce champ permet de quantifier le temps passé sur le traitement de cette demande. Cette durée s’ajoutera aux temps passés sur les tâches associées au ticket. Il se retrouvera dans l’onglet Coûts du ticket lorsqu’il sera validé. Cet onglet sert à valoriser les temps passés.

Titre : ce champ est obligatoire, il définit le nom du ticket dans la liste des demandes. Il doit donc être le plus explicite possible. (ne pas se contenter de « messagerie », mais plutôt « problème d’envoi de message vers l’extérieur avec dernière version du courrielleur ». Ce libellé sera repris comme base de question si vous souhaitez injecter ce problème et sa solution dans votre base de connaissances, voire dans la FAQ.

Description : ce champ permet une description complète du problème rencontré.

Fichier (16 Mio max) : ce champ permet de joindre un document à une demande.

Matériel : en fonction de la définition du profil utilisé, il est ici possible d’afficher les éléments de l’inventaire présents dans la base de données (partieGénéral), en désignant d’abord le type d’objet, puis en sélectionnant cet objet dans la liste. Si des éléments d’inventaire ont comme utilisateur le demandeur, il sera possible de spécifier sur lequel porte la demande (partie Mes matériels).

Source de la demande : ce champ permet de préciser l’origine de la demande. La liste des sources est gérée dans le menu Configuration – Intitulés, section Assistance, table Source de la demande. Une source par défaut est désignée pour les tickets issus de l’interface de GLPI et une autre pour les demandes récupérées au travers d’un collecteur mail.

Catégorie : ce champ permet de définir la catégorie de la demande. Les catégories sont gérées dans le menu Configuration – Intitulés, sectionAssistance. Les catégories sont gérées par entité (ne pas oublier de se positionner sur l’entité souhaitée avant de créer les catégories), et de manière arborescente. Il est possible de rendre obligatoire la désignation d’une catégorie pour chaque ticket. Cette information peut être une source très utile pour mettre en place des traitements automatisés à l’aide de règles.

Demande de validation : GLPI offre désormais la possibilité de faire valider une demande d’assistance. La personne en charge de valider le ticket doit être désignée parmi les utilisateurs ayant un profil les y autorisant, et ayant ce profil sur l’entité du ticket.

Tickets liés

GLPI propose d’associer les tickets entre eux :

 Cliquez sur le lien Ajouter. GLPI vous propose alors deux possibilités :

Lié à Ticket ID : ce champ est un champ informatif auquel aucun traitement n’est associé. Saisissez l’identifiant du ticket à associer au ticket en cours.

La liaison est réciproque : l’identifiant du ticket courant apparaîtra dans les liaisons du ticket lié.

Duplique Ticket ID : cette fonction permet de lier le ticket courant avec le ticket dont l’id est saisi ici. Lorsqu’une solution est saisie dans l’un des tickets, celle-ci est automatiquement copiée dans la solution de l’autre ticket.

 Validez la création du ticket en cliquant sur le bouton Ajouter.

images/07RI08.png

3. Par un collecteur de mails

GLPI offre une dernière solution pour alimenter la file de tickets : l’utilisation de collecteurs de mails.

Le principe d’un collecteur de mails est d’interroger le contenu d’une boîte aux lettres de messagerie et de convertir chaque message en ticket. Il n’y a donc dans ce cas aucune saisie à effectuer. Le demandeur rédige donc sa demande dans son courrielleur habituel et envoie son message à une adresse définie.

Il est possible de définir autant de collecteurs que vous le souhaitez. Il sera donc possible d’utiliser plusieurs boîtes aux lettres afin d’effectuer un premier tri dans les demandes. Il est dans ce cas possible d’organiser vos boîtes par entités, par catégories de demandes, etc. Ainsi pour une demande concernant les imprimantes : écrire à la boîte dépannage_imprimantes@masociete.com…

Pour configurer un collecteur de mails

Vous devez avoir des droits de configuration, vous utiliserez donc un compte ayant un profil super-admin.

Connectez-vous avec le compte glpi.

 Placez-vous dans le menu Configuration – Collecteurs.

 Cliquez sur le bouton Ajouter.

Renseignez les différents champs :

Nom : ce champ permet de définir le nom du collecteur de mails. Ce nom doit être explicite car il peut être utilisé comme critère dans les règles de traitement des tickets.

Lorsqu’un collecteur de mails au moins est créé, une nouvelle catégorie de règles s’affiche (menu Administration – Règles). Voir ci-dessous pour la définition des règles liées au helpdesk.

Serveur : ce champ permet de spécifier l’adresse du serveur de messagerie utilisé.

Options de connexion : les champs ci-dessous permettent de définir la façon dont GLPI va se connecter au serveur de messagerie.

  • IMAP/POP : ce champ permet de définir si la connexion doit récupérer les messages et les supprimer de la boîte aux lettres (mode POP) ou bien si les messages doivent être conservés sur la boîte après avoir été récupérés (mode IMAP).
  • SSL : ce champ permet de définir si la connexion est sécurisée par SSL (Secure Sockets Layers).
  • TLS/NO-TLS : ce champ permet de définir si la connexion est sécurisée par TLS (Transport Layer Security).
  • NO-VALIDATE-CERT/VALIDATE-CERT : ce champ permet de définir si une vérification de la validité du certificat est nécessaire pour la connexion au serveur de messagerie.

Dossier des messages (optionnel, souvent INBOX) : ce champ définit le dossier dans lequel les messages doivent être récupérés.

Port (optionnel) : ce port dépend du mode de fonctionnement de la connexion (POP ou IMAP) et de la sécurisation ou non de cette connexion. Cela donne : IMAP (port 143), IMAPS (port 993), POP (port 110) et POPS (port 995).

Chaîne de connexion : la chaîne de connexion est un champ calculé à partir des valeurs des champs précédents.

Identifiant : ce champ est l’identifiant du compte ayant les droits en lecture sur la boîte aux lettres.

Mot de passe : ce champ permet la saisie du mot de passe associé au compte ci-dessus.

Taille maximale des fichiers importés par le collecteur : ce champ permet de limiter la taille des pièces jointes aux messages récupérés dans la boîte aux lettres par le collecteur de mails.

Commentaires : ce champ commentaire peut être utile pour expliciter l’utilisation initiale de ce collecteur.

 Validez la création en cliquant sur le bouton Ajouter.

images/07RI09.png

4. Avantages et inconvénients des trois modes d’alimentation

Afin de comparer les différentes solutions, il convient de lister des critères de comparaison :

  • La simplicité d’utilisation pour le demandeur.
  • La simplicité d’exploitation par les équipes d’assistance.
  • La facilité de mise en œuvre et d’exploitation.

La simplicité d’utilisation pour le demandeur

Au travers de ce critère, il faut également lire le niveau d’acceptation du changement dans les habitudes et les contraintes nouvelles imposées.

  • Deux modes d’alimentation ressortent ici favoris : l’alimentation par collecteur mails et la saisie par un technicien suite à un appel téléphonique. Ces deux modes ne présentent que peu de difficultés pour le demandeur. Un léger effort de formulation de la demande devra tout de même être fait dans la demande par messagerie, mais cela reste souvent un outil maîtrisé.
  • A contrario, le recours au formulaire de saisie en mode authentifié apporte de nombreuses contraintes à l’utilisateur :
  • Se connecter à l’outil, avec éventuellement la nécessité d’avoir encore un nouveau mot de passe. Le recours à une source d’authentification externe (voire de SSO) est une nécessité absolue dans le plan d’acceptation de la contrainte.
  • Formaliser la demande : L’obligation pour l’utilisateur de décrire son problème est souvent assez mal ressentie. De plus, selon la configuration du formulaire de demande, les champs de saisie obligatoires peuvent agacer les demandeurs qui souhaitent au plus vite cliquer sur le boutonEnvoyer message.
  • Une dernière contrainte est d’avoir à disposition une connexion vers le serveur GLPI.

La simplicité d’exploitation par les équipes d’assistance

Ce critère est celui qui doit s’imposer car il préfigure une plus grande efficience dans le traitement des demandes.

  • L’utilisation de collecteurs de mails présente un niveau de complexité d’exploitation plus élevé que les autres modes d’alimentation : en effet, dans un message il n’existe aucun formalisme, ni aucune obligation pour le demandeur de formuler sa demande sous une forme permettant une automatisation de son exploitation. Ce mode d’alimentation impose donc un travail important de reformulation et beaucoup de temps gaspillé.

Il est tout de même important de signaler que GLPI est capable à la réception d’un message d’associer le ticket généré à l’utilisateur possédant l’adresse mail émettrice du message.

L’alimentation par le formulaire de saisie en mode anonyme peut se rapprocher de ce niveau de complexité d’exploitation.

  • L’utilisation du formulaire par le demandeur en mode authentifié est un compromis intéressant car il permet, en fonction des éléments saisis (dont le cadre est connu), d’effectuer un prétraitement, comme par exemple une attribution automatique du ticket en fonction de la catégorie de la demande. Le demandeur peut également lui-même associer sa demande à un élément de son propre inventaire.
  • Enfin, la demande saisie par le technicien permet une reformulation directe et une prise en charge immédiate de la demande. Ce type de mode d’alimentation est celui qui génère le moins d’erreurs de prise en charge.

La facilité de mise en œuvre et d’exploitation

Il n’y a quasiment aucune contrainte dans l’utilisation de collecteurs mail et dans celle des formulaires de saisie par l’utilisateur.

En revanche, la mise en place d’un accueil pour la saisie des demandes par un technicien impose une organisation très lourde à mettre en place et ne peut être envisagée que pour les très grosses structures. La disponibilité doit être permanente dans les plages définies.

En conclusion

Avant de mettre en place un ou plusieurs circuits d’alimentation de la file de tickets, vous devrez commencer par mener une réflexion sur les attentes de vos clients et sur les moyens dont vous disposez pour y répondre.

Votre réponse pourra naturellement être un cumul de plusieurs solutions. Vous devrez dans ce cas bien définir à quels cas d’utilisations correspond chacun des circuits.

Votre analyse pourra se baser sur ces trois critères mais pourra également être complétée par des critères basés sur la formation des utilisateurs, les coûts induits par les différentes solutions….

L’intérêt de cette partie est de vous laisser entrevoir les implications et les contraintes que la mise en place de GLPI pourra avoir sur le fonctionnement de votre structure.

  1. Deja un comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: