Support Technique on Shigaepouyen

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

Mon, 13 Apr 2009 10:24:10 +0000

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 :P )

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.”

N'oubliez pas le support ! (1ère partie)

Mon, 06 Apr 2009 09:33:45 +0000

En ne préparant pas le support* d’un nouveau service** durant la phase projet, il y a de fortes chances que les équipes de production*** existantes ne soient ni compétentes ni préparées pour assurer le support au moment du lancement !

Et c’est pour ça que des développeurs se retrouvent à supporter une application ad vitam eternam après la fin du projet… alors que tout le monde préfèrerait déléguer cette tâche à une équipe dédiée au support, afin que les développeurs puissent faire ce qu’ils font de mieux : développer :P

La question à se poser est donc la suivante : “que faut-il faire (notamment durant le projet) pour être en mesure de supporter tel ou tel nouveau service quand il sera mis en production ?”

Je vous propose 9 pistes pour ne rien oublier ! Cette semaine, première partie de l’article avec les 4 premiers points :

l’audit et la sécurité de l’information
la planification des ressources
le modèle de support
la récupération de désastre

Audit IT et sécurité de l’information

Il s’agit essentiellement de documenter:

Les régulations éventuelles auxquelles sont soumises le service (Bâle 2 pour les banques, Sarbanes-Oxley pour les boites côtés à NYSE, …)
Le service (sa description, sa criticité pour l’entreprise), le système (l’architecture, les contrats de maintenance), les procédures (par exemple pour la gestion des changements en production)
Les personnes responsables (propriétaire du service, responsables de la production et du support, les signataires du SLA)
Les mesures de sécurité (DRP, continuité, …) et de gestion des accès (niveaux de permissions, approbation des demandes de droit, etc.)
Les audits à prévoir (fréquence, destinataires, etc.)

Comme bien souvent avec les audit, il s’agit de s’assurer que cette documentation existe et qu’elle représente la réalité.

Planification des ressources

Il s’agit d’anticiper :

Les besoins en ressources (matérielles et humaines, en fonction du type de contrat, du profil requis)
Les coûts engendrés (par ces différentes ressources lors des différentes phases avant et après le lancement)

L’objectif est de pouvoir budgéter ces sommes et les faire payer par le client (il faut donc aussi identifier le sponsor côté client).

Modèle de support

Une fois les ressources en place, on pourrait croire qu’il suffit de leur donner des choses à faire pour que tout se passe bien…

En réalité, il faut expliquer à chacun d’où viennent les demandes, ce qu’elles concernent (il n’y a rien de pire que de recevoir une demande dont on ne comprend pas de quoi il s’agit !), ce qui est attendu et à qui on peut faire appel quand on rencontre un problème qu’on ne sait pas résoudre (escalade fonctionnelle).

Ill s’agit donc d’organiser :

Les équipes et leurs rôles (par exemple en structurant les équipes en niveau 1-2-3)
Les types de demandes : les incidents, les demandes d’accès et les demandes d’amélioration ne suivent pas forcément le même parcours ; il faut l’expliciter pour que le niveau 1 oriente correctement les demandes
Les flux de traitement des demandes
Les responsabilités de chaque équipe (par exemple : qui doit rappeler l’utilisateur pour lui confirmer la résolution ? qui doit contacter le fournisseur en cas de problème de maintenance ?)

Sans ça, les demandes arriveront au mauvais endroit au mauvais moment, et les incidents ne seront pas résolus en temps et en heures.

Récupération de désastre

Scénario catastrophe : un avion s’écrase sur le Data Center. En combien de temps est-on capable de remettre en oeuvre le service auprès des utilisateurs ?

Les DRP (Disaster Recovery Plan - Plan de Récupération de Désastre) détaille les étapes à suivre pour remonter les serveurs, le réseau et les applications auprès des utilisateurs à partir de la sauvegarde la plus récente.

Pour arriver à ce résultat, il faut déterminer :

Le risque (scénarios potentiels/risques, impacts business, personnes clés, etc.)
une stratégie de récupération (DR site, Load Balancing, hot standby, etc.) et la valider avec le client
Le coût de la solution choisie, lancer les investissements
Les éléments à intégrer, afin de pouvoir rédiger le plan
Les modalités pour tester le plan de récupération à intervalles réguliers

Notons néanmoins que ce travail sera fait à l’échelle du Data Center, et pas dans le cadre d’un projet pour une seule application. Mais les besoins clients seront revus à chaque projet, et le SLA mis à jour en conséquence.

Fin de la première partie !

La semaine prochaine, la suite de cet article avec les 5 derniers points :

Les SLA/OLA
Les outils
La formation
La gestion des changements en production
La gestion de la connaissance

Glossaire simplifié

* support : le “support informatique” regroupe les équipes et les procédures visant à résoudre les incidents, et qui permettent aux utilisateurs d’obtenir de l’assistance.

** service : dans le contexte ITIL, un service est une fonctionnalité délivrée aux utilisateurs (messagerie, gestion commerciale, etc.) ; d’où l’expression “niveau de service”. Si vous n’êtes pas familier avec ITIL, vous pouvez remplacer le mot “service” par “application” - ça aura du sens dans la plupart des phrases.

*** production : la “production informatique” regroupe toutes les équipes et tous les matériels qui font que les services sont délivrés aux utilisateurs. Ce sont eux qui “font tourner le bouzin” chaque jour.

**** fournisseur de service : le “fournisseur de service” regroupe toutes les équipes informatiques engagées dans la délivrance, le support et la gestion du service pour le client. C’est en quelque sorte la DSI vue d’un point de vue client-fournisseur.