ITIL V3 Les processus de la transition des services

Cration : janvier 2008 Mise jour : juin 2013

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

Table des matires

1 Planification et support la transition ................................................................................................ 6 1.1 Ambition, objectifs et objet du processus .................................................................................... 6 Ambition (goals) du processus ............................................................................................ 6 Objectifs (objective) du processus........................................................................................ 6 Objet (purpose) du processus............................................................................................... 6 1.1.1 1.1.2 1.1.3 2 2.1

Gestion des configurations et des actifs de service ............................................................................ 7 Ambition, objectifs et objet du processus .................................................................................... 7 Ambition (goals) du processus ............................................................................................ 7 Objectifs (objective) du processus........................................................................................ 7 Objet (purpose) du processus............................................................................................... 7 2.1.1 2.1.2 2.1.3 2.2 2.3

Modle de configuration ............................................................................................................. 7 Dfinitions.................................................................................................................................. 8 Elment de configuration (CI ou Configuration Item) .......................................................... 8 Systme de gestion des configurations (CMS ou Configuration Management System) ......... 8 Bibliothque des supports dfinitifs (DML ou Definitive Media Library) ............................ 8 Configuration de rfrence (configuration baseline) ............................................................ 9 Grer et planifier ............................................................................................................... 10 Identifier les configurations ............................................................................................... 10 Contrler les configurations............................................................................................... 10 Historiser et gnrer des rapports sur les tats des CIs ....................................................... 10 Vrifier et auditer .............................................................................................................. 10

2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 3 3.1

Activits ..................................................................................................................................... 9

Gestion des changements ................................................................................................................ 11 Ambition, objectifs et objet du processus .................................................................................. 11 Ambition (goals) du processus .......................................................................................... 11 Objectifs (objective) du processus...................................................................................... 11 Objet (purpose) du processus............................................................................................. 11 Ce qui est dans le primtre ............................................................................................... 11 Ce qui est hors primtre ................................................................................................... 11 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.3 3.4

Primtre .................................................................................................................................. 11

Risques ..................................................................................................................................... 11 Types de demandes de changement .......................................................................................... 12 Dfinition dune demande de changement ......................................................................... 12 Dfinition dun modle de changement.............................................................................. 12 Dfinition dun changement standard ................................................................................ 12

3.4.1 3.4.2 3.4.3

3.4.4 3.4.5 3.5 3.6 3.7

Dfinition dun changement urgent.................................................................................... 12 Dfinition dun changement normal................................................................................... 13

Activits cls ............................................................................................................................ 14 Les 7 R de la gestion des changements................................................................................ 14 Principaux rles et comits du processus .................................................................................. 14 Rle dautorit de changement : les diffrents niveaux ...................................................... 14 Rle de gestionnaire des changements ............................................................................... 15 Comit consultatif des changements (CAB ou Change Advisory Board) ............................ 15

3.7.1 3.7.2 3.7.3

3.7.4 Comit consultatif des changements urgents (ECAB ou Emergency Change Advisory Board) 15 4 Evaluation (des changements) ......................................................................................................... 16 4.1 Ambition, objectifs et objet du processus .................................................................................. 16 Ambition (goals) du processus .......................................................................................... 16 Objectifs (objective) du processus...................................................................................... 16 Objet (purpose) du processus............................................................................................. 16 4.1.1 4.1.2 4.1.3 5 5.1

Validation et tests de services.......................................................................................................... 17 Ambition, objectifs et objet du processus .................................................................................. 17 Ambition (goals) du processus .......................................................................................... 17 Objectifs (objective) du processus...................................................................................... 17 Objet (purpose) du processus............................................................................................. 17 5.1.1 5.1.2 5.1.3

Gestion des dploiements et des mises en production ...................................................................... 18 6.1 Ambition, objectifs et objet du processus .................................................................................. 18 Ambition (goals) du processus .......................................................................................... 18 Objectifs (objective) du processus...................................................................................... 18 Objet (purpose) du processus............................................................................................. 18 Unit de mise en production .............................................................................................. 18 Options de mise en production........................................................................................... 18 Modle de mise en production et de dploiement ............................................................... 19 Planifier............................................................................................................................. 19 Prparer pour la construction, les tests et le dploiement.................................................... 19 Construction et tests .......................................................................................................... 19 Planifier et se prparer au dploiement .............................................................................. 19 Excuter le transfert, le dploiement et le retrait ................................................................ 19 Vrifier le dploiement ...................................................................................................... 20 6.1.1 6.1.2 6.1.3 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6

