La gestion des niveaux de service

1. La gestion des niveaux de service

1.1. Rappels sur la discipline et le CRM (Customer Relationship Management)

Si ITIL® présente le centre de services (Service Desk) comme le point d’entrée unique de l’organisation des TI, en réalité, c’est le point d’entrée unique pour les utilisateurs. Il existe un second point d’entrée pour les clients. La notion de client recouvre les notions pratiques suivantes :

  • les directions des utilisateurs

  • les sponsors (ou commanditaires dans le sens de celui qui passe la commande)

  • les fonctions métiers

Ces relations ne sont pas gérées par le centre de services car elles ne demandent pas les mêmes compétences et ne travaillent pas sur la même échelle de temps (un incident traité par le centre de services est géré différemment de la négociation des SLA, par exemple).

Ces relations sont habituellement gérées par une structure appelée CRM (Customer Relationship Management) ou gestion de la relation client. Cette structure n’est pas formalisée dans ITIL® mais la gestion des niveaux de service décrit l’une des activités de cette structure.

Les personnes intervenant dans le cadre de cette structure seront appelées Account Manager, gestionnaire de compte ou commercial selon l’organisation.

La gestion des niveaux de service, pour un fonctionnement optimum, devrait être géré par une structure neutre et indépendante à la fois de l’organisation des TI et des organisations métiers. Elle ne devrait donc pas être partie de l’organisation des TI comme le préconise ITIL® mais devrait plutôt être :

  • à la direction qualité ou

  • dans une structure méthode, externe à l’organisation des TI

