ITIL V3 Les cinq axes de la conception des services

Cration : juillet 2011 Mise jour : juillet 2011

A propos
A propos du document Ce document de rfrence sur le rfrentiel ITIL V3 a t ralis en se basant directement sur les 5 livres ITIL de la version 3 : Service Strategy, Service Design, Service Transition, Service Operation et Continual Service Improvement parus en 2007. Il est mis la disposition de la communaut francophone ITIL pour diffuser les connaissances de base sur ce rfrentiel. Ce document peut tre utilis de manire libre condition de citer le nom du site (www.itilfrance.com) ou le nom de lauteur (Pascal Delbrayelle).

A propos de lauteur Pascal Delbrayelle intervient avec plus de 25 ans dexprience comme consultant sur les projets dune direction informatique ayant comme facteur de succs la mise en oeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place dun site de secours, la mise en place dun outil de gestion des configurations ou la dfinition des normes et standards techniques des environnements de production. Ces projets requirent : la connaissance des diffrents mtiers du dveloppement et de la production informatique la pratique de la conduite de projets techniques de la direction informatique la matrise de la dfinition et de la mise en place de processus pour rationaliser et adapter les mthodes de travail au sein de la direction informatique A propos de mission et de formation Si vous pensez que lexprience de lauteur sur le rfrentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, nhsitez pas le contacter pour toute question ou demande : par mail : pascal.delbrayelle@itilfrance.com par tlphone : +33 (0)6 61 95 41 40 Quelques exemples de mission : Modlisation simple des processus de gestion des changements, des projets et des mises en production en vue de la slection, lachat et limplantation dun outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances Accompagnement avec la rorganisation dun DSI passant dune organisation en silos techniques vers une organisation inspire du rfrentiel ITIL et la mise en oeuvre doutils pour institutionnaliser les processus ITIL Accompagnement dune DSI dans la formulation de lappel doffres au futur centre de services en se basant sur les processus et la fonction centre de services du rfrentiel ITIL

Sommaire
1 2 3 4 5 Conception de solutions de service ................................................................................................................ 4 Conception de systmes de support, en particulier le portefeuille des services ............................................... 5 Conception darchitectures technologiques et doutils techniques ................................................................... 7 Conception de processus informatiques ....................................................................................................... 11 Conception systmes de mesure et de mtriques......................................................................................... 13

1 Conception de solutions de service

En raison du nombre trs important dactivits raliser lors du dveloppement dun nouveau service ou lvolution dun service existant, il est ncessaire de structurer et dadopter une approche formelle et structure.

Ce schma prsente le cycle de vie dun service dans ses trois phases : conception, transition et exploitation. Un transfert de connaissances performant entre quipe projet et quipe de production permet une progression sans heurt du service tout au long de son cycle de vie. Les domaines prendre en compte lors de la conception sont les suivants : Analyser et valider les besoins daffaires Revoir et modifier les services et les infrastructures techniques pour leur permettre dtre rutiliss pour le service en prvision Concevoir les solutions pour rpondre aux besoins daffaires (dj documents) en dfinissant et en documentant les aspects suivants : o o o les installations, les besoins fonctionnels, les informations ncessaires pour surveiller la performance du service ou du processus les processus daffaires soutenus, les dpendances, la criticit et limpact du service ainsi que les bnfices daffaires apports par le service les cycles daffaires, variations saisonnires et autres variations sur les volumtries du service (nombre de transactions, nombre et types dutilisateurs, etc.) ainsi que la croissance future anticiper les exigences de niveau de service (y compris la continuit de service) et les activits qui seront ncessaires la mesure, la production de rapports sur le service ainsi que la revue des informations produites les chanciers impliqus les rsultats du service et limpact sur les autres services dj en production les besoins de tests, y compris les tests dacceptation utilisateur (UAT ou User Acceptance Tests) et les responsabilits de chacun dans la gestion des tests

o o o