Termes utiliss dans le processus .............................................................................................. 18

Activits cls ............................................................................................................................ 19

6.3.7 6.3.8 6.3.9 7 7.1

Conduire le support de dbut de vie (ELS ou Early-Life Support) ...................................... 20 Passer en revue et terminer un dploiement ....................................................................... 20 Passer en revue et clturer la transition du service ............................................................. 20

Gestion des connaissances .............................................................................................................. 21 Ambition, objectifs et objet du processus .................................................................................. 21 Ambition (goals) du processus .......................................................................................... 21 Objectifs (objective) du processus...................................................................................... 21 Objet (purpose) du processus............................................................................................. 21 Donne .............................................................................................................................. 22 Information ....................................................................................................................... 22 Connaissance ..................................................................................................................... 22 Sagesse .............................................................................................................................. 23 7.1.1 7.1.2 7.1.3 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.3

Concept-cl : Donnes-> InformatIon -> Connaissance -> Sagesse ........................................... 21

Exemple de systme de gestion de connaissances des services (SKMS) .................................... 23

1 Planification et support la transition

1.1 Ambition, objectifs et objet du processus
1.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : planifier et coordonner les ressources pour sassurer que les exigences de la stratgie des services appliques dans la conception des services pour concevoir une approche globale sont effectivement respectes dans lexploitation des services. identifier, grer et contrler les risques de dysfonctionnements des activits de transition.

1.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectifs concrets de : planifier et coordonner les ressources pour russir la mise en oeuvre dun service nouveau ou modifi dans les estimations prvues de cots, de qualit et de dlai sassurer que toutes les parties adoptent un cadre de rfrence commun de processus et de systmes afin damliorer lefficacit et lefficience des activits de planification et de coordination fournir des plans clairs et complets qui permettent aux clients et aux projets de changement business daligner leurs activits avec les plans de transition des services

1.1.3 Objet (purpose) du processus

Pour atteindre ces objectifs, le processus a pour objet de : planifier les ressources et la capacit appropries pour fabriquer les packages dinstallation, intgrer, livrer, tester, dployer et mettre en production les nouveaux services et modifications des services. fournir du support aux quipes et intervenants de la transition des services. planifier les changements de manire assurer que lintgrit de tous les actifs clients, actifs de service et configurations puisse tre maintenue tout au long de la transition du service. sassurer que tous les carts, risques et difficults de la transition des services sont signals aux dcisionnaires et parties prenantes appropris. coordonner les activits dans les projets, les interventions fournisseurs et les quipes internes quand cela savre ncessaire.

2 Gestion des configurations et des actifs de service

2.1 Ambition, objectifs et objet du processus
2.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : supporter les besoins et objectifs de contrle des affaires et des clients. supporter des processus efficaces et efficients de la gestion des services en fournissant des informations fiables sur les configurations pour permettre aux intervenants de prendre des dcisions au bon moment (cest--dire pour autoriser changements et dploiements, pour rsoudre plus rapidement incidents et problmes). minimiser le nombre de difficults portant sur la qualit et la conformit causes par des configurations incorrectes de services et dactifs. optimiser les actifs de service, les configurations techniques (IT configurations), les aptitudes et les ressources.

2.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectif concret de : dfinir et contrler les composants des services et de linfrastructure maintenir jour les informations de configuration sur les services et linfrastructure actuels et prvus, ainsi que conserver un historique de ces informations.

2.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de : identifier, contrler, enregistrer, raliser les comptes-rendus, auditer et vrifier les items de configuration et les actifs de service, comprenant les versions, les bases de rfrence (baselines), les sous-composants, leurs attributs et liens entre eux. avoir lautorit sur, grer et protger lintgrit des items de configuration et des actifs de service (et, lorsque cela est appropri, les actifs de leurs clients) au travers du cycle de vie des services en sassurant que seuls les composants autoriss sont utiliss et que seuls les changements autoriss sont mis en oeuvre. sassurer de lintgrit des configurations et des actifs ncessaire pour contrler les services et linfrastructure des TI en mettant en place et en utilisant un systme complet de gestion des configurations (CMS = Configuration Management System).

2.2 Modle de configuration

Le modle de configuration est le rsultat de la modlisation : des services, des actifs et de linfrastructure des relations entre ces lments de configuration (CI ou Configuration Item) Cest LE modle utilise par tous les acteurs du fournisseur de services : internes et sous-traitants.

