Après la présentation détaillée du contenu du catalogue de services, il est évident que, pour une performance optimale, le catalogue de services doit être intégré réellement dans un référentiel plus large qui s’appelle la CMDB et placé sous le contrôle du processus de gestion des configurations et des actifs de service.

Ceci permet de lier :

• les utilisateurs et clients aux services d’affaires

• les services d’affaires aux services d’opérations

• les services d’opérations aux composants techniques

• certains composants techniques à des caractéristiques d’utilisateur

• les rôles d’opérations aux équipes du fournisseur de services (internes et sous-traitants)

L’apport de valeur est de faciliter tout ce qui analyse d’impact : incident, changement, etc.

Les investissements réalisés pour l’élaboration du catalogue de services et les dépenses d’exploitation courante de la gestion du catalogue seront ainsi mieux rentabilisés.

Le référentiel ITIL® précise que les demandes de service fréquentes devraient être définies sous la forme de modèles de requête (ou de demande de service).

Cela nécessite la définition d’une procédure de traitement et des données en entrée que doit fournir le demandeur.

Les demandes de service sont décrites dans le catalogue des services d’affaires (services d’utilisation) et devraient être associé à une procédure de traitement.

L’outil idéal devrait intégrer un moteur de traitement de flux (workflow) pour effectuer le suivi administratif du traitement des demandes. Certains logiciels proposent une orchestration des activités du workflow en ce sens que certaines activités ne sont pas manuelles mais peuvent être réalisées par des outils logiciels à condition de pouvoir les piloter au travers du moteur de traitement de flux.

Attention à la complexité du projet de mise en œuvre du catalogue de services avec les procédures : il peut y avoir plusieurs centaines de services d’utilisation à développer (donc plusieurs centaines de procédures) et le choix de l’outil est crucial pour la faisabilité du projet : s’il faut plusieurs jours pour développer un workflow, il va falloir une équipe de 5 personnes pendant un an pour saisir toutes les procédures de traitement !

Enfin, l’utilisateur peut aussi suivre l’avancement du traitement de sa demande.

Le catalogue des services d’affaires (avec les services d’utilisation) sera plus performant :

• s’il est intégré à un portail utilisateurs proposant par ailleurs d’autres fonctionnalités comme la saisie de tickets d’incidents par ex.

• si l’outil logiciel permet de gérer facilement les différents profils des personnes qui consultent (client, utilisateur) afin de proposer des vues différentes

• si l’outil logiciel permet de filtrer les services proposés en fonction du type de client auquel l’utilisateur appartient

Le portail utilisateurs devrait aussi offrir :

• des facilités pour trouver rapidement une information dans le catalogue : au bout d’un certain temps (très court généralement), l’utilisateur décroche son téléphone et appelle le centre de services pour demander son information s’il ne la trouve pas dans le catalogue

• distinguer la consultation simple (pour s’auto-former) de la consultation pour faire une demande

Afin d’être complet dans les informations proposées (utilité et garantie d’un service), le catalogue de services présentés aux utilisateurs et clients devraient contenir les niveaus de service décrits dans les SLA.

La gestion des niveaux de service n’est pas de la responsabilité du processus de gestion du catalogue de services. Néammoins, la publication du contenu des SLA peut être intégrée dans la publisation du catalogue de services.

Cela est aussi valable en interne sur les services d’opérations (avec les OLA et UC).

16.1. 4 types proposés

Il existe quatre types de liens fréquents entre un service d’opérations et ses composants techniques.

Nous allons les décrire en détail juste après.

16.2. Service non lié à un composant technique

Certains service d’opérations ne sont pas liés à un composant technique. Il s’agit là des prestations pures comme celles du centre de services (prise d’appel, etc.) ou d’une équipe projet (élaboration de cahier des charges, etc.).

16.3. Service lié à un seul composant technique

Certains services d’opérations portent sur la gestion un seul composan technique. Ce peut être le cas d’une salle informatique, d’un serveur central, du SAN/NAS, de la virtualisation des serveurs, du système de sauvegarde, etc.

16.4. Service lié à une série de composants techniques indistinguables

