Eviter les pièges du référentiel ITIL : confondre \"Conception des Services\" et \"conception d\'un service\"

2. Eviter les pièges du référentiel ITIL

2.1 Confondre "Conception des Services" et "conception d'un service"

2.1.1 Le cycle de vie des services présenté selon ITIL®

Le cycle de vie des services tel qu’il est présenté dans ITIL® est un schéma très conceptuel pour faire passer l’idée d’un cycle de vie :

Malheureusement, il peut porter à confusion avec un autre cycle de vie plus opérationnel et il faudrait plutôt dire « Cycle de vie de la gestion des services », ce qui est plus long à dire et difficile à retenir, surtout dans les formations ITIL® Fondamentaux effectuées au pas de charge.

2.1.2 L'autre cycle de vie : celui d'UN service

Ce modèle global de cycle de vie des services peut donner l’impression qu’un service passe successivement de la conception des services, la transition des services puis l’exploitation des services, pour revenir en conception des services pour élaborer une nouvelle version par exemple.

Je l’ai souvent vu comme, par exemple, dans certains supports de formation ITIL® Fondamentaux.

Or, ceci est faux en partie car ce n’est pas comme cela que cela se passe pour un service.

En laissant tomber la partie stratégie des services où le service peut être inscrit très longtemps à l’avance dans le portefeuille de services s’il s’agit de quelque chose de stratégique, la mise en place d’un service commence par une demande de changement (lancement d’un projet). Nous sommes alors directement projetés dans … la transition des services sans passer par la case conception des services !

Le service est alors conçu (dans les processus de transition des services et des processus projets non décrits dans ITIL®), développé, testé puis mis en production dans cette même phase de transition. C’est d’ailleurs pour cela que celle-ci s’appelle comme cela : le service va ainsi passer de l’état d’idée à quelque chose d’opérationnel en production.

Le cycle de vie d’un service se résume donc à deux phases du Cycle de vie des Services : transition et exploitation puis rebouclera sur transition s’il faut le faire évoluer. Cela se fera au travers d’une demande de changement.

De même, en fin de vie, le retrait du service sera effectué par le biais d’une ultime demande de changement.

2.1.3 La conception des services : une phase très mal perçue par les utilisateurs d'ITIL®

Alors nous pouvons nous demander légitimement à quoi sert finalement la phase de conception des services ? D’autant plus qu’au vu des processus de cette phase, on retrouve aussi des activités que nous ne pouvons réaliser que dans la phase de transition (élaborer un SLA se fait en même temps que la conception du service par exemple) ou qui sont à première vue rattachés à la phase d’exploitation (des activités opérationnelles comme la surveillance de la disponibilité ou de la capacité suffisante des composants techniques qui sont en exploitation), de quoi alimenter quelques interrogations.

Simplifions le discours ITIL® et voyons les deux ambitions de la phase de conception des services :

  • relayer ce qui a été élaboré au niveau stratégique (phase de stratégie des services) vers les activités quotidiennes des équipes où deux groupes de personnes sont clairement identifiés : les équipes de développement et les équipes d’exploitation

  • concevoir un cadre de fonctionnement pour les équipes de transition et les équipes d'exploitation, tant aussi bien dans la manière de travailler (processus, méthodologies, normes, etc.) qu’au niveau technique avec la conception de solutions d’infrastructures aptes à supporter les futurs services d’affaires et surtout les niveaux de service associés.

Le résultat de tout cela (l’ensemble des livrables de l’ensemble des processus de la phase) est contenu dans le célèbre mais encombrant SDP (Service Design Package ou package de conception de service).

2.1.4 Un autre facteur de confusion : les processus de la conception des services eux-mêmes

D’une manière générale, un processus est destiné à atteindre un objectif simple.

Or, ce que j’ai constaté dans la documentation ITIL® et les différents supports de formation ITIL® Fondamentaux, c’est qu’un processus est associé à un ensemble impressionnant d’objectifs, certains liés à la conception, d’autres à la transition et enfin d’autres à l’exploitation.

Ce n’est pas une erreur du référentiel ITIL® car il faut comprendre en réalité que pour couvrir les ambitions du processus, ce dernier se décompose en plusieurs sous-processus, chacun des sous-processus se voyant attribué l’un des objectifs du processus.

Le processus étant la « somme » de ces différents sous-processus, il cumule donc tous les objectifs de ses sous-processus.

Enfin, lorsqu’on examine les activités des sous-processus, nous constatons que certaines sont de nature de conception, d’autres de nature de transition et d'autres encore de nature d’exploitation.

Certains sous-processus peuvent même mélanger des activités de phases différentes. Alors, imaginez la vision que l’on peut avoir du processus résultant.

Par exemple pour les processus de la conception des services, nous allons trouver des activités de conception, de transition, d’exploitation sans oublier le souci permanent d’amélioration continue.

Pour des raisons concrètes de compréhension des livres ITIL®, toutes les activités d’un processus sont rangées dans un seul livre (donc une seule phase). Le choix délibéré qui a été fait a été de ranger un processus dans la phase pour lesquelles les activités prépondérantes du processus s’y trouvent.

Les processus de conception des services sont donc difficilement appréhendables si nous n’avons pas cette compréhension globale de ce que sont les processus ITIL®.

Prenons un exemple : ceci de la gestion des niveaux de services.

