Comment implémenter ITIL dans de petites et moyennes structures?

Le support informatique au sein des petites et moyennes structures se limitent souvent au rôle de pompier.

Noyés par les incidents et problématiques des utilisateurs, les services informatiques n’ont pas toujours les moyens de contribuer à la création de valeur au sein de l’entreprise.

Pourtant, on estime que près de 50% de la valeur ajoutée générée par les entreprises est du fait du système d’information (source Wikipédia).

Limiter, voir éliminer, les problématiques et incidents récurrents permet de se concentrer sur ce qui apporte de la valeur, à savoir l’alignement stratégique de l’informatique avec les besoins métiers, ou gouvernance des systèmes d’information.

Je vous propose avec cet article, un plan projet pour implémenter un centre de service ITIL.

Une première étape avant de vous lancer dans une démarche pleinement ITIL et au final vous concentrer sur ce qui aura de la valeur pour l’entreprise et pour vous.

ITIL est très procédurier et demande du reporting (et donc de la saisie), tout ce que détestent les informaticiens… et la plupart des personnes en règle générale.

Pourtant, une fois les processus maitrisés et les routines en place, les gains sont énormes pour le service informatique et les utilisateurs.

Le temps consacré à faire le pompier diminue, et parfois fortement, libérant ainsi du temps mis à profit de projets plus intéressants et beaucoup plus motivant pour l’équipe.

Mais avant de continuer, commençons par une rapide présentation d’ITIL.

Présentation d’ITIL

« ITIL (Information Technology Infrastructure Library pour « Bibliothèque pour l’infrastructure des technologies de l’information ») est un ensemble d’ouvrages recensant les bonnes pratiques du management du système d’information.

Rédigée à l’origine par des experts de l’Office public britannique du Commerce (OGC), la bibliothèque ITIL a fait intervenir à partir de sa version 3 des experts issus de plusieurs entreprises de services telles qu’Accenture, Ernst & Young, Hewlett-Packard, Deloitte, BearingPoint ou PriceWaterhouseCoopers.

C’est un référentiel très large qui aborde les sujets suivants :
• Comment organiser un système d’information ?
• Comment améliorer l’efficacité du système d’information ?
• Comment réduire les risques ?
• Comment augmenter la qualité des services informatiques ? »

(Source Wikipédia)

ITIL, pour quoi faire ?

« L’adoption des bonnes pratiques de l’ITIL par une entreprise permet d’assurer à ses clients (internes comme externes) un service répondant à des normes de qualité préétablies au niveau international.

ITIL est à la base de la norme BS15000 (première norme de Gestion de Services Informatiques formelle et internationale) un label de qualité proche des normes de l’ISO par exemple.

ITIL permet, grâce à une approche par processus clairement définie et contrôlée, d’améliorer la qualité des SI et de l’assistance aux utilisateurs en créant notamment la fonction (au sens « département de l’entreprise ») de Centre de services ou « Service Desk » (extension du « help desk ») qui centralise et administre l’ensemble de la gestion des systèmes d’informations.

ITIL est finalement une sorte de “règlement intérieur” du département informatique des entreprises qui l’adoptent.

Les bénéfices pour l’entreprise sont une meilleure traçabilité de l’ensemble des actions du département informatique.

Ce suivi amélioré permet d’optimiser en permanence les processus des services pour atteindre un niveau de qualité maximum de satisfaction des clients. »

(Source Wikipédia)

Vous partez de zéro, inutile de mettre la pression sur le service informatique !

Rien n’est en place ? Alors prenez votre temps.

Ce n’est pas compliqué, loin de là, mais ça demande beaucoup de rigueur de la part du service informatique comme de la part des utilisateurs.
Toute la difficulté de mise en place est liée à ceci.

Ce que je décris ici, va prendre du temps à roder, comptez plusieurs mois avant de maitriser ces étapes.

Une fois maitrisées, il sera nécessaire de former tous les membres du service informatique (DSI) et se conformer aux exigences d’ITIL pour exceller.

