La priorité ne se demande pas, elle se calcule
Le réglage le plus rentable du helpdesk, et le plus souvent négligé.
Si le demandeur choisit la priorité, tout devient urgent. Ce n'est pas de la mauvaise foi : chacun juge depuis son poste, et personne n'a la vue d'ensemble.
GLPI propose une matrice : la priorité est le croisement de l'urgence et de l'impact.
| Impact faible | Impact moyen | Impact élevé | |
|---|---|---|---|
| Urgence faible | très basse | basse | moyenne |
| Urgence moyenne | basse | moyenne | haute |
| Urgence élevée | moyenne | haute | très haute |
L'urgence dit à quelle vitesse c'est gênant, l'impact dit combien de personnes sont touchées. Une imprimante en panne pour une personne n'a pas la priorité d'un serveur de fichiers arrêté pour tout le monde, même si la première signale plus fort.
La conséquence pratique : retirez au demandeur le choix de la priorité, laissez-lui l'urgence, et déduisez l'impact de la catégorie ou du service concerné.
Les règles métier, le vrai moteur
Une règle métier examine un ticket à sa création ou à sa modification, et agit. Trois usages couvrent l'essentiel.
Affecter automatiquement. Catégorie « messagerie » vers le groupe qui gère la messagerie. Lieu « site de Lyon » vers l'équipe locale. Le ticket arrive chez la bonne personne sans qu'un humain trie.
Fixer l'impact à partir du service du demandeur ou du matériel concerné : un ticket portant sur un serveur de production ne peut pas avoir un impact faible.
Signaler ce qui sort de l'ordinaire : ouverture par un dirigeant, mot clé sensible, ticket rouvert pour la troisième fois.
Deux précautions. Les règles s'exécutent dans l'ordre, et une règle peut arrêter l'évaluation des suivantes : l'ordre est donc une décision, pas une conséquence. Et une règle trop large produit des affectations aberrantes que personne ne comprend six mois plus tard, quand son auteur est parti. Commentez chaque règle dans son libellé.
Modèles et tickets récurrents
Le modèle préremplit un ticket : catégorie, groupe, tâches à faire. L'arrivée d'un salarié devient un ticket avec ses six tâches déjà écrites, plus rien ne s'oublie.
Le ticket récurrent naît tout seul à intervalle régulier. C'est ainsi que les opérations périodiques, test de restauration, vérification des sauvegardes, revue des comptes, cessent de dépendre de la mémoire de quelqu'un.
Un test de restauration trimestriel qui existe comme ticket récurrent se fait. Le même, inscrit dans une procédure, se fait la première année.
La validation
Certaines demandes exigent un accord avant exécution : achat, accès à une application sensible, intervention en dehors des heures.
GLPI porte une validation intégrée : le ticket part en attente de validation, le valideur reçoit une notification, il approuve ou refuse avec un commentaire, et la trace reste.
Le bénéfice n'est pas le contrôle, il est la trace. La question « qui a autorisé cet accès » obtient une réponse datée, et personne n'a à se souvenir d'un échange oral.
Les formulaires
L'interface de dépôt standard demande un titre et une description. Résultat : « ça ne marche pas », et un aller-retour pour obtenir le nécessaire.
Un formulaire pose les bonnes questions selon la demande : pour un accès, quelle application et pour qui ; pour une panne, quel poste et depuis quand. Il alimente directement les champs du ticket et déclenche la bonne affectation.
C'est historiquement l'apport d'un plugin très répandu, désormais intégré dans les versions récentes sous forme de gestionnaire de formulaires. Le principe compte plus que l'outil : une question posée au dépôt évite un aller-retour d'une journée.
À retenir
Retirez la priorité au demandeur : elle se calcule en croisant urgence et impact. Les règles métier affectent, qualifient et signalent, dans un ordre qui est une décision. Les tickets récurrents portent les opérations périodiques qui, sinon, se perdent. Et un formulaire économise un aller-retour par ticket.