Un regard plus attentif sur la façon dont la gestion des problèmes est effectuée
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.
Cependant, en demandant aux gestionnaires de problèmes comment ils traitent les problèmes, on découvre généralement les véritables procédures qui décrivent les étapes à suivre pour trouver et traiter les problèmes. Ces processus et procédures documentés sont très utiles : les attentes sont très clairement définies quant aux étapes à suivre pour faire progresser les problèmes qui nécessitent une attention particulière.
Lire les tickets de problèmes ou demander aux responsables de problèmes comment ils remplissent les étapes des procédures semble être une étape logique pour en savoir plus sur la façon dont la valeur est créée dans la gestion des problèmes, car c'est là que les informations sont réellement recueillies, les données analysées et les conclusions tirées. Alors, comment mesurer la performance de la Gestion des Problèmes ? De nombreuses organisations semblent mesurer des paramètres liés au temps autour des problèmes, ou compter le nombre de tickets de problèmes dans un état donné. En voici quelques exemples :
- 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
Si l'on considère les objectifs de la gestion des problèmes : trouver les causes des problèmes et prendre des mesures proactives pour éviter de futurs incidents et problèmes, dans quelle mesure les exemples ci-dessus permettent-ils de savoir si une équipe atteint ces objectifs ? Demandons-nous une chose, et mesurons-nous quelque chose de complètement différent ?
Une expérience de vie réelle
Après environ deux jours d'évaluation de la manière dont la gestion des problèmes était gérée dans le département informatique d'une entreprise internationale, nous avons décidé de faire une pause pour comparer nos résultats avec ceux des participants à l'évaluation. Les champs qui ont été pris en compte pour l'inspection comprenaient le résumé du ticket et la description du problème, ainsi que les mises à jour de la progression individuelle et les descriptions de la résolution.
Dans la plupart des tickets de problème, le résumé indique clairement l'application ou le matériel affecté et ce qui ne va pas, suivi de quelques données sous-jacentes dans la description détaillée du problème. D'autres mises à jour indiquaient généralement comment le problème passait par les étapes de la procédure de gestion des problèmes au fur et à mesure que le temps passait, pour aboutir à une conclusion dans la description de la résolution.
Bien qu'il semble s'agir d'un cas individuel, il représente le modèle observé au sein de l'équipe chargée de l'évaluation. En parlant d'autres expériences, l'image suivante a été faite, représentant les observations vues :
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 ?
- Quel niveau de confiance l'équipe de résolution avait-elle dans le fait que la cause trouvée était vraiment la "vraie 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.
Maîtrisez les problèmes récurrents - Obtenez la stabilité.
Certains pourraient affirmer que lorsque la "magie" est bien faite, l'entreprise verra un faible nombre de problèmes récurrents, ce qui a été indiqué comme un indicateur de performance pour la gestion des problèmes ci-dessus. Ceci est vrai !
Malheureusement.
Ce qu'une entreprise obtient par des problèmes récurrents est un message selon lequel le processus de Gestion des Problèmes n'a pas fait un bon (ou assez bon) travail pour trouver la cause profonde lorsque le problème s'est produit pour la première fois. Comme la réapparition d'un problème peut prendre des semaines ou des mois, il s'agit d'un indicateur tardif et imprécis de la performance de la Gestion des Problèmes. Ce qu'il faut vraiment, c'est un moyen de mesurer les performances (et donc la valeur) de la gestion des problèmes de telle sorte qu'une entreprise puisse prédire que le nombre de problèmes récurrents va diminuer. En d'autres termes : quels sont les principaux indicateurs de performance de la gestion des problèmes ?
Trouver des mesures qui indiquent dans quelle mesure les problèmes ont été résolus peut n'avoir qu'un effet modéré pour les problèmes simples (à faible impact), où la récurrence ne serait pas appréciée mais ne serait pas non plus catastrophique. Certaines entreprises connaissent de temps à autre des incidents et des problèmes critiques qui les placent au bord d'un événement commercial catastrophique lié à un ou plusieurs événements informatiques, et elles décident de ne plus jamais revivre cette expérience ! La mesure des problèmes récurrents et des tendances n'est probablement pas une mesure suffisante.
Une meilleure pratique pour faire de la magie ?
Si l'on demande aux ingénieurs et aux analystes quel est leur processus de réflexion interne lorsqu'ils traitent des tickets de problème, on obtient de nombreuses réponses différentes. Il en va tout autrement lorsqu'on demande au même public comment configurer une application spécifique ou du matériel. Il est évident aujourd'hui qu'une approche commune pour la configuration d'une application ou d'un matériel présente de nombreux avantages :
- Une "meilleure configuration" pour le bien utilisé réduit les variations.
- Une compréhension commune de la manière dont les actifs apportent une valeur ajoutée à l'ensemble de l'infrastructure facilite la gestion des capacités.
- Il simplifie la communication sur la façon dont les actifs sont configurés ou modifiés.
- Il permet un transfert et une maintenance transparents et de haute qualité.
Compte tenu de ces facteurs, il est remarquable qu'il n'existe souvent aucune approche commune pour le traitement des problèmes. En conséquence, cela reste de la magie.
Lorsqu'une meilleure pratique pour trouver les causes profondes des problèmes est établie, elle offre des avantages très similaires à ceux d'une meilleure pratique pour configurer un actif. En outre, cela permettrait de créer un nouveau langage pour le dépannage, avec une terminologie qui permet de documenter ce à quoi ressemble la "magie" et comment on arrive aux conclusions.
À quoi ressemble la "magie" ?
Il existe de nombreuses façons de trouver la cause profonde d'un problème. Certaines sont plus efficaces que d'autres, et des personnes différentes (sans cadre standard) ont naturellement des approches différentes. L'efficacité de tout groupe de dépanneurs se situe quelque part le long d'une courbe en cloche. Les experts en dépannage ont une bonne réputation et peuvent se voir confier n'importe quelle tâche en toute confiance. Ceux qui ont une bonne réputation sont bons pour la plupart des tâches et peuvent encore s'améliorer. Ceux qui ont une mauvaise réputation ont probablement besoin d'aide.
La méthode Kepner-Tregoe (KT) d'analyse des problèmes a été étudiée et définie dans les années 1950, et n'a cessé d'être affinée et testée depuis. Il est facile de reconnaître que c'était bien des années avant l'invention de l'acronyme ITIL.
On a fait valoir qu'une méthode qui existe depuis si longtemps ne peut pas convenir au secteur informatique, car ni l'informatique ni ITIL n'existaient à l'époque où la méthode a été étudiée. Il faut examiner de plus près la méthode KT d'analyse des problèmes pour porter un jugement plus approprié. Les principales étapes de l'analyse des problèmes sont les suivantes :
- Décrire le problème
- Liste des causes possibles
- Évaluation des causes possibles
- Prouver la véritable cause
- Penser au-delà de la réparation
Pour chacune de ces étapes, il y a des intentions claires et des sous-étapes - qui sont mises en œuvre par la formulation des questions et la documentation des réponses pour obtenir les bonnes données qui alimentent le processus de réflexion de l'analyse des problèmes. Tout ceci se fait sans avoir à l'esprit un produit ou un problème spécifique, et est très similaire à ITIL, qui fonctionne pour toutes sortes d'organisations informatiques. L'analyse des problèmes est une approche permettant de trouver la cause profonde de nombreux problèmes différents, indépendamment du secteur ou de la technologie.
Un problème quelconque ?
Eh bien... oui ! Mais il existe une définition très spécifique de l'AC du terme " problème " qui est différente, mais qui correspond tout à fait à ITIL. Selon la KT, trois critères doivent être vrais, avant de déclencher le processus d'analyse des problèmes :
- Il doit y avoir un écart entre la performance réelle et la performance souhaitée. C'est ce que nous appelons un écart (par exemple, la machine ne fonctionne pas, alors qu'elle devrait fonctionner) ;
- La cause de la déviation est inconnue (par exemple, il ne s'agit pas d'une erreur connue) ;
- Il doit y avoir un besoin de connaître l'écart (par exemple, permettre de prendre des mesures).
Le résultat d'une série d'étapes bien définies pour trouver la cause première est que les personnes chargées du dépannage peuvent commencer à communiquer et à documenter ce qui a déjà été fait et ce qui doit être fait dans le processus. L'image ci-dessous donne un exemple de modélisation textuelle des données recueillies pour décrire les symptômes d'un problème.
Magie connue
Lorsque les étapes d'une approche cohérente et reproductible de l'analyse des problèmes sont bien comprises, il devient beaucoup plus facile de mesurer la qualité d'une cause fondamentale trouvée. Si la magie de la recherche de la cause première est comprise, elle peut être documentée, reproduite, transmise en douceur et chronométrée efficacement ; ce sont toutes les caractéristiques d'une meilleure pratique.
Dès qu'une organisation de support informatique commence à utiliser une approche unifiée de l'analyse des problèmes, la qualité ou la valeur immédiate des individus et des équipes peut être mesurée. C'est exactement ce que font les consultants KT lorsqu'ils évaluent la qualité des processus de dépannage existants dans un environnement de support informatique. En lisant les tickets d'incidents et de problèmes existants, et en estimant dans quelle mesure il faut structurer l'approche par rapport à une norme connue, nous pouvons aider à générer un indicateur de base pour la qualité du dépannage.
À titre d'exemple : Les informaticiens qui documentent systématiquement leur Synopsis (ou le champ équivalent dans leur outil de gestion des cas) en termes d'objet avec une déviation (répondant à la question : "Qu'est-ce qui ne va pas avec quoi ?") semblent passer en moyenne un peu plus de 10% de temps en moins avant de trouver la cause première.
Tout cela peut sembler si facile que cela ne peut pas être vrai - le simple fait de documenter l'objet et le défaut dont les experts prévoient de trouver la cause profonde permettra de gagner un peu plus de 10 % sur le délai de clôture. Vous avez peut-être raison : cela peut sembler facile, mais ce n'est pas le cas. Pour que ce processus de pensée s'imprime et devienne un réflexe, il faut un changement de comportement, et dans le feu de l'action, sous la pression du temps et d'autres pressions de l'entreprise, cette simple étape peut tomber à l'eau si elle n'est pas pratiquée et soutenue loin des questions de haute pression. Les étapes de la mise en œuvre d'une meilleure pratique en matière de dépannage sont bien comprises, mais le changement nécessite de l'attention, de la concentration, une bonne planification et de la réflexion. Heureusement, la réflexion est facile, mais les équipes de mise en œuvre peuvent être distraites. Les processus de réflexion de l'AC, comme l'analyse des problèmes, ne sont pas une solution miracle qui garantit que la cause première sera trouvée. Il s'agit simplement d'une méthode qui guide des experts déjà bien informés vers l'objectif, et le degré de réussite dans la recherche de la cause fondamentale peut varier en fonction de la qualité des données (et de l'observabilité) qui entrent dans le processus.
Ce dernier point est un ingrédient clé de la réussite ; il ne suffit pas de remplir le formulaire, le modèle ou la feuille de calcul pour obtenir une bonne cause fondamentale, car l'analyse de problèmes repose sur une base solide de logique dure qui doit être utilisée activement. Elle nécessite toujours une collecte intensive de données, une réflexion et une vérification, ce qui n'est pas différent du dépannage dans un environnement de dépannage non structuré. Le grand changement est que les étapes de la réflexion deviennent visibles et reçoivent un nom, le tout basé sur un plan sous-jacent clair pour l'analyse des problèmes. Grâce à cela, nous pouvons mesurer et communiquer sur notre situation et nos progrès dans le processus de recherche de la cause première.
Dans ce cas, la mesure n'est pas une requête de base de données montrant combien de temps ou combien de tickets répondent à un ensemble donné de critères. Il s'agit d'une évaluation qui peut être donnée par des experts internes (dépannage) qui jugent de la qualité des données recueillies au cours des différentes étapes de l'analyse du problème. Une telle évaluation devient alors un indicateur de performance principal pour la qualité de l'analyse du problème.
Où allons-nous à partir de maintenant ?
Lire un livre sur la façon de jouer du violon ne fait pas du lecteur un grand violoniste. De même, il ne suffit pas de former une organisation sur la manière de mieux réfléchir au dépannage pour qu'elle devienne un groupe de dépanneurs de classe mondiale. Il faudra de l'attention, de l'exercice et du dévouement pour intégrer cette approche dans les modes de pensée des individus, et les résultats seront payants. Investir dans la recherche des causes profondes dans le cadre de la gestion des problèmes, c'est investir dans les compétences techniques et l'expérience afin de disposer d'une main-d'œuvre consciente et bien équipée pour trouver des solutions de qualité à des problèmes complexes. Au début d'un cas de Gestion des Problèmes, un manager ne saura (toujours) jamais combien de temps il faudra pour trouver la cause première, mais il y aura une direction claire et planifiée et le temps d'arrivée sera plus prévisible, ce qui permet de mesurer la qualité de la Gestion des Problèmes.
Par Berrie Schuurhuis, Kepner-Tregoe
À propos de Kepner-Tregoe
Kepner-Tregoe est le leader de la résolution de problèmes. Depuis plus de six décennies, Kepner-Tregoe a aidé des milliers d'organisations dans le monde entier à résoudre des millions de problèmes grâce à une analyse des causes profondes et à des compétences décisionnelles plus efficaces. Kepner-Tregoe s'associe aux organisations pour réduire considérablement les coûts et améliorer les performances opérationnelles grâce à
des services de formation, de technologie et de conseil en matière de résolution de problèmes.