2.3 Dfinitions
2.3.1 Elment de configuration (CI ou Configuration Item)
Cest un actif, un composant de service et, plus globalement, tout lment qui sera sous le contrle de la gestion des configurations : service daffaires, service technique, systme complet, matriels, logiciels, documentations, quipes de support, etc.

2.3.2 Systme de gestion des configurations (CMS ou Configuration Management System)

Il sagit du systme de gestion (application, outil logiciel, etc.) de la CMDB (Configuration Management DataBase) qui contient toutes les informations sur les CIs (Configuration Item). Cest un concept pouvant englober plusieurs bases de donnes ou rfrentiels physiques.

2.3.3 Bibliothque des supports dfinitifs (DML ou Definitive Media Library)

Il sagit dun stockage scuris des versions dfinitives autorises (media des versions logicielles) ayant pass les contrles dassurance qualit. Par extension et facilit dutilisation, elle comprend aussi tous les fichiers utiles au moment de linstallation dun logiciel : cl de licence (do limportance du mot "scuris" dans la dfinition) documentation, etc. Elle constitue une base pour la gestion des mises en production et des dploiements et lun des lments en entre des plus importants.

2.3.4 Configuration de rfrence (configuration baseline)

Il sagit dune configuration dun service, dun produit, dune infrastructure valide servant de base dautres activits. Pour tre plus clair, une configuration de rfrence peut tre assimile une photographie dune partie de la CMDB conserve comme rfrence et utilise pour comparaison avec des situations ultrieures de la CMDB (volutions lies des mises en production par ex.). La configuration de rfrence contient un ensemble dlments de configuration et leurs relations. Elle sera utilise par ex. pour effectuer un retour arrire aprs une mise en production en chec.

2.4 Activits

2.4.1 Grer et planifier

Cette activit consiste laborer le processus et dfinir les ressources qui travailleront dans le processus. Cette activit ne fait pas rellement partie du processus car il sagit pour le propritaire de processus de dfinir et de formaliser son processus et de mettre en place les moyens ncessaires pour que le processus qui sera mis en place puisse effectivement remplir ses objectifs.

2.4.2 Identifier les configurations

Il sagit, pour un primtre donn de la CMDB, de formaliser : lidentification des structures de configuration et de leurs inter-relations la slection des CIs leur nommage leur tiquetage la dfinition de leurs attributs la dfinition de la documentation de configuration la dfinition des types dlments de configuration lidentification des bibliothques de support lidentification des configurations de rfrence lidentification des units de mise en production Cette activit est faire une premire puis de manire rcurrente : pour tendre le primtre de la CMDB de nouveaux types dlments non contrls jusqu prsent (approche par phase de la CMDB) pour reprendre, modifier ou descendre un niveau de dtail plus fin toute partie existante de la CMDB (approche itrative de la CMDB)

2.4.3 Contrler les configurations

Le principe faire respecter est clair : aucun CI ne doit tre ajout, modifi, remplac ou enlev sans suivre une procdure de contrle approprie. Pour cela, il faut dfinir les procdures de mises jour des CIs qui soient efficaces et utilisables par les diffrents acteurs du fournisseur de services.

2.4.4 Historiser et gnrer des rapports sur les tats des CIs

Cette activit consiste dfinir formellement le changement dtat des CIs fournir les donnes historiques et actuelles concernant chaque CI

2.4.5 Vrifier et auditer

Cette activit consiste sassurer quil y a conformit entre les bases de rference documentes (par ex. accords) et lenvironnement daffaires rel vrifier lexistence physique des CIs en production, dans la DML et les stocks de pices de rechange vrifier que la documentation de mise en production et de configuration existe avant de faire une mise en production

10

3 Gestion des changements

3.1 Ambition, objectifs et objet du processus
3.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : rpondre aux volutions des besoins daffaires des clients tout en maximisant la valeur (des services) et en rduisant les nuisances dues aux incidents, dysfonctionnements et au travail refaire (re-work). rpondre aux demandes de changement des organisations daffaires et de lorganisation informatique qui vont aligner les services sur les besoins daffaires.

3.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectif concret de : sassurer que les changements sont enregistrs puis valus, autoriss, classs par priorit, planifis, tests, implants, documents et revus de manire contrle.

3.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de : sassurer que des mthodes standardises et des procdures sont utilises pour un traitement efficient et rapide de tous les changements. sassurer que tous les changements sur les items de configuration et les actifs de service sont enregistrs dans le systme de gestion des configurations (CMS = Configuration Management System). sassurer que les risques encourus par les affaires sont optimiss de bout en bout.

