La pratique de la gestion des services

La chaîne de valeur informatique (ITIL × Lean)

Création : juin 2013 Mise à jour : juin 2013

2

A propos

A propos du document Ce document pratique est le résultat de la mise en oeuvre du référentiel ITIL et d'autres référentiels dans des directions informatiques en France au travers des missions qui me sont confiées depuis 2004. Il est mis à la disposition de la communauté francophone ITIL pour diffuser quelques conseils et notes sur le passage souvent délicat de la théorie à la mise en pratique de ces référentiels. Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).

A propos de l'auteur Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en œuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production. Ces projets requièrent :

la connaissance des différents métiers du développement et de la production informatique la pratique de la conduite de projets techniques de la direction informatique la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter

les méthodes de travail au sein de la direction informatique

A propos de mission et de formation Si vous pensez que l’expérience de l’auteur sur la gestion des services informatiques (ITSM) peut vous aider dans vos projets sur l’organisation ou sur la production informatique, n’hésitez pas à le contacter pour toute question ou demande :

par mail : pascal.delbrayelle@itilfrance.com par téléphone : +33 (0)6 61 95 41 40

Quelques exemples de mission : Modélisation simple des processus de gestion des changements, des projets et des

mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances

Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL

Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL

3

Table des matières 1 Pourquoi travailler sur un « réseau de valeur » plutôt que sur les processus ITIL eux-mêmes ? ....... 5

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

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

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

2 ITIL et la démarche Lean ................................................................................................................... 8 2.1 Chasser le muda avec Lean ....................................................................................................... 8

2.2 Les 5 principes de la démarche Lean ......................................................................................... 8

2.3 Principe n° 1 : définir la valeur .................................................................................................... 8

2.4 Principe n°2 : identifier la chaîne de valeur ................................................................................. 9

2.5 Principe n°3 : obtenir un flux ....................................................................................................... 9

2.5.1 Premier objectif : supprimer les stocks ................................................................................ 9 2.5.2 Deuxième objectif : supprimer les monuments .................................................................. 10

2.5.3 Troisième objectif : développer la flexibilité de l'outil de travail .......................................... 10

2.6 Principe n°4 : « tirer » la production .......................................................................................... 11

2.7 Principe n°5 : viser la perfection ............................................................................................... 11

3 Exemple de formalisation de la chaîne de valeur ITSM ................................................................... 12

3.1 Objectifs ................................................................................................................................... 12

3.2 Description des organisations d’affaires de l’étude de cas ........................................................ 12

4 Organisation, processus et résultats d’affaires ................................................................................ 12

4.1 La structure en 3 niveaux ......................................................................................................... 12

4.2 3 niveaux pour relier facilement affaires et services d’affaires .................................................. 13

4.3 Exemple de l’organisation d’affaires Point de vente .................................................................. 14

4.4 Exemple 1 du processus de haut niveau « Gérer le commerce » ............................................. 15

4.5 Exemple 2 du processus de haut niveau « Gérer les ressources humaines » .......................... 17

5 Services d’affaires : entre le marteau et l’enclume ........................................................................... 19

5.1 Exemple 1 du service d’affaires « Gestion commerciale d’un point de vente » ......................... 20

5.2 Exemple 2 du service d’affaires « Utiliser un poste bureautique Point de vente » ..................... 21

6 Services d’opérations, rôles d’opérations associés et modèle AXER ............................................... 23

6.1 Exemple 1 du service d’opérations « Application de gestion commerciale Commercia - niveau CRITIQUE » ........................................................................................................................................ 25

6.2 Exemple 2 du service d’opérations « Poste bureautique Point de vente - niveau CRITIQUE » . 26

7 Rôles d’opérations ........................................................................................................................... 27

7.1 Exemple du rôle de propriétaire de service d’opérations .......................................................... 28

7.2 Exemple du rôle d’expert .......................................................................................................... 29

7.3 Exemple du rôle d’exploitant..................................................................................................... 30

7.4 Exemple du rôle d’installateur ................................................................................................... 31

7.5 Exemple du rôle de réceptionnaire d’incidents et de demandes de travaux .............................. 32

8 Métiers et organisation du fournisseur de services .......................................................................... 34

8.1 Exemple simple du métier de technicien poste de travail .......................................................... 34

4

8.2 Exemple complexe du métier d’expert systèmes d’exploitation ................................................ 34

8.3 Exemple du métier sous-traité de mainteneur externe réseau WAN ......................................... 36

8.4 Exemple de l’équipe d’organisation DSI/OPE/APP-Gestion applicative .................................... 37

8.5 Exemple de l’équipe d’organisation DSI/RCL/SER-Gestion de l’offre de services .................... 38

8.6 Exemple du sous-traitant PAMPLEMOUSSE ........................................................................... 39 8.7 Un exemple très connu : le CAB (Change Advisory Board) ...................................................... 40

