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.

Lorsqu’on aborde de manière conceptuelle services d’affaires et services d’utilisation, il peut être difficile lorsqu’on a identifié un service de le catégoriser affaires ou utilisation.

Une question très concrète permet de distinguer ces deux types : quels sont les niveaux de service essentiels à proposer au client qui va l’acheter :

• service d’affaires : ce sont les quatre thèmes classiques ITIL® de disponibilité, de capacité (et de performance), de sécurité de l’information et de continuité de service qui sont à proposer

• service d’utilisation : seul ce qui va intéresser le client (comme l’utilisateur du reste), c’est le délai de livraison ou de réalisation.

Dans ITIL®, les demandes faites sur ces services d’utilisation seront traitées dans le processus d’exécution des requêtes sous la forme de modèles de requête (ou modèle de demande de service) qui sont, rappelons-le, des manières pré-définies (des procédures) de traiter certains types de requête.

A noter que certains services d’utilisation seront traités sous la forme de changements standard.

5.1. Vue cliente

Voyons maintenant la structure détaillée d’un service d’affaires.

Pour cela, revenons à la terminologie ITIL® et présentons là de manière simplifiée (les détails du référentiel ITIL® sur ce point n’apporte pas grand chose à la présentation).

Pour un client, le service d’affaires sera vue comme étant composé :

• d’un service principal (Core Service) répondant aux besoins de base du processus d’affaires pour tous les clients qui l’utilisent

• éventuellement d’un ou de plusieurs services complémentaires ou options (Enhancement Services) pour apporter de la valeur supplémentaire dans certains cas d’utilisation ou contextes d’utilisation du processus d’affaires (mais qui n’est pas nécessaire à tous les clients)

Evidemment, des options sont proposées lorsque certaines parties du service ne sont pas utilisées par un client et que ces options coûtent un supplément. Cela permet aussi de différencier le prix du service en fonction des contextes des différents clients.

5.2. Vue utilisateur

Pour l’utilisateur, la perception en est toute autre. Il ne s’occupe pas du prix de ce qu’il utilise. En revanche, le service le satisfait lorsqu’il peut réaliser de manière autonome ses activités métiers en utilisant des ressources informatiques.

L’utilisateur peut utiliser de manière autonome une application par ex. sans qu’il ait besoin de faire appel à une personne de l’organisation informatique. Et ce, à chaque fois qu’il a besoin de l’utiliser.

De plus, dans certains cas pour réaliser des actions métiers spécifiques, l’utilisateur peut contacter l’informatique pour demander une invervention du fournisseur de services informatiques afin de compléter son « expérience » du service d’affaires.

Certaines de ces demandes peuvent être formalisées sous la forme de services (en fait, il s’agit de sous-services attachés au service d’affaires) ; que j’appelle services d’utilisation car ils sont nécessaires pour l’utilisation correcte et optimale du service d’affaires.

Ces services d’utilisation seront aussi décrits dans le catalogue de services.

Voici quelques exemples de services d’utilisation :

• demande d’accès au service d’affaires : obtenir, modifier ou résilier

• traitements convenus et standard (dans le sens : formalisés et décrits dans le catalogue de services avec une procédure de traitement elle-même formalisée et écrite) : déménagement d’un poste de travail par ex.

Ces traitements ne peuvent pas être réalisés de manière autonome par les utilisateurs du service d’affaires, soit nécessairement (par ex. fonctionnalités non prévues dans le logiciel acheté à l’extérieur et nécessitant une intervention technique) ou volontairement (fonctionnalités verrouillées et non accessibles dans l’application par les utilisateurs afin d’avoir un contrôle de l’organisation informatique ou d’un responsable hiérarchique client dans le traitement de ces demandes).

Ces demandes seront traditionnellement traitées et gérées dans le cadre d’outils logiciels embarquant des fonctions de traitement de flux (workflow).

On s’aperçoit ici que l’outil logiciel gérant le catalogue de services devra soit intégrer des fonctions de traitement de flux, soit interfacé avec un outil de traitement de flux.