Chez Valiantys, nous sommes réellement enthousiastes sur la solution JIRA. Nos clients nous sollicitent très régulièrement sur le déploiement de cette solution dans un contexte de Service Desk et nous capitalisons notre connaissance sur ce sujet depuis plusieurs années. Nous sommes toujours étonnés de voir comment, grâce aux fortes capacités de paramétrage de cet outil, il est possible de mettre aisément en œuvre JIRA dans des cas d’utilisation éloignés de son positionnement initial : le bug tracking.
Lorsqu’une entreprise souhaite outiller son Service Desk IT, elle se retrouve souvent confrontée à deux options :
- Choisir un outil dédié souvent très cher, intégrant des fonctionnalités sophistiquées, relativement lourd à déployer et au final, pour une utilisation très partielle de ses capacités (souvent inférieure à 30%)
- Ou choisir un outil (JIRA) déjà utilisé dans l’entreprise (généralement pour les processus de développement logiciel), très apprécié des utilisateurs, simple à déployer et raisonnable au niveau tarification.
Nos clients retiennent régulièrement la deuxième option car elle leur permet d’aligner plus simplement l’effort du projet (coût, délais, charges,…) au niveau d’exigence attendu.
Récemment un client témoignait sur l’agilité du déploiement JIRA : « ma société a fait un choix stratégique pour son futur outil de Service Desk, en l’occurrence un très gros acteur du marché. Comme dans le meilleur des cas le projet de déploiement s’étalait sur 2 ans, nous sommes partis sur JIRA car nous avions besoin d’une solution opérationnelle à très court terme »
Une des différences majeures entre le domaine de la gestion des demandes côté processus de développement logiciel et celui côté Service Desk est la volumétrie (nombre de demandes ou d’accès concurrents,..). Dans le cas de Service Desk la volumétrie est communément 10 à 20 fois supérieure et atteint fréquemment plusieurs centaines de milliers de demandes. De ce point de vue, les performances des dernières versions de JIRA ainsi que la fonctionnalité d’archivage annoncée dans la roadmap Atlassian sont des points très rassurants.
Lors de nos premiers projets de déploiement JIRA pour des activités de Service IT, nous nous sommes heurtés à certaines limitations fonctionnelles. Il est cependant si aisé d’étendre les fonctionnalités de l’outil que nous avons décidé de nous lancer dans le développement de fonctionnalités de 3 add-ons utilisés dans plus de 40 pays et commercialisés via la Market Place Atlassian)
- VertygoSLA : qui permet d’optimiser la gestion des contrats de services (SLA) et d’aider les agents à prioriser les traitements des tickets,
- nFeed : qui propose des champs personnalisés qui peuvent être alimentés avec des données externes provenant par exemple d’une CMDB existante ou d’un Web Service,
- PowerReport : qui permet de suivre des KPI pour l’amélioration des processus de support.
Une autre exigence forte est la mise à disposition des utilisateurs d’une interface très simple afin de fluidifier la remontée de demandes. Nous savons qu’Atlassian travaille activement autour de cette fonctionnalité. Néanmoins, aujourd’hui l’utilisation de l’API JIRA ou des Email handlers permet de couvrir en partie ce besoin.
Par ailleurs, la mise en place d’une base de connaissance derrière le système de ticketing est très rapidement identifiée comme une exigence importante. Dans ce cas, les capacités d’intégration de JIRA avec Confluence (le Wiki d’Atlassian) permet de construire une solution globale efficace qui mixte gestion des demandes, FAQ et référentiel de fiches de résolution.
Aujourd’hui, nous sommes encore confrontés à certaines mises en œuvre complexes (problématique d’assignation, escalades de tickets, règles de gestion sur les liens entre tickets, synchronisation, visibilité…), néanmoins, JIRA se positionne comme une réelle alternative aux solutions dédiées du marché et dispose, à notre avis, d’un réel avenir dans le domaine de la gestion du support IT.
