Les trois façons d'échouer
Elles sont connues, et elles se reproduisent parce que chacune paraît raisonnable au départ.
Commencer par l'outil. On choisit un logiciel, on l'installe, on découvre ensuite qu'aucun processus n'est décidé. L'outil impose alors les siens, souvent inadaptés, et l'équipe le subit.
Tout vouloir d'un coup. CMDB complète, catalogue exhaustif, engagements de délai sur tout. Six mois de préparation, aucun bénéfice visible, et l'essoufflement avant la mise en service.
Copier une organisation plus grande. Les pratiques d'une DSI de cinq cents personnes appliquées à une équipe de trois produisent une bureaucratie que personne ne tient.
L'ordre qui fonctionne
Quatre étapes, chacune apportant un bénéfice avant la suivante. Ce point est le plus important : une étape qui n'apporte rien de visible fait perdre le soutien nécessaire à la suivante.
Un canal unique de demande. Avant tout le reste. Même un simple formulaire et une file : vous obtenez la visibilité, qui est la condition de toute décision ultérieure.
Les incidents et les demandes séparés, avec une poignée de catégories et un catalogue d'une page.
L'inventaire automatique, puis les relations des deux ou trois services vitaux seulement.
Les changements et les analyses de cause, une fois que le quotidien tient.
Ce qui suit vient plus tard, ou jamais selon la taille : gestion financière formalisée, capacité, continuité comme processus distinct.
Ce qu'il faut au départ, et c'est peu
Une personne qui porte le sujet, avec du temps reconnu. Pas un projet en plus du travail.
Le soutien de la direction, réduit à une chose précise : qu'elle passe elle aussi par le canal prévu. Une exception permanente pour l'encadrement défait la règle pour tout le monde.
Un périmètre restreint et assumé, annoncé comme tel. « On commence par les incidents, le reste viendra » se comprend mieux qu'un plan complet non tenu.
Les signaux qui disent que ça prend
À trois mois, quatre signes ne trompent pas.
Les gens déposent sans qu'on le leur rappelle. C'est le signal principal.
L'équipe consulte la base de connaissances au lieu de redemander.
Quelqu'un cherche dans l'historique avant de traiter un ticket : cela signifie que l'historique est devenu crédible.
Une décision a été prise à partir d'un chiffre issu de l'outil, plutôt que d'une impression.
Si rien de tout cela n'apparaît, le problème n'est pas la motivation des gens : c'est que l'outil ne leur rend pas encore service.
Ce qui fait durer
Le couplage au travail réel. Ce qui demande une tâche séparée meurt ; ce qui se fait pendant l'intervention survit.
Un rendez-vous trimestriel qui change une chose.
Une part d'automatique. Ce qui repose entièrement sur la discipline humaine se dégrade dès la première période chargée.
Un successeur. La question à poser dès le premier mois : si la personne qui porte cela part, qu'est-ce qui s'arrête ? Ce qui ne peut être repris par personne d'autre n'est pas une pratique, c'est une habitude individuelle.
Et l'outil, alors
Il vient après les décisions, et il compte moins qu'on ne le croit. Un outil correct sur des processus décidés rend un bon service ; un excellent outil sans processus produit une file de tickets mal qualifiés.
Pour une mise en oeuvre concrète de tout ce qui précède, le catalogue propose le cours GLPI : administrer son parc et son helpdesk, qui traite l'inventaire, le ticketing et l'exploitation dans un outil libre et largement répandu.
À retenir
Ne commencez pas par l'outil, ne visez pas l'exhaustivité, ne copiez pas une organisation plus grande. Canal unique d'abord, puis séparation des flux, puis inventaire et relations des services vitaux, puis changements. Le signal de réussite à trois mois est que les gens déposent sans qu'on le leur rappelle. Et prévoyez un successeur dès le premier mois.