Nature

Objectif

Stratégie

Assurer et améliorer les relations et la communication avec les organisations d'affaires

Conception

S’assurer que des cibles spécifiques et mesurables sont développées

Conception et Exploitation

Surveiller (1) et améliorer (2) la satisfaction du client par le biais de la qualité de service

1. Exploitation

2. Conception

Conception

S’assurer que l’informatique et les clients ont des attentes claires et non ambigües du niveau de service

Transition et Exploitation

Définir (1), documenter (1), valider (1), surveiller (2), mesurer (2), rapporter (2) et revoir (1) le niveau des services informatiques

1. Transition

2. Exploitation

Amélioration continue

S’assurer que des mesures pro-actives sont mises en place partout il est possible d’en justifier les coûts

Chaque objectif est lié à un sous-processus élémentaire et peut être modélisé sous la forme d’un traitement de flux (workflow).

Le processus d’ensemble de gestion des niveaux de service a été catégorisé dans la conception des services car les activités les plus importantes sont situées dans cette phase.

Les autres processus de cette phase sont aussi découpables de la même manière.

Leur objectif commun est de mettre en place et de maintenir les règles de fonctionnement, les infrastructures mutualisées (SAN, réseaux, etc.), les processus et les procédures, les méthodologies projets, etc. que les chefs de projet et les exploitants devront appliquer dans la transition des services et dans l’exploitation des services.

Il est à noter que le sous-processus le plus connu de la gestion des niveaux de service est « définir, documenter, valider, surveiller, mesurer, rapporter et revoir le niveau des services informatiques » et que cet objectif est de nature de transition et d’exploitation. Il va donc couvrir la phase de réalisation du changement (ou la phase de projet) pour un nouveau service (élaboration et accord sur les niveaux de service) et la phase d’exploitation (surveillance et production de rapport sur les accords de niveau de service).

Ceci ajoute à la confusion possible sur l’intérêt de la phase de conception des services.

Habituellement, lors de missions en clientèle, j’intègre ce sous-processus dans la méthodologie projet (ainsi que les autres sous-processus de nature de transition).

2.1.5 La conception des services : tactique de mise en œuvre de la stratégie des services

Quand on regarde bien les activités quotidiennes réalisées dans une organisation informatique, on y retrouve deux grandes catégories réalisées par des équipes au fonctionnement bien différent :

  • les activités de développement où on fait passer un service (que se soit une application ou une infrastructure technique) de l’état d’idée à un ensemble opérationnel de composants

  • les activités d’exploitation où on gère au quotidien les services fournis et les infrastructures techniques

Afin de structurer ces activités et de les aligner pour qu’elles servent au mieux les objectifs stratégiques, il est nécessaire de définir une tactique de mise en œuvre de la stratégie des services.

Lorsque l’on examine les processus de conception des services, on s’aperçoit qu’ils remplissent ce rôle.

2.1.6 Le célèbre mais encombrant SDP (package de conception de service)

Ce livrable est en sortie de la conception des services et c'est aussi un livrable d’entrée de la phase de transition de service. C’est comme cela qu’il est présenté dans les principes de la phase de conception des services.

Il contient donc le résultat des cogitations de l’ensemble des processus de conception des services, entre autres les livrables classiques :

  • le catalogue des services

  • les accords de niveaux de service, les accords de niveau d’opérations et les contrats de sous-traitance

  • le plan de disponibilité,

  • le plan de capacité,

  • les plans de continuité de service,

  • la politique de sécurité,

  • la politique vis-à-vis des fournisseurs externes (procédure d’achat, fournisseurs référencés, configurations avec des tarifs négociés, etc.)

Il va aussi contenir toutes les règles et préconisations à appliquer dans les phases de transition et d’exploitation des services :

  • méthodologie projet et l’ensemble des processus de transition et d’exploitation, ainsi que les modèles de processus (procédures) associés

  • choix d’infrastructures lourdes comme la virtualisation, le SAN, etc.

  • préconisations et briques standard d’infrastructure à même de répondre à la plupart des exigences de niveau de service (au vu du contenu du pipeline des services qui a déjà été élaboré)

Enfin, il contiendra aussi tous les modèles de document et les documentations des outils logiciels à utiliser dans les phases de transition et d’exploitation.

Malheureusement, à d’autres endroits de la documentation ITIL®, le SDP est présenté comme étant l’ensemble des documents accompagnant la mise en œuvre d’UN service. Par exemple, si ce dernier est traité en mode projet, le SDP est présenté comme étant l’ensemble des livrables du projet.

Il y aurait donc autant de SDP que de mise en œuvre de nouveaux services ou d’evolutions de service.

Ceci est contradictoire avec la définition clairement énoncée du livrable en entrée de la transition des services.

Les deux points de vue sont conciliables en les présentant de la manière suivante : il contient initialement l’ensemble des livrables de la conception des services (y compris les modèles de document) puis va s’enrichir des documents liés à chaque changement (mise en œuvre d’un nouveau service ou évolution de service existant).

Il s’agit donc d’un ensemble documentaire très volumineux puisqu’il contient toutes les documents opérationnels utilisés en conception, en transition et en exploitation des services.

Il sera donc géré naturellement sous une forme de gestion documentaire et c’est une partie importante de la base de connaissances.