9 Conclusion ...................................................................................................................................... 41

10 Bibliographie et références .......................................................................................................... 41

5

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.

6

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 :

7

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 selon ITIL 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.

8

2 ITIL et la démarche Lean

2.1 Chasser le muda avec Lean Indépendamment de ITIL, un autre référentiel utilise depuis longtemps la notion de chaîne de valeur et l’a mis au centre de son raisonnement. La démarche Lean, mise au point par Toyota, est une méthode de gestion globale qui permet à l’entreprise d’être au plus près de la demande client et d’éliminer tous les gaspillages. Pour ceux qui connaissent ITIL, ces notions n’ont-elles pas un air de déjà entendu ? Les processus ITIL permettent d’industrialiser et de rendre plus efficaces et efficientes les activités informatiques (sous la forme de processus) afin de gagner en maturité (le niveau Initial étant souvent appelé le chaos où tout est fait un peu n’importe comment et où les résultats ne sont pas souvent au rendez-vous) et de prendre en compte systématiquement les besoins des clients dans tout ce qui est entrepris à l’organisation informatique. La démarche Lean est une lutte incessante contre le muda (gaspillage) qui est définie comme toute activité consommatrice de ressources mais non productrice de valeur pour les clients. Cependant, cette démarche s’applique initialement au monde industriel qui fournit des produits (et des services associés) à des clients et les principes de la démarche, évidemment transposable aux activités d’un fournisseur de services informatiques, demandent néammoins quelques adaptations. De leur côté, les bonnes pratiques ITIL présentent essentiellement des processus informatiques à mettre en place afin de garantir l’utilité (le contenu fonctionnel de ce qui est proposé par le fournisseur informatique) et la garantie (les niveaux de service). Les processus ITIL sont le fruit d’une longue réflexion sur la manière la plus efficace d’optimiser les ressources et de s’aligner sur ce que demandent les clients, basée sur la mise en place correcte de tous les actifs de service. Cependant, résumer cette réflexion à l’énoncé de processus est un peu réducteur et certains éléments ont été mis de côté. Ainsi, les petites structures ont du mal à reconnaître un intérêt à la mise en œuvre de tous les processus alors que la mise en œuvre d’éléments de réflexion intermédiaires sur certains (comme le catalogue de services par exemple) suffiraient. Il faut donc reprendre tous les éléments de la réflexion et, comme ils vont être nombreux, il va falloir les trier et c’est là que la démarche Lean va être utile.

2.2 Les 5 principes de la démarche Lean Rappelons les principes de base de la démarche Lean et nous verrons que ces principes sont déjà largement familiers à tous ceux qui connaissent ITIL. Encore un domaine que Monsieur Jourdain pratiquait tous les jours… Le propos ici n’est pas de les présenter dans le détail mais plutôt de montrer que la version 3-2007 de ITIL et la version 2011 intègrent parfaitement ces notions Lean.

2.3 Principe n° 1 : définir la valeur Définir la valeur qu’apporte un produit ou un service à un client est le point de départ de la démarche Lean. Pour ITIL, lorsqu’un fournisseur de services informatiques veut fournir un service à un client, il doit nécessairement définir ce que ce service va apporter comme valeur aux clients qui l’utiliseront. La seule manière efficace de faire ce travail est d’élaborer un portefeuille puis un catalogue de services d’affaires. Il est à noter que la première caractéristique qui doit être définie avant toute autre considération pour un service d’affaires est son apport de valeur au client. Sur ce même point de départ de la réflexion, il faut remarquer que nous sommes d’ailleurs bien loin des considérations technologiques dont la bonne utilisation et la bonne gestion sont le métier de base de l’informatique. Pour définir l’apport de valeur aux clients, le plus simple et le plus efficace est de s’intéresser au fonctionnement des organisations d’affaires et, si ce fonctionnement a été formalisé sous la forme de

9

processus d’affaires, à ces processus, les objectifs qu’ils doivent atteindre et les résultats qu’ils doivent produire. Nous allons ensuite réfléchir à la manière d’aider ces processus d’affaires en imaginant des services d’affaires au travers de ce qu’ils peuvent faciliter (utilité du service) et en évitant le plus possible les inconvénients qu’ils risquent d’apporter (garantie [de bon fonctionnement] du service). La démarche lean précise encore quel seul le client final peut définir la valeur apportée par un service. C’est aussi un des principes affirmés dans ITIL.

2.4 Principe n°2 : identifier la chaîne de valeur La chaîne de valeur Lean comprend l’ensemble des actions nécessaires pour faire franchir un produit (ici, nous allons essayer de les transcrire pour un service) les trois phases critiques du management lean de toute entreprise :

la phase de résolution des problèmes (attention : sens différent de celui d’ITIL) : conception et mise en œuvre d’un nouveau service

la phase de gestion de l’information : enregistrement d’une demande de mise en œuvre du service en provenance d’un nouveau client et planification de cette mise en œuvre

