1. La documentation ITIL : les bonnes pratiques sans les explications pratiques
La mise en œuvre des niveaux de service est essentielle pour démontrer les aptitudes du fournisseur de services à tenir ses promesses.
Il s’agit là du faîte de la toiture d’une maison et beaucoup de projets ITIL commencent par la mise en place des niveaux de service. Même les architectes qui nous dessinent de belles maisons pratiques à vivre n’ont jamais osé commencer la construction d’une maison par le toit.
Parmi les étapes importantes préalables, nous devons définir à peu près dans cet ordre :
- Les services d’affaires formalisés par la publication du catalogue de services d’affaires : leur élaboration est avant tout dicté par des considérations marketing et par une approche métier (unités d’affaires et processus clients) ; ils vont constituer la façade de la maison comme la porte d’entrée ou les fenêtres
- Les services IT (ou techniques selon ITIL), que je préfère appeler services d’opérations par la publication (en interne à la DSI) du catalogue des services d’opérations : leur élaboration est avant tout technique car on y parle de serveurs informatiques, de réseaux, d’applications, d’environnements de virtualisation ou de bases de données ; ils vont constituer les pièces de la maison comme le salon ou la salle de bain
- Les accords de niveau de service (SLA) portant sur la garantie de fonctionnement des services d’affaires ; ils vont contribuer à l’aspect extérieur de la maison et doivent donner l’impression de simplicité et de facilité à vivre
- Les accords de niveau opérationnels (OLA) et contrats de sous-traitance (UC) portant sur la garantie de fonctionnement des services d’opérations ; ils vont confirmer l’aspect extérieur de la maison en démontrant la simplicité et la facilité à les utiliser
Chacun de ces points est important et si, l’un manque à l’appel, le tout est gâché par une mauvaise impression des utilisateurs.
Lors de mes missions, j’ai constaté la difficulté à découper un catalogue en services d’affaires. Très souvent et malheureusement car ce n’est pas la meilleure approche, la réflexion débute à partir de notions techniques internes comme les applications ou les postes de travail.
Bon an, mal an, la DSI finit par obtenir un catalogue de services d’affaires. Mais ce n’est pas la fin du calvaire.
Après avoir élaboré une première version des accords de niveau de service (SLA), la difficulté suivante consiste à définir les services d’opérations et les accords de niveau opérationnel et contrats de sous-traitance associés de manière méthodique en repoussant le plus possible la technique de la cartomancienne consistant à tirer des cartes au hasard (des composants techniques par ex.) et à leur donner une interprétation qui sonne juste (« tout cela constitue le service d’opérations Stockage SAN »).
Plusieurs approches complémentaires existent et il faut utiliser l’ensemble de ces approches car aucune d’elle ne garantit seule d’aboutir à un découpage en services d’opérations qui soit efficace et compréhensible par tous.
L’approche que je vais décrire utilise des notions a priori étrangères au catalogue de services et donne une méthode pour découper un service d’affaires en services d’opérations sans que l’étape de définition des accords de niveau opérationnel (OLA) et contrats de sous-traitance soit un calvaire.
Il s’agit ici de transposer les rôles de processus et la notion de type de responsabilité basée sur le modèle RACI.
2. Aligner les accords de niveau de service (OLA) et les contrats de sous-traitance (UC) sur les accords de niveau de service (SLA) : le mécano du service d’affaires
L’alignement des niveaux de service passe obligatoirement par la décomposition du service d’affaires en service d’opérations.
Il existe trois natures de services d’opérations en relation avec la nature de la ventilation de la facturation :
- les services d’opérations communs (ou de base) tels que le réseau WAN : il coûterait plus cher de gérer la répartition réelle des coûts que d’inclure le coût global dans un pot commun qui sera réparti proportionnellement à l’usage des services d’affaires
- les services d’opérations partagés tels qu’un serveur de bases de données hébergeant les données de plusieurs applications
- les services d’opérations dédiés tels que l’application de gestion commerciale pour le service d’affaires de gestion commerciale
Prenons le cas simplifié à l’extrême d’un service d’affaires de gestion commerciale composé principalement de l’utilisation de l’application de gestion commerciale développée en interne.
L’application est client/serveur avec une interface web utilisée sur les postes bureautiques des utilisateurs. Les différentes parties du réseau sont omni-présentes et les serveurs web et base de données sont des serveurs virtuels hébergés sur une plate-forme de virtualisation. Enfin, le stockage des deux serveurs sont sur un réseau de stockage SAN dédié.
Dans cette vision simple, nous avons quand même pas moins de 8 services d’opérations.
Il faut maintenant identifier les équipes qui ont une responsabilité opérationnelle sur chacun de ces services d’opérations.
Les responsabilités de base sont multiples :
- réception des incidents et requêtes,
- exploitation au quotidien du service d’opérations,
- installation des correctifs et des nouvelles versions du service d’opérations ou
- expertise sur le service d’opérations
A cela, il faut ajouter la propriété du service d’opérations pour information car il peut être fait appel à lui en cas d’incident ou de problème et il est intéressant de l’inclure dans la documentation.
D’autres responsabilités peuvent être ajoutés par la suite si la DSI a atteint un niveau de maturité suffisant.
La démarche classique consiste ensuite à reporter dans un grand tableau la liste des fonctions de la DSI et des sous-traitants associés à un service d’opérations sur au moins l’une des responsabilités évoquées.
Les accords de niveau opérationnel (OLA) et contrats de sous-traitance peuvent ensuite être déduits de cette grande matrice.
Cependant, tout changement dans la gestion des services d’opérations comme, par exemple, l’externalisation de la gestion des postes bureautiques à l’occasion du départ à la retraite du patron de l’équipe bureautique oblige à remodifier l’ensemble du tableau pour remplacer les références de l’équipe bureautique par celles du sous-traitant. Et encore, il est possible que, dans l’appel d’offres, une partie des responsabilités soit externalisée auquel cas, il faut faire attention dans les modifications du tableau.
3. Les rôles d’opérations : une transposition des rôles de processus pour séparer l’aspect organisationnel de la gestion des services d’opérations
Depuis longtemps, et cela donne des questions classiques dans l’examen ITIL Fondamentaux, la formalisation des processus utilise la notion abstraite de rôle pour séparer la formalisation des activités de processus des équipes de l’organisation.
Dans la formalisation des processus, la chaîne des notions entre les activités de processus et l’organisation du fournisseur de services dans son ensemble se présent de la manière suivante :
De plus, lorsqu’on identifie tous les rôles intervenant dans une activité, il est recommandé de s’appuyer sur le modèle RACI (Responsible-Accountable-Consulted-Informed) pour ne pas oublier l’un des rôles. Il y a aussi d’autres avantages à utiliser ce modèle (éviter les redondances comme deux autorités différentes sur une même activité par ex.).
Afin de simplifier et d’être exhaustif et cohérent dans l’identification de tous les intervenants sur un service d’opérations, il est intéressant d’utiliser cette même notion de rôle pour séparer la gestion des services d’opérations de l’organisation :
Afin de transposer complètement la démarche sur les services d’opérations, le modèle RACI (4 familles de types de responsabilité) est aussi à transposer.
En faisant simplement, il est possible d’inventer un modèle AXER :
- Autorité : approuve le travail effectué par les équipes de transition et d’exploitation et est garant du résultat du service d’opérations
- eXpertise : lié à des activités d'expertise sur les services d’opérations : essentiellement le support des incidents de niveau 3 et l’assistance au chef de projet dans la conception d’une solution répondant à une demande de changement
- Exploitation : lié à des activités opérationnelles (exploitation au quotidien du service technique) : essentiellement l’exécution du plan d’exploitation et le support des incidents de niveau 2 ; il est aussi lié à des activités opérationnelles de mise en production des services et des composants et intervient sur l'environnement de production sous le contrôle de la gestion des changements : ces activités consistent à appliquer strictement les procédures d'installation et de déploiement décrites dans les documentations d'installation et d'administration des services d’opérations fournies préalablement dans le cadre de la gestion des changements
- Réception des incidents et requêtes : point d’entrée du fournisseur de services, traditionnellement c’est le centre de services mais cela peut aussi être le centre de services d’un fournisseur externe (notamment en cas d’externalisation où les activités du sous-traitants sont une boîte noire)
L’étape suivante est de déterminer les rôles et de les classer. Voici les rôles possibles dans une première version de la réflexion :
Enfin, il faut ensuite prendre chacun des services d’opérations un par un et associer les rôles puis les métiers et les fonctions, comités et sous-traitants de l’organisation pour formaliser l’ensemble des intervenants (et ce qu’ils font) sur un service d’affaires.
Pour le service d’affaire de gestion commerciale, l’application elle-même est liée aux intervenants centre de services, équipe d’exploitation et études de la manière suivante :
Le service d’opérations d’environnement de virtualisation est lui-même lié au centre de services et à l’équipe de virtualisation (l’équipe d’exploitation n’est pas un intervenant car l’équipe de virtualisation ne lui fait pas confiance et effectue elle-même les tâches d’exploitation) :
Le service d’opérations réseau WAN est, quant à lui, entièrement sous-traité à l’extérieur, y compris la réception des incidents et requêtes par les utilisateurs la propriété reste en interne chez l’équipe réseaux) :
L’utilisation de la notion de rôles facilite la gestion et l’analyse des relations complexes entre services d’affaires, services d’opérations et intervenants dans de nombreux cas d’utilisation :
- identifier tous les intervenants internes et externes d’un service d’affaires dès lors qu’une architecture générale a été conçue
- identifier le périmètre d’intervention d’un ou de plusieurs sous-traitants : services d’opérations concernés et quelles activités opérationnelles pour en changer, lancer un nouvel appel d’offres pour n’avoir plus qu’un seul sous-traitant, etc.
- transcrire les exigences de niveau de service du service d’affaires en exigences de niveau opérationnel à destination de chacune des entités concernées
- etc.
Le service d’affaires utilisé dans l’article à des fins de démonstration est structuré de la manière suivante :
