N’oubliez pas le support ! (2ème partie)

Si le chef de projet s’attache uniquement à délivrer le produit à temps, sans préparer ce qui se passera après, il y a de fortes chances que tout aille bien… jusqu’au premier problème !

Et à ce moment-là, on se rend compte que personne ne sait quoi faire, à part rappeler les personnes qui avaient travaillé sur le projet en espérant qu’elles soient encore disponibles et compétentes…

Le but de cet article est de donner 9 pistes pour aider les chefs de projet à préparer cet « après-projet ».

Après avoir vu l’audit, la planification des ressources, le modèle de support et la récupération de désastre dans la première partie publiée de la semaine dernière, passons en revue cette semaine les 5 derniers points :

• les SLA/OLA
• les outils
• la formation
• la gestion des changements en production
• la gestion de la connaissance

SLA / OLA

Les notions de « service rendu » et de « besoin client » sont au coeur de la démarche ITIL.

Le SLA (Service Level Agreement = Accord de Niveau de Service) décrit :

• les parties prenantes dans la délivrance du service (client qui paie et qui signera le document, utilisateurs qui utiliseront le service, le fournisseur de service**** responsable de la gestion du service, et toutes les personnes dont la responsabilité est engagée vis à vis du client)
• le niveau de service que les équipes informatiques s’engagent à délivrer au client (disponibilité, gestion de la capacité et de la continuité, performances, …)
• la façon dont les utilisateurs peuvent contacter les équipes techniques (procédure et formalisme des demandes, horaires de contact, délais de résolution en fonction des priorités et du type de demande)
• la relation entre le client et le fournisseur de service (relance des appels, escalade hiérarchique, revue du document)

En définissant clairement les relations entre le client et le fournisseur de service (ce que chacun peut attendre de l’autre), le SLA protège autant le fournisseur de service qu’il garantit des performances au client.

Il s’agit donc de capturer :

• les besoins et attente du client en terme de niveau de service (ce qui l’oblige à réfléchir à ce qu’il sera prêt à payer pour l’atteindre)
• les efforts à déployer pour atteindre ce niveau de service, et les garanties à inclure dans le SLA pour qu’il soit signé avant le lancement du service.

Dans tous les cas, cette démarche s’appuie sur le Catalogue des Services et sur des OLA (Operational Level Agreement=Accord de Niveau Opérationnel) qui permettent au fournisseur de service de maîtriser la façon dont le service est délivré et supporté. C’est parce qu’il gère et contrôle ses procédures internes que le fournisseur de service peut s’engager sur un niveau de service vis à vis du client.

Les outils

Pour chaque technicien impliqué dans le support du service, il s’agit ici d’installer et configurer :

• un poste de travail avec les outils standards
• les outils nécessaires au métier du support (ACD, gestion des tickets d’appel, …)
• les outils spécifiques au service supporté (par exemple la console Active Directory, un logiciel de débuggage, prise de contrôle à distance, émulateur de terminal, etc.)

Ce coût devra être pris en compte dans la planification budgétaire. Il faut aussi penser à la place nécessaire pour accueillir les techniciens (ce n’est pas forcément évident de mettre tout le monde dans la même pièce si on est déjà à l’étroit !).

La formation

Quand vous avez une nouvelle recrue, il faut assurer :

• la formation de base (culture d’entreprise, outils et process du support)
• les formations spécifiques (techniques, fonctionnelles ou autre)

Suivant votre entreprise, vous disposerez de différentes méthodes pour y parvenir (binôme, formation en classe, stage sur le terrain, documentation projet, manuels utilisateurs, etc.).

Les contraintes habituelles sont :

• l’argent (par exemple, les formations spécifiques faites en externe sont coûteuses)
• le temps (en règle générale la formation est chronophage)
• la langue (car les formations et documents ne sont pas forcément disponibles en français)
• la localisation des équipes (il faut parfois dupliquer la formation, ou choisir un modèle du type « train-the-trainer »)

Il s’agit donc de d’optimiser la formation en fonction des contraintes dont vous disposez.

Suivant le contexte, la formation de base au métier du support prend de 2 à 6 mois, et la formation « avancée » prend jusqu’à 2 ans. Il faut donc prévoir ces délais pour entamer la démarche à temps ; d’autant que pour les nouveaux services, on ne maîtrise pas forcément quel sera le niveau de connaissance requis pour supporter l’application.

Gestion de la configuration, des changements, de la mise en production, de développement, de la qualité, etc.

Voici la règle d’or du support utilisateur : quelle que soit la taille et la qualité de votre équipe support, ils ne seront jamais assez nombreux pour répondre à toutes les demandes. Comme les gaz, les appels des utilisateurs prennent toute la place disponible.

Le corollaire : si vous recevez plus de demandes que vous ne pouvez en traiter, augmenter la taille de votre équipe ne résoudra pas le problème (sur le long terme).

Il faut attaquer le problème par l’autre bout : faire baisser le nombre d’appel. Or plus il y a de bugs, ou plus les changements en production se font n’importe comment et sans prévenir, plus le nombre d’appels augmente (nouveaux bugs inconnus, interruptions de service non planifiées, etc.)

Il est donc indispensable de faire respecter :

• un planning de développement
• une approche qualité avec des tests (unitaire, intégration, régression, utilisateurs, etc.)
• un process de gestion des changements, pour maîtriser les mises en production
• une gestion de la configuration qui vous permette de savoir à chaque instant quel est l’état de l’infrastructure de votre SI (généralement, ça aide à résoudre un incident de savoir ce qui a été modifié juste avant que ça se produise…)
• une gestion des problèmes pour identifier les incidents récurrents et en traiter les raisons profondes (au lieu  de subir les appels des utilisateurs et résoudre l’incident à chaque fois qu’il se produit), d’autant que c’est ça la réelle assistance qu’attendent les utilisateurs – l’approche financière est souvent un bon levier pour ça, car les équipes techniques peuvent facilement tomber dans la facilité et ne pas traiter les causes profondes d’un incident sous le prétexte qu’il existe un contournement.

Gestion de la connaissance

En règle générale, les gens qui ont la connaissance ne seront jamais là quand vous en aurez vraiment besoin.

Quelle que soit la formation mise en oeuvre, vous aurez donc besoin de définir :

• un outil intégré au suivi des tickets d’appel, pour stocker et trouver la connaissance
• un process, pour récupérer, valider, formaliser et tenir à jour la connaissance
• un périmètre, pour inclure la connaissance pertinente, et exclure les éléments inutiles
• une audience, pour restreindre l’accès aux données techniques sensibles, et si possible permettre aux utilisateurs de résoudre eux-même leurs problèmes

En imaginant que vous avez déjà tout ça, il ne vous reste plus qu’à remplir la base de connaissance ! Et ça prendra toujours plus de temps que vous n’en avez, et de toute façon vous ne trouverez pas l’information utile quand vous en avez vraiment besoin (cynisme inside 😛 )

En conclusion

Certaines de ces pistes permettront d’établir des standards, qui pourront être réutilisés pour d’autres situations, alors que d’autres seront spécifiques au projet concerné. Le plus difficile sera parfois d’avoir les bons interlocuteurs pour avancer sur ces différents sujets (ce qui peut être le cas si l’organisation n’a pas encore atteint un certain niveau de maturité…).

Mais si vous travaillez dans le support informatique, n’oubliez jamais la plus importante devise Shadok : « S’il n’y a pas de solution, c’est qu’il n’y a pas de problème. »