Certains services d’opérations sont liés à une série de composants techniques indistinguables de l’extérieur. Il s’agit par ex. de la gestion d’un cluster de serveurs. Le système est un service d’opérations à part entière vu de l’extérieur (il a un comportement spécifique).

Prenons l’exemple d’un cluster de serveurs gérant des moteurs de bases de données. A un instant donné, un moteur de base de données tourne sur l’un des serveurs constituant le cluster.

Cependant, de l’extérieur, je n’ai pas besoin de savoir précisément sur quel serveur tourne actuellement le moteur de base de données, le service m’est rendu par le cluster avec un niveau de service défini au niveau cluster.

Ce comportement est similaire aux fonctions d’onde en physique quantique : un comportement spécifique apparaît lorsque je conçois une particule comme étant la superposition d’états dictés par la fonction d’onde (notamment des ondes d’interférences) qui disparaît dès lors que je m’intéresse directement à la particule.

Un autre exemple est l’hébergement de machines virtuelles sur un cluster d’ESX VMware proposant par ex. une disponibilité de 100%. Pour cela, je devrai activer certaines options spécifiques du cluster (HA et FT) pour obtenir une disponibilité de VM de 100%, alors que je sais parfaitement qu’une VM seule peut planter et ne peut pas m’assurer un taux de disponibilité de 100%.

16.5. Service lié à une série de composants techniques distinguables selon un critère utilisateur

Le dernier type de service d’opérations est celui qui est lié à des composants techniques distinguables selon un critère directement ou indirectement à l’utilisateur.

En fait, dès que me sont précisés le service d’opérations et l’utilisateur concerné, je peux connaître le composant technique unique concerné par ma recherche.

Quelques exemples classiques :

• le service d’opérations « Gérer le poste bureautique utilisateur » : à chaque utilisateur attaché à ce service d’opérations correspond un et un seul poste bureautique

• d’autres services d’opérations associés à une caractéristique utilisateur, par ex. « Gérer les routeurs réseaux d’étage » est associé à l’ensemble des routeurs réseaux et je peux associer un routeur d’étage à un utilisateur selon sa localisation géographique (données associées à l’utilisateur)

Tout ceci nécessite un outillage logiciel conséquent et on voit mal comment tout cela serait géré dans une feuille Excel par ex.

Cette liste propose des données essentielles minimales pour décrire un service d’opérations.

Elle contient les informations de cartographie, à savoir :

• les services d’affaires se basant sur le service d’opérations

• les composants techniques associés

Ces liens sont gérés plus globalement par le processus de gestion des configurations et des actifs de service dans la CMDB.

De même que pour les rôles de processus, la description du service d’opérations ne contient pas le nom des équipes associés aux rôles mais seulement un lien entre le rôle et les équipes dans l’organisation. Il sera donc nécessaire, pour être performant, de décrire la structure organisationnelle du fournisseur de services (organigramme interne et sous-traitants) dans la CMDB afin de gérer le plus efficacement possible ces liens.

Parmi les critères permettant de regrouper les services d’opérations, en voici quelques uns :

• les composants techniques gérés : aucun (prestation pure comme par ex. la réalisation d’un cahier des charges par une équipe de chefs de projet), un seul (serveur central ou mainframe par ex.), plusieurs

• les équipes intervenant sur le service d’opérations dans le respect du modèle AXER (une seule équipe par responsabilité, interne ou externe)

• les niveaux de service à opérer sur les composants techniques : un seul niveau de service par service d’opérations, ils peuvent aussi être nommés OR, ARGENT, BRONZE par ex. ou CRITIQUE, NORMAL, BASIQUE)

• habituellement, les services d’opérations sont associés à des documentations techniques telles que : documentations d’installation, d’exploitation, de support, d’administration, etc.

13.1. Exemple de liste

Puisque les ressources techniques associées sont gérés selon un même niveau de service, il est intéressant de nommer ce niveau de sevice et de l’intégrer dans le nom du service d’opérations.

Voici quelques exemples simples de services d’opérations :

• serveurs Linux opérés selon un niveau Gold

• serveurs Linux opérés selon un niveau Silver

Il pourrait avoir d’autres critères discrimants en fonction de l’organisation du fournisseur de services :