3.2 Primtre
3.2.1 Ce qui est dans le primtre
Le primtre inclut tout changement sur un service, ce qui veut dire : lajout, la modification ou le retrait dun service ou dun composant de service autoris, planifi ou support, avec la documentation associe.

3.2.2 Ce qui est hors primtre

Aux deux extrmits de lchelle de taille des changements, il y a ce quon appelle communment des changements qui sont hors primtre du processus ITIL : changements ayant un impact beaucoup plus large que les changements de service (tel que dfinis audessus) : ces changements seront grs gnralement au niveau de la direction gnrale et dclencheront des demandes de changement pour les services informatiques impacts dans le projet changements au niveau oprationnel (rparation dimprimantes par ex.) : ces changements seront traits sous la forme dincidents incidents ou dans des procdures dexploitation

3.3 Risques
Voici, au travers des indicateurs de risque suivants, quelques risques pouvant entraner lchec ou de mauvais rsultats sur le fonctionnement du processus : Changements non autoriss (appels aussi changements sauvages ) : une valeur diffrente de zro est inacceptable. Interruptions non planifies Faible taux de succs des changements : une mthodologie dfaillante, absente ou mal applique peut tre lorigine de mauvais rsultats, de mme que des technologies mal matrises Nombre levs de changements urgents : beaucoup de demandeurs arrivent faire passer leurs changements en urgence et lorganisation informatique accepte lurgence de telles demandes Livraison des projets en retard : une mthodologie inexistante ou mal applique ou simplement une charge de travail trop leve sur les quipes de dveloppement par rapport au nombre de ressources sont souvent lorigine de ce symptme

11

3.4 Types de demandes de changement

3.4.1 Dfinition dune demande de changement
Une demande de changement est une communication formelle visant modifier un ou plusieurs lments de configuration. En clair, cest le livrable qui va initier le processus de gestion des changements. Une organisation doit sassurer que les procdures et formulaires appropris couvrent les demandes prvisibles. Il sera moins risqu et plus rapide de traiter de manire procdure des demandes de nature identique plutt que dtudier et de planifier chaque demande de manire individuelle. Mme sil est impratif de traiter tous les changements par le processus et de remplir par consquent une demande pour chaque changement, il reste nammoins impratif dviter une approche bureaucratique sous peine de rejet par les intervenants. Tout lart du propritaire de processus va consister ici mettre en place progressivement les contraintes et le niveau de bureaucratie en prenant en compte le retour dexprience et les avis des intervenants.

3.4.2 Dfinition dun modle de changement

Un modle de changement est une manire de pr-dfinir des tapes suivre pour conduire le processus traiter un type particulier de changement. En clair, il sagit dcrire et de valider une procdure de traitement qui particularise et dtaille les activits du processus pour un type de demande qui arrive de manire frquente. La procdure tant plus dtaille, les acteurs cits dans la procdure doivent respecter la procdure et nont plus se proccuper du processus gnral de gestion des changements. Le traitement de ces demandes particulires reste nammoins sous le contrle du processus de gestion des changements.

3.4.3 Dfinition dun changement standard

Un changement standard est le rsultat de la logique du modle de changement pousse lextrme : il ne passe plus par le processus de gestion des changements. Il sagit, en effet, dun changement dont la procdure de ralisation est connue, matrise et valide. Pour certains types de changement qui reviennent souvent et qui ne sont pas des changements importants, il peut tre intressant de dvelopper une procdure de ralisation, de la valider puis de lappliquer de manire rptitive chaque fois quune demande de ce type de changement est initie. Cest le processus de gestion des changements qui identifie de tels cas et qui dcide de la mise en place de procdures standard de ralisation. A partir du moment o une telle procdure est en place pour un type de changement, ces changements sont dits standard. Pour rsumer, un changement standard sur un service ou une infrastructure possde les caractristiques suivantes : son approche est pr-autorise par la gestion des changements dispose dune procdure reconnue et tablie (prouve) est associ un risque et un impact habituellement faibles les implications budgtaires sont connues Voici quelques exemples de changements standard : linstallation dun poste de travail mise jour dune application avec un impact mineur Lun des points importants prciser dans la procdure standard est lapprobation de la demande. Dans le cas normal, cest le comit consultatif des changements qui est lautorit sur le changement. Pour un changement standard, lautorit est dlgue, par exemple, au client (poste de travail) ou un ingnieur dune tierce partie (remplacement dune imprimante en panne). Ceci restera prciser au niveau de chacune des procdures. Certains changements standard pourront tre traits dans le cadre du processus dexcution des requtes par le centre de services.

