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.

Partie du catalogue de services interne au fournisseur de services (qui comprend les équipes internes et les sous-traitants), les services d’opérations (ou services techniques dans la terminologie ITIL®) sont décrits très sommairement dans la documentation ITIL®.

La description d’un service d’opérations proposée ici est personnelle et correspond à une proposition pratique ayant un intérêt dans les activités du fournisseur de services.

L’application du référentiel ITIL® peut néammoins aboutir à d’autres définitions du service d’opérations.

La définition proposée d’un service d’opérations part des ressources techniques associées au service d’opérations.

Un service d’opérations est un ensemble de prestations fournies par différentes équipes informatiques (internes ou sous-traitées) sur un ensemble de ressources techniques similaires (serveurs Linux par ex. ou bases de données Oracle) opérées avec le même niveau de service.

La principale difficulté d’un service d’opérations est d’ « exister » entre les services d’affaires d’un côté et les ressources techniques de l’autre côté.

Cette définition permet de bien préciser l’intérêt des services d’opérations. Un service d’affaires (par ex. la gestion commerciale d’un magasin) se basera sur des services d’opérations (serveur Linux critiques, réseau, bases de données critiques, etc.).

Cela n’est pas suffisant pour aboutir à un modèle clair de catalogue de services d’opérations. Il est nécessaire d’y ajouter des contraintes supplémentaires pour définir le périmètre d’un service d’opérations et clarifier leur utilisation.

Sur un ensemble de ressources similaires à opérer, il existe différentes actions à réaliser et différentes responsabilités à assurer par les équipes internes et les sous-traitants.

Nous allons catégoriser les responsabilités et ajouter la contrainte suivante : une seule équipe (interne ou externe) ayant une responsabilité particulière sur les ressources du service d’opérations.

Par exemple, une seule équipe qui réalise l’exploitation au quotidien des ressources du service. Si des serveurs Linux sont gérés pour partie en interne par un service d’exploitation et pour une autre partie par un infogérant, il est alors nécessaire de scinder les serveurs Linux en deux services d’opérations, chacun étant exploité par une équipe spécifique.

Nous allons voir ensuite la typologie des responsabilités habituelles sur un service d’opérations.

10.1. Distinction entre vues cliente et utilisateur : organiser des sessions de formation

Point important : il est nécessaire de distinguer le titre et la description pour un client du titre et de la description pour un utilisateur.

Par ex., dans le cas de mon propre catalogue de services, je propose une prestation d’organisation de sessions de formation ITIL® Fondamentaux.

Je m’adresse à la fois aux organismes de formation (où je propose une prestation plus ou moins complète mais sans à avoir à planifier les sessions de formation ni à gérer les inscriptions) et aux directions informatiques désirant organiser des sessions de formation en interne.

La vue cliente contient la description de la prestation portant sur les sessions de formation et la vue utilisateur ne contiendra que le descriptif de la formation.

Evidemment, un client doit avoir aussi accès à la vue utilisateur.

Dans l’exemple proposé, si une DSI me commande une prestation pour organiser des sessions de formation et gérer les incriptions du personnel informatique, je dois proposer deux services d’utilisation aux utilisateurs (qui sont ici les participants aux sessions de formation) : l’inscription et la désinscription.

10.2. Structure d'un service d'affaires : gérer le commerce

Autre exemple (simplifié) : la gestion commerciale d’un magasin

• service principal : gestion commerciale du magasin

• service en option : assistance sur site à l’inauguration du magasin (l’informatique envoie du personnel sur place pendant les journées d’inauguration du magasin qui ne doivent pas être perturbées par un incident informatique malgré les risques : expérience limitée des équipes du magasin sur le nouveau logiciel, stress des équipes du magasin pendant cette période, etc.)

• service d’utilisation (ou service d’accession pour Enabling Services) pour la préparation à l’utilisation :

  • initialiser les données du magasin dans le système (cas de la création d’un magasin),

  • migrer les données du magasin de l’ancien système (cas d’un magasin existant migrant vers le nouveau système)