Pour l’instant, inutile de mettre la pression sur la DSI ; pas de SLA dans cette phase !

Le SLA (service level agrement) est le niveau de service que la DSI négociera avec les utilisateurs (ou plutôt les directions métiers).
Exemple : la DSI s’engage à résoudre un incident de niveau 1 dans les 4h.
Les niveaux sont à définir en fonction de la complexité des incidents.

Lorsqu’un SLA s’imposera (c’est un peu le but d’ITIL : un contrat de service entre service informatique et utilisateurs), il faudra négocier les ressources (matérielle, humaine, financière) pour pouvoir le respecter.

1ère étape, la mise en place d’une CMDB

Pour faire simple, une CMDB (Configuration Management DataBase) est une base de données de vos configurations.
Chaque machine et équipement informatique ainsi que leurs configurations y sont répertoriés.

Par exemple, pour un PC vous indiquerez : les numéros de série/produit et date d’acquisition (pour le suivi de contrat), la configuration matérielle, les logiciels installés et leurs versions, qui utilise le matériel (l’origine d’un incident peut aussi être placé entre la chaise et le clavier), sa localisation, etc.

Par la suite il faudra être méthodique et rigoureux : toute modification sur un équipement ou logiciel devra être consigné dans la CMDB.

Dans le cas contraire, la CMDB perdra sa raison d’être et la démarche perdra de sa puissance.

En règle général, un logiciel est utilisé.

Alimenter la CMDB est un travail long et très fastidieux.
Prenez le temps de choisir votre logiciel, en cas de changement, la reprise de données (de l’ancien logiciel vers le nouveau) risque d’être compliqué.

Pour ma part j’ai toujours travaillé sur du spécifique redéveloppé en interne.

Certains utilisent des ERP open source et détournent leur fonctionnement (paramétrage et développement nécessaire).

En gratuit, GLPI est une solution : intègre une CMDB, un service desk ITIL (dont fiches d’incident), un outil d’analyse, gestion de contrats et licences, etc..
L’outil d’analyse (concerne la 3ème partie) n’est pas extraordinaire, mais c’est un très bon début.

Une chose est sure, les membres du service informatique doivent impérativement maitriser le logiciel.

Pourquoi une CMDB ?

Il y a deux avantages majeurs à la mise en place d’une CMDB.

1. Elle vous aidera à homogénéiser votre parc.
Plus un parc est hétérogène et plus les sources de problèmes sont nombreuses.
Vous pourrez ainsi voir sur quel type de machine intervenir en priorité, les ordres de renouvellement, mettre à jour et au même niveau vos versions logicielles, etc.

2. En recoupant avec les analyses (cf. 3ème étape), il sera possible de profiler incidents et problèmes.
Par exemple, l’incident A intervient presque exclusivement sur les logiciels B en version X.
Il sera facile d’en conclure qu’une mise à jour du logiciel B s’impose ou qu’un contact avec l’éditeur est nécessaire pour fixer le problème.

2ème étape, mise en place d’un guichet unique

Le guichet unique est au cœur d’ITIL (avec la CMDB).

Un seul numéro de téléphone, une seule adresse email et une seule url Intranet pour contacter le support informatique.

Au fil du temps, diminuer les demandes directes (les utilisateurs qui se présentent au service informatique ou qui accrochent un membre de l’équipe au détour d’un couloir) pour privilégier les canaux de communication précédemment cités.

Le service informatique se déplacera en cas de nécessité.

Pourquoi un guichet unique?

1. Consigner les demandes: celles-ci devront toutes être consignées dans le cadre des analyses (cf. 3ème partie).
Si, au détour d’un couloir un membre de l’équipe informatique est interpelé pour intervenir sur un incident et que ceci se reproduit plusieurs fois… il ne consignera pas les incidents, tout simplement.

2. Mettre en place un système d’escalade.
Le guichet unique devient un centre de tri.
Au premier niveau, il peut résoudre les problèmes par téléphone et/ou prise en main à distance.