Sassurer que le contenu des critres dacceptation du service (SAC ou Service Acceptance Criteria) sont dfinis au dbut Evaluer et chiffrer plusieurs solutions possibles avec les avantages et inconvnients de ces solutions sur tous les aspects : les cots doivent prendre en compte les aspects utilit du service et exigences de niveau de service et devraient inclure le cot total de possession (TCO ou Total Cost of Ownership) (cots de conception, de mise en production et dexploitation) Rvaluer et confirmer les bnfices daffaires du service : retour sur investissement (ROI ou Return on Investment) Ngocier et valider la solution retenue par lorganisation daffaires Vrifier que la solution sintgre bien dans les stratgies et politiques de lentreprise, de lorganisation daffaires et de lorganisation informatique ; si tel nest pas le cas, il faudra soit revoir la solution, soit adapter les stratgies et politiques incompatibles (en relation avec la phase de stratgie des services) Sassurer que lensemble des contrles de scurit et de qualit dentreprise et dinformatique sont intgrs dans la solution Effectuer une valuation de maturit de lorganisation informatique pour vrifier son aptitude atteindre les objectifs du service sur les thmes suivants : o o o bnfices daffaires et cots informatiques (cots ponctuels de mise en oeuvre et cots rcurrents dexploitation) risques lis au nouveau service et impact sur les risques existants en gnral (une attnuation est attendue) aptitude et maturit de lorganisation daffaires (tude mener par lorganisation daffaires elle-mme) pour sassurer que les personnes, les processus, les moyens, etc. seront aptes tirer le maximum de bnfices du futur service aptitude et maturit de lorganisation informatique : infrastructures industrielles, structure organisationnelle de linformatique, processus, personnes (aptitudes, connaissances et comptences) et outils techniques.

Les accords passs avec les fournisseurs ncessaires pour fournir et maintenir le service La fourniture dun dossier cohrent de livrables (SDP ou Service Design Package) pour les phases suivants de transition, dexploitation et damlioration du nouveau service ou du service modifi

2 Conception de systmes de support, en particulier le portefeuille des services

La manire la plus efficace pour grer tous les aspects des services durant leur cycle de vie consiste "informatiser linformatique", savoir mettre en place des systmes de gestion de ces donnes pour automatiser et faciliter les processus associs (processus informatiques). Le portefeuille des services est le systme de gestion le plus critique dentre eux : il relie les besoins des organisations daffaires aux solutions proposes par lorganisation informatique et dcrites en termes de bnfices apportes aux affaires. La valeur apporte aux organisations daffaires correspond la valeur relle sur le march (des fournisseurs informatiques, interne et externes) ; elle permet une comparaison avec dautres fournisseurs de services. Le portefeuille des services fait partie du systme de gestion des connaissances sur les services (SKMS ou Service Knowledge Management System) et est rfrenc comme document dans le systme de gestion des configurations (CMS ou Configuration Management System).

Voici une possibilit de cycle de vie dun service : Spcifi : un ensemble de besoins daffaires est transmis par une organisation daffaires lorganisation informatique Dfini : les besoins sont en cours dvaluation, de dfinition et de documentation en y incluant les exigences de niveau de service Analys : les besoins sont en cours danalyse Approuv : la dcision pour que linformatique propose une solution en rponse aux besoins exprims est prise Lanc : les besoins sont communiqus aux parties prenantes de lorganisation informatique et les ressources et budgets en cours dallocation Conu : le nouveau service et/ou les modifications de services existants sont en train dtre conus, et commands si ncessaire Dvelopp : le service ou lvolution de service et ses composants sont en cours de dveloppement, et rceptionns si ncessaire (achats externes) Construit ou Intgrs : les lments sont en cours dassemblage pour obtenir un "package" global Test : les lments sont en cours de test Mis en production : la solution est en cours de mise en production Oprationnel ou En exploitation ou En production : la solution est oprationnelle dans lenvironnement de production Hors service ou Retir : le service et ses composants ne sont plus en production mais certaines parties sont conserves et restent actives pour des raisons daffafires et/ou rglementaires Les quipes de lorganisation informatique travaillant sur la conception des services ont accs lensemble des services quels que soient ltat davancement de ces services. Les utilisateurs des organisations daffaires et les quipes de production de lorganisation informatique nont accs qu la partie des services dont ltat est situ entre "lanc" et "oprationnel", partie appele Catalogue des services. La partie des services dont ltat est compris entre "spcifi" et "approuv" est appel pipeline des services et est utilise par les quipes ayant dfinir des priorits sur les demandes de cration ou de modification de services et valider le lancement de la mise en oeuvre des solutions. Le portefeuille de services devrait inclure les informations suivantes pour un service donn : le nom du service la description du service ltat (ou le statut) du service la classification et la criticit du service les applications utilises les donnes et/ou les schmas de donnes utiliss

 les processus daffaires soutenus les propritaires ct organisation daffaires les utilisateurs (organisations daffaires) les propritaires informatiques la garantie : niveaux de service (SLA) et exigences (SLR) les services de soutien (ou services techniques) les ressources de soutien les services dpendants les accords de niveaux de service internes : accords de niveaux oprationnels (OLA) et contrats de soustraitance (UC) les cots du service la facturation du service (si applicable) les revenus et bnfices du service les mtriques du service

