Pourquoi travailler sur un « réseau de valeur » plutôt que sur les processus ITIL® eux-mêmes ?

1 Pourquoi travailler sur un « réseau de valeur » plutôt que sur les processus ITIL® eux-mêmes ?

1.1 Mettre en place des processus : la réalité contredit la théorie des consultants

Une approche basée uniquement sur la mise en place de processus n’est malheureusement pas une approche holistique du problème d’industrialisation et d’optimisation d’une organisation informatique en vue de la transformer en un fournisseur de services efficace.

Le référentiel ITIL® d’ailleurs le rappelle dans la définition des actifs de service. Ils sont destinés à fournir de la valeur aux clients sous la forme de services et sont constitués de deux familles :

  • les aptitudes et

  • les ressources

Les processus sont classés dans la famille des aptitudes au même titre que la culture de services, l’organisation, les connaissances et les personnes. Donc, pour atteindre notre objectif, il faut se pencher sur tous les types d’actifs de service et non pas uniquement les processus informatiques.

De plus, structurer un projet ITIL® autour de la mise en œuvre de ces processus s’avère lourd et longue et, à en croire les consultants ITIL®, cette mise en œuvre devrait, à elle seule résoudre tous les problèmes.

Or, la réalité est toute autre et mes clients m’ont très souvent challengé sur cette approche, d’autant plus fortement que la taille de l’organisation informatique était petite (dans une PME/PMI par exemple). Comment voulez-vous justifier du coût de formalisation détaillée d’un processus comme celui de l’élaboration de la stratégie informatique qui va ne concerner que le directeur informatique et, dans une petite structure, qu’une petite partie de son temps ?

D’autres processus sont aussi difficiles à justifier dans une petite structure : la gestion du catalogue de services par exemple. D’accord pour élaborer et publier un catalogue de services mais pourquoi donc mettre en place des enchaînements détaillés d’activités pour le gérer avec un outil de traitement de flux (workflow) ?

Un certain nombre de processus, dont celui-ci, sont plus utilement connus par leurs livrables que par leurs activités (ici, le catalogue de service mais je pourrais aussi citer le plan de capacité).

1.2 Changer de paradigme : s’intéresser à tous les actifs de service et prioriser leur amélioration

Mais alors, quels sont les éléments importants pour une mise en œuvre réussie (et pas trop chère) du référentiel ITIL® ?

Si déjà s’intéresser « simplement » aux processus est coûteux en budget et en temps, alors qu’en est-il d’une approche plus complète ?

Evidemment, le simple inventaire de tout ce qu’il faudrait améliorer ne suffit pas : comme pour les incidents, l’organisation informatique a plusieurs axes d’amélioration à traiter en parallèle et il est nécessaire de fixer une priorité à chacun d’entre eux.

Il faut aussi comprendre qu’améliorer un actif de service sera explicité et mesuré souvent par un positionnement sur une échelle de maturité dont les principes généraux sont à prendre dans le référentiel CMM-I (les 5 niveaux de maturité plus le niveau Initial).

Préalablement au projet, il faut réaliser une étude de maturité pour :

  • évaluer le niveau actuel de maturité de l’organisation sur chacun des actifs de services nécessaires à son bon fonctionnement

  • évaluer le niveau de maturité raisonnable à atteindre sur chacun des actifs de service

En bilan de cette évaluation, il faut analyser, actif par actif, l’écart entre aujourd’hui et ce qu’il est raisonnable d’atteindre compte-tenu du contexte. Avec d’autres critères, il est alors possible de classer par ordre de priorité ces améliorations (montée de maturité d’un actif) et donc, d’apporter une information essentielle lors de la définition de chacune des étapes du projet ITIL®.

Cette démarche permet aussi d’abandonner certaines améliorations estimées trop lourdes à mettre en place au regard des coûts nécessaires à leur mise en œuvre.

Au fil de mes missions, lors de la phase d’interviews des équipes, j’ai abandonné petit à petit mes questions portant exclusivement sur la maturité des processus dans l’organisation pour l’étendre à l’ensemble des actifs de service.

Pour me faciliter la tâche, j’ai aussi élaboré un schéma présentant les dépendances entre ces différents actifs de services, ce qui fournit une autre information nécessaire à l’élaboration du plan projet.

La confrontation entre ce schéma de dépendances et les priorités des améliorations à apporter donne une bonne idée initiale des différentes étapes du projet.

En même temps, ce schéma permet aussi de synthétiser la réflexion et facilite la restitution du plan projet aux équipes informatiques (cela facilite ensuite l’appropriation du projet par les équipes).