3.4.4 Dfinition dun changement urgent

Un changement urgent est un changement implanter aussi rapidement que possible. Les critres dapprciation de lurgence dun changement sont prciser dans le processus de gestion des changements et laisss aussi largement lapprciation des personnes (pas uniquement le demandeur).

12

Dployer un patch de scurit peut tre considr comme un changement urgent si lapplication stricte du processus de gestion des changements implique un dlai de mise en oeuvre trop long par rapport au risque de scurit.

3.4.5 Dfinition dun changement normal

Par complment, un changement normal est un changement qui nest ni standard, ni urgent. Les changements normaux sont donc tous les autres et passent "normalement" par le processus de gestion des changements.

13

3.5 Activits cls

Les points importants retenir sur les activits sont les suivants : Estimer et valuer : dfinition de limpact, de la priorit et de lautorit du changement (rle du processus) Planifier : le rsultat de lactivit est la publication des dates du changement dans les deux livrables : o CS (Change Schedule) : calendrier des changements o PSO (Projected Service Outage) : calendrier des interruptions planifies de service Cette activit doit aussi penser aux plans de retour arrire ! Coordonner : inclut la construction du changement (dveloppement, acquisition) et les tests

3.6 Les 7 R de la gestion des changements

Les 7 R de la gestion des changements sont les suivants : Qui a REQUIS ce changement ? Quelle est la RAISON de ce changement ? Quel est le RETOUR attendu de ce changement ? Quels sont les RISQUES de ce changement ? Quelles sont les ressources ncessaires pour raliser ce changement ? Qui est RESPONSABLE de la construction, des tests et de la mise en production de ce changement ? Quelles RELATIONS existent-ils entre ce changement et les autres ? Une grande partie des rponses ces questions peut tre apporte par linitiateur de la demande au travers du formulaire de demande de changement par exemple. Le reste des rponses doit absolument tre apport avant valuation et estimation du changement. Sans ces informations, la prise de dcision par le comit consultatif des changements devient alatoire en terme de risques et de rsultats.

3.7 Principaux rles et comits du processus

3.7.1 Rle dautorit de changement : les diffrents niveaux
Il existe diffrents niveaux dautorit de changement. Le schma suivant prsente ces diffrents niveaux (ce schma doit tre adapt lorganisation dans lequel le processus est prvu dtre mis en place), y compris les deux extrmes qui sont hors primtre du processus de gestion des changements :

14

3.7.2 Rle de gestionnaire des changements

Ce rle est associe une personne prcise dans lorganisation et ce rle gre la totalit des changements. Il a les caractristiques suivantes : il est gestionnaire du processus de gestion des changements il est lautorit sur les changements il se fait conseiller par le comit consultatif des changements (CAB) pour lvaluation, la priorisation et la planification des changements (do probablement ladjectif consultatif pour le CAB car le CAB conseille le gestionnaire des changements mais cest ce dernier qui a le dernier mot) il prside les runions du CAB

3.7.3 Comit consultatif des changements (CAB ou Change Advisory Board)

Il est habituellement constitu de reprsentants : de tous les domaines du fournisseur de services du business (organisations daffaires) tierces parties comme les fournisseurs externes

3.7.4 Comit consultatif des changements urgents (ECAB ou Emergency Change Advisory Board)
Il sagit dun sous-ensemble du CAB qui prend les dcisions concernant les changements urgents.

15

4 Evaluation (des changements)

4.1 Ambition, objectifs et objet du processus
4.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : tablir correctement les attentes de toutes les parties concernes (par une demande de changement) fournir des informations compltes et fiables la gestion des changements pour tre sr quun futur service qui perturbera les services en production et introduira des risques ne soit pas trait sans validation.

4.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectifs concrets de : valuer les effets voulus dun changement et, dans une mesure raisonnable compte-tenu des contraintes de capacit, de ressources et dorganisation, les effets ngatifs potentiels. fournir des rsultats de bonne qualit afin que la gestion des changements puisse prendre la dcision dapprouver ou non le changement en tout connaissance de cause.

4.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de : fournir des moyens standardiss et pertinents de dterminer la performance dun changement dans le contexte actuel des services et de linfrastructure ainsi que dans ce qui sera mis en place dans le cadre de ce changement.

16

