Accueil

ITIL®

Lean IT

Pratique

Plus

Crédit image : Pixabay

ITIL® : comprendre les 4 "P" de la conception des services

Publié le 2 février 2017 par Pascal Delbrayelle

Un concept anodin dans ITIL® qui s'avère fondamental lorsqu'un fournisseur informatique (interne ou externe) veut réussir sa transformation en fournisseur de services informatiques et numériques.

Il permet de changer de paradigme lors de la phase de conception d'un service ou d'un élément constitutif d'un service : un projet ne délivre plus uniquement un produit technologique mais une prestation complète fournie aux clients.

Imaginons un projet applicatif classique. Le chef de projet doit non seulement continuer à concevoir l'application et les infrastructures qui vont l'accueillir (partie Produits) mais aussi :

  • l'impact et les modifications dans les processus, procédures et documents de transition (documents de planification du projet) et d'exploitation (opérations et support)

  • l'impact et les modifications sur les personnes et les équipes de transition et d'exploitation (notamment la charge de travail de transition et la charge de travail récurrente d'exploitation et de support), ce qui permettra de justifier de ressources supplémentaires

  • enfin, si certaines activités de transition ou d'exploitation sont sous-traitées, il faut naturellement prendre en compte l'impact sur les activités des sous-traitants car ces derniers peuvent vouloir renégocier leurs contrats de sous-traitance pour prendre en compte ce qu'il y aura à réaliser et à gérer

La réalité malheureusement fréquente des projets applicatifs

Je constate chez mes clients qu'un mode de fonctionnement obsolète est en place : le chef de projet applicatif négocie avec le client (la direction métier par ex.) le contenu fonctionnel de la future application uniquement.

Il conçoit, développe et teste (fonctionnellement) la nouvelle application et termine son travail de chef de projet en prévenant les équipes d'exploitation qu'il y a une nouvelle application à installer et à exploiter.

Un minimum d'infrastructure a été conçu mais le chef de projet considère cela comme un mal nécessaire pour faire tourner l'application (et je ne vous dis pas ce qu'il pense des équipes d'exploitation).

De plus, lorsque le chef de projet intègre l'équipe d'exploitation dans son projet en les invitant dans les réunions projet par exemple, on constate très souvent un désintérêt des exploitants à ces réunions sous prétexte qu'il s'agit d'"activités projets qui ne les concernent pas". Etant déjà débordés par des soucis d'exploitation, ils n'ont pas de "temps à perdre" avec des réunions projet sans comprendre qu'en procédant ainsi, ils s'ajoutent à moyen terme des problèmes supplémentaires d'exploitation. On constate aussi que ce sont ces mêmes équipes qui se plaignent aussi constamment de livraisons applicatives de mauvaise qualité...

Les équipes d'exploitation se débrouillent ensuite avec les moyens du bord pour faire tourner les applications mais ont parfois des difficultés sur la qualité de service par manque de moyens.

Pour le concept des 4 "P", il faut reconnaître que ce mode de fonctionnement ancestral ne prend en compte que la moitié du quart de ce qu'il faudrait faire : seule la partie Produits est prise en compte et encore, seulement sur la partie applications, la partie infrastructures est timidement et avec répulsion prise en compte parce qu'il en faut une !

Cela renforce aussi l'impression pour la direction métier qu'il y a clairement deux entités différentes au sein de l'organisation informatique. Elle se retrouve parfois à devoir arbitrer des conflits internes entre ces deux entités informatiques.

Les 4 "P" : travailler ensemble pour délivrer un service complet au client

En clair, le chef de projet applicatif doit aussi prendre en compte les contraintes d'exploitabilité de la solution et les moyens limités des équipes d'exploitation.

Cela commence par un relevé d'exigences auprès du client sur les niveaux de service en parallèle du relevé d'exigences fonctionnelles.

Le chef de projet sera donc aussi responsable du bout-en-bout et sera imputable (Accountable) sur le bon fonctionnement de la solution en production (fonctionnalités et niveaux de service). L'équipe d'exploitation devra aussi participer à l'équipe projet pour apporter sa connaissance des contraintes d'exploitation et s'éviter du travail ultérieur, amorçant ainsi un cercle vertueux puisque cela leur dégagera encore plus de temps pour participer aux projets applicatifs.

Le travail conjoint de l'équipe applicative et des équipes d'exploitation permettra de trouver un équilibre entre les fonctionnalités, la performance et le coût de la solution mise en place (autre concept de la conception des services).

Plus d'informations dans les ateliers que j'anime pour mes clients.

ITIL® est une marque déposée d'Axelos.