Evidemment, comme pour les tickets d’incidents, la priorité des améliorations de chacun des actifs de service bouge au fil du temps et des circonstances. Un plan projet n’a jamais eu pour vocation de rester figé quoiqu’il arrive par la suite. C’est un document dynamique et une base de travail pour réévaluer constamment les priorités et le calendrier prévisionnel.

Enfin, il faut souligner que d’autres référentiels se mettent en place pour aller au-delà des processus informatiques. L’initiative commune d’une université irlandaise et de la société Intel aboutit à une démarche plus exhaustive appelée IT-CMF (IT Capability Maturity Framework) où la maturité de l’organisation informatique sur différents domaines n’est pas basée uniquement sur la maturité des processus mais sur la maturité des aptitudes et ressources essentielles à la maturité du domaine. Elle est essentiellement basée sur l’expérience des participants qui élaborent ce référentiel.

C’est sur ce référentiel que je m’essaie de m’appuyer aujourd’hui. Il est plus global que le référentiel ITIL® et englobe toute sa démarche processus.

1.3 Cartographier les éléments apportant de la valeur aux clients

Mon expérience actuelle, plus restreinte, m’a permis d’établir une cartographie des aptitudes et ressources en les positionnant sur ce que j’ai appelé réseau de valeur impliquant le fournisseur de services informatiques.

L’établissement de ce réseau de valeur permet donc de s’interroger efficacement sur le rôle de chacun de ces éléments dans ce qu’il peut apporter aux clients et utilisateurs.

A l’heure actuelle, ma cartographie est la suivante :


Il y a quatre grands domaines :

A.

le point de départ de toute démarche (tout doit partir des clients et de leurs besoins) : l’offre de services

B.

les processus informatiques décrits selonITIL®

C.

l’organisation globale du fournisseur de services informatiques : les équipes (ou fonctions) de l’organisation interne, les comités et les sous-traitants

D.

enfin, les composants technologiques, constituant le premier cercle de la CMDB

Il y a aussi ce qui relie les différents domaines :

  • les services d’opérations (terme ITIL® : services techniques) permettant de relier le domaine de l’offre de services au domaine des composants technologiques

  • les rôles permettant de relier les domaines offres de services, processus et organisation

Les rôles sont habituellement connus pour leur utilisation dans les processus afin de définir les responsabilités des acteurs du processus dans leurs activités. Ils permettent de relier les processus à l’organisation.

Or, les processus ne sont pas directement reliés aux résultats d’affaires des clients. Ce lien direct est constitué des services d’affaires qui leur sont fournis avec les niveaux de service garantis (en réalité, c’est même uniquement cet apport de valeur qui intéressent les clients).

C’est pour cela que le catalogue de services et les niveaux de service sont pour moi deux éléments essentiels dans l’amélioration du fonctionnement de l’organisation informatique car ils permettent de relier les attentes des clients aux ressources technologiques, l’organisation et même les processus.

Dans cette réflexion, j’ai constaté qu’il existe un autre type de rôle que celui de rôle de processus : les rôles d’opérations qui permettent de relier les différentes entités de l’organisation à la gestion des différents services d’opérations. Ce faisant, en partant de la criticité de chaque processus d’affaires, il est possible de préciser les niveaux de service attendus sur les services d’affaires, puis sur les services d’opérations et enfin, les actions de gestion sur ces derniers réalisés par les différentes entités de l’organisation, le tout sans parler obligatoirement de processus. Nous sommes ici dans la gestion des accords de niveau de service (SLA), d’accord de niveau d’opérations (OLA) et de contrat de sous-traitance (UC).

Pour aider à la formalisation de ces rôles d’opérations, j’ai eu l’occasion de définir une démarche similaire au modèle RACI pour relier services d’opérations aux différentes équipes, comités et sous-traitants intervenant dans la gestion de ces services d’opérations. Je l’ai appelé le modèle AXER :

  • Autorité ou propriétaire du service d’opérations

  • eXpert intervenant sur le service d’opérations

  • Exploitant gérant au quotidien le service d’opérations afin de garantir son bon fonctionnement

  • Réceptionnaire des incidents et des demandes de travaux sur ce service d’opérations

En parallèle de la mise en œuvre urgente et évidente de certains processus, une démarche ITIL® sera complétée, à mon sens, par la démarche suivante :

  • établir et formaliser ce réseau de valeur

  • puis, par le biais de l’amélioration continue, de travailler en permanence sur chacun des éléments de ce réseau de valeur afin de rester aligné de manière optimale sur les besoins des clients.