La première décision structurante
Si vous ne retenez qu'une chose de ce chapitre : une panne et une commande ne se traitent pas dans la même file.
Une panne veut dire que quelqu'un ne peut plus travailler. Elle se mesure en minutes, on accepte un contournement, et l'objectif est le rétablissement.
Une commande, un nouvel accès, un poste pour un arrivant, une boîte partagée, se mesure en jours, suit une procédure, demande parfois une autorisation, et l'objectif est la conformité à ce qui a été convenu.
Mélangées, elles produisent trois effets, tous mauvais : un délai moyen qui ne décrit rien, une commande urgente qui passe devant une panne, et une équipe incapable de dire où va son temps.
Le catalogue de services, en une page
Un catalogue de services est la liste de ce que l'informatique s'engage à fournir, avec pour chaque entrée ce qu'il faut pour la demander et le délai annoncé.
C'est la chose la plus rentable à produire d'un projet ITSM, et elle tient sur une page :
| Demande | Informations à fournir | Délai annoncé |
|---|---|---|
| Accès à une application | application, personne, motif, validation du responsable | 2 jours ouvrés |
| Poste pour un arrivant | date d'arrivée, profil de poste, service | 5 jours ouvrés |
| Boîte partagée | nom, membres, responsable | 1 jour ouvré |
Trois bénéfices immédiats. L'utilisateur sait quoi fournir, donc l'aller-retour disparaît. Le délai est connu, donc la relance à deux heures disparaît. Et ce qui n'est pas au catalogue devient une discussion explicite, plutôt qu'une demande qui traîne sans que personne ose dire non.
Les engagements de délai, mesurés d'abord
Un engagement de délai n'a de valeur que s'il est tenu. Trois règles.
Mesurer avant d'annoncer. Trois mois d'observation donnent vos délais réels ; les engagements se fixent à partir de là, légèrement plus exigeants.
Deux niveaux suffisent au début : ce qui bloque l'activité, et le reste.
Le délai de première réponse compte plus que le délai de résolution. C'est lui que l'utilisateur ressent. Une panne prise en charge en dix minutes et résolue en quatre heures est mieux vécue qu'une panne silencieuse résolue en deux heures.
Les demandes qui n'en sont pas
Deux cas méritent un traitement particulier, sans quoi ils saturent la file.
Les questions. « Comment fait-on pour... ». Elles se répondent une fois, et leur réponse a vocation à devenir un article consultable. Une question qui revient dix fois est un manque de documentation, pas dix demandes.
Les demandes qui relèvent d'une décision, achat notable, exception à une règle. Elles ne se traitent pas dans la file courante mais par la validation, avec une trace de qui a autorisé.
Ce que vous n'avez pas besoin de faire
Le référentiel décrit des dizaines de pratiques. En PME, quatre suffisent : incidents, demandes, changements, et une base de connaissances.
Ce qui peut attendre, sans dommage : la gestion financière formalisée, la gestion de la capacité, la gestion des niveaux de service au sens contractuel complet, la gestion de la continuité comme processus distinct.
Le dire explicitement évite une culpabilité inutile. Une équipe de trois personnes qui traite proprement quatre pratiques rend un meilleur service qu'une équipe qui en documente quinze et n'en applique aucune.
À retenir
Deux files distinctes : rétablir, et fournir. Un catalogue d'une page qui dit quoi fournir et sous quel délai. Des engagements fondés sur une mesure, avec la première réponse comme repère. Les questions deviennent des articles. Et quatre pratiques suffisent en PME, le reste peut attendre.