la phase de transformation physique : pour un service, il s’agit plutôt de transformation au sens large des ressources pour fournir le service au client au moment où il en a besoin

Une analyse de la chaîne de valeur qui aura été cartographiée permettra d’identifier : les activités directes à la fourniture du service générant de la valeur pour le client les activités indirectes ne créant pas de valeur mais étant indispensables actuellement comme le

contrôle qualité ou la surveillance (c’est la même chose pour un produit et pour un service) les activités ne créant pas de valeur et qui existent en raison d’une rupture entre deux maillons

de la chaîne : par exemple pour un service, la rupture dans la continuité de l’information de gestion (il faut resaisir des informations pour faire une demande à un sous-traitant par exemple), la rupture géographique (un poste de travail avec socle technique constitué du système d’exploitation et des outils de base doit être expédié physiquement chez un éditeur de logiciels pour l’installation de l’application par exemple), etc.

Les deux dernières sont évidemment des exemples de muda (gaspillage) qu’il conviendra d’éliminer (mais attention : pas n’importe comment et pas n’importe quand car cela va demander des efforts d’amélioration, un peu de temps et comporte des risques). C’est pour cela que le réseau de valeur ITSM que j’utilise chez mes clients est utile pour entamer cette démarche de chasseur de muda.

2.5 Principe n°3 : obtenir un flux Ce principe précise qu’une fois la chaîne de valeur établie et les actions inutiles ayant été éliminées, il est nécessaire de mettre en place un flux séquencé dans les actions qui restent. Cette étape est plus explicite dans le monde physique de la fabrication de pièces que dans un contexte de fourniture de services. 2.5.1 Premier objectif : supprimer les stocks L’idée de flux est qu’une pièce ne soit pas être stockée à la fin d’une opération en attendant que les ressources soient disponibles pour la traiter dans l’opération suivante. Pour cela, la chaîne de production doit être :

sans rupture entre deux opérations

avec des opérations de même durée de traitement afin de mettre en place un flux structuré : à intervalle de temps régulier, les pièces de toute la chaîne passent simultanément d’une étape à une autre afin d’occuper tout le temps tous les postes de traitement (chaque poste réalisant une opération)

La mise en œuvre de ce principe est déjà très difficile dans le monde de l’industrie. Elle est aussi à haut risque car, une mauvaise implantation de ce principe peut générer des dégâts considérables.

10

Ainsi, la chaîne de fabrication délivre, lorsqu’elle est à son rendement maximal, un exemplaire du produit pour chaque période de temps. Organisée de cette manière, une chaîne de production peut obtenir un rendement très supérieur à une chaîne classique et produire des pièces dans un délai très fortement réduit par rapport cette même chaîne classique (ramené de quelques mois à quelques jours par exemple). Sur ce point, il est possible de faire un parallèle avec certains phénomènes de mécanique quantique comme la supra-conductivité : dans certaines circonstances (notamment de température), les électrons d’un métal s’alignent et se déplacent de manière synchrone de telle sorte que le métal ne présente plus de résistivité. Cela permet d’obtenir des intensités électriques très importantes sans échauffement, ce qui est impossible dans le monde macroscopique. 2.5.2 Deuxième objectif : supprimer les monuments Ce principe de flux va aussi mettre du plomb dans l’aile à un raisonnement apparemment logique lié à l’industrialisation de plus en plus massive. Dans le monde physique, la logique communément admise où certaines opérations doivent, pour pouvoir coûter unitairement le moins possible, être réalisées en très grand nombre (d’où l’apparition de machines-outils de plus en plus énormes). Malheureusement, la contrepartie est que, pour que cela fonctionne, il ne faut pas que l’opération soit interrompue (car la machine-outil « monumentale » a des coûts d’amortissements énormes et qu’il faut la rentabiliser), d’où l’apparition de stocks de sécurité de pièces en amont (il ne faut pas de rupture de stock) et en aval (une fois la machine lancée, peu importe le volume de pièces demandées ou commandées, il faut produire, quitte à stocker en attendant que quelqu’un utilise ces pièces par la suite). La démarche lean tend à s’attaquer à cette logique du « monumental » en revenant à des enchaînements d’opérations plus simples, moins massifs et les plus indépendants possibles de ces monuments qui générent du stock, donc du muda à un point tel que le gaspillage ainsi généré coûte plus cher que les gains de productivité bruts apportés par le « monument », entraînant au final un apport de valeur négatif. Cela pourrait se traduire dans le monde informatique comme un conseil pour ne mettre en place des « monuments » informatiques (SAN, virtualisation de serveurs, gestion centralisée des applications et des informations, etc.) qu’uniquement quand cela est rendu nécessaire. En effet, ces monuments informatiques générent des coûts cachés qui vont contrebalancer les effets d’échelle voire donner, au final, un apport de valeur négatif. Attention à ces coûts non visibles en début de projet car ce sont des coûts annexes. Beaucoup d’erreurs ont été faites en informatique (délocalisation du développement applicatif ou mise en place d’un ERP par exemple). Chacun retrouvera dans son expérience personnelle l’un de ces projets « monumentaux » qui s’est enlisé par la suite et a fini par coûter beaucoup plus cher que prévu. Ici, la logique peut être l’ennemi. Il faut prendre en considération tous les effets annexes lors de l’analyse de valeur d’un futur service.

