Cinq clés sur les incidents et les problèmes

Cinq clés sur les incidents et les problèmes

La gestion des incidents est pour vous un problème (haha) ? Voici cinq clés qui vont vous permettre de vous y retrouver un peu plus dans ce qui est souvent le premier pas vers la démarche ITIL.

1 - Indicateur de maturité

La gestion des incidents fait généralement partie du premier processus qui est mis en oeuvre dans ITIL. Souvent parce que l’on pense (à tort) que c’est déjà ce que l’informatique maîtrise le mieux. Si vous voulez facilement connaître le niveau de mise en oeuvre et de compréhension de la gestion des incidents et des problèmes au sein de votre organisation informatique il est très facile de faire un petit test : allez demander à 10 personnes, choisies au hasard, quelle est la différence entre un problème et un incident. En fonction des réponses, vous allez savoir si votre processus est bien en place ou pas.  

Voici quelques réponses possibles : 

• « Je ne sais pas » : vous avez encore du travail !
• « Un problème est une panne et un incident… c’est aussi une panne, mais moins grave » : ça commence à rentrer.
• « Les incidents c’est le premier niveau, les problèmes c’est le second niveau » : la mise en place est en cours, vous avez besoin de sensibiliser vos équipes et ça devrait aller tout seul.
• « Un problème c’est un incident dont on n’a pas la solution » : bon début, mais encore du travail.
• « Un problème est un incident récurrent » : presque tout bon, vous pouvez passer à la mise en oeuvre du processus suivant !
• « Un problème est la cause d’un incident. Un incident est une dégradation du business » : chez vous tout le monde est certifié ITIL ?

2 - Les techniciens malheureux

Il faut bien comprendre qu’un technicien informatique est quelqu’un qui aime résoudre des énigmes, puis expliquer comment il a fait. Donnez un casse-tête à un technicien et il va passer sa semaine à le résoudre. Sa ténacité est telle qu’il va même y passer son temps libre et ne renoncera qu’en tout dernier recours. Hélas, cette approche est difficilement compatible avec la gestion des incidents telle que nous la présente ITIL. En effet, pour le référentiel, l’objectif est de restaurer le service le plus rapidement possible. L’aspect technique n’a que peu d’importance… Et du coup ce genre de situation frustre les techniciens. Mettez des techniciens dans votre centre de services et vous allez avoir des personnes malheureuses qui ne resteront pas dans votre entreprise 

3 - La gestion des problèmes en intérim

Une erreur des plus classiques est de penser que la gestion des problèmes est une activité parallèle à la gestion des incidents. Et quand je dis «parallèle», je veux dire « secondaire ». En réalité, la gestion des problèmes est le processus qui va permettre de sortir du « mode pompier » et ainsi reprendre la maîtrise de son infrastructure. Cependant, pour que cela fonctionne, il faut mettre des moyens. La pire approche que vous pouvez avoir est de prendre un technicien et, une demi-journée par semaine, de lui donner le rôle de gestionnaire des problèmes. La bonne approche consiste en fait à nommer un vrai gestionnaire des problèmes à plein temps et des techniciens pouvant l’aider à résoudre les problèmes.

4 - Le véritable objectif de la gestion des incidents

Beaucoup de personnes pensent que l’objectif de la gestion des incidents est la résolution des incidents. En fait, il n’en est rien. L’objectif principal est de restaurer le service le plus rapidement possible. Il faut bien comprendre que, dans ITIL, nous sommes sur une approche business. Le rôle de l’informatique est justement de supporter le business. Donc l’aspect technique (même s’il est toujours très présent) n’est pas une finalité en soi. Dans la gestion des incidents, on se moque de savoir ce qui a provoqué l’incident, l’important est de savoir comment l’utilisateur va pouvoir continuer à travailler, et comment mettre en oeuvre cette solution le plus rapidement possible. 

5 - La vraie différence entre incident et problème (et leurs gestions)

En fait, si vous voulez comprendre la vraie différence entre un incident et un problème il suffit de se référer à la médecine. Un incident est un symptôme, tandis qu’un problème est la maladie…

On est en hivers, il fait froid, vous êtes malade. Vous avez de la température, le nez qui coule, mal à la gorge et des courbatures. Ceci est autant d’incidents qui vous concernent. 

Vous allez effectuer une gestion des incidents : 

• température/courbature : paracétamol
• Mal de gorge : sirop
• Nez qui coule : spray nasal 

Et du coup, vous vous sentez mieux ! Mais vous êtes toujours malade. Vous allez donc chez le médecin qui vous dit que vous avez une angine et vous prescrit des antibiotiques et du repos.

Reprenons, le mal de gorge est un  symptôme. C’est donc un incident. Vous allez traiter cet incident de manière à annuler ses effets : c’est la gestion des incidents. Mais pour résoudre ce qui provoque ces incidents, vous allez traiter la maladie, c’est-à-dire le problème. Une fois le problème résolu, les incidents n’apparaitront plus. Ce sont donc deux processus qui fonctionnent en parallèle :

• La gestion des incidents s’occupe de résoudre les inconforts liés à une situation dégradée.
• La gestion des problèmes travaille pour s’assurer que les incidents ne se reproduiront pas.

J’espère que ce rapide tour d’horizon vous aura intéressé. Si vous souhaitez me contacter, n’hésitez pas à le faire : thibault_carrier@yahoo.fr

Vous pouvez aussi télécharger ma brochure sur les sensibilisations à ITIL à l’adresse suivante :  https://mon-partage.fr/f/DPun72dk/

Comments

[Thibault Carrier]

Bonjour Dali,



Merci pour ce retour d'expérience, qui me semble un peu douloureux.



Il existe un moyen très simple de convaincre les personnes de l'utilité de séparer les incidents des problèmes, et aussi de démontrer un ensemble de gains liés à ITIL : c'est l'utilisation de Serious Games. J'en connais plusieurs (que j'ai animés) : Airport Simulation, Formula One, High Performance Simulation, ...

L'avantage de ces jeux est de pouvoir mettre en position certaines personnes. Ainsi, si tu as des gens qui sont persuadés que l'on peut faire de la gestion de problème et d'incident en même temps, il suffit de leur donner le role de problem manager dans le jeu. Ils comprendront rapidement que tant qu'ils restent avec les équipes des incidents,ils ne font jamais de gestion des problèmes. :)

[dali]

Bonjour Thibault



Je suis totalement d'accord avec toi pour cette présentation des chose et c'est une réalité que nous vivons aujourd'hui dans notre contexte

En fait Je suis sur un projet de mise en place de ITIL au seins d'une organisation classique et parmi les points qui se présente très ambigus c'est la différence entre problème et incident parce que tout simplement c'est la même équipe qui traite les incidents et les problèmes et les gens ne voit pas pourquoi ce n'est pas la même chose

Au début nous avons commencés par le processus de IM qui en cours de déploiement et nous somme en plein dans cette histoire de "c'est quoi l'incident et c'est quoi le problème"



Merci