3.1. Une nouvelle équipe

Parmi les éléments à dimensionner en phase de conception, il faut évaluer la charge de travail supplémentaire pour les équipes projets et exploitation.

Il est préconisé de mettre en place une équipe (ou une personne) qui gère les activités courantes du processus de gestion du catalogue de services et, ultérieurement, les activités du processus de gestion des niveaux de service.

C’est dans cette équipe que nous retrouverons les propriétaires de services au sens ITIL®.

Cette équipe commence à apparaître et est souvent nommée Relations Clients ou Organisation (« O » de DOSI).

Elle peut aussi se voir attribuer comme responsabilité la gestion du Package de conception des services (SDP).

3.2. Les processus liés

Des charges de travail supplémentaires apparaissent en gestion de projet car les chefs de projet doivent maintenant considérer que ce qu’ils doivent livrer n’est plus une application ou une infrastructure technique mais un service complet.

Cela impose, si on veut être cohérent de bout en bout, de demander à ses sous-traitants de gérer leurs propres catalogues de services. Les services d’affaires qu’ils proposent et qui sont utilisés en interne seront référencés dans notre propre catalogue de services comme des services d’opérations.

Enfin, il est important, pour être cohérent avec la gestion des services ITIL® et pour rationaliser les activités, de confier la gestion des accès au catalogue de services au processus de gestion des accès ITIL® (s’il est en place dans l’organisation).

3.3. Les activités spécifiques

Les activités opérationnelles quotidiennes sont les suivantes :

• s’assurer de la complétude, de la cohérence et de la version à jour informations du catalogue en auditant régulièrement ce livrable

• assister les chefs de projet dans leur nouvelle démarche, au début et à chaque fois qu’un nouveau chef de projet est nommé

• mettre en production les mises à jour du catalogue et les procédures liées aux services d’utilisation (workflows) au travers d’un outil ergonomique et complet

2.1. Conception du système de gestion du processus

L’approche proposée est la mise en place d’un processus de gestion du catalogue de services selon les bonnes pratiques ITIL®.

Un processus ITIL®, quel qu’il soit, et son écosystème peuvent être représentés sur le modèle ci-dessus.

Dans un référentiel qualité ISO/IEC 9000, l’écosystème du processus (tout ce qui lui permet de fonctionner correctement et d’atteindre ses objectifs) est nommé système de gestion (Management System).

Outre les personnes et les équipes qui travaillent selon le processus, le système de gestion comprend principalement 3 parties :

• une grande partie des activités du processus va produire et maintenir à jour un ensemble de documents et d’enregistrements rassemblés dans le livrable du processus (ensemble théorique des documents et des données ; dans la réalité, il s’agit d’une collection de documents, fiches, enregistrements dans une base, etc.)

• une petite partie des activités du processus va permettre de gérer les droits d’accès au livrable des personnes à l’extérieur du processus et dont les activités vont être facilitées par l’utilisation de ces éléments à jour

• un outil de gestion (souvent, un logiciel ou une application) permettant de gérer et de tracer les activités du processus, de stocker et de publier de manière sécurisée le contenu du livrable du processus

2.2. Préoccupation permanente : le VOI positif et rapide du processus

Dans sa phase d’exploitation, un processus impose des contraintes (utiliser un logiciel pour assurer la traçabilité des activités) et ne présente pas toujours un apport de valeur direct à l’organisation sur la partie « Produire et maintenir à jour le contenu du livrable »).

C’est particulièrement le cas pour le processus de gestion du catalogue de services où ces activités sont aujourd’hui très peu réalisées.

De plus, l’outillage souvent logiciel) mis en place pour supporter le processus et la charge de travail supplémentaire que le processus impose aux différentes équipes augmentent encore la dépense.

