Le faux problème de l'outil
JSM s'installe en quelques minutes, et se paramètre en quelques heures, quelques jours pour les projets les plus complexes. Ce qui prend des semaines, voire des mois, c'est tout le reste : aligner l'ensemble des parties prenantes sur le catalogue de services, les RACI de chaque processus, la gouvernance cible.
Comme nous aimons souvent le rappeler chez BleuLemon, déployer JSM Cloud ou un équivalent, c'est un projet d'organisation avec un outil dedans.
Les 7 principaux facteurs clés de succès, détaillés ici :
- Réussir son cadrage
- Sponsorship et gouvernance
- Préparer son catalogue de services
- Impliquer ses utilisateurs et soigner l'expérience client
- Identifier les KPI en amont et simplifier les SLA
- Ne pas rogner sur la conduite du changement
- Mettre en place le run et penser amélioration continue
Le cadrage : définir la cible avant de configurer
Étape indispensable, le cadrage est également un piège dans lequel il faut éviter de s'embourber, au risque de passer des mois en réunions et de s'enfermer dans des choix qui se révèleront parfois malheureux à l'épreuve du monde réel. Il est important d'accepter une dose d'incertitude en phase de cadrage.
L'objectif
Identifier les enjeux, le périmètre, les parties prenantes, les intégrations, le lotissement, l'architecture, les KPI et le macro planning cible.
L'ensemble des éléments permettant de répondre aux questions : qui, quoi, quand.
Les pièges
- Se lancer à ce stade dans la conception détaillée, définir les workflows et les formulaires. Pour le « comment », on attend la phase de réalisation.
- Le périmètre qui s'étend : définir un scope initial et s'y tenir autant que possible. Les besoins connexes ou complémentaires seront traités dans un deuxième temps.
Ce que nous conseillons
JSM se configure en quelques minutes et permet de préparer facilement des mini « démonstrations » visuelles. Elles permettent de prendre des décisions et des arbitrages sur des cas réels spécifiques à chaque équipe. Un « bon » consultant Atlassian saura les identifier, vous guider et s'ajuster en phase de réalisation sans vous assommer de jargon et d'ateliers dès le cadrage.
Le sponsorship et la gouvernance : qui décide, qui arbitre, qui administrera ?
Définir les rôles clés dès la phase de cadrage et impliquer dès ce moment les métiers, futurs « clients » de la solution. C'est ce qui évite le piège du projet « IT pour les ITs ».
Ce que nous conseillons
- Un Product Owner disponible et à même de prendre des décisions et d'imposer ses arbitrages, en s'appuyant si besoin sur un comité identifié en amont.
- Un ou plusieurs « application owners », chargés du run de la solution, avec leur disponibilité future. Une application « vivante » nécessite toujours un peu de travail d'administration pour optimiser ou s'adapter aux évolutions des processus.
- Un sponsor qui saura prioriser et défendre le projet auprès du top management de l'organisation.
Le piège
Attention au mythe du « zéro administrateur en run ». Il ne résiste à aucun déploiement réel. S'appuyer si besoin sur une TMA.
Le catalogue de services : pourquoi c'est le vrai cœur du projet
Le catalogue de services permet de répondre aux questions : quoi, qui, sur le projet.
C'est un référentiel IT interne, et il se définit en amont :
- Quels sont les types de demandes de services ou d'incidents ?
- Qui sont les clients ?
- Qui est en charge du traitement de chacun de ces types de demandes ou d'incidents ?
- En combien de temps ?
- Qui les valide ?
- Est-ce que certains types de demandes contiennent des données sensibles ou confidentielles ?
Le piège
Le plus couramment rencontré : vouloir fusionner le catalogue de services et le portail JSM. Le catalogue de services est à définir en amont, il s'agit d'un référentiel IT interne.
Encore une fois, un « bon » consultant saura ensuite traduire l'ensemble de ces éléments dans un portail utilisateur simple, ergonomique et adapté au langage « métier » de l'organisation.
Ce que nous conseillons
Assets, et pas seulement pour la CMDB. La généralisation d'Assets dans l'offre standard de la « Service Collection » permet désormais à tous les clients JSM de construire un catalogue de services avancé, structuré et évolutif en utilisant ce module. Plus que des assets informatiques, ce sont de véritables référentiels applicatifs et fonctionnels que nous construisons avec nos clients dans Assets, véritable base de données intégrée.
Les avantages clés
- Des automatismes avancés, en s'appuyant sur les différents attributs de chaque objet.
- Une administration simplifiée : pas besoin d'archéologie dans les scripts ou les règles d'automation… Assets se met à jour aussi simplement qu'un fichier XLSX.
- Des possibilités d'évolution infinies (ou presque…). La combinaison du référentiel Assets, des automations, des workflows et des champs personnalisés nous permet de répondre à 99,9 % des use cases de nos clients.
N'hésitez pas à nous challenger si vous en doutez ;)
Le piège
Le piège d'Assets : un référentiel rapidement obsolète. Identifier en amont le ou les responsables de chacune des données du référentiel, pour garantir leur mise à jour régulière.
Expérience utilisateur du portail : la face émergée de l'iceberg
Le centre d'aide et les portails sont l'unique vitrine visible du projet pour 90 ou même 99 % des utilisateurs. Il est donc essentiel de porter le plus grand soin au branding, à la structure et à la clarté du portail.
Les pièges
- Le langage « ITIL ». Rencontrer les utilisateurs finaux pour comprendre leur vocabulaire, leur maturité et leurs futurs usages principaux.
- La sur-qualification et les formulaires à rallonge avec de multiples champs obligatoires… Collecter « uniquement » les données qui permettent de « router » et de prioriser les demandes entrantes.
Ce que nous conseillons
Règle de sobriété : mieux vaut 5 types de demandes bien pensés avec chacun 5 champs que 30 formulaires détaillés que personne ne trouve.
Le canal e-mail est souvent le premier canal d'échange avant la mise en place de JSM. Les équipes peuvent l'accepter temporairement et convaincre progressivement leurs clients des avantages du portail, ou opter pour une transition plus brutale avec un message automatique et un lien vers le portail sur la boîte de l'équipe.
Notre retour d'expérience BleuLemon
Sauf clients très « nomades », consommateurs de support sur leurs téléphones ou leurs tablettes, les demandeurs comprennent les enjeux et acceptent le plus souvent assez facilement de passer par le portail.
Reporting et SLA : mesurer ce dont on a besoin, pas ce que l'outil sait produire
C'est probablement le facteur le plus souvent traité en dernier, et celui qui coûte le plus cher à rattraper. Un tableau de bord se construit en une heure. Une donnée manquante parce que le champ n'existait pas au démarrage, cela se rattrape par une reprise d'historique, ou pas du tout.
L'objectif
Identifier, dès le cadrage, les questions auxquelles le futur reporting devra répondre. Non pas les graphiques souhaités, mais les décisions qu'ils doivent éclairer : faut-il renforcer une équipe ? Quels types de demandes automatiser en priorité ? Le niveau de service est-il tenu, et pour qui ?
De ces questions découlent les données à collecter, donc les champs, donc les formulaires, donc le catalogue. C'est bien pour cette raison que le sujet est à aborder pendant le cadrage, pas après quelques semaines de run.
Les pièges
- Mesurer l'activité plutôt que le service rendu. Le nombre de tickets clos par agent est une donnée facile à produire mais rarement utile… Le délai de première réponse perçu par le demandeur, le taux de réouverture ou la part de demandes traitées sans intervention humaine racontent une histoire nettement plus exploitable.
- Confondre SLA contractuel et SLA de pilotage. Les deux n'ont ni la même finalité, ni la même exigence de précision. Un engagement contractuel doit être opposable, donc simple, documenté et calculé sur un calendrier incontestable. Un SLA de pilotage est lui un engagement « fictif », mesurant un axe de travail défini par l'équipe ou le management. Il peut être plus complexe et accepter un peu plus de « flou » dans son calcul.
- Multiplier les engagements. Un temps de prise en charge et un temps de résolution suffisent dans la grande majorité des cas. Empiler trois ou quatre SLA par type de demande produit surtout des indicateurs que personne ne consulte et des alertes que tout le monde ignore.
Ce que nous conseillons
- Définir les indicateurs avant la mise en production, sinon on mesure ce que l'outil sait produire plutôt que ce dont on a besoin.
- Peu d'engagements, mais tenables et compris. Un SLA qu'une équipe ne peut pas honorer avec ses effectifs actuels n'est pas un engagement, c'est une dette.
- Trancher au cadrage ce qui sera couvert par le reporting natif JSM et ce qui nécessitera un outil complémentaire de type Atlassian Analytics ou solution de BI. La réponse conditionne le budget et parfois le choix de licence.
- Prévoir une revue des SLA après quelques mois d'exploitation. Les premiers engagements sont des hypothèses. Les données réelles diront lesquelles étaient justes.
La conduite du changement : deux chantiers, pas un seul
Former les agents et communiquer aux utilisateurs sont deux chantiers distincts, avec des publics, des messages et des calendriers différents. Les traiter comme un seul est l'erreur la plus fréquente, et la plus dommageable : les équipes support se retrouvent à absorber l'incompréhension des demandeurs en plus de leur propre montée en compétence.
Ce que nous conseillons, côté agents
- Former sur la configuration réelle du client, pas sur une démonstration générique. Un agent qui a vu son propre catalogue, ses propres files et ses propres automatismes est opérationnel. Un agent qui a suivi une présentation générale de JSM devra tout réapprendre le jour de la mise en production.
- Définir clairement ce qui relève de l'administration courante et ce qui nécessite un arbitrage. Sans cette frontière, la moindre demande d'évolution remonte au projet, ou n'est jamais traitée.
- Associer les agents à la phase de réalisation. Ceux qui ont participé aux ateliers de conception deviennent naturellement les relais auprès de leurs collègues. C'est de la formation gratuite et bien plus efficace qu'un support de présentation.
Ce que nous conseillons, côté utilisateurs
Les utilisateurs finaux n'ont pas besoin d'une formation. Ils ont besoin de savoir où cliquer, ce qu'ils y gagnent, et que leur demande ne va pas disparaître dans un tunnel.
Le message tient en trois points : voici le nouveau point d'entrée, voici pourquoi il est préférable à l'ancien, voici ce qui se passe après l'envoi de votre demande. Tout le reste est du bruit.
Le portail doit être suffisamment clair pour ne pas nécessiter de mode d'emploi. Si une notice est indispensable, le problème est dans le portail, pas dans la communication.
Les pièges
- Communiquer le jour de la mise en production. Il faut annoncer, rappeler, puis accompagner. Une seule annonce, aussi bien rédigée soit-elle, ne survit pas à une boîte de réception.
- Généraliser d'emblée. Un pilote sur une équipe volontaire pendant quelques semaines permet de corriger ce qui doit l'être avant que l'ensemble de l'organisation ne se forge une première impression. Une mauvaise première impression sur un portail de support se paie pendant des mois.
- Négliger les quick wins visibles. Une demande auparavant traitée en trois jours et désormais résolue en deux heures grâce à un automatisme est le meilleur argument de déploiement possible. Il faut l'identifier tôt et la mettre en avant.
Notre retour d'expérience
Le vrai indicateur d'adoption n'est pas le nombre de tickets créés dans le portail, c'est la baisse des sollicitations hors canal officiel : mails directs aux agents, messages Teams, interpellations dans le couloir. Tant que ces canaux parallèles persistent, le projet n'est pas terminé, quel que soit le contenu des tableaux de bord.
Le run et l'amélioration continue : le projet ne s'arrête pas à la mise en production
Un projet JSM déclaré terminé le jour de la mise en production est un projet qui se dégradera lentement. Le catalogue vieillit, les process évoluent, les équipes changent, et la plateforme se transforme d'elle-même au rythme des évolutions Cloud.
L'objectif
Savoir qui administre, et avec quel temps. C'est la question à poser au cadrage, et à reposer avant la mise en production. Comme évoqué plus haut, le mythe du zéro administration en run ne résiste pas à la réalité : une application vivante demande du temps, ne serait-ce que pour ajuster un formulaire, ajouter un type de demande ou intégrer une nouvelle équipe.
Deux modèles fonctionnent, à condition d'être assumés :
- Une compétence interne identifiée, avec un temps effectivement alloué et sanctuarisé. Un application owner à qui l'on confie la plateforme en plus d'un poste déjà complet finira par ne plus l'administrer du tout.
- Une TMA, qui garantit la disponibilité et la compétence, à condition de conserver en interne la capacité d'arbitrage sur les évolutions fonctionnelles.
Ritualiser la revue
Une revue trimestrielle du catalogue et des SLA suffit, et elle doit avoir un livrable : ce que l'on ajoute, ce que l'on modifie, et surtout ce que l'on supprime. Un type de demande utilisé trois fois en un an encombre le portail sans rendre service. Retirer est un acte d'amélioration continue au même titre qu'ajouter.
Alimenter un backlog d'évolutions dès la phase de pilote. Toutes les idées ne seront pas retenues, mais une demande tracée est une demande arbitrable, alors qu'une demande orale devient une frustration.
Le piège propre au Cloud : la veille n'est pas optionnelle
Sur JSM Cloud, les évolutions arrivent sans qu'on les demande. Nouvelles fonctionnalités, changements d'interface, ajustements de licence, évolutions des politiques de données : autant de sujets qui peuvent impacter la configuration, les coûts ou la conformité d'une plateforme en production.
Concrètement, cela suppose de suivre les annonces de releases et les changements de licensing, d'anticiper les impacts réglementaires, notamment sur la localisation et l'usage des données pour les organisations européennes, et de tester les nouveautés significatives dans un environnement de recette avant de les ouvrir aux équipes.
C'est un travail de quelques heures par trimestre pour une organisation qui s'y astreint, et un projet de remise à niveau pour celle qui découvre trois ans de changements d'un seul coup.
Ce qu'il faut retenir
S'il ne fallait retenir que 3 réflexes :
- Traiter le « qui » et le « quoi » avant le « comment ».
- Assumer la sobriété : peu de types de demandes, peu de champs, peu de SLA, mais compris et tenus.
- Prévoir dès le cadrage qui administrera la plateforme, avec quel temps, et selon quel rythme de revue.
Le reste, la configuration, se fait vite. C'est même la partie la plus simple du projet.
PS : on avait dit en introduction « presque jamais » technique. La seule limite vraiment technique de l'outil que nous avons rencontrée, qui peut faire dérailler votre projet ou le transformer en usine à gaz immaintenable : vouloir un outil 100 % multilingue, sur le portail et surtout sur l'interface back-office des agents… C'est clairement la limite de JSM Cloud actuellement.
