Les organisations, privées comme publiques, sont de plus en plus nombreuses à souhaiter mettre leurs utilisateurs au centre de leurs préoccupations. A ce titre, les plateformes de services de toutes sortes aux utilisateurs deviennent des points clés du Système d’Information, et le moyen privilégié des utilisateurs pour entrer en contact avec l’organisation. Dans le cadre de mes missions en tant que consultante pour SmartView, j’ai contribué à la mise en place de JSM (Jira Service Management) pour différentes équipes de support.
J’ai pu très rapidement constater, en échangeant avec les différents acteurs, qu’il s’agissait à chaque fois d’un chantier complexe et très vaste :
- L’organisation des différentes équipes impliquées est rarement claire, partagée avec et par tous ;
- Les besoins et les contraintes des équipes sont souvent assez spécifiques, nous connaissons tous les « On est ITSM, Agile et tout et tout mais on ne fait pas tout à fait pareil car nous c’est différent » ;
- Les équipes ont parfois pris des (plus ou moins mauvaises) habitudes dont elles ne sont pas toujours prêtes à se défaire ;
- Un outil est déjà en place, et bien qu’il ne donne plus satisfaction (et que tout le monde s’accorde à le dire), les utilisateurs ont énormément de mal à se séparer de leurs petites fonctionnalités préférées ;
- Le sujet ne nécessite pas uniquement de mettre en place un projet Jira, il va s’étendre à la définition et implémentation de notions bien plus larges, comme les catalogues de services, les référentiels des actifs, etc.
Au cours des dernières années, j’ai pu mener notamment un projet conséquent de ce type qui a commencé il y a trois ans, et continue toujours aujourd’hui, en marche « courante ».
Ces années de réalisation, de remise en question et d’adaptation, associées à d’autres projets similaires, ont permis de tirer plusieurs enseignements, bonnes pratiques, et surtout une solution adaptée et convenant à différents contextes.
Crédit photo
Et ce sont ce travail de réflexion, les obstacles rencontrés et les solutions mises en place que je vais partager avec vous au travers d’une série d’articles.
Ce que vous trouverez dans cette série d’articles :
- Un retour d’expérience concret et pragmatique sur un cas d’usage réel de mise en place de Jira Service Management ;
- Des idées d’implémentation d’un processus d’assistance aux utilisateurs dans Jira ;
- Des astuces à utiliser, et des questions à se poser, dans le cas d’un projet similaire.
Dans ce premier article, je vais vous présenter :
- Le contexte dans lequel ce projet de trois années s’est déroulé ;
- Les premières difficultés auxquelles il a fallu faire face et que nous aurions pu éviter ;
- La vue globale de la solution mise en œuvre.
Un changement porté à l’origine par l’outil
Le contexte de mon client est assez classique. La Direction des Systèmes d’Information (DSI), accompagnée des directions métiers, est chargée entre autres choses de :
- Livrer et maintenir de nombreuses applications couvrant différents domaines métiers ;
- Mettre à disposition du matériel et des équipements aux utilisateurs ;
- Proposer de l’expertise métier ;
- Réaliser l’assistance métier et technique.
Différentes équipes gravitent autour de ces missions :
- Des équipes de développement et de maintien en condition opérationnelle des applications, organisées par domaine solution et par domaine métier ;
- Des équipes d’infrastructure, organisées par domaine technique ;
- Trois équipes d’assistance (métier et/ou technique), organisées par thématique et zone géographique.
Tout a commencé avec l’équipe d’assistance métier dont les frustrations autour de l’outil actuel prenaient de l’ampleur. Jusqu’à ce que la décision soit prise un beau jour : « on change d’outil ! ».
Souhaitant en profiter pour améliorer et fluidifier les échanges et interactions entre les équipes, le choix s’est naturellement porté sur Jira, déjà utilisé au sein de l’organisation.
Le projet initial était donc un changement d’outil sans remise en question de l’organisation ou du processus, et surtout sans prendre en compte les autres équipes d’assistance.
Et pourtant… des problématiques plus profondes ont rapidement émergé :
- Les équipes se plaignaient régulièrement du manque de visibilité de l’avancement de leurs sujets envoyés aux équipes de développement ;
- Un fossé s’était creusé entre les différentes équipes d’assistance, qui n’arrivaient pas à partager une vision commune de leur activité de support ;
- Certaines procédures restaient très artisanales et ne garantissaient pas vraiment une réponse de qualité et cohérente à l’utilisateur ;
- Certains processus étaient lourds et complexes, ce qui ralentissait le traitement des demandes ;
- L’organisation des équipes d’assistance n’était pas optimale (un grand nombre d’acteurs différents travaillant chacun sur un domaine très précis avec ses spécificités).
Conseil 1 – Ne négligez pas votre organisation et vos processus
L’outil est un facilitateur de votre travail au quotidien, il est au service de votre organisation, et non pas l’inverse. Lorsque vous changez d’outil, il peut être judicieux d’en profiter pour lever la tête du guidon et se poser des questions. Remettre à plat la « tambouille interne », identifier des axes d’amélioration, revoir les choses sous un autre angle. Mais aussi prendre en compte l’ensemble des parties prenantes, même si le projet semble concerner uniquement une équipe.
Vous trouverez sûrement des améliorations à apporter à votre organisation, impactant votre projet. Cette étape est pour moi indispensable pour garantir son succès et ne pas retomber dans certains travers.
Un projet en trois temps
Le projet a donc démarré pour une première équipe. En soi, commencer « petit » n’est pas un problème, bien au contraire. Mais ici, il n’y a pas eu de réflexion globale et commune en amont. Le déploiement de ce projet a donc été réalisé en se concentrant exclusivement sur les besoins et les pratiques de l’équipe d’assistance métier.
Et un an après… l’histoire s’est répétée : c’est l’équipe d’assistance technique qui a souhaité changer son outil, sans solliciter l’assistance métier ou les membres de la gouvernance Jira.
Petite anecdote : l’équipe d’assistance technique avait même évoqué à l’époque le fait d’utiliser une autre instance de Jira, proposition relative au fossé cité précédemment observé entre les équipes. Idée abandonnée.
Malheureusement, il a fallu plusieurs mois pour pallier les conséquences de ce choix :
- Paramétrage complètement spécifique, ne respectant pas les normes et nomenclatures mises en place par la gouvernance ;
- Philosophie opposée à celle de l’équipe d’assistance métier ;
- Choix « du pauvre » par manque de connaissances de Jira, pénalisant l’équipe d’assistance technique dans leur quotidien.
Heureusement, quelques mois plus tard, lorsque la dernière équipe d’assistance a eu le même projet, nous avons pu intervenir dès le début, forts de l’expérience du déploiement de Jira pour les deux premières équipes et ne pas répéter les mêmes erreurs.
Conseil 2 – Communication et collaboration
Vous avez déjà mis en place un premier projet d’assistance : appuyez-vous sur les membres du projet pour connaitre les bonnes pratiques mises en place, les choses qui ont marché ou moins marché. Par exemple en organisant un rendez-vous régulier avec un référent par équipe pour partager les bonnes pratiques, les points de vue, et l’avancement du projet.
Essayez d’adopter une vision commune entre vos équipes d’assistance : elles ont normalement en commun au moins un objectif : délivrer un service de qualité et efficace à des utilisateurs ayant besoin d’aide.
Et n’oubliez pas ce fameux utilisateur : si vous avez un fonctionnement trop différent entre vos projets Jira, ce dernier pourrait se retrouver perdu ou frustré. Pour lui, vous êtes une seule entité.
Enfin, même si Jira permet une personnalisation complète et spécifique de chaque projet, avoir une logique et une cohérence dans la définition des champs, des états, des workflows, etc. est nécessaire pour simplifier et réduire les temps de maintenance.
Votre Jira vous remerciera.
Un socle commun personnalisable et extensible
Cela n’a pas été toujours facile, nous sommes passés par des phases de « faire et défaire », le temps de trouver « la bonne formule » 🪄 satisfaisante pour mon client.
Aujourd’hui, je pense que passer par là n’a pas été une totale perte de temps. Les équipes avaient besoin de temps et de s’approprier petit à petit l’outil pour accepter ensuite de changer leur mode de fonctionnement et tendre vers une organisation commune. Et nous avions également besoin de ce recul pour bien identifier ce qui se cachait au final derrière l’organisation de chaque équipe, et imaginer une solution globale.
L’idée d’un socle commun mais personnalisable, et surtout extensible selon les spécificités, s’est donc construite au fur et à mesure des prises de conscience des équipes et des propositions d’amélioration apportées régulièrement.
Nous avons compris que certaines spécificités ne seraient pas modifiables, mais des fonctionnements identiques sont apparus de plus en plus clairement :
- Un découpage des équipes en cellules d’assistance ;
- Un catalogue de services d’assistance permettant de qualifier et catégoriser les demandes ;
- L’escalade vers les équipes de support de niveau 2 et 3 ;
- Les modalités de transfert vers une autre équipe ;
- La possibilité d’orienter facilement un ticket directement vers la bonne cellule ;
- Un lien fort avec les autres référentiels (catalogue des applications, données RH, Configuration Management Database (CMDB)…).
À la lumière des éléments cités précédemment, nous avons donc pris la décision de partir sur trois projets Jira différents, c’est-à-dire trois portails utilisateurs. Un par équipe.
De cette façon, chaque équipe peut avoir :
- Son propre workflow, adapté au mieux à son organisation ;
- Les champs dont elle a besoin pour traiter efficacement les demandes, selon les services proposés ;
- Ses choix de communication et de visibilité pour les utilisateurs finaux.
Conseil 3 – Trouvez le bon découpage en projets Jira
Avoir plusieurs projets et donc plusieurs portails utilisateurs dans Jira n’est pas du tout un problème. Il ne faut pas oublier que le point d’entrée unique pour l’utilisateur est le « Centre de services », une surcouche au-dessus de tous les portails. Le centre de services offre une vue globale de tous les portails de l’instance Jira, une barre de recherche transverse et l’accès à l’ensemble des demandes de l’utilisateur.
À mon sens, afin de trouver la bonne granularité lors du découpage en projets, il faut se poser les questions suivantes :
- Mes équipes d’assistance sont-elles indépendantes en termes de services et / ou d’organisation ?
- Certains services s’adressent-ils à une population réduite d’utilisateurs ?
Certains services nécessitent-ils une attention particulière en termes de confidentialité ?
Côté workflows, nous avons choisi de les simplifier pour fluidifier le traitement des tickets.
Pour les élaborer, nous sommes partis des processus. Dans notre cas, nous avons pu constater que les trois équipes d’assistance étaient déjà très matures sur ce sujet. Leurs processus étaient clairs et leurs attentes de modélisation sous forme de workflows dans l’outil également : ils ont tout de suite su quelles étapes étaient à retranscrire et celles qui n’étaient pas nécessaires.
Nous avons alors pu partir de cette vision simplifiée pour créer les workflows en se concentrant sur ce qui était indispensable.
Conseil 4 – Mettez en place une version simplifiée de votre processus comme workflow
Un réflexe que j’observe souvent est de calquer son workflow Jira sur le processus. On peut se retrouver alors avec des noms d’état à rallonge (par exemple « En attente d’une évolution de l’équipe de dev »), des étapes intermédiaires souvent redondantes, en doublon, ou inutiles.
Cela n’est pas facile, mais essayez de simplifier votre workflow en bonne intelligence : vous permettrez aux équipes de fluidifier les échanges avec tous les acteurs et de gagner en efficacité et qualité sur le traitement des tickets.
Pour faire cela, voici quelques pistes :
- Identifier les étapes qui s’enchainent et sollicitent la même personne (c’est-à-dire le responsable de réaliser l’action attendue à l’étape en question) : il est probable que vous puissiez réunir ces étapes en une seule dans Jira ;
- Identifier les étapes clés du processus : ce sont celles où il y a des actions très particulières à mener (notification par exemple de certaines personnes, lancement d’une automatisation, etc.) : ces étapes seront à identifier clairement dans le workflow ;
- Impliquer les agents qui traiteront les tickets : ce sont les plus à même de vous indiquer les étapes qui sont sûrement de trop ou celles qui manquent pour qu’ils puissent réaliser leur travail dans les meilleures conditions. Un clic de trop répété sur des dizaines de tickets peut générer de la frustration et une perte en efficacité.
En synthèse
- Gardez en tête que l’outil est au service de l’organisation et des processus, et non pas l’inverse, et ne négligez pas l’impact qu’ils auront sur votre projet ;
- Favorisez la communication et la collaboration entre toutes les parties prenantes du projet ;
- Posez-vous les bonnes questions pour identifier le nombre de projets JSM dont vous aurez besoin, en tenant compte des avantages et des contraintes que cela induit ;
- Identifiez les étapes clés de votre processus qui constitueront ensuite la base de votre workflow, et restez simple et efficace lors de l’élaboration de ce dernier.
Bien entendu, et comme indiqué précédemment, il a fallu tâtonner avant d’obtenir ces résultats. Mais faire et défaire dans Jira n’est pas si compliqué : pour la majorité des paramétrages, le coût pour revenir en arrière ou rajouter des éléments est relativement faible (quelques minutes à quelques heures). Mais cela à condition que les conseils précédents aient été suivis au mieux : car dans ce cas, les ajustements seront très certainement mineurs (nouvel état, fusion de projet, changement de libellé d’un champ…).
Conseil bonus – Rien n’est immuable
Un dernier conseil, qui me semble être le plus important : rien n’est immuable ! Un choix qui peut être parfait aujourd’hui ne le sera peut-être plus demain… et ce n’est pas grave. Surtout, il faut s’autoriser à changer des choses, expérimenter et ajuster selon les retours des utilisateurs, et le changement des équipes et de l’organisation. Cela peut paraître évident, mais je vois souvent des équipes qui ont peur de rester coincées avec un paramétrage, et hésitent à s’engager à chaque étape de validation. Alors que souvent, une modification dans Jira est très rapide et facile à mettre en place.
Et la suite ?
Dans les prochains articles, je vous proposerai de plonger plus en détail dans l’implémentation de certaines étapes clés.
Et d’ici là, n’oubliez pas de câliner votre Jira : il le vaut bien ! 💖
Illustration de couverture Journey Vectors par Vecteezy
