Trois objets, un exemple
Les définitions officielles n'aident personne. Un exemple, si.
Chaque lundi matin, quinze personnes ne peuvent plus imprimer. Le service support rétablit à chaque fois en redémarrant le service d'impression.
Les incidents sont les quinze tickets hebdomadaires. Ils sont traités, et bien traités : le service revient.
Le problème est la cause qui les produit, jamais cherchée parce que le contournement fonctionne. Ici, une tâche planifiée du dimanche qui laisse le service dans un état instable.
Le changement est la modification qui supprimera la cause, et qui doit être préparée et validée parce qu'elle touche la production.
Trois objets distincts, trois rythmes : l'incident se compte en heures, le problème en semaines, le changement en dates de fenêtre.
Le problème, et pourquoi personne ne l'ouvre
La gestion des problèmes échoue presque toujours pour la même raison : elle n'est le travail de personne. Chacun traite ses incidents, la file avance, et l'incident récurrent revient à l'infini parce qu'il est individuellement peu coûteux.
Un déclencheur écrit règle cela mieux qu'un discours : au troisième incident de même nature dans le mois, on ouvre un problème. C'est un seuil, il est arbitraire, et son mérite est d'exister.
Dans GLPI, le problème porte ses incidents liés, ce qui donne immédiatement son coût réel : quinze tickets par semaine, dix minutes chacun, soit deux heures et demie hebdomadaires. Ce chiffre est ce qui obtient l'autorisation d'y passer une demi-journée.
Le problème porte aussi une distinction utile : la solution de contournement, qui rétablit le service, et la solution définitive, qui supprime la cause. Écrire la première dans la base de connaissances accélère les incidents restants pendant qu'on travaille la seconde.
Le changement, et l'analyse d'impact
Le changement encadre une modification de production. Il porte trois informations que l'expérience rend indispensables.
Ce qui est touché, par les liens vers les éléments du parc.
Le plan de retour arrière. La question à laquelle il faut avoir répondu avant, et non pendant : comment revient-on si cela échoue, et en combien de temps.
La fenêtre, validée par ceux qui subiront l'interruption.
GLPI propose une analyse d'impact : à partir des relations entre éléments, elle affiche ce qui dépend de l'objet modifié. Sa qualité dépend entièrement de la qualité des relations saisies. Sur un parc où personne n'a lié les applications à leurs serveurs, elle n'affiche rien d'utile, et c'est un excellent indicateur de la maturité de l'inventaire.
Les projets
Un projet regroupe des tâches, des dates, des coûts et des intervenants. Il sert à ce qui dépasse le ticket : renouvellement d'un parc de postes, migration d'un serveur, ouverture d'un site.
Deux usages fonctionnent bien, et un troisième échoue.
Ce qui fonctionne : suivre un projet informatique avec ses tickets liés, et garder le budget consommé au même endroit que le parc concerné.
Ce qui échoue : remplacer un outil de gestion de projet par GLPI pour des projets qui n'ont rien d'informatique. L'outil n'est pas fait pour cela, et la tentative use tout le monde.
À retenir
L'incident rétablit, le problème cherche la cause, le changement la supprime sous contrôle. Ouvrez un problème au troisième incident de même nature dans le mois : le seuil arbitraire vaut mieux que la bonne intention. Un changement sans plan de retour arrière n'est pas prêt. Et l'analyse d'impact ne vaut que ce que valent vos relations d'inventaire.