1.2. La démarche de mise en place des SLA (conventions de niveau de service



1.2.1. Etape 1 : expliciter les SLR (organisations métiers)

Chaque organisation métier doit reprendre les services fournis par l’organisation des TI et utilisés pour supporter les processus métiers et établir, pour chacun d’entre eux, les exigences en termes de :

  • support : quels sont les besoins de réactivité de l’organisation des TI en cas d’incident sur le service utilisé (interruption ou dégradation) ?

  • capacité : quels sont les besoins en capacité actuels et futurs du service utilisé ?

  • disponibilité : quand le service utilisé doit-il être disponible et combien de temps peut-on supporter une interruption ou une dégradation du service utilisé

  • sécurité : quels sont les besoins en sécurité (confidentialité, intégrité et accessibilité des données et des traitements) du service utilisé ?

  • continuité de service : qu’est-ce qui doit être maintenu en cas de sinistre majeur sur les infrastructures des TI et dans quelles conditions minimales acceptables pour la survie de l’entreprise ?

Ces exigences doivent ensuite être rassemblées et transmises à une structure neutre (appelée Quelqu’un sur le schéma).

1.2.2. Etape 2 : traduire les SLR en termes de niveaux de service (« Quelqu’un »)

Une structure neutre doit ensuite transposer les exigences métiers (exprimées en termes métiers) en exigences techniques, donc en niveaux de service.

Ces exigences techniques seront transmises ensuite à l’organisation des TI afin de déterminer si celle-ci peut ou non satisfaire les exigences et les niveaux de service demandés.

1.2.3. Etape 3 : confronter avec les possibilités techniques et budgétaires et établir ou modifier les OLA et UC (organisation des TI)

L’organisation des TI doit ensuite :

  • confronter ces exigences techniques avec les possibilités techniques et budgétaires de l’organisation des TI

  • confronter éventuellement avec les OLA et UC en place en interne (s’ils existent)

  • établir ou modifier les OLA et UC et faire des contre-propositions si les exigences ne peuvent pas être remplies par l’organisation des TI

  • établir les coûts prévisionnels associés au niveau de service demandé

Ces contre-propositions et ces devis sont ensuite retransférées à la structure neutre (« Quelqu’un ») pour négociation avec les organisations métiers.

1.2.4. Etape 4 : revoir les SLR et négocier les SLA (« Quelqu’un »)

La structure neutre anime les échanges et les rencontres entre les clients (organisations métiers) et l’organisation des TI pour :

  • revoir les SLR et négocier les SLA : cela permet de mettre en cohérence les niveaux de service exigés (client) et possibles (fournisseur de services). Le coût des mises à jour des niveaux de service internes est aussi disponible. Le résultat peut montrer une réduction du niveau d’exigences des clients et/ou une mise à jour des niveaux de service offert par le fournisseur de services. Ce dernier cas n’étant possible qu’après accord sur les coûts induits.

En aucun cas les SLR ne peuvent être modifiés : peu importent si les exigences valorisées dans les SLA sont moins grandes que celles qui sont décrites dans les SLR. De toute manière il n'appartiennent pas au fournisseur de services mais bien aux clients. La démarche d’amélioration continue fera, qu’un jour, les SLA seront revus et cette revue permettra peut-être au fournisseur de services de mieux satisfaire les exigences du métier.

1.2.5. Etape 5 : Mettre en place les SLA, OLA et UC (organisation des TI)

Une fois les SLA acceptés par toutes les parties, l’organisation des TI peut ensuite implanter les SLA et démarrer la surveillance de ceux-ci (suivi des performances, dépassements de seuil, etc.). Éventuellement, le fournisseur de services reformalisera les OLA et les UC qui le lie à ses fournisseurs de service internes et externes.

1.3. La phase de négociation : repérer les incohérences, les « trous » et la non-application des SLA

Cette phase est cruciale dans le processus car elle permet de traiter tous les risques pouvant causer un dysfonctionnement du processus. Les principaux risques sont les suivants :

1.3.1. Les risques de non-conformité

Ils concernent deux aspects :

  • SLR et SLA : les SLA ne répondent pas (écarts très importants) aux exigences métiers. Généralement dû à une organisation des TI qui impose son point de vue.

  • SLA et OLA/UC : les OLA et UC ne permettront pas au fournisseur de services d’assure les niveaux de service convenus dans les SLA. En général parce que l’organisation des TI s’est engagée sur des niveaux de service sans avoir vérifier sa capacité à répondre d’un point de vue opérationnel (à l’interne).

1.3.2. Les risques de non-exhaustivité

Ils concernent deux aspects :

  • les SLA ne couvrent pas tous les services ou toutes les clientèles : certains services ou utilisateurs ne sont alors pas couverts par un SLA. En cas de dysfonctionnement ou de demande sur ce service, personne n’est capable de décider ou d’agir convenablement.

  • les OLA et UC ne couvrent pas tous les SLA : cela entraîne une instabilité dans le système (un niveau de service convenu dans un SLA n’est pas atteint mais tous les niveaux de service des OLA et UC sont atteints) et des difficultés à situer la composante d’infrastructure à incriminer et à agir pour rétablir le niveau de service.

1.3.3. Les risques d’irréalisme dans les niveaux de service convenus dans les SLA

Un objectif de niveau de service doit être « S.M.A.R.T. » à savoir :

  • Spécifique

  • Mesurable

  • Atteignable ou Applicable

  • Réaliste (peRtinent)

  • limité dans le Temps

1.4. Les problèmes éventuels lors de l’implantation des processus

Les problèmes éventuels relevés par ITIL® sont les suivants :

  • l’engagement est fait sur des objectifs irréalistes (basés sur des envies « tiens, ça serait bien d’y ajouter ceci » plutôt que de vrais objectifs)

  • les SLA ne sont pas relayés par des OLA et/ou des UC.

  • l’autorité est insuffisante pour négocier ou initier des améliorations (des deux côtés)

  • résistance au changement.

  • les responsabilités de chacun sont floues amenant à des situations non prévues dans les SLA

  • compréhension insuffisante des besoins du métier et de l'entreprise et aucune justification des niveaux de service demandés.

  • importance insuffisante accordée aux processus ou aux services critiques pour le métier.

  • niveaux de service retenus imposés aux clients.

  • SLA basés sur les contraintes des TI plutôt que sur celles du métier.

  • les SLA ne font pas l’objet d’une communication large (surtout vers le centre de services).

  • la gestion des niveaux de service est souvent vue comme de la mise en place de contrats d’arbitrage (SLA défini comme une police d’assurance par les deux parties)

1.5. SLA, services et clientèles

Le SLA doit être vu comme étant la rencontre entre :

  • un ou plusieurs services et

  • une ou plusieurs clientèles

pour laquelle on spécifie des niveaux de service pour :

  • le support

  • la capacité

  • la disponibilité

  • la sécurité

  • la continuité de ces services