Traduction plus ou moins heureuse de "Management" en Anglais.
Bien souvent, au quotidien on ne parle plus de "gestion des incidents" mais du processus "Incidents". On cesse de parler de gestion des changements pour parler des changements tout court...
C'est à la fois une mauvaise habitude et un symptôme de l'idée qu'on se fait d'ITIL et des processus dans trop de cas.
Quelle idée est-ce que j'essaie d'introduire ici ?
Les processus ITIL sont des processus "administratifs" et il faut l'assumer.
Attention : en France, c'est un mot connoté de façon péjorative... Il faut comprendre "qui servent à administrer, piloter, conduire...".
En effet, dans les DSI, ce qui manque ce n'est pas le savoir faire technique ou l'expérience. Des "techos", des "héros", des "barbus de la prod", ça on en a...
Les processus ITIL n'ont pas pour objet de remplacer ce savoir-faire.
C'est à la fois leur force et pour certains leur faiblesse...
- C'est une force car cela permet à ITIL de s'implémenter sur une organisation existante.
- C'est une faiblesse seulement si on attend d'ITIL qu'il résolve des problème dans le management RH ou qu'il comble un manque de savoir-faire opérationnel.
Tel que je vous vois vous voulez un exemple concret ?
La Gestion des Incidents met en place les mécanismes permettant de "s'assurer" que les incidents sont résolus.
Il ne dit pas "comment" résoudre un incident (passer une commande de relance du serveur, remplacer le matériel, livrer un patch, revenir à la version n-1...).
C'est la même chose pour chaque autre processus.
Y compris la Gestion des Changements.
Celle-ci a pour vocation à "s'assurer" que les changements arrivent à bon port (certains traduisent par le passage d'un état stable à un nouvel état stable).
Les DSI ressentent souvent le besoin de mieux gérer les déploiements en production (parfois appelés en interne mises en production).
Souvent cela fait suite à une accélération des modifications apportées par les projets, qui créent de plus en plus d'interruptions de service.
Et là, les choses s'enchaînent...
On se dit, "tient on va se faire un coup d'ITIL...":
- un déploiement c'est une mise en production, or une mise en production modifie "quelque chose".
- donc si ça modifie c'est un changement...
- donc la réponse c'est la gestion des changements...
Immanquablement on commencera à enregistrer toute modification en production par "un changement".
Au début cela semble cohérent et un premier pas en avant.
Jusque là, aucune modification n'était tracée... on se dit que c'est mieux que rien...
Sauf que...ce job c'était celui d'une procédure de déploiement, qui devrait exister, même sans ITIL...
Pas celui de la GESTION des changements...
A ce stade, j'espère que je ne vous ai pas perdu cher lecteur...
Mon propos c'est de dire que l'objectif de la Gestion des Changements, ce n'est pas de savoir qu'on a installé un serveur lame ce matin à 10H05.
Ça se situe sur un autre plan, il s'agit en premier lieu de :
- savoir qui le demande
- s'assurer qu'on a évalué les gains on peut en attendre (résoudre un incident, accueillir une nouvelle application, améliorer les performances...)
- s'assurer qu'on a évalué les risques et le résultat
- s'assurer qu'on a évalué le coût, les ressources nécessaires, les possibilités de planning
- et sur la base de tout ça... autoriser -ou pas- le changement de cette lame.
Autrement dit une nouvelle fois, "s'assurer que" le job sera fait comme convenu.
Et alors la Gestion des Mises en production ?
Rendez-vous dans les prochains billets : Gestion des Changements, Gestion des Mises en production et des déploiements.