2.5.3 Troisième objectif : développer la flexibilité de l'outil de travail D’autre part, un autre point essentiel développé dans le système lean est la flexibilité impérative des unités de travail. Une conséquence induite d’avoir des unités de fabrication petites en évitant les monuments est que le fournisseur va pouvoir fabriquer des petites séries au même coût que celui des grandes séries, pour peu que l’unité de production puisse être reconfigurée rapidement (encore du muda à chasser) entre deux séries à produire. Il faut donc faire en sorte que les manipulations des postes de fabrication (changement d’outil par exemple) doivent être les plus courtes possibles (un changement d’outil ou de paramétrage d’une machine-outil est un délai donc un gaspillage). Dans cet esprit, le monde des services a quelques exemples. Le premier qui me vient à l’esprit est la virtualisation des serveurs physiques. Imaginez que des serveurs soient utilisés dans un environnement de test. Une fois un plan de test déroulé, avec une configuration physique particulière, il faut préparer le serveur pour la campagne de test suivante : ajouter de la mémoire, ajouter ou enlever des cartes réseaux, le connecter ou le déconnecter d’un SAN, etc.

11

Lorsque vous avez appris à faire ces manipulations sur des serveurs virtualisés, par quelques clics de souris et ce, parfois, de manière dynamique (système d’exploitation non arrêté), vous comprenez que vous obtenez des gains de temps similaires au monde de l’industrie (ici, de l’ordre de quelques heures à quelques minutes).

2.6 Principe n°4 : « tirer » la production Ce principe est la continuation du précédent : aucune action ne doit être lancée tant que personne en aval ne le demande, ce qui donne le nom de « tirer » (pull). Ceci évite l’apparition de stocks avec des pièces produites quelque part (sans besoin réel en aval) et devant donc attendre que quelqu’un en aval en ait besoin et en demande. Dans le monde ITIL, c’est un principe simple qui passe souvent inaperçu lors de la présentation des caractéristiques d’un processus : le déclencheur du processus est celui qui sera bénéficiaire du résultat du processus. Un processus ne fait donc pas d’ « auto-allumage » et les ressources ne sont engagées lorsque le bénéficiaire du résultat du processus le demande. Ce principe est dont déjà intégré aux processus ITIL. Il faudra donc le respecter scrupuleusement pour éviter le muda : une occurrence de processus se déclenchant « spontanément » ou trop tôt et produisant un résultat dont personne n’a besoin à ce moment-là. Il s’agit là d’un gaspillage d’autant plus important que certains résultats ne peuvent être stockés et sont donc définivement perdus (par ex., la préparation d’une campagne de communication pour un arrêt planifié d’un service d’affaires qui s’est « déclenchée » alors même que les dates planifiées n’ont pas encore été validées et qui s’avèreront par la suite impossibles à conserver). Un autre exemple dans l’informatique est la virtualisation des serveurs. Certaines suites logicielles comme VMware par exemple propose même un catalogue de services dans lesquels les utilisateurs (comprenez ici des chefs de projet) font eux-mêmes leurs demandes de serveurs de tests (configuration, date de mise à disposition, durée d’utilisation, etc.).

2.7 Principe n°5 : viser la perfection La mise en œuvre des quatre principes précédents rend visible petit à petit et régulièrement des défauts qui sont alors à corriger. D’où « viser la perfection » qui exprime le fait de ne pas relâcher l’effort et, en parallèle de la mise en œuvre des quatre premiers principes, de travailler en permanence sur des améliorations possibles de ce qui a été mis en place. Pour ceux qui connaissent ITIL, cela leur rappelera des concepts apparus en 2007 avec l’amélioration continue des services. Lors de la mise en place d’une démarche lean, des objectifs sur ce principe sont introduits simultanément aux autres principes comme, par exemple, l’identification de problèmes (au sens ITIL) et la mise en place d’un plan d’actions visant à améliorer un ou deux points par mois dans chaque domaine. Je précise systématiquement à mes clients que mettre en œuvre des sous-projets ITIL n’est pas suffisant. Il est nécessaire de mettre en place immédiatement après la fin d’un sous-projet un suivi pour déterminer si le résultat obtenu peut encore être amélioré afin de rester aligné de manière optimale sur les besoins des clients. Le système lean précise exactement la même chose avec deux approches à combiner :