5 Validation et tests de services

5.1 Ambition, objectifs et objet du processus
5.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : sassurer quun futur service fournira de la valeur aux clients et la gestion des affaires.

5.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectifs concrets de : fournir la preuve quun package dinstallation mettra en place un nouveau service ou un service modifi qui dlivrera les rsultats et la valeur attendus par les clients dans les cots, les capacits et la suppression des contraintes tels que prvus. valider quun service est adapt au besoin : il dlivrera la performance requise avec la suppression des contraintes identifies. sassurer quun service est adapt lusage : il rpond aux spcifications demandes dans des termes et des conditions dutilisation donns. confirmer que les besoins des clients et des parties prenantes pour le futur service ont t correctement dfinis et remdier prcocment toutes les erreurs et variations dans le cycle de vie du service (il est considrablement moins cher dintervenir en amont par rapport la correction des erreurs en production).

5.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de : planifier et implanter un processus structur de test et de validation permettant dapporter la preuve objective que le futur service supportera les exigences daffaires des clients et des parties prenantes, incluant les niveaux de service. sassurer par la qualit un package dinstallation, ses constituants, le service rsultant et son aptitude pour chaque mise en production. identifier, valuer et traiter les difficults, les erreurs et les risques au travers de la transition des services.

17

6 Gestion des dploiements et des mises en production

6.1 Ambition, objectifs et objet du processus
6.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : dployer les packages dinstallation en production et de faire fonctionner correctement le service de manire dlivrer de la valeur au client et tre capable de passer le relai lexploitation des services.

6.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectifs concrets : sassurer quil y a des calendriers clairs et comprhensibles de dploiement et dinstallation pour permettre aux projets de changements daffaires et clients daligner leurs activits sur ces calendriers. sassurer quun package dinstallation peut tre construit, install, test et dploy efficacement sur un groupe de configurations ou un environnement cible avec succs et dans le respect du calendrier prvu. sassurer quun nouveau service ou un service modifi et ses systmes, technologies et organisations impacts sont capables de rpondre aux exigences du service, cest--dire son utilit, ses garanties et niveaux de service. sassurer de minimiser les impacts imprvus sur les services en production et les organisations dexploitation et de support. sassurer que les clients, les utilisateurs et les quipes informatiques impliqus dans la gestion des services sont satisfaits des pratiques de la transition des services et des rsultats quelle produit (cest-dire la documentation utilisateur et la formation).

6.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de : dfinir et de valider les plans de dploiement et dinstallation avec les clients et les parties prenantes. sassurer que chaque package dinstallation est constitu dun ensemble de composants de service et dactifs associs qui soient compatibles chacun avec les autres. sassurer que lintgrit dun package dinstallation et de ses composants est conserve tout au long des activits de la transition des services et trace correctement dans le systme de gestion des configurations (CMS). sassurer que tous les packages dinstallation et de dploiement peuvent tre tracs, installs, tests, vrifis et/ou dsinstalls ou restaurs en cas de besoin. sassurer que les changements concernant lorganisation et les parties prenantes pendant les activits de dploiement et dinstallation sont grs. enregistrer et grer les carts, les risques, les difficults crs par un nouveau service ou un service modifi et prendre les actions correctives ncessaires. sassurer du transfert de connaissances pour permettre aux utilisateurs et clients doptimiser leur utilisation du service afin de suppporter au mieux leurs activits daffaires. sassurer que les comptences et la connaissance sont transfres aux quipes dexploitation et de support pour leur permettre de fournir, supporter et maintenir le service conformment aux garanties et niveaux de service prvus.

6.2 Termes utiliss dans le processus

6.2.1 Unit de mise en production
Une unit de mise en production dcrit les parties dun service ou de linfrastructure informatique sont normalement livres ensemble selon la politique des mises en production.

6.2.2 Options de mise en production

Les trois options de mise en production cits dans le processus sont les suivants : approche big bang ou chelonne pousse (push) ou traction (pull) automatise ou manuelle

18

6.2.3 Modle de mise en production et de dploiement

Comme pour le modle de changement, le modle de mise en production et de dploiement est une spcialisation du processus sur certains types courants de mises en production et de dploiements. Il sagit, pour chacun de ces types courants, de dtailler le processus sous la forme de procdures et de documents standard que lon utilisera en lieu et place du processus dans le cas appropri. Cette approche prpare la mise en place doutils de flux de traitement (workflow). Un modle de mise en production et de dploiement possde les caractristiques suivantes : structure de mise en production : structure-type du package et des environnements cibles livrables obligatoires et facultatifs pour chaque tape environnements contrls de construction et de tests rles et responsabilits pour chaque tape lavancement-type dune mise en production et des configurations modles-types de calendrier de mise en production et de dploiement systmes, outils et procdures en soutien activits de transfert de responsabilits chaque tape de mise en production et de dploiement

