Il est temps de parler... de temps de résolution et de MTTR ! Le temps de résolution est une métrique qui existe depuis aussi longtemps que je me souvienne. Si le temps de résolution (ou MTTR) n'est pas nouveau, il est temps d'y regarder de plus près et de décortiquer ce que signifie réellement le temps de résolution.
Pourquoi maintenant ? Parce que le temps de résolution compte... beaucoup ! Et le temps de résolution est, à la base, un indicateur de la convivialité et de l'expérience utilisateur. C'est aussi l'une des mesures les plus mal comprises et les plus mal interprétées. Alors, mettons-nous au travail !
Dans ce guide Time to Resolve
Qu'est-ce que "Time to Resolve" ?
Qu'entendez-vous par "temps de résolution" ?
Le Time To Resolve (MTTR) nous donne le temps moyen nécessaire à la résolution d'un cas ou d'un incident présentant le même symptôme lors d'une interruption ou d'un scénario de résolution de problème :
Time To Resolve = temps entre l'incident et la résolution pendant la durée de la panne
En substance, le temps de résolution est un indicateur qui nous dit combien de temps les utilisateurs attendent pour une erreur spécifique. Peu importe que les utilisateurs rencontrent le même problème ou un problème différent, mais plutôt qu'ils aient déjà rencontré quelque chose de similaire auparavant et combien de temps il leur faut pour se remettre en marche en trouvant une solution.
MTTD et MTTR : quelle est la différence ?
MTTD et MTTR sont taillés dans le même moule. Mais ce ne sont pas les mêmes ! Le MTTR nous indique le temps nécessaire pour remettre un système en état de marche, tandis que le MTTD nous indique le temps écoulé entre le moment où un incident s'est produit et celui où il a été résolu. Pour simplifier, nous allons nous concentrer sur le temps de résolution dans cet article, mais je voulais que vous soyez conscient de la légère différence entre MTTD et MTTR.
Le MTTD est le temps écoulé entre l'incident et le moment de la résolution.
Le MTTR désigne le temps écoulé entre l'incident et le moment de la résolution.
Exemple : Temps de l'incident (TOI) et temps de résolution (TOR)
Il est utile de penser au MTTR de la manière suivante : Un problème survient au moment X, il faut en moyenne Y temps à l'utilisateur A pour trouver une solution, puis le problème est résolu au moment Z.
Gardez également à l'esprit que MTTD désigne le temps écoulé entre le moment où un incident se produit et celui où il est résolu, tandis que MTTR désigne le temps écoulé entre le moment où le problème se produit et celui où il est résolu. Cela peut sembler trivial, mais je pense que nous avons tous été confrontés à cette confusion plus d'une fois, alors je voulais m'assurer que nous étions parfaitement clairs.
Quand dois-je mesurer le temps de résolution ?
Le Time To Resolve nous fournit d'excellentes données lorsque nous devons comprendre la satisfaction des utilisateurs pour les erreurs récurrentes - celles qui présentent des symptômes similaires. Par exemple :
- Pourquoi mon site était-il encore en panne ? C'est arrivé la semaine dernière ! Je ne peux pas croire que vous ne pouvez pas empêcher que cela se produise encore et encore...
- Après avoir mis à jour mon navigateur, je continue à recevoir ce message. Pourriez-vous demander à quelqu'un d'y jeter un coup d'œil ?
- Les instructions que vous avez envoyées n'étaient pas claires. Quelqu'un peut-il les relire ?
Si le temps de résolution est quelque chose que vous pouvez mesurer (et le temps de résolution est possible pour tout le monde), alors le temps de résolution vous aidera à comprendre le temps qu'il faut à vos utilisateurs pour se remettre au travail après une panne. En gros, combien de temps les utilisateurs ont-ils mis avant de pouvoir reprendre leur travail après avoir rencontré le problème ?
Après tout, le "temps", c'est de l'argent ! Voyons donc comment nous pouvons faire en sorte que le temps de résolution soit toujours disponible pour être utilisé ...
Le délai de résolution nous permet de calculer le temps pendant lequel vos utilisateurs attendent la résolution d'un problème. Nous pouvons ensuite comparer ces données dans le temps et entre différentes équipes. Il existe plusieurs autres indicateurs clés de performance (ICP) qui sont utilisés pour déterminer s'il y a des problèmes dans ce domaine - le temps de résolution est l'un d'entre eux !
Comment mesurer le temps nécessaire pour résoudre un problème ?
Tout d'abord, le Time To Resolve doit être mesuré pour pouvoir être utilisé. Le temps de résolution peut être mesuré de trois façons : (1) le temps entre l'incident et le moment de la résolution, (2) le temps pendant la durée de la panne, (3) le temps entre l'incident et le moment de la fermeture. Il y a des avantages et des inconvénients à chaque méthode, ainsi que la manière dont elle peut être rapportée ; gardez donc ces éléments à l'esprit lorsque vous choisissez une méthode pour votre équipe. Examinons les trois méthodes ci-dessous.
1.) Temps entre l'incident et le moment de la résolution : Il s'agit d'une excellente mesure pour les équipes qui souhaitent une rotation rapide car vous pouvez extraire des données rapidement après qu'une panne se soit produite. L'inconvénient est que vous perdez certaines données historiques si quelque chose n'a pas encore été résolu dans les 72 heures (ce qui était autrefois considéré comme une bonne pratique), mais cela permet d'accélérer les choses sur des périodes plus longues, ce qui pourrait aider à réduire le délai de déclaration. Le temps de résolution pendant la période de panne est l'un de nos indicateurs les plus populaires !
2.) Le temps entre l'incident et le moment de la fermeture : Voici un exemple de temps entre l'incident et l'heure de fermeture où vous pouvez voir qu'il y a eu 100 minutes entre le début du problème et le moment où l'utilisateur de ce ticket particulier a pu se remettre en marche. Cette méthode est plus longue que celle qui consiste à extraire des données juste après une panne, mais elle nous donne des données historiques beaucoup plus nombreuses sur une plus longue période. Ces données peuvent être analysées par différentes équipes afin de déterminer ce qui est le plus long (et pourquoi).
3.) Temps écoulé entre l'identification du problème et sa résolution : Voici un autre exemple de temps entre l'heure d'identification du problème et l'heure de clôture. Cette fois-ci, vous pouvez voir qu'il a fallu 50 minutes à l'utilisateur pour que son problème soit résolu, et il est également clair que cette fois-ci, les données proviennent de plusieurs jours plutôt que d'un seul. N'oubliez pas que ces données sont plus difficiles à extraire que les autres méthodes, car les problèmes ont tendance à être mis à jour au fur et à mesure qu'ils progressent dans votre flux de travail. Gardez à l'esprit que nous avons besoin d'au moins 24 heures entre les mises à jour avant de pouvoir capturer des données sur le temps de résolution.
En général, le temps de résolution (mesure) entre dans l'une de ces trois catégories :
- pendant les temps d'arrêt (le temps de collecte des données comprend les temps d'arrêt et le temps nécessaire au personnel pour résoudre le problème)
- après le temps d'arrêt (jours ou semaines après la collecte des données)
- le temps dans la file d'attente (de l'heure de début dans le système jusqu'à l'heure de fermeture dans le système).
Vos utilisateurs attendent, que faire maintenant ?
C'est ici que le temps de résolution devient délicat ! N'oubliez pas que le "temps", c'est de l'argent. Il est donc important que vous preniez votre temps pour résoudre les données et les transformer en quelque chose d'utile. Voici quelques questions que vous pourriez vous poser :
- Quelle est l'ampleur réelle de ce problème ?
- À quoi ressemble ce problème au fil du temps ? Voyez-vous des tendances se développer ?
- Mon équipe s'améliore-t-elle ou se dégrade-t-elle dans la résolution rapide des problèmes ?
Il n'est pas toujours facile de transformer vos données sur le temps de résolution en quelque chose d'utile. Parfois, les équipes disposent d'une grande quantité d'informations, mais elles savent qu'elles ne peuvent pas apporter de changements sans données sur le temps de résolution. En extrayant les données sur les délais de résolution, vous serez en mesure non seulement de vous comparer à vos homologues du secteur, mais aussi de voir si votre temps est utilisé efficacement dans ce domaine !
Conseils pour réduire le délai de résolution et le MTTR
Vous savez donc ce qu'est le temps de résolution, comment le mesurer et le suivre. Maintenant, vous voulez diminuer cette mesure très importante. Voici nos conseils préférés !
- N'ayez pas peur d'arrêter de faire quelque chose qui prend du temps mais qui est sans importance. Si vous consacrez votre temps à un grand nombre de choses qui ne font qu'ajouter du temps sans apporter de valeur ajoutée, il est peut-être temps de réévaluer ces activités.
- Commencez à utiliser (ou continuez à utiliser) une plateforme d'observabilité ou un système de gestion des incidents comme Pagerduty ou d'autres solutions qui laissent moins de place à l'erreur, plutôt que le courrier électronique ou les feuilles de calcul si c'est la façon dont vous suivez actuellement les incidents. Les courriels peuvent se perdre ou être oubliés, les feuilles de calcul deviennent désordonnées et confuses et, en fin de compte, le temps continue de s'écouler pendant que vous faites des allers-retours pour tenter de résoudre les problèmes.
- Classez toujours votre travail par ordre de priorité - commencez par les tâches les plus importantes car elles prendront le plus de temps, puis classez par ordre de priorité le temps nécessaire à l'accomplissement d'une tâche pour gagner du temps.
- D'autres moyens d'améliorer le temps de résolution sont les suivants : avoir un processus clair et facile à suivre, s'assurer que votre équipe est formée de manière appropriée à tous les niveaux, et toujours savoir quels tickets sont dans la file d'attente - ainsi vous savez exactement combien d'utilisateurs vous attendent !
Réflexions finales sur le délai de résolution et le MTTR
Le délai de résolution est un excellent indicateur de la qualité du travail informatique. Il est utilisé comme une indication que les problèmes sont résolus correctement et en tenant compte de la gestion du temps. Avoir un taux de résolution efficace signifie que les problèmes sont résolus assez rapidement pour que les équipes puissent s'y attaquer, mais pas trop rapidement au point de considérer qu'il s'agit d'une "lutte contre le feu" plutôt que d'une véritable analyse des causes profondes du problème. Un bon KPI de temps de résolution aide les équipes à répondre à des questions sur le service à la clientèle, l'efficacité, le temps passé sur les tâches, entre autres. Il est donc important de ne pas seulement "se concentrer" sur le temps de résolution, mais aussi de comprendre ce que cela signifie pour votre équipe !