le kaikaku (ou révolution instantanée) : approche qui consiste à tout révolutionner pour mettre en place quelque chose de totalement nouveau ; ceci correspond très souvent à la première phase d’un projet ITIL où des sous-projets sont lancés (formalisation de processus, mise en place d’un outil logiciel, formation des personnes, etc.)

le kaizen (amélioration continue et progressive) : démarche d’amélioration continue telle qu’elle est présentée dans le référentiel ITIL.

12

3 Exemple de formalisation de la chaîne de valeur ITSM

3.1 Objectifs Voyons, sur une étude de cas imaginaire, tirée de plusieurs expériences en clientèle, comment formaliser et relier les différents éléments de la chaîne de valeur. Nous allons voir que ce schéma de réseau de valeur permet de bien :

caler l’intérêt de chaque élément, par exemple, la différence entre service d’opérations et services d’affaires qui est toujours difficile à déterminer et

délimiter correctement le périmètre du service d’affaires ainsi que la granularité des services d’affaires

Bien sûr, ce modèle va au-delà des bonnes pratiques décrites dans ITIL mais il me permet de décrire le champ d’action des bonnes pratiques sous un angle beaucoup plus concret. Dans cette étude, je me bornerai à présenter les deux domaines qui, à mon sens, sont moins bien décrits que les deux autres :

l’offre de services (A) et l’organisation (B)

En effet, les processus sont largement décrits dans les livres ITIL et les composants technologiques et les relations entre ceux-ci n’apportent pas de valeur dans cette présentation. Il y aura aussi une description des rôles d’opérations, inspirée de celle d’un rôle d’activité de processus et adaptée au contexte d’un service d’opérations.

3.2 Description des organisations d’affaires de l’étude de cas L’étude se base sur un contexte d’entreprise où l’on retrouve deux unités d’affaires :

des points de vente où le cœur de métier est le commerce et où on retrouve tous les processus liés à des activités commerciales au sens large et des processus support à l’activité principale

une organisation centrale qui proposent des services de support aux points de vente (l’organisation informatique en fait partie).

Pour des raisons de simplification et de clarté dans les schémas, toutes les unités d’affaires, tous les processus d’affaires, les services et entités organisationnelles ne seront pas représentés. Le contexte proposé reste néammoins suffisant pour avoir une vue d’ensemble du réseau de valeur et de son intérêt.

4 Organisation, processus et résultats d’affaires

4.1 La structure en 3 niveaux Afin de définir l’apport de valeur des services d’affaires, il est nécessaire de connaître un minimum des activités d’affaires facilitées par ces services informatiques. Pour ma part, j’utilise une représentation concrète qui structure les informations liées aux organisations et aux processus d’affaires sur 3 niveaux :

1. Organisations d’affaires (ou unités d’affaires) : ici, nous avons deux organisations, les points de vente et l’organisation centrale

2. Processus d’affaires de haut niveau : chaque organisation d’affaires a des grands domaines d’activités à gérer, comme la gestion des ressources humaines, la gestion commerciale (pour les points de vente), etc.

3. Processus d’affaires (niveau plus détaillé) : chaque grand domaine d’activités peut être décomposé en processus (ou sous-processus) comme, par ex. pour le domaine « Gérer les ressources matérielles » :

a. gérer les bâtiments b. gérer les équipements

13

c. gérer l’aménagement des locaux d. gérer l’entretien e. disposer des équipements non productifs

Cette structure, arbitraire, reste suffisamment simple pour pouvoir formaliser rapidement les processus d’affaires. Elle génère néammoins quantité de données à gérer.

4.2 3 niveaux pour relier facilement affaires et services d’affaires Le choix simplificateur de deux niveaux de processus dans une organisation d’affaires a été le suivant :

un service d’affaires facilite le fonctionnement d’un processus de haut niveau comme la gestion commerciale d’un point de vente ou la gestion des ressources humaines

une demande de service (attention : pour ITIL, ce terme a un sens différent), publiée au catalogue de services, attachée un un service d’affaires et pour lequel il existe un formulaire de demande et une procédure formalisée pour traiter la demande, est associée à un processus de second niveau comme, par ex., la demande d’installation d’un poste bureautique est associée au processus de recrutement du personnel (entre autres)

Cette simplification sur deux niveaux est arbitraire mais permet d’avoir une vue structurée de l’ensemble des processus d’affaires et d’organiser plus facilement le catalogue de services d’affaires. Voici le modèle de cette partie du réseau de valeur :

Notez que l’accord de niveau de service (SLA) comprend :

les thèmes liés à la garantie sur le service (disponibilité, capacité, sécurité, continuité de service pour ITIL et le développement durable que j’avais ajouté dans la réponse à un appel d’offres) et

les thèmes liés à la garantie sur les demandes de service (délai de livraison et développement durable, incluant par ex. le nombre de kilogrammes de CO² produit lors du traitement de la demande)

14