6.3 Activits cls

6.3.1 Planifier
Cette activit consiste dfinir les lments suivants : plans de mise en production et de dploiement intgrer dans le plan global de transition des services critres de Go/NoGo construction et tests pralables la mise en production planification des pilotes planification des packages de mises en production et de leurs constructions planification du dploiement planification de la logistique et de la fourniture planification financire/commerciale

6.3.2 Prparer pour la construction, les tests et le dploiement

Cette activit consiste : planifier les ressources lancer les actions de formation

6.3.3 Construction et tests

Cette activit possde un volet de fond et un volet drouler chaque mise en production et dploiement : laborer les procdures de construction et de tests acqurir et tester les composants les plus fiables possibles fabriquer de manire standard le package de mise en production laborer et grer les environnements de tests drouler les plans de tests et superviser les pilotes de service effectuer des rptitions de service (simulation la plus raliste possible)

6.3.4 Planifier et se prparer au dploiement

Cette activit consiste conduire les actions suivantes : valuer ultimement (une dernire fois) avant dploiement par le groupe de dploiement dvelopper les plans et prparer le dploiement

6.3.5 Excuter le transfert, le dploiement et le retrait

Cette activit consiste conduire les actions suivantes : transfrer les actifs financiers vrifier la synchronisation avec la transition du business et de lorganisation dployer les processus et les supports (documentations) dployer des moyens transfrer/dployer le service supprimer les actifs redondants

19

6.3.6 Vrifier le dploiement 6.3.7 Conduire le support de dbut de vie (ELS ou Early-Life Support)
Le support de dbut de vie est une situation intermdiaire avant lexploitation effective. Cette tape permet aux ressources de dploiement contribuer la stabilisation du service.

6.3.8 Passer en revue et terminer un dploiement

Il faut vrifier, entre autres, lenregistrement correct et exhaustif des problmes et erreurs connues rencontres lors de ce changement (pour utilisation ultrieure, par ex. pour le support incidents).

6.3.9 Passer en revue et clturer la transition du service

Cette activit qui termine le processus permet de : vrifier que toutes les activits de transition sont termines vrifier que des mtriques fiables sont en place

20

7 Gestion des connaissances

7.1 Ambition, objectifs et objet du processus
7.1.1 Ambition (goals) du processus
Lambition du processus au sein de la gestion des services est de : sassurer que la bonne information est dlivre au bon endroit ou la bonne personne, au bon moment pour permettre des dcisions claires.

7.1.2 Objectifs (objective) du processus

Pour raliser cette ambition, le processus a pour objectif concret de : permettre aux organisations damliorer la qualit des prises de dcision en sassurant que les donnes et informations fiables et scurises soient disponibles tout au long du cycle de vie des services.

7.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de : permettre au fournisseur de services dtre plus efficace et amliorer la qualit de service, augmenter la satisfaction et rduire les cots du service. sassurer que les quipes ont une comprhension claire et commune de la valeur apporte par les services quils fournissent aux clients et de la manire dont des bnfices sont raliss par lutilisation de ces services. sassurer que, un endroit et un moment donns, les quipes du fournisseur de services ont les informations adquates sur : o qui utilise actuellement leurs services o les niveaux actuels de consommation o les contraintes de la fourniture des services o les difficults rencontres par les clients en essayant de raliser tous les bnfices prvus de lutilisation des services.

7.2 Concept-cl : Donnes-> InformatIon -> Connaissance -> Sagesse

21

La connaissance sur les services passe par les tapes classiques suivantes :

7.2.1 Donne
Une donne est le rsultat direct dune mesure. Elle peut tre collecte par un outil de supervision, par une personne ou tre dj prsente dans une base de donnes par ex. Une donne seule ne permet pas de prendre une dcision sur une action lancer. Par exemple, pour le mois dernier, les donnes suivantes ont t releves : 1 217 incidents enregistrs au centre de services 98 changements ont t mis en production Pour tre complet, le mois prcdent, la donne suivante a t enregistre : 10 nouveaux prestataires employs la direction informatique Le raisonnement bas sur ces donnes est volontairement trs simplifi (peut-tre trop certaines tapes).