3 Conception darchitectures technologiques et doutils techniques

Au del des architectures de composants techniques, la conception architecturale doit aussi prendre en considration ce qui fait fonctionner la technique : les personnes, les fournisseurs et les processus. Le terme "Architecture" a pour dfinition dans le contexte ITIL :

Une architecture est lorganisation fondamentale dun systme, constitue de ses composants, des relations entre ces composants et avec lenvironnement et des principes guidant sa conception et son volution.
Le terme "Systme" est utilis dans son sens le plus gnral et ne se limite pas linformatique :

Un systme est un ensemble dlments organiss pour accomplir une fonction spcifique ou un ensemble de fonctions.
Enfin, le terme "Conception architecturale" a pour dfinition dans le cadre ITIL :

La conception architecturale est : le dveloppement et la maintenance de politiques, stratgies, architectures, conceptions, documents, plans et processus pour le dploiement et lexploitation qui en dcoule ainsi que lamlioration des services et solutions informatiques au travers dune organisation.
La conception architecturale doit faire en sorte : que tous les composants techniques (infrastructures, applications, donnes, services sous-traits) et leur gestion servent lintrt des organisations daffaires quun quilibre soit trouv entre innovation, risques et cots quune conformit existe entre les architectures, les stratgies, les politiques, les rglementations et standards affrents quune coordination existe entre, dune part, concepteurs, planificateurs et stratges informatiques et, dautre part, concepteurs et planificateurs des activits daffaires. La conception darchitectures couvrent tous les aspects : dfinition et gestion des rles, responsabilits, services, technologies, cadres (frameworks), processus, procdures et fournisseurs. Lorsquon rassemble toutes ces architectures pour se placer du point de vue de lentreprise, on obtient ce que lon appelle une architecture dentreprise.

La dfinition du Gartner est la suivante :

Larchitecture dentreprise est le processus de dclinaison de la vision et de la stratgie daffaires en changement dentreprise avec la dfinition, la communication et lamlioration des principes et modles cls qui dcrivent les futures tats de lentreprise et qui permettent son volution.

Larchitecture dentreprise est compose des grands domaines suivants :