4.3 Exemple de l’organisation d’affaires Point de vente Voici un exemple concret de cartographie basé sur ce modèle :

15

Tous les processus n’ont pas été représentés dans cet exemple.

4.4 Exemple 1 du processus de haut niveau « Gérer le commerce » Tous les services d’affaires du catalogue n’ont pas été représentés. Seule la « gestion commerciale d’un magasin » a été associée à ce processus de haut niveau.

16

Le processus de niveau 2 « Facturer et encaisser » est associé à des demandes de service. Seules quelques demandes de service sont présentées ici :

Ces deux demandes de service sont attachées au service d’affaires « Gestion commerciale d’un magasin ».

17

4.5 Exemple 2 du processus de haut niveau « Gérer les ressources humaines »

Ce second exemple présente les liens entre les processus de gestion des ressources humaines et le service d’affaires « poste bureautique ».

18

Le processus de niveau 2 « Gérer les promotions, les démotions, les départs et les retraites » est associé à des demandes du service d’affaires « Poste bureautique ».

19

5 Services d’affaires : entre le marteau et l’enclume La première caractéristique d’un service d’affaires est son apport de valeur aux différents processus d’affaires et aux résultats d’affaires associés. Il n’a aussi qu’une existence « commerciale » ou « marketing » et n’a aucune consistance technique. L’apport de valeur aux organisations d’affaires se fait au travers des services d’affaires mais cet apport de valeur ne devient réalité que lorsque les différents composants technologiques nécessaires à la fourniture et au support du service d’affaires sont en place dans l’environnement de production. En pratique, il est possible d’associer directement ces différents composants technologiques aux services d’affaires mais cela devient très difficile à gérer et il est nécessaire de créer un élément intermédiaire dans la chaîne de valeur : ce qu’ITIL appelle les services techniques dans trop préciser ses caractéristiques par ailleurs. Pour ma part, je préfère parler de service d’opérations, certains « services techniques » peuvent ne contenir aucun élément technique (comme, par ex., fournir la présence d’un technicien sur place pendant les jours d’ouverture d’un point de vente afin de traiter plus rapidement les incidents informatiques qui surviendraient pendant cette période critique). Un service d’opérations regroupe les éléments techniques de technologies identiques ou équivalentes et opérées selon le même niveau de service (souvent spécifié au travers d’un nom comme OR, ARGENT, BRONZE par ex.). Voici quelques exemples concrets de services d’opérations.

20

5.1 Exemple 1 du service d’affaires « Gestion commerciale d’un point de vente »

Seuls quelques services d’opérations (et non pas la totalité) ont été attachés au service d’affaires. Pour des raisons de visibilité, les noms des services d’opérations sont composés du nom de la technologie suivi du niveau de service (qui doit parler à tout le personnel informatique et qui doit avoir été défini dans le glossaire). Les liens entre service d’affaires et services d’opérations se trouvent naturellement dans des schémas d’architecture applicative.

21

Enfin, pour cet exemple, voici la représentation de la demande de service « Déclarer un type de TPE monétique » :

5.2 Exemple 2 du service d’affaires « Utiliser un poste bureautique Point de vente »

Dans cet exemple, il est visible que ce service d’affaires n’est pas uniquement l’achat et la livraison d’un poste de travail sur le bureau de l’utilisateur. Il s’accompagne de sa connexion au réseau de l’entreprise, à la mise en place d’une adresse de messagerie et d’autres éléments de base nécessaires à toute personne de l’entreprise pour pouvoir utiliser efficacement son poste de travail.

22

Enfin, voici la représentation de la demande de service « installation d’un poste de travail Point de vente » :

23

6 Services d’opérations, rôles d’opérations associés et modèle AXER Un service d’opérations, tel que l’ensemble des serveurs/système Unix/Linux exploités selon un niveau de service CRITIQUE, est opéré par des personnes ou des équipes (internes ou sous-traitants). Leurs rôles sont définis dans ce que j’appelle des rôles d’opérations, en parallèle des rôles de processus qui lient activités et organisation. Comme pour les rôles de processus où le modèle RACI (Responsible-Accountable-Consulted-Informed) est une aide à la formalisation des activités et une aide à la lisibilité des différents intervenants dans un processus (matrices de responsabilités), les rôles d’opérations peuvent être structurés selon le même principe, en adoptant un modèle approprié. Il s’agit du modèle AXER (Autorité-eXpert-Exploitant-Réceptionnaire) :

Enfin, chaque rôle identifié et rangé dans l’un de ces catégories doit être associé à UNE ET UNE SEULE entité dans l’organisation. C’est une règle que j’impose afin d’obtenir un niveau de granularité clair des services d’opérations.

24

Dans cette étude de cas, 5 rôles d’opérations ont été formalisés :

