ITIL : trois écueils à éviter

Avec un peu de recul face à de nombreuses réalisations Itiliennes, on peut constater trois types d’écueils à éviter. Le premier est le « tout est procédure » : on se contente de rédiger des procédures en s’inspirant des manuels de l’Itil et en se faisant assister par des théoriciens de l’Itil qui sont nombreux sur le marché du conseil. On aboutit alors à de belles procédures mais l’appropriation par les opérationnels est aléatoire, variable et potentiellement entachée de compromis fâcheux d’organisation. Si l’on évaluait cette pratique avec un « modèle de maturité », le simple fait d’écrire des procédures ne donne qu’une note de 2/5… l’important c’est la vie quotidienne, c’est le passage à l’acte et c’est cela qu’il faut faire évoluer et auditer par un expert de la production qui ne se fera pas berner par des écrits ‘lettres mortes’.

Le deuxième écueil consiste à trop insister sur un process en particulier, à en attendre la perfection avant de passer au process suivant. On risque alors de s’enferrer dans des mises en œuvre interminables. On veut une gestion de configuration trop détaillée, on veut couvrir un nombre trop important de workflows dans un outil de help-desk, les exemples fourmillent. Le caractère –ou le niveau de souffrance- du responsable de la production se lit aux choix faits. Inutile de dire que les SSII qui vendent un outil sur un process donné pourraient abonder dans ce sens. Il faut rappeler ici que l’intérêt de l’Itil est la mise en œuvre combinée de quelques process pratiquement en même temps (au moins configuration/incidents/changements en ‘service support’) pour obtenir un effet coordonné et une mise sous contrôle qui évite les échappatoires.

Enfin, le troisième piège que l’on constate consiste à évacuer les responsabilités. C’est le plus insidieux. Or l’Itil définit certaines responsabilités qui doivent être reconnues, prises en compte et assumée dans l’organisation. Un exemple pédagogique est souvent fourni par la gestion des changements. Une entité (‘change advisory board’) est chargée de la validation et peut refuser une demande de changement. Dans certaines entreprises françaises, le simple fait qu’un changement doive se demander et n’est donc pas acquis d’office est une révolution culturelle ! Il faut faire assumer dans l’entreprise des responsabilités Itiliennes et si possible par ceux qui y sont prédisposés par leurs missions antérieures. Ainsi une équipe système aura la responsabilité du traitement des problèmes du système ; une équipe de pilotage du traitement des incidents ; un responsable d’application des demandes des changements sur son application, etc.

En conclusion, on peut dire que responsabilité, cohérence et esprit pratique sont les mots d’ordre d’une Itilisation réussie.