Comme vous le savez tous, la fin des années 1980 était l’époque où les Guns N’ Roses remportaient un succès fulgurant, où Madonna et Michael Jackson se produisaient lors de leurs premières tournées mondiales, mais ces années étaient également marquées par un mouvement (peut-être) plus important encore avec l’apparition d’ITIL. Grâce à ce nouveau cadre, l’informatique a pu commencer à fournir des services et non uniquement de la technologie à ses utilisateurs et clients. Tout le monde s’accorde à dire que les pannes de service sont des facteurs négatifs qui doivent être résolus dans les plus brefs délais.

Lorsqu’un problème apparaît 

Le problème peut apparaître comme s’il était traité par un psychologue plutôt que par un professionnel de l’informatique – nous, les humains, trouvons qu’il est extrêmement difficile de laisser une douleur évidente sans réponse, même si nous avons la promesse d’une amélioration plus tard. Si vous y réfléchissez, c’est précisément l’origine du “Catch 22”.

“Catch 22” est une situation paradoxale à laquelle un individu ne peut pas s’échapper en raison de règles ou de limitations contradictoires.

Lors de la mise en œuvre des Bonnes Pratiques ITIL dans une organisation, vous mettez en place des pratiques (qui dans ITIL v3 étaient appelées processus) car vous souhaitez :

• être plus efficace
• être plus structuré
• prendre le contrôle de notre infrastructure
• économiser de l’argent
• augmenter la satisfaction client

Pour en savoir plus, consultez notre article 7 conseils pour implémenter ITIL dans une organisation.

Catch 22

Bien que le but ultime de toutes les pratiques soit de satisfaire vos clients, certaines d’entre elles sont plus orientées utilisateurs que d’autres. C’est là où les problèmes commencent : vous investissez toutes vos ressources dans les pratiques les plus orientées utilisateurs et cela vous laisse désarmés alors que vous devriez investir du temps et de l’énergie dans des pratiques moins orientées utilisateurs mais tout aussi, voire plus, importantes.

Se concentrer sur les pratiques orientées utilisateur est un choix évident. Lorsque les utilisateurs mettent la pression sur le Service Desk, ou lorsqu’un incident impacte la production, ou lorsque les clients attendent la prochaine version du produit, vous souhaitez agir. Il est humainement très difficile (dans certaines situations je dirais impossible) de rejeter ces activités au profit de celles qui n’auront pas d’effet immédiat.

Du coup, vous finissez par investir tout votre temps et votre énergie dans la lutte contre les incendies, sans même avoir le temps de vous demander comment il est possible d’avoir autant d’incendies à éteindre. Et ici, vous trouvez votre “catch 22” : les interruptions de service (incidents) sont des événements négatifs et doivent être résolus dès que possible. Vous vous concentrez tellement sur la deuxième partie de la phrase que vous en oubliez la première.

Si vous convenez que les incidents sont des facteurs négatifs, qui ont un impact très négatif sur la satisfaction du client, alors vous devriez essayer de les éviter, n’est-ce pas ? Et si vous ne pouvez pas les éviter complètement, l’un des objectifs de la gestion des problèmes ou problem management, en anglais, est certainement de minimiser leur impact. Nous sommes tous d’accord là-dessus, mais c’est plus facile à dire qu’à faire, car nous sommes humains et donc nous sommes catalysés par la partie « résoudre le plus tôt possible » de la phrase.

Ce n’est pas une solution magique, mais…

Il n’y a donc pas d’échappatoire ? Sommes-nous condamnés à chasser les moulins à vent ? Heureusement non. Mais comme déjà mentionné, il n’y a pas de solution magique. Ou du moins aucune à ma connaissance (si vous en avez une entre les mains, n’hésitez pas à la partager avec nous), mais on peut y travailler !

On pourrait penser que dans une situation idéale, une organisation devrait avoir deux équipes distinctes pour travailler sur les incidents et les problèmes, afin qu’elles puissent éviter d’être aspirées dans le catch 22. Cependant, les choses ne sont pas toujours aussi simples.

Les incidents et les problèmes sont étroitement liés

La première motivation est de justifier l’impossibilité d’équipes séparées, puisque vous n’avez pas assez de professionnels pour dédier une équipe uniquement à la résolution de problèmes. Même si cela est vrai dans la plupart des situations, nous ne séparerions probablement pas ces deux activités de toute façon, car elles sont étroitement liées.

En effet, les connaissances techniques et les compétences nécessaires sont étroitement liées. L’un apprend de nombreuses choses utiles pour résoudre les problèmes et documenter les solutions de contournement, tandis que l’autre travaille sur les incidents, et vice versa. Des groupes complètement séparés ne sont donc pas la meilleure solution, mais des groupes temporaires pourraient l’être. En effet, former un groupe temporaire sur un ou plusieurs problèmes doit éviter aux membres de l’équipe l’anxiété liée à la gestion des incidents, à condition que l’équipe puisse travailler dans un lieu dédié.

Mise en œuvre claire des trois phases de la gestion des problèmes

Une mise en œuvre claire des trois phases de la gestion des problèmes, comme suggéré dans ITIL 4, peut vous aider à entrer dans la bonne direction. Étant donné que chaque phase a un résultat bien défini, il est relativement facile de confier les différentes phases à différents groupes, cela peut également être un bon moyen de répartir la charge de travail.

Phase d’identification des problèmes, à la fois proactive et réactive, cette phase devrait, à mon sens, être réalisée par des professionnels ayant à la fois des compétences techniques et fonctionnelles. Ils doivent avoir une bonne connaissance de l’organisation ainsi qu’une vision claire de l’infrastructure technique sur laquelle reposent vos services. Les deux sont nécessaires pour identifier la présence de problèmes potentiels et produire ensuite les résultats requis : une documentation complète et détaillée des problèmes (enregistrement du problème).

Une hiérarchisation de l’enregistrement du problème doit avoir lieu entre la phase d’identification des problèmes et la phase de contrôle. C’est essentiel pour réduire le stress (il y a toujours trop à faire) et s’assurer que vous utilisez au mieux vos ressources limitées.

La phase de contrôle des problèmes doit être effectuée par des techniciens expérimentés, créatifs et ouverts d’esprit. En commençant par l’enregistrement du problème, ils analysent les problèmes et documentent leurs conclusions. Cela amènera les problèmes à l’état d’erreur connue. Les résultats attendus de cette deuxième phase sont des solutions de workflow, qui permettront de résoudre les incidents plus rapidement (et cela améliore la satisfaction des utilisateurs et laisse du temps libre à notre personnel technique, suggérant la fin du catch 22).

Le contrôle des erreurs est la troisième et dernière étape des pratiques de gestion des problèmes. Une activité importante de cette phase est, encore une fois, une activité de priorisation. Étant donné que les erreurs connues peuvent rester ouvertes pendant un certain temps et que les circonstances sont vouées à changer, cette activité de hiérarchisation doit être tenue régulièrement. La priorité des erreurs connues doit être évaluée par une équipe de professionnels. En effet, plusieurs critères doivent être pris en considération, tels que :

• impact sur la satisfaction client
• coût de l’application de la solution de contournement actuelle
• coût de la résolution finale
• faisabilité technique de la résolution finale
• influence sur les produits partenaires que nous utilisons

Une fois les erreurs connues classées par ordre de priorité, le travail peut commencer sur une résolution finale ou une amélioration de la solution de contournement.

Nous espérons que cette approche structurée de la gestion des problèmes vous inspirera suffisamment pour vous convaincre de l’adapter à votre propre organisation, afin de vous sortir du « catch 22 of Problem Management ».