Pour faire simple, un seul rôle a été associé aux types Autorité, eXpertise et Réception. Deux rôles ont été associés au type Exploitant (l’installation pouvant être confiée à une autre équipe que celle d’exploitation comme, par ex., l’installation d’un serveur sur un site distant peut être confiée à un sous-traitant implanté localement et différent de l’équipe d’exploitation interne en central).

25

6.1 Exemple 1 du service d’opérations « Application de gestion commerciale Commercia - niveau CRITIQUE »

Cette application est dédiée au service d’affaires « Gestion commerciale d’un magasin » et les différents métiers informatiques (fiches de poste) opérant le service d’opérations ainsi que leur rattachement à l’organisation sont directement visibles sur le schéma. Il est possible de voir directement qui fait quoi dans la gestion de ce service d’opérations, de la même manière qu’une matrice de responsabilités permet de voir qui fait quoi dans un processus. Dans ce schéma, nous constatons que plusieurs personnes se sont proclamées propriétaire du service. Comme dans le modèle RACI, nous pouvons imaginer que l’existence de plusieurs propriétaires (ou autorités) pourra naturellement entraîner des conflits lors des arbitrages et un manque de lisibilité pour savoir qui parle au nom de l’organisation informatique au moment de prendre une décision sur le contenu fonctionnel de l’application.

26

6.2 Exemple 2 du service d’opérations « Poste bureautique Point de vente - niveau CRITIQUE »

Ce service d’opérations est partagé entre deux services d’affaires (les autres dépendances n’ont pas été définies dans l’exemple) et les rôles d’opérations ainsi que les métiers et entités d’organisations associés sont représentés.

27

7 Rôles d’opérations Les schémas présentés dans ce paragraphe ne contiennent pas tous les liens vers les services d’opérations. D’autre part, ces rôles sont associés à différentes équipes internes et à des sous-traitants en fonction du domaine de responsabilités. Les logiciels ITSM comme EasyVista ou Serena Service Management réalisent ce partitionnement beaucoup mieux que moi. Les domaines de responsabilité (hormis pour le Réceptionnaire) sont les suivants :

28

7.1 Exemple du rôle de propriétaire de service d’opérations Ce schéma permet de voir les différents métiers et les différentes entités dans l’organisation qui sont propriétaires de services d’opérations.

29

7.2 Exemple du rôle d’expert On retrouve ce rôle d’expert dans la définition des fonctions ITIL de gestion technique et de gestion des applications. Le schéma peut être utilisé pour avoir une synthèse des équipes de support de niveau 2 ou 3 (selon l’organisation) dans les incidents pour l’ensemble des services d’opérations cités. Il est donc possible de configurer le logiciel de gestion des tickets d’incidents sans pour cela avoir formalisé le processus de gestion des incidents et la relation entre le rôle de support incident de niveau 2 avec les différentes entités dans l’organisation. C’est d’ailleurs ainsi que beaucoup d’organisations informatiques procèdent de manière empirique sur la gestion des incidents et le paramétrage de l’outil.

30

7.3 Exemple du rôle d’exploitant Sur ce schéma, on voit que le rôle d’exploitant à plusieurs métiers (dont un réalisé à l’extérieur) et appartenant principalement à la fonction de contrôle de l’exploitation. Certaines autres équipes dans l’organisation réalisent l’exploitation de domaines particuliers et complexes (stockage ou virtualisation des serveurs par exemple).

31

7.4 Exemple du rôle d’installateur Sur ce schéma, il est possible d’identifier rapidement :

quels sont les métiers informatiques et les entités de l’organisation habilités à réaliser des installations sur l’environnement de production et

quels sont les services d’opérations concernés

Ici, il faut constater que les rôles d’opérations sont une alternative pour identifier qui fait quoi sur l’environnement de production sans être obligé de définir les processus correspondants. Nous avons ici une cartographie (simplifiée) des métiers qui peuvent réaliser des installations en production sans avoir formaliser le processus ITIL de gestion des mises en production et des déploiements.

32

7.5 Exemple du rôle de réceptionnaire d’incidents et de demandes de travaux Il s’agit d’associer pour un service d’opérations une équipe ou un sous-traitant qui va réceptionner les tickets d’incidents (escalade au niveau 2 par le centre de services) et les demandes de travaux (dans le cadre du traitement d’une requête par le centre de services qui pilote les différentes actions de la procédure en faisant des demandes de travaux aux différents acteurs de la procédure). Ici, la segmentation est plus simple car seuls deux domaines permettent de tout classer :

En effet, les incidents et demandes sur tout service d’opérations hors réseaux WAN sont traités par l’équipe d’exploitation interne. Les réseaux WAN sont externalisés à un sous-traitant PAMPLEMOUSSE qui possède sont propre point d’entrée (son propre centre de services).

33

Le rôle de réceptionnaire se cartographie de la manière suivante :

34