• services d’utilisation dans l’utilisation quotidienne du service :

  • donner, modifier ou supprimer l’habilitation d’accès d’un utilisateur : réservé au directeur du magasin par ex. ; nécessite une opération technique de la part de l’informatique

  • ajouter ou modifier une caisse : fonction de l’ERP qui a été verrouillée pour les magasins afin de les contraindre à passer par l’organisation informatique pour réaliser ces actions ; la raison première est que la stratégie de tarification est basée sur le nombre de caisses d’un magasin (item facturable décrit dans le processus ITIL® de gestion financière des services) car cela est un bon critère pour évaluer la taille d’un magasin (qui est proportionnel au coût de fourniture du servces d’affaires) ; dans ce contexte, si cette option peut être utilisée directement par un directeur de magasin et qu’il le sait (parce qu’il a suivi la formation), je vous laisse deviner le scénario non prévu qui se mettra en place…

• services d’utilisation dans l’arrêt de l’utilisation du service :

  • obtenir une sauvegarde des données du magasin : cela indique une volonté de quitter l’enseigne ou d’arrêter le magasin (la sauvegarde servira, dans le premier cas, à réinjecter les données dans un autre système d’information et, dans le second, à conserver les données pour un éventuel contrôle fiscal par ex.)

Voici quelques erreurs classiques (que j’ai donc aussi faites par le passé) dans l’élaboration du catalogue de services d’affaires :

• nommer la prestation informatique et non pas uniquement l’application ou le matériel proposé : par ex. le poste bureautique qui est souvant facturé 2 à 3 fois plus cher que le même matériel acheté « nu » dans une grande surface

• si une partie d’un service d’affaires est commune avec une autre partie de services d’affaires : éviter les copier/coller (difficultés de maintenance par la suite) et créer un nouveau service d’affaires avec la partie commune (il s’agit de factoriser cette partie dans un nouveau service d’affaires) ; cela arrive avec les services facilitateurs (ou pratiques)

Autres points importants dans la réflexion :

• les clients et utilisateurs ne voient que la partie services d’affaires du catalogue (et un utilisateur n’a pas la même vue qu’un client) : ce point est développé juste après

• chaque client ou organisation d’affaires ne voit pas le même ensemble de services d’affaires, de services d’utilisation et de niveaux de services : il est utile de ne présenter que les services qu’une personne a le droit d’utiliser mais attention au nombre de vues ; plus le nombre de vues est important, plus la charge de travail pour les gérer est importante

• la présentation et l’utilisation doivent être conviviales et compréhensibles des personnes qui consultent le catalogue : interdire le jargon informatique (sauf si les clients sont eux-mêmes des informaticiens)

• tous ces éléments nécessite impérativement d’intégrer dans la réflexion l’outil logiciel qui va gérer le catalogue de services : il ne sont pas nombreux à répondre à tous ces critères (si on ne tient pas compte des discours commerciaux et marketing) ; il est, par ex., nécessaire d’étudier quelles sont les fonctionnalités de recherche d’une information dans le catalogue et les fonctionnalités de filtres (ceux obligatoires et ceux définissables par l’utilisateur)

Cette liste est une liste classique de données détaillant un service d’affaires en complément de l’apport de valeur et des fonctionnalités déjà présentés.

Point important : il est nécessaire de distinguer le titre et la description pour un client du titre et de la description pour un utilisateur.

Ceci posé, il est nécessaire de définir la structure de la description d’un service d’affaires avec tous les éléments que nous venons de voir.

Cela permettra d’aborder la définition d’un modèle de fiche concret pour décrire les services d’affaires.

Le service d’affaires est composé :

• du service principal : décrit en premier lieu par son apport de valeur aux clients

• des services complémentaires (ou d’amélioration selon la terminologie ITIL®) : décrits aussi par leur apport de valeur aux clients

• des services d’utilisation associés : pouvant être catégorisés s’il y a beaucoup de services à présenter

Les principales catégories de services d’utilisation peuvent être :

• préparer à l’utilisation du service : par ex., un client a commandé un service d’affaires et ses utilisateurs peuvent maintenant demander à utiliser le service d’affaires

• utiliser le service : ce sont les demandes standard pouvant être faites par les utilisateurs dans le cadre d’une utilisation normale du service d’affaires (par ex. déménager le poste de travail) ; cette catégorie peut aussi être éclatée en plusieurs catégories s’il y a un nombre important de services d’utilsiation associés

• arrêter l’utilisation du service : par ex. un magasin veut quitter l’enseigne pour en intégrer une autre, il faut proposer un service d’utilisation pour extraire les données comptables du magasin et lui remettre un ensemble de fichiers qui pourra ensuite être repris par les services centraux de la nouvelle enseigne.

Dans ITIL®, on parle aussi de services facilitateurs ou pratiques (Enabling Services). Pour ces services, il est possible de définir la même structure de description.