JIRA et le ticket management
JIRA n’est plus à présenter ! L’outil d’Atlassian a fait ses preuves pour l’outillage des processus SI ou IT. En témoigne, l’impressionnante liste des clients (plus d’informations ici : http://www.atlassian.com/software/jira/customers.jsp). Si les processus liés au développement (change management, release management…) constituent le périmètre « historiques » de JIRA, il est dorénavant commun d’utiliser cet outil pour supporter les processus de gestion des accès, des incidents, des services… ce que la bibliographie désigne habituellement sous le terme « ticket management ».
Un enregistrement JIRA (une demande) correspond alors à un ticket. Il suivra un workflow précis, en fonction de certains de ses attributs. Les étapes de déclaration, d’assignation, d’escalade, de résolution… sont alors toutes tracées dans l’outil.
Indicateurs et SLA
L’avènement des standards qualité de gestion de services, tels que les versions successives du référentiel ITIL ou la norme ISO 20000, a rendu centrale la notion de Service Level Agreement (SLA) dans toute les relations client-fournisseur.
Cette notion désigne un contrat, entre deux entités, qui formalise un engagement sur un ensemble d’indicateurs à respecter.
Les indicateurs qui peuvent être définis et suivis dans le cadre d’un SLA sont illimités. Ainsi, un fournisseur peut s’engager sur des plages d’ouverture d’un service, des plages de disponibilité, des temps moyen ou maximaux de prise en compte, de première réponse, de résolution…
Nous avons choisi de classer ces indicateurs en 3 familles :
– Certains d’entre eux ont une portée par « demande » : leur respect est directement vérifiable demande par demande (ticket par ticket pour reprendre un terme cher aux fournisseurs de services). C’est le cas, par exemple, des indicateurs de type « temps maximal de résolution », « temps de première réponse »… Pour chaque ticket, il est possible de dire si l’objectif a été respecté ou non.
– D’autres ont une portée plus large : leur respect n’est vérifiable qu’après consolidation sur un ensemble de demandes sur une période de temps à définir. C’est le cas des indicateurs qui représentent des temps moyens par exemple.
– Enfin, d’autres indicateurs sont directement liés à l’organisation du fournisseur. C’est le cas des horaires d’ouverture du service par exemple.
Nous allons voir dans la suite comment mettre en place le suivi de certains de ces indicateurs au travers de l’outil JIRA avec, notamment, VertygoSLA.
Le calcul des indicateurs
Valiantys propose le plugin VertygoSLA, qui permet de gérer des indicateurs de la première famille : ceux qui correspondent au niveau « Ticket». Le plugin permet par exemple de suivre :
– le temps d’affectation,
– le temps de résolution,
– n’importe quel temps entre 2 transitions (Il est possible dans VertygoSLA de définir ses propres indicateurs de la première famille : temps de première réponse, temps de proposition de solution de contournement, temps de fermeture…).
Ces 2 valeurs sont comparées à des valeurs d’engagement (objectif). Il est ainsi possible de savoir si, pour chaque ticket, les temps d’engagement qui composent le SLA, sont respectés ou non.
Concernant la définition et l’obtention des indicateurs qui ont une portée plus globale (2ème famille), Valiantys propose de s’appuyer sur une autre solution, JIRA Advanced Report (https://www.valiantys.com/display/AT/Jira+Advanced+Report). Ici, il va s’agir de concevoir et d’implémenter des éléments avancés de reporting sur la base de requêtes SQL. Vous pourrez ainsi obtenir, par exemple, des graphiques montrant l’évolution des temps moyens réels et objectifs sur des intervalles de temps variables (semaine, mois année…).
Enfin, chez certains clients, des intégrations JIRA/CONFLUENCE vont permettre de déclarer les indicateurs organisationnels (horaires de services…) dans CONFLUENCE. Ces informations sont alors envoyées à JIRA lors de la création d’un ticket. Grâce à ce mécanisme, vous pourrez dire à JIRA de ne prendre en compte que les heures ouvertes pour les calculs de SLA !