La rentabilité du processus (valeur sur investissement) et assurée par la mise à disposition du contenu du livrable du processus à un maximum de personnes (côté informatique et côté clients). Ces personnes vont utiliser et exploiter le contenu du livrable du processus afin de faciliter et de fiabiliser leurs activités quotidiennes (bénéfices : gain de temps, utilisation de données à jour, fiables et complètes).

Ceci peut être représenté par le bilan ci-dessus.

Dans le cas du processus de gestion du catalogue de services, les personnes bénéficiaires seront à la fois les équipes internes de la DSI et les utilisateurs de cette même DSI.

Clairement, pour le catalogue de services (et plus tard les niveaux de service), il sera nécessaire de renforcer les équipes informatiques. Les bénéfices en retour (VOI ou Value On Investment) seront, pour les équipes informatiques et les utilisateurs, une clarification de qui propose quoi, des gains de temps et de fiabilité dans les projets et des gains de temps dans le traitement des demandes utilisateurs.

2.3. Maximiser l'apport de valeur et le VOI et mettre en place les 3 composantes d'un service

Afin de maximiser l’apport de valeur et le VOI du processus, il est préconisé de voir le projet comme ayant pour objectif la mise en place d’une prestation (ou d’un service, au sens ITIL® du terme) qui est de proposer un catalogue de services informatiques complet et à jour et de faciliter les demandes pouvant être faites avec ce catalogue.

Pour ITIL®, la mise en place d’un service nécessite 3 composantes :

• des processus pour structurer, fiabiliser et tracer les activités liées à la prestation fournie

• des outils (dont des outils logiciels) pour sécuriser et accélérer les activités ainsi qu’assurer le stockage des informations nécessaires pour assurer une prestation de qualité

• des personnes pour faire fonctionner les activités des processus

Un mélange équilibré de ces 3 composants permettra aux personnes qui vont profiter de ce service de voir trois effets indispensables :

2.4. Définition du processus et processus liés

Pendant cette phase de conception, il va être nécessaire d’évaluer les coût récurrents du processus.

Habituellement, ils sont de deux types :

• la charge de travail des personnes dans le processus

• les coûts de maintenance de la solution logicielle

Pour évaluer la charge de travail des personnes dans le processus, il faut prendre en compte la taille et les spécificités des activités de l’organisation et s’appuyer sur les quatre objectifs du processus ITIL® :

• gérer les informations contenues dans le catalogue de services (mettre à jour le catalogue de services lors du traitement des changements et des projets)

• s’assurer que le catalogue de services est à jour et reflète les détails, les statuts, les interfaces et dépendances de tous les services opérationnels ou en cours de développement, le tout en conformité avec les politiques en vigueur (vérifier l’exhaustivité, la fiabilité et la conformité des informations du catalogue de services)

• s’assurer que le catalogue de services est accessible aux personnes habilitées de telle manière qu’elles pourront utiliser de manière efficace et efficiente les informations du catalogue de services (gérer les accès au catalogue de services)

• s’assurer que le catalogue de services supporte les besoins en perpétuelle évolution de l’ensemble des processus de gestion des services dans leur utilisation des informations du catalogue de services, y compris toutes les informations sur les interfaces et dépendances (amélioration continue du processus)

Beaucoup de processus sont liés à la gestion du catalogue de services. Un minimum de maturité dans ces processus facilitera un VOI positif et rapide du processus.

La démarche proposée se déroule en 2 étapes suivies de l’« étape » permanente d’exploitation et d’amélioration continue. Elle intègre les macro-activités suivantes :

• valider les principes, concevoir le processus, les outils logiciels et la structure du catalogue et réaliser un pilote sur quelques services

• faire évoluer la méthodologie projet pour y intégrer les activités de transition des processus de gestion :

  • du catalogue de services

  • des niveaux de service

• élaborer la première version du catalogue de services (rétro-documentation de l’existant)

• mise en place du processus de gestion du catalogue de services en alignement avec la nouvelle méthodologie projet, exploitation courante et amélioration continue du processus

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.