• serveurs Linux opérés en interne

• serveurs Linux externalisés chez XXX

Les outils d’exploitation sont eux-mêmes à décrire sous la forme de services d’opérations :

• système de supervision AAA

• système de sauvegarde

• logiciel anti-virus

Les environnements physiques sont aussi à décrire sous la forme de services d’opérations :

• salles informatiques

Les applications représentent un nombre important de services d’opérations.

Enfin, n’oubliez pas que le nom d’un service d’opérations doit d’abord décrire la prestation autour des ressources techniques plutôt que les ressources techniques elles-mêmes.

13.2. Exemple : gérer les serveurs Linux/bases de données selon le niveau Gold

Ensuite, il va être possible de définir le niveau de service selon lequel les ressources techniques associées sont opérées en précisant les critères habituels de disponibilité, de capacité, de sécurité de l’information et de continuité de service.

13.3. Exemple de matrice de responsabilités AXER

Le modèle AXER permet aussi de présenter synthèse des responsabilités de chacune des équipes sur l’ensemble des services d’opérations sous la forme d’une matrice de responsabilités.

C’est l’équivalent de la matrice de responsabilités du modèle RACI et permet, d’un seul coup d’œil, de voir qui fait quoi sur chacun des services d’opérations.

Parmi les particularités de l’exemple proposé :

• serveurs Linux de niveau de service CRITIQUE et NORMAL : le directeur informatique en est l’autorité mais ils sont opérés chez l’infogérant

• serveurs Linux de niveau de service BASIQUE : l’infogérant en est l’autorité, a l’expertise en interne, les opère au quotidien et a un centre de services associé (il s’agit d’une prestation de type PaaS)

• bases de données Oracle : celles qui sont critiques sont opérées en interne alors que les autres sont externalisées

• l’application de gestion commerciale (tous les modules) a pour autorité l’editeur du logiciel et les équipes internes ont un niveau d’expertise sur le module encaissement (probablement pour accélérer les temps d’intervention en cas d’incident, le module encaissement étant critique) mais pas sur le module de gestion des stocks (module non critique pour les affaires)

Nous allons faire une analogie avec les rôles de processus qui interviennent dans les activités d’un processus.

Le modèle RACI (Responsible-Accountable-Consulted-Informed) est une aide à la conception d’un processus et une aide à la clarification de qui fait quoi dans les différentes activités du processus.

Il est facile de déterminer des rôles classiques intervenant sur les ressources d’un service d’opérations :

• quelqu’un ou une équipe est le propriétaire du service (terminologie ITIL®)

• une équipe a l’expertise sur les ressources techniques (expertise Linux, expertise Oracle, etc.)

• une équipe réalise l’exploitation au quotidien des ressources techniques

• enfin, une équipe réceptionne et traite les demandes des utilisateurs du service d’opérations sur les ressources techniques associées

Il est possible de définir d’autres responsabilités mais celles-ci sont les principales.

Ces rôles sont appelés rôles d’opérations et, afin d’avoir une homogénéité dans la terminologie, les services techniques (selon ITIL®) sont appelés services d’opérations.

Ceci est formalisé dans le modèle AXER (similaire au modèle RACI pour les processus) :

• Autorité : propriétaire du service

• eXpert : équipe ayant l’expertise sur les ressources techniques associées

• Exploitant : équipe opérant au quotidien les ressources techniques

• Réceptionnaire : équipe réceptionnant et traitant les demandes sur le service d’opérations

Chaque responsabilité sera ensuite associé à une et une seule équipe du fournisseur de services (interne ou externe).

Cela impose, par exemple :

• que les ressources techniques associées ne requièrent qu’un seul domaine d’expertise, assuré par une équipe unique

• qu’elles sont exploitées par une seule et même équipe

• que des ressources techniques gérées à l’extérieur par un sous-traitant nécessitent un point d’entrée chez le sous-traitant à qui soumettre les demandes et les incidents liés aux ressources techniques (le sous-traitant doit avoir un centre de services qui joue le rôle de réceptionnaire)

  Le modèle AXER peut être enrichi s’il est opportun de séparer des responsabilités plus fines.