Au niveau 2, par exemple, il peut faire le choix d’envoyer quelqu’un sur place.
Cette personne ne sera pas sans cesse interrompue (par d’autres appels au support) pendant sont intervention. Il gagnera donc du temps, l’utilisateur aussi.

Suivant la taille du service, il n’est pas toujours possible de procéder ainsi par manque de ressources. Mais à partir de deux personnes c’est possible.

Afin de ne pas démotiver les membres de l’équipe informatique, des rotations sont à mettre en place. Toujours le même au téléphone est à éviter.

3. Eliminer la dissolution et la multiplication des demandes.
Certains utilisateurs n’hésitent pas à appeler plusieurs personnes en cas de problème ou pour une quelconque demande.
Et, lorsqu’il y a le feu, le service informatique peine souvent à communiquer correctement en son sein.
1 demandeur = 1 unique point de demande.

3ème étape, les fiches d’incident et de résolution

Telle une pieuvre, ITIL à plusieurs cœurs.
On dira donc, là aussi, que les fiches d’incident et de résolution sont au cœur du système.

Pour que la démarche fonctionne, il faut tout consigner… je vous avais prévenu, c’est très procédurier.
Le service informatique doit pleinement jouer le jeu.

1. Préparez vos fiches d’incidents.
Pour chaque appel, vous devez remplir une fiche d’incident : nom de l’appelant, service, tel, date, heure d’appel, type d’incident (matériel, logiciel), nature de l’incident (description), etc.

Mieux vaux décomposer la nature des incidents : incident « macro Excel » plutôt que incident « Excel ».
Ceci pour faciliter les analyses.

2. Attachez une fiche résolution à la fiche incident (c’est automatique dans les logiciels).
Il s’agit là de décrire comment l’incident a été solutionné.

Ces fiches vous permettront, pour de futurs appels similaires, de mettre en place des procédures de résolution d’incident (avec des arbre de décision par ex. 
Si j’ai tel problème, alors je fais ça, sinon je fait autre chose et ainsi de suite).

Les analyses

Avant de commencer vos analyses, attendez de 1 à 3 mois (suivant la volumétrie d’appel au support).
Le temps d’alimenter votre base d’incident et d’améliorer vos fiches.

Une fois le délai passé :
Répertoriez les incidents et créez des groupes : problème matériel A, problème logiciel métier X, etc.

Lors des analyses, vous vous rendrez compte que vous avez souvent des appels concernant le logiciel métier X.
Dans le jargon ITIL, ces incidents deviennent des problèmes.
Une action doit être mené sur le logiciel métier X pour éliminer les appels.

Exemple : formation du personnel (si c’est un problème d’utilisation), mise à jour du logiciel, appel du support éditeur pour fixer le problème, etc.

N’oubliez pas de recouper ces analyses avec les données de la CMDB comme expliqué dans la 1ère étape.

Faites régulièrement des analyses : une fois par mois par ex. (fonction du nombre d’appels).

Le but est :
- D’améliorer vos processus pour répondre aux appels, en instaurant des procédures
 (et diminuer les temps d’intervention).
- D’éliminer les sources de problème et libérer du temps sur la partie « pompier ».

Même si je vous ai conseillé de ne pas mettre en place « publiquement » de SLA pour l’instant, simulez en un au sein du service informatique.
Par exemple : prendre en compte un appel dans l’heure, résoudre un incident de niveau 1 dans les 2h, etc.

Ceci vous permettra, lorsque vous négocierez un SLA avec les directions métiers, d’avoir des éléments pour fixer le niveau de service.

En conclusion

Les puristes penseront que la démarche n’est pas « full ITIL compliant » et c’est le cas.

Mais comme je l’indiquais en introduction, plusieurs mois seront nécessaires pour la mise en place des quelques éléments cités.

Et ce n’est que parce que la pratique sur ces éléments arrivera à maturité que l’implémentation d’ITIL fonctionnera.

Ensuite vous pourrez entrer dans une démarche ITIL à la lettre et en toute sérénité pour obtenir les bénéfices présentés en introduction.