La qualité perçue d’un service est basée sur l’opinion d’un utilisateur, qu’il considère selon sa propre perception à un instant T. Elle comporte de fait une dimension subjective et se révèle difficile à mesurer quantitativement, ce qui la démarque de la qualité mesurée d’un service. C’est pourtant grâce à la prise en compte de ces deux types de qualités, perçue et mesurée, qu’une Direction des Systèmes d’Information peut réellement mettre en œuvre un management de la qualité de service!
Stéphanie Clavé, Responsable Opérationnel d’Agence chez Inside, nous faire part de son expérience dans un domaine où le ressentit se confronte parfois aux mesures les plus rigoureuses.
Qu’entendez-vous par la qualité de service perçue dans le contexte d’une DSI ?
La qualité de service perçue (ou QS perçue) est la qualité de service estimée par un utilisateur à un instant T ou sur une période plus longue (il est également possible de mixer les deux). Elle est donc très différente de la qualité de service dite « mesurée » car elle est beaucoup plus subjective, et très dépendante du moment de la prise en compte de l’estimation. D’ailleurs, la qualité de service mesurée d’une DSI peut s’opposer à sa qualité perçue : les indicateurs de la première peuvent être satisfaisants (taux de disponibilité du réseau supérieur à 99%), et ceux de la seconde insatisfaisants (accès Wi-Fi à ce réseau surchargé). Pour disposer d’une véritable vision de la qualité de service d’une DSI, il faut donc mettre en œuvre des bonnes pratiques (ITIL) et des KPIs, et mesurer du côté de l’utilisateur le ressentit des services proposés. Car in fine la DSI est bien au service des utilisateurs, la qualité des services IT « perçue » est donc primordiale.
Comment mesure-t-on cette forme de qualité des services IT ? Pourriez-vous nous partager des exemples ?
Comme pour la qualité de service mesurée, il faut identifier des KPIs pour la qualité de service perçue. Pour autant il faut garder en tête que l’utilisation d’applications ou de services ne se résume pas à l’identification de ces derniers. Il peut y avoir en effet d’autres éléments qui entrent en jeu dans l’environnement de l’utilisateur qui feront apparaître un dysfonctionnement ou des irritants. Pour mettre en place une mesure de la qualité perçue, il y a deux méthodologies principales. La première est dite « à chaud » et consiste à montrer à l’utilisateur une fenêtre de notation de l’application ou du service qu’il vient d’utiliser (il doit donner une note par exemple). La seconde est dite « à froid » et peut prendre la forme d’enquêtes de satisfaction par exemple (avec des envois réguliers et des panels d’utilisateurs qui peuvent changer à chaque envoi). Les informations sont ici plus détaillées, avec des verbatims à analyser.
Comment améliorer cette qualité des services IT perçue par les utilisateurs ? Quels sont les leviers à mettre en place ?
Le levier le plus fort est certainement celui qui va consister à faire travailler ensemble les différentes parties prenantes. Par exemple un travail de groupe doit continuer après l’expression des besoins, au risque de laisser le service IT continuer tout seul. Il est donc nécessaire de faire des revues de qualité dans le temps, en impliquant à chaque fois des représentants des utilisateurs finaux. Ce qui évitera de livrer un outil qui répond incomplètement à l’attendu, surtout quand l’environnement de développement diffère de l’environnement d’utilisation (difficulté d’accès à un réseau Wi-Fi par exemple dans un bâtiment spécifique). Et si l’équipe de développement dispose d’insuffisamment de retours terrains pour comprendre le contexte (qui peut être différent d’un utilisateur à l’autre), elle ne peut mettre en œuvre de correctifs, ce qui va engendrer des insatisfactions… Donc une qualité perçue dégradée du service IT.
Quels sont vos conseils pour bien commencer cette démarche qualité ?
Je conseille de déjà commencer par faire un mapping du projet, pour identifier les collaborateurs qui vont construire ce projet (ceux sur lesquels s’appuyer pour remonter les informations via des enquêtes, ceux qui vont améliorer l’existant, faire de l’AMOA et de l’AMOE) et les collaborateurs qui interagissent avec l’application visée par la Direction des Systèmes d’Information (les utilisateurs et leurs typologies d’activité et leurs modes de connexion, qui peuvent différer en fonction de leur poste). Il faudra ensuite identifier des référents dans chaque groupe comme représentant d’un panel d’utilisateur. L’idée est de confronter les points de vue et de détecter les irritants pour obtenir des KPIs « rouge ou orange » afin d’assurer l’amélioration continue. Un sponsor du Comex pour diriger ce type de campagne est alors très utile, et la notion de suivi dans le temps est essentielle.
Les actions à mener doivent donc s’étaler sur tout le projet, c’est ainsi qu’il est possible de rapidement identifier et mettre en œuvre des quick-win en parallèle d’un plan d’action à plus long terme. Il faut également communiquer sur cette démarche au sein de l’organisation, mesurer et remesurer pour s’assurer de renforcer la qualité de service et l’expérience utilisateur. Le fait de prendre en compte tous ces aspects et de mettre des actions en œuvre (et donc les moyens associés) est un marqueur de la maturité d’une DSI, et par corolaire de la qualité de tous ses services.
Echangeons autour de la qualité mesurée et perçue de votre support et de vos process IT !