Tactique et la vue services

Réf. ITSM-M0106-V010-009

Les services techniques sont des boîtes noires intermédiaires pour lesquelles il va falloir surveiller et gérer la performance.

Comme pour les services d’affaires où fournisseur et client doivent se mettre d’accord sur les niveaux de service, les services techniques doivent faire l’objet de négociation et d’accord entre le mini-fournisseur d’un service technique et le fournisseur de services dans son ensemble (ici figurant le rôle de client du service technique).

Ces accords seront formalisés dans des documents appelés accord de niveau d’opérations (OLA pour Operational Level Agreement) si le mini-fournisseur est une entité interne ou contrat de sous-traitance (UC pour Underpinning Contract, contrat sous-jacent).

Pour cette raison, dans la suite de ce document, j’utiliserai le terme de service d’opérations à la place de service technique, pour avoir une homogénéité de vocabulaire avec l’OLA ou accord de niveau d’opérations.

Chaque service d’opérations est aussi un mélange équilibré entre technologies, processus et personnes.

Certains services d’opérations seront à forte composante processus. D’autres seront à forte composante technologique.

Les services d’opérations basés sur un processus

Il s’agit de gérer sous la forme de boîte noire le système de gestion du processus en incluant la description du processus.

Les rôles de processus et le modèle RACI pourront donc être utilisés pour décrire ce type de service d’opérations.

Un exemple de ce type est la conduite de projet applicatifs, proposé par une équipe de chef de projets.

Les services d’opérations basés sur une technologie

Les explications qui suivent ne sont pas dans ITIL® mais sont issues de mon expérience personnelle.

Nous allons décrire les services d’opérations à base d’une technologie spécifique, par exemple le stockage disque.

Pour ce type de service d’opérations, il est possible d’accélérer la formalisation de ces services avant même que les processus ITIL® ne soient en place en définissant directement le lien entre service d’opérations et qui fait quoi pour gérer et fournir le service.

En reprenant une terminologie processus (le rôle et le modèle RACI), il est possible de définir des rôles d’opérations associés à chaque service d’opérations.

Un rôle d’opérations est un ensemble classique de responsabilités autour de la gestion d’un service :

  • Autorité : le propriétaire de service (celui qui décide du contenu et qui négocie avec les clients), dans l’exemple utilisé, cela peut être le responsable de l’exploitation

  • eXpert : celui ou ceux qui ont un niveau d’expertise sur la technologie, par exemple, l’équipe stockage au sein de l’organisation informatique

  • Exploitant : l’équipe qui exploite le service d’opérations au quotidien, par exemple, l’infogérant si l’environnement de production est externalisé

  • Réceptionnaire : quel est le point de contact à qui escalader un ticket d’incident ou une demande portant sur le service d’opérations, par exemple, le centre de services de l’infogérant (la description du service contient les informations pratiques pour le contacter : numéro de téléphone, adresse électronique, etc.)

Le modèle AXER, comme le modèle RACI, impose une règle simple : une seule équipe (ou une seule personne) n’est associé à un rôle d’opérations.

Par exemple, si le service de stockage disque est en partie exploité en interne et une autre partie est externalisée chez un sous-traitant (par exemple, dans le cadre d’un site de secours possédant lui aussi un SAN), il conviendra de créer deux services d’opérations séparés. Le principe de base étant de simplifier la présentation d’un service d’opérations et de connaître immédiatement avec le nom du service d’opérations, qui fait quoi et, en l’occurrence, qui exploite le SAN en question (l’interne ou l’infogérant).

Il s’agira de mettre en place le système de gestion permettant de suivre la performance du service d’opérations.

Enfin, les services d’opérations peuvent aussi dépendre d’autres services d’opérations. Mais attention à ne pas créer trop de dépendances, le modèle final pouvant être plus complexe que le modèle sans les services d’opérations en intermédiaire entre services d’affaires et actifs de service !

La construction la plus simple de cette cartographie dépend fortement du contexte du client et cela se travaille sous la forme d’ateliers pour avancer progressivement dans la démarche la plus efficace.