7.2.2 Information
Une information est une donne laquelle un sens et une interprtation ont t donns. Une information permet un responsable oprationnel de prendre une dcision (dchelle locale ou petite chelle) sur une action mener. Par exemple, les donnes prcdentes sont interprtes de la manire suivante : augmentation de 240 % du nombre dincidents par rapport au mois prcdent augmentation de 15 % du nombre de changements mis en production par rapport au mois prcdent lemploi des 10 prestataires supplmentaires le mois prcdent est li une augmentation temporaire de la charge de travail dintgration, de test et de mise en production dune refonte du systme dinformation Le responsable du centre de services peut dcider de prendre un prestataire supplmentaire en renfort ( condition quil ait le budget videmment) pour absorber la charge supplmentaire qui ne semble pas diminuer. Le responsable des mises en production peut, en premire analyse, conclure que laugmentation importante du nombre dincidents nest pas lie la mise en production des changements, tant donn la faible augmentation du nombre de changements mis en production pendant la mme priode.

7.2.3 Connaissance
La connaissance est le rsultat dune rflexion sur les informations analyses en se basant sur : ses expriences, ses ides, ses valeurs, les avis dautres personnes consultes pour loccasion sa propre expertise et celle de ses pairs La connaissance permet aux responsables de confronter les informations au contexte de lorganisation et dautres contextes externes lorganisation afin davoir une meilleure connaissance et une interprtation largie des phnomnes mis en lumire par ces informations. Les dcisions prises ce niveau seront dchelle intermdiaire ( un niveau tactique par ex.). Le responsable portant le rle de gestionnaire des changements peut tablir une corrlation entre larrive des nouveaux prestataires et laugmentation des incidents en ayant connaissance des lments suivants : en raison de lurgence (elle-mme lie limportance des retards dans les mises en production du nouveau systme dinformation), la dizaine de prestataires a t forme en une demi-journe au fonctionnement de lorganisation informatique, certainement trop rapidement sur lintrt et lobligation de respecter le processus de gestion des changements le responsable des mises en production nest pas forcment en phase avec son quipe (ceux qui ralisent les mises en production sur le terrain) aprs discussion avec quelques techniciens ralisant les mises en production, il savre une dgradation importante de la qualit des livraisons et, compte-tenu de lurgence, certains contrles ne sont plus pris en compte voire raliss, laissant partir en production des kits dinstallation de moindre qualit et fiabilit une discussion rapide avec un consultant ITIL apporte un lment nouveau : le succs du processus de gestion des changements est aussi li un taux de changements sauvages trs faible La connaissance de ces lments (entre autres) permet dapporter une interprtation largie du phnomne constat : laugmentation trs importante du nombre dincidents sur la priode est trs probablement lie laugmentation trs importante du nombre de changements sauvages raliss par les nouveaux prestataires forms trop rapidement aux processus en vigueur lorganisation informatique. Ces changements sauvages sont, par essence, indtectables par les indicateurs de performance du processus de gestion des changements. Sil stait content de son tableau de bord sur les indicateurs de performance (qui restent un niveau correct), le gestionnaire des changements serait pass ct de lexplication de lexplosion du nombre dincidents et ne se serait pas remis en question alors quil est lorigine du problme.

22

Lattitude qui consiste se contenter du paradigme de son tableau de bord nest pas la bonne. Il faut largir ce paradigme en intgrant toute la connaissance ncessaire pour avoir du recul sur son tableau de bord. Parmi les dcisions prendre pour corriger le tir, il y a un contrle plus important des activits ralises par les prestataires et une action de formation plus longue. Certains prestataires, agissant trop en franc-tireur sans se proccuper des consquences de leurs actes techniques, peuvent aussi tre remplacs par dautres.

7.2.4 Sagesse
Cette tape ultime de la dmarche permet : daboutir un tat desprit gnral de discernement final sur le contenu (informations, connaissances) et de jugement de bon sens, de sadapter de nouvelles situations et de lancer les actions dadaptation de lorganisation, des personnes, des processus et des outils et, au final, de provoquer des changements de cap de lorganisation afin danticiper les grands changements venir et lvolution dun domaine Cette facult est rencontre chez les responsables seniors de lorganisation ainsi que chez le responsable de lorganisation informatique. Elle permet de prendre des dcisions long terme et des dcisions stratgiques pour lorganisation informatique.

7.3 Exemple de systme de gestion de connaissances des services (SKMS)

23