8 Métiers et organisation du fournisseur de services Les rôles d’opérations sont associés aux métiers, eux-mêmes associés à des entités de l’organisation du fournisseur de services. La classification métiers que j’ai utilisée est celle du CIGREF : « Nomenclature 2009 des emplois-métiers du SI dans les grandes entreprises » Les entités d’organisation du fournisseur de services (au sens ITIL du terme) se rangent dans trois grandes catégories :

les équipes internes comme le contrôle des opérations, les comités (comme le comité consultatif des changements ou CAB et les sous-traitants

Les rôles d’opérations sont liés aux métiers.

8.1 Exemple simple du métier de technicien poste de travail Le technicien poste de travail a la fois un type de responsabilité exploitant et d’installateur et aussi d’expert, comme le montre le schéma suivant :

8.2 Exemple complexe du métier d’expert systèmes d’exploitation Ce métier est expert sur l’ensemble des systèmes d’exploitation mais réalise aussi l’exploitation et les installations sur les systèmes Linux destinés à réaliser de l’hébergement web. L’exploitation n’est donc pas confiée de manière inhabituelle à l’équipe d’exploitation Cette situation concrète arrive quelquefois lorsque l’organisation n’a pas confiance dans l’équipe d’exploitation pour gérer cette partie de l’environnement de production. Le cas est assez fréquent avec le réseau où l’équipe réseaux réalise aussi l’exploitation des éléments réseaux car l’équipe d’exploitation n’a pas suffisamment de compétences sur ce domaine pour opérer sans risque sur cette partie de l’environnement.

35

36

8.3 Exemple du métier sous-traité de mainteneur externe réseau WAN Le sous-traitant PAMPLEMOUSSE est représenté dans l’organisation sous son expression la plus simple : un métier « boîte noire » de mainteneur externe du réseau WAN. On retrouve aussi sur le schéma la liste des rôles d’opérations auxquels il est associé (les cinq rôles du modèle) ainsi que le service d’opérations qu’il opère complètement : le réseau WAN.

37

8.4 Exemple de l’équipe d’organisation DSI/OPE/APP-Gestion applicative Cette équipe est constituée de son responsable (fiche de poste : responsable des systèmes applicatifs) et des opérationnels (une seule fiche de poste pour tout le monde : gestionnaire d’applications).

38

8.5 Exemple de l’équipe d’organisation DSI/RCL/SER-Gestion de l’offre de services

Cette équipe regroupe tous les métiers informatiques en contact avec les clients (au sens ITIL).

39

8.6 Exemple du sous-traitant PAMPLEMOUSSE L’entité représentée par un sous-traitant est en réalité traité simplement avec des métiers « boîte noire » et, dans son expression la plus simple, un seul métier global pour le sous-traitant est représenté dans l’organisation.

40

8.7 Un exemple très connu : le CAB (Change Advisory Board) Un peu en dehors du réseau de valeur présenté ici, voici l’ exemple du comité consultatif des changements avec les métiers participant à ce comité (en version simple) :

La cartographie permet donc d’identifier rapidement les participants à un comité.

41

9 Conclusion Cette approche réseau de valeur combinant les principes ITIL (les actifs de service permettent au fournisseur de services de fournir de la valeur à ses clients sous la forme de services) et les principes Lean (notamment la chaîne de valeur) est plus pragmatique à mettre en place et permet d’obtenir des résultats plus rapides que la simple mise en œuvre des processus ITIL. En effet, le réseau de valeur prend en compte les réflexions intermédiaires aboutissant à la définition des processus ITIL et y travailler avant les processus peut permettre de gagner du temps, notamment dans les petites structures informatiques comme dans les PME/PMI par ex. De plus, lorsqu’un client ne peut pas mettre en place la totalité des processus ITIL pour des raisons de retour sur investissement, le réseau de valeur permet de s’intéresser à d’autres actifs plus concrets mais tout aussi efficaces dans l’atteinte des résultats informatiques. Ce réseau de valeur sera par la suite complété par les résultats du référentiel IT-CMF (IT Capability Maturity Framework) où tous les actifs de service sont présentés ainsi que l’interprétation concrète des 5 niveaux de maturité CMM-I pour chacun d’entre eux. Je suis bien évidemment à votre disposition si vous êtes intéressé par cette approche. Pascal Delbrayelle.

10 Bibliographie et références En dehors du référentiel ITIL, voici mes sources d’inspiration pour ce dossier pratique :

« Système Lean – Penser l’entreprise au plus juste, 2ème édition » de James Womack et Daniel Jones aux éditions Pearson France (ISBN : 978-2-7440-7391-5)

Site internet http://ivi.nuim.ie/it-cmf pour le détail du référentiel IT-CMF, référentiel qui m’a été conseillé par Robin Lauff ( ) fr.linkedin.com/pub/robin-lauff/1/271/187/

« CIGREF – Nomenclature 2009 des emplois-métiers du SI dans les grandes entreprises » : document pdf téléchargeable sur le site du CIGREF : http://www.cigref.fr/c/toutes-les-publications