Mesurer la qualité de la gestion des problèmes dans un environnement ITIL, partie 1

A Closer Look at How Problem Managers Measure Performance

Comprendre comment les analystes et les ingénieurs travaillent sur les problèmes, trouvent les causes profondes et assurent le suivi avec des actions appropriées semble être une tâche facile. Une fois que l'on a accès à l'application utilisée pour documenter la gestion des problèmes ITIL, le contenu des cas peut être lu. Tout ce qui semble être nécessaire est l'accès à l'outil de gestion des cas et quelques compétences pour utiliser cet outil.

However, asking Problem Managers how they handle problems will typically uncover the true procedures that describe what steps they take when finding and working on problems. These documented processes and procedures are very helpful when expectations are very clearly set on the steps to be taken to progress problems that require attention.

Reading problem tickets or asking Problem Managers how they fill in the steps in the procedures seems a logical next step to find out more about how value is created in Problem Management. This is where information is really gathered, data is analyzed and conclusions are drawn. So, how does the performance of Problem Management get measured? Many organizations seem to measure timing-related parameters around the problems, or counting the number of problem tickets, in a given state. Examples include:

  • Nombre de tickets de problèmes ouverts (backlog) par groupe d'applications, considéré dans le temps
  • Âge moyen des tickets de problèmes ouverts, souvent considéré dans le temps
  • Temps moyen pour trouver la cause profonde dans les tickets de problèmes
  • Nombre de problèmes récurrents

Considering the goals of Problem Management: to find causes of problems and proactively take actions to avoid future incidents and problems, how well do the examples above tell how successful a team is towards achieving these goals? Are we asking for one thing and measuring something completely different?

Une expérience de vie réelle

About two days into an assessment of how Problem Management was being handled in a global IT department of a worldwide company, we decided to take a break to compare our findings amongst the participants in the assessment. Fields that were considered for inspection included the ticket summary and problem description, as well as individual progress updates and the resolution descriptions.

The pattern was seen in most problem tickets. The summary was clearly indicating the affected application or hardware and what was wrong with it, followed by some underlying data in the detailed problem description. Further updates would typically indicate how the problem was traveling through the procedural steps of Problem Management as time was progressing and reaching a conclusion in the resolution description.

Although this seems like an individual case, it represents the pattern that was seen amongst the team doing the assessment. After talking through other experiences, the following picture was made to represent the observations seen

Cela soulève une série de questions sur la façon dont les conclusions ont été tirées et les actions ont été prises ou planifiées :

  • Quelles sont les données à recueillir pour trouver efficacement une cause ?
  • Comment les experts s'assurent-ils qu'ils ont recueilli les données appropriées au moment opportun ?
  • A quoi ressemble la magie ? Quelles mesures non documentées ont été prises ? Quelle réflexion non documentée a été menée ?
  • Quelles autres causes ont été envisagées ?
  • What level of confidence did the resolving team have that found the cause really was the “true cause”?
  • Quels effets secondaires les mesures prises pour résoudre le problème ont-elles pu provoquer ?

Les réponses à ces questions peuvent donner un bon aperçu de la manière dont la valeur a été créée dans la Gestion des Problèmes pour un ticket donné. Les réponses à ces questions ne sont généralement pas liées au calendrier ou aux paramètres numériques des procédures de gestion des problèmes. Elles concernent la qualité de la collecte des données et la qualité des processus de réflexion des personnes impliquées.

In our next blog, learn what “magic” is really all about. Finding stability after recurring problems and realizing that there is no common way to handle a single problem will reveal exactly how Problem Management “magic” is performed.

Image du blog 1
Measuring Problem Management Quality in an ITIL Environment, Part 2
Image du blog 1
Measuring Problem Management Quality in an ITIL Environment, Part 3
Image du blog 1
Measuring Problem Management Quality in an ITIL Environment, Part 4
Image du blog 1
Qu'est-ce qui lie ITSM et ITIL® à Agile et DevOps ?

Nous contacter

Pour des demandes de renseignements, des détails ou une proposition !