Architecture de service : elle traduit toutes les architectures plus techniques (produit, application, donne, etc.) en un ensemble de services rendant indpendant les modles de services communiqus aux organisations daffaires des changements techniques (remplacement dune technologie par une autre par ex.) ; Architecture dapplication : elle fournit un plan dactions pour le dveloppement et la maintenance des applications, elle montre les inter-dpendances entre applications et fait le lien entre le contenu fonctionnel des applications et les plans daffaires (processus daffaires, etc.) ; Architecture dinformation/donne : elle dcrit la manire dont les donnes et les informations de lentreprise sont dfinies, stockes et gres pour tre partages par les applications et les utilisateurs ; elle couvre de plus en plus les moyens techniques pour accder ces donnes et informations de lentreprise ; Architecture dinfrastructure informatique : elle dcrit la structure, la fonction et la rpartition gographique des composants techniques matriels, logiciels et communications utiliss par lorganisation informatique ; elle dfinit aussi les standards techniques de ces composants (quels sont les composants autoriss, "tolrs" et interdits par ex. ? ) ; lensemble tant dcompos en architecture produit (description des produits techniques) et architecture de gestion (manires dutiliser et de grer ces composants techniques) ; Architecture environnementale : elle tlcommunications, etc.) et leur gestion. dcrit les environnements informatiques (salles,

Les relations entre toutes ces architectures peuvent tre rsumes de la manire suivante :

Il est possible dimaginer trois rles darchitecte dans ce contexte, travaillant sous lgide dun architecture dentreprise expriment dans lorganisation : Architecte dactivits daffaires ou organisationnel : gre les modles, les processus et lorganisation des entits daffaires ainsi que la gouvernance de lorganisation Architecte de service : pouvant tre spar des rles darchitecte applications et donnes, il gre les relations entre architectures daffaires, applicatives et donnes ; il travaille essentiellement sur la structure et le contenu du portefeuille de services Architecte dinfrastructure informatique : gre la partie technique, sa structuration et ses modles pour soutenir les applications et les donnes Lorsque ces architectures sont en place, elles facilitent grandement les activits de la conception des services en imposant un cadre de travail. Cette dernire utilisera les architectures et les composants de ces diffrentes architectures au lieu de tout "rinventer" chaque conception dun nouveau service.

Message cl : Les bnfices rels et le retour sur investissement dune architecture dentreprise ne proviennent pas de larchitecture elle-mme mais de laptitude dune organisation concevoir et mettre en oeuvre des projets et des solutions dune manire rapide et cohrente.
Les diffrentes architectures doivent prendre en compte les axes suivants : les activits daffaires, les personnes,

10

 les processus, les outils, la technologie Ces architectures peuvent tre utilises dans les trois axes dapproche suivants :

Concevoir de haut en bas afin de garantir que lorganisation informatique, son personnel, ses processus et ses technologies sont bien aligns sur les besoins et objectifs des organisations daffaires Concevoir de bas en haut afin de garantir que les processus informatiques de gestion des services et des technologies sont bien aligns sur les technologies Concevoir en intgrant de bout en bout afin de garantir la meilleure cohrence et efficacit possibles des technologies pour fournir les services aux organisations daffaires et dviter lapparition de silos techniques Deux pralables sont ncessaires pour le dveloppement de ces architectures au sein de lorganisation informatique : la gestion des processus daffaires : quels sont les processus daffaires et comment sont-ils relis aux services fournis par lorganisation informatique ? la gestion de la qualit de service : quentend-on par qualit de service ? Comment et o sera-t-elle mesure ? Ce sont les lments cls qui doivent tre prciss par la gestion des niveaux de service et la direction informatique.

4 Conception de processus informatiques

Un processus est un ensemble structur dactivits conu pour accomplir un objectif spcifique. Il prend une ou plusieurs entres et les transforme en sortie dfinies. Il intgre tous les rles, les responsabilits, les outils et les contrles de gestion requis pour fournir les donnes de sortie de manire fiable. Il peut sappuyer, si besoin, sur des politiques, des standards et des lignes directrices dfinies par ailleurs. La dfinition dun processus intgre aussi les procdures et modes opratoires qui lui sont associs et qui permettent de prciser de manire concrte et oprationnelle comment raliser les activits du processus.

11

Le contrle de processus peut tre dfini comme lactivit de planifier et de rguler un processus avec pour objectif de mettre en place et de conserver un processus efficace, efficient et cohrent.
Les processus, une fois dfinis, doivent tre documents afin de permettre une utilisation rptitive et contrle. Des contrles peuvent tre dfinis puis rendus oprationnels en dfinissant et en mettant en place des mtriques et des mesures du processus.

Un processus doit tre organis sur un ensemble dobjectifs. Les sorties du processus doivent inclure, outre latteinte des objectifs par des rsultats concrets : des mesures du processus, des rapports et des informations sur lamlioration future du processus Chaque processus doit appartenir un propritaire de processus qui sera responsable du processus, de latteinte de ses objectifs et de son amlioration continue. Les objectifs du processus doivent pouvoir sexpliciter en termes mesurables et tre exprims en termes de bnfices pour les organisations daffaires. La conception des services aide chaque propritaire de processus dfinir son processus en proposant des termes et modles standard, ce qui permet aussi au final davoir une cohrence de forme sur la dfinition de lensemble des processus et davoir une cohrence fonctionnelle et oprationnelle sur lensemble avec une intgration correcte de bout-en-bout et des interfaces inter-processus cohrents.

12

Un processus sera efficace lorsquil atteindra ses objectifs et sera efficient lorsquil les atteint en utilisant un minimum de ressources. Les rapports sur les mesures defficacit et defficience du processus devraient tre prvus ds la conception et faire partie des lments en sortie du processus. Cette approche sinscrit dans la dmarche "planifier-faire-agir-vrifier". La dfinition du processus avec tous ses lments doit tre valu, analys et revu rgulirement pour une amlioration continue ou pour viter la dtrioration invitable de lefficacit et de lefficience du processus lie aux changements dans lenvironnement de celui-ci. Une organisation informatique doit adopter une approche pragmatique dans la conception et la mise en oeuvre des processus : inutile de dfinir des processus parfaits mais concevoir plutt des processus pratiques et amliorables (en incluant les mcanismes damlioration).

5 Conception systmes de mesure et de mtriques

Si vous ne pouvez pas mesurer, vous ne pouvez pas grer.

Une attention particulire doit tre porte lors de la slection des mesures raliser et les mthodes pour les mesurer. En effet, cela affectera le comportement des personnes parties prenantes dans les processus surtout lorsquon parle dobjectifs, de performances des quipes et des personnes et de parties variables de salaires bases sur la performance. Les mesures orientes sur latteinte des objectifs daffaires et sur lamlioration devraient tre les seules retenues. Le choix portant sur des mesures autres entranerait des comportements nfastes au fonctionnement et la performance de lentreprise. En ce qui concerne la phase de conception des services, les critres devraient tre : concevoir des solutions correspondant aux besoins daffaires concevoir le niveau de qualit adapt (viter la sous-qualit et la sur-qualit) concevoir des solutions avec un minimum derreurs ("bugs") ncessitant des correctifs aprs dploiement concevoir des solutions efficaces et efficientes pour les organisations daffaires. Les mthodes de mesures et mtriques devraient permettre de mesurer latteinte de ces objectifs. Il faut nammoins tenir compte de la maturit des processus en place : des processus de faible niveau de maturit ne permettront pas de mettre en place des mesures sophistiques (qui seront alors sans valeur et sans interprtation intressante). Il existe 4 groupes de mtriques pour mesurer un processus : lavancement en mettant en place des jalons et en validant les livrables au fur et mesure de la progression du traitement la conformit aux besoins de la gouvernance, des rglements et acceptation des intervenants respecter le processus lefficacit du processus pour atteindre ses objectifs et pour fournir les rsultats attendus lefficience du processus pour utiliser le minimum de ressources dans le respect de son efficacit Lorsque les processus sont immatures, seuls les deux premiers groupes peuvent tre mis en place, lefficacit et lefficience ne pouvant tre mesurs que lorsque le processus a atteint un degr de maturit suffisant. La mthode de mesure la plus efficace pour toujours conserver en tte latteinte des objectifs daffaires est la mise en place dun "arbre de mtriques" ou "arbre dindicateurs de performance" (KPI ou Key Performance Indicator). Les mesures doivent tre hirarchises afin de faire le lien entre les mesures lmentaires et techniques et les mesures sophistiques et synthtiques de latteinte des objectifs daffaires.

13

Sans cette approche hirarchique, on peut constater les cueils suivants : les mesures ne sont pas alignes sur les besoins et objectifs daffaires la visibilit globale est impossible obtenir des domaines o aucune mesure nest effectue existent mais ne sont pas identifis certains domaines sont bien mesurs (voire trop bien) tandis que dautres domaines le sont trs mal ou pas du tout il ny a pas duniformit de forme dans la restitution des mesures les dcisions sont prises et les actions damlioration sont lances partir dinformations incompltes ou inexactes

14

Voici un exemple classique de hirarchisation des mesures :

Cette hirarchisation des tableaux de bord permet chacun davoir les informations relatives ses niveaux et domaines de responsabilits : les dirigeants de lentreprise ont un tableau de bord synthtique align sur les proccupations daffaires les dirigeants informatiques et leurs clients ont un tableau de bord synthtique sur la gestion des services informatiques les gestionnaires des services et les clients ont des tableaux de bord synthtiques sur lensemble des services fournis et spcifiques sur chacun des services les propritaires et les gestionnaires de processus ont des tableaux de bord sur les performances de leur processus les experts et exploitants techniques ont des tableaux de bord sur la performance des architectures et composants techniques dont ils ont la responsabilit

15

Ces tableaux de bord prsentent aussi lhistorique de chaque mesure tous les niveaux ce qui permet didentifier les drives et les dgradations de performance dun des lments mesurs. La collecte et la gestion des donnes de mesure et la production des tableaux de bord devraient tre automatises le plus possible tant donn la charge de travail que cela implique.

16