Vous êtes sur la page 1sur 23

ITIL V3 Les processus de la transition des services

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

A propos

Création : janvier 2008 Mise à jour : juin 2013 A propos A propos du

A propos du document

Ce document de référence sur le référentiel ITIL V3 a été réalisé 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 référentiel. 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 oeuvre 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

Création : janvier 2008 Mise à jour : juin 2013 A propos A propos du

A propos de mission et de formation

Si vous pensez que l’expérience de l’auteur sur le référentiel 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, 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

2

Table des matières

  • 1 Planification et support à la transition

................................................................................................

6

1.1

Ambition, objectifs et

 

objet du processus

6

1.1.1

Ambition (goals)

du

processus

6

1.1.2

Objectifs (objective)

du

6

1.1.3

Objet (purpose) du processus

 

6

  • 2 Gestion des configurations et des actifs de service

7

2.1

Ambition, objectifs et

 

objet du processus

7

2.1.1

Ambition (goals)

du

processus

7

2.1.2

Objectifs (objective)

du

7

2.1.3

Objet (purpose) du processus

 

7

2.2

Modèle de configuration

 

7

2.3

8

 

2.3.1

Elément

de

configuration (CI ou Configuration Item)

8

2.3.2

Système de gestion des configurations (CMS ou Configuration Management System)

8

2.3.3

Bibliothèque des supports définitifs (DML ou Definitive Media Library)

8

2.3.4

Configuration de référence (configuration baseline)

9

2.4

Activités

9

2.4.1

Gérer et planifier

 

10

2.4.2

Identifier les

configurations

 

10

2.4.3

Contrôler les configurations

10

2.4.4

Historiser et générer des rapports sur les états des CIs

10

2.4.5

Vérifier et auditer

 

10

  • 3 Gestion des changements

 

11

3.1

Ambition, objectifs et

objet du processus

11

3.1.1

Ambition (goals)

du

processus

11

3.1.2

Objectifs (objective)

du

11

3.1.3

Objet (purpose) du processus

11

3.2

Périmètre

11

3.2.1

Ce qui est dans le périmètre

11

3.2.2

Ce

qui

est

hors périmètre

11

3.3

Risques

11

3.4

Types de demandes de changement

..........................................................................................

12

3.4.1

Définition d’une demande de changement

12

3.4.2

Définition d’un modèle de

 

12

3.4.3

Définition d’un changement standard

12

3

  • 3.4.4 Définition d’un changement urgent

 

12

  • 3.4.5 Définition d’un changement

13

  • 3.5 Activités clés

............................................................................................................................

14

  • 3.6 Les 7 « R » de la gestion des changements

 

14

  • 3.7 Principaux rôles et comités du processus

..................................................................................

14

  • 3.7.1 Rôle d’autorité de changement : les différents niveaux

14

  • 3.7.2 Rôle de gestionnaire des changements

...............................................................................

15

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

15

  • 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

  • 4.1.1 Ambition (goals)

du

processus

16

  • 4.1.2 Objectifs (objective)

du

16

  • 4.1.3 Objet (purpose) du processus

 

16

  • 5 Validation et tests de

 

17

  • 5.1 Ambition, objectifs et

objet du processus

 

17

  • 5.1.1 Ambition (goals)

du

processus

17

  • 5.1.2 Objectifs (objective)

du

17

  • 5.1.3 Objet (purpose) du processus

 

17

  • 6 Gestion des déploiements et des mises en production

18

  • 6.1 Ambition, objectifs et

objet du processus

 

18

  • 6.1.1 Ambition (goals)

du

processus

18

  • 6.1.2 Objectifs (objective)

du

18

  • 6.1.3 Objet (purpose)

du processus

 

18

  • 6.2 Termes utilisés dans le processus

18

  • 6.2.1 Unité de mise en production

18

  • 6.2.2 Options de mise en

 

18

  • 6.2.3 Modèle de mise en production et de déploiement

19

  • 6.3 Activités clés

 

19

  • 6.3.1 Planifier.............................................................................................................................

19

  • 6.3.2 Préparer pour la construction, les tests et le déploiement

19

  • 6.3.3 Construction et tests

..........................................................................................................

19

  • 6.3.4 Planifier et se préparer au déploiement

 

19

  • 6.3.5 Exécuter le transfert, le déploiement et le retrait

19

  • 6.3.6 Vérifier le déploiement

 

20

4

  • 6.3.7 Conduire le support de début de vie (ELS ou Early-Life Support)

20

  • 6.3.8 Passer en revue et terminer un déploiement

.......................................................................

20

  • 6.3.9 Passer en revue et clôturer la transition du service

20

7

Gestion des connaissances

21

  • 7.1 Ambition, objectifs et

objet du processus

 

21

  • 7.1.1 Ambition (goals)

du

processus

21

  • 7.1.2 Objectifs (objective)

du

21

  • 7.1.3 Objet (purpose) du processus

 

21

  • 7.2 Concept-clé : Données-> InformatIon -> Connaissance -> Sagesse

21

Donnée

  • 7.2.1 ..............................................................................................................................

22

Information

  • 7.2.2 .......................................................................................................................

22

Connaissance

  • 7.2.3 .....................................................................................................................

22

  • 7.2.4 ..............................................................................................................................

Sagesse

23

  • 7.3 Exemple de système de gestion de connaissances des services (SKMS)

23

5

  • 1 Planification et support à la transition

    • 1.1 Ambition, objectifs et objet du processus

      • 1.1.1 Ambition (goals) du processus

L’ambition du processus au sein de la gestion des services est de :

planifier et coordonner les ressources pour s’assurer que les exigences de la stratégie des services appliquées dans la conception des services pour concevoir une approche globale sont effectivement respectées dans l’exploitation des services. identifier, gérer et contrôler les risques de dysfonctionnements des activités de transition.

  • 1.1.2 Objectifs (objective) du processus

Pour réaliser cette ambition, le processus a pour objectifs concrets de :

planifier et coordonner les ressources pour réussir la mise en oeuvre d’un service nouveau ou modifié dans les estimations prévues de coûts, de qualité et de délai s’assurer que toutes les parties adoptent un cadre de référence commun de processus et de systèmes afin d’améliorer l’efficacité et l’efficience des activités de planification et de coordination fournir des plans clairs et complets qui permettent aux clients et aux projets de changement business d’aligner leurs activités 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é appropriées pour fabriquer les packages d’installation, intégrer, livrer, tester, déployer 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 manière à assurer que l’intégrité de tous les actifs clients, actifs de service et configurations puisse être maintenue tout au long de la transition du service.

s’assurer

que

tous les écarts,

risques et

difficultés de la transition des services sont

signalés aux

décisionnaires et parties prenantes appropriés. coordonner les activités dans les projets, les interventions fournisseurs et les équipes internes quand cela s’avère nécessaire.

6

  • 2 Gestion des configurations et des actifs de service

    • 2.1 Ambition, objectifs et objet du processus

      • 2.1.1 Ambition (goals) du processus

L’ambition du processus au sein de la gestion des services est de :

supporter les besoins et objectifs de contrôle 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 décisions au bon moment (c’est-à-dire pour autoriser changements et déploiements, pour résoudre plus rapidement incidents et problèmes). minimiser le nombre de difficultés portant sur la qualité et la conformité causées par des configurations incorrectes de services et d’actifs. optimiser les actifs de service, les configurations techniques (IT configurations), les aptitudes et les ressources.

  • 2.1.2 Objectifs (objective) du processus

Pour réaliser cette ambition, le processus a pour objectif concret de :

définir et contrôler les composants des services et de l’infrastructure maintenir à jour les informations de configuration sur les services et l’infrastructure actuels et prévus, 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, contrôler, enregistrer, réaliser les comptes-rendus, auditer et vérifier les items de configuration et les actifs de service, comprenant les versions, les bases de référence (baselines), les sous-composants, leurs attributs et liens entre eux. avoir l’autorité sur, gérer et protéger l’intégrité 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 s’assurant que seuls les composants autorisés sont utilisés et que seuls les changements autorisés sont mis en oeuvre.

s’assurer

de l’intégrité des configurations et

des

actifs nécessaire pour contrôler les services et

l’infrastructure des TI en mettant en place et en utilisant un système complet de gestion des configurations (CMS = Configuration Management System).

  • 2.2 Modèle de configuration

Le modèle de configuration est le résultat de la modélisation :

des services, des actifs et de l’infrastructure des relations entre ces éléments de configuration (CI ou Configuration Item) C’est LE modèle utilisée par tous les acteurs du fournisseur de services : internes et sous-traitants.

7

2.3 Définitions 2.3.1 Elément de configuration (CI ou Configuration Item ) C’est un actif, un

2.3

Définitions

  • 2.3.1 Elément de configuration (CI ou Configuration Item)

C’est un actif, un composant de service et, plus globalement, tout élément qui sera sous le contrôle de la gestion des configurations :

service d’affaires, service technique, système complet, matériels, logiciels, documentations, équipes de support, etc.

  • 2.3.2 Système de gestion des configurations (CMS ou Configuration Management System)

Il s’agit du système de gestion (application, outil logiciel, etc.) de la CMDB (Configuration Management DataBase) qui contient toutes les informations sur les CIs (Configuration Item). C’est un concept pouvant englober plusieurs bases de données ou référentiels physiques.

  • 2.3.3 Bibliothèque des supports définitifs (DML ou Definitive Media Library)

Il s’agit d’un stockage sécurisé des versions définitives autorisées (media des versions logicielles) ayant passé les contrôles d’assurance qualité. Par extension et facilité d’utilisation, elle comprend aussi tous les fichiers utiles au moment de l’installation d’un logiciel :

clé de licence (d’où l’importance du mot "sécurisé" dans la définition) documentation, etc. Elle constitue une base pour la gestion des mises en production et des déploiements et l’un des éléments en entrée des plus importants.

8

2.3.4 Configuration de référence ( configuration baseline ) Il s’agit d’une configuration d’un service, d’un
  • 2.3.4 Configuration de référence (configuration baseline)

Il s’agit d’une configuration d’un service, d’un produit, d’une infrastructure validée servant de base à d’autres activités. Pour être plus clair, une configuration de référence peut être assimilée à une « photographie » d’une partie de la CMDB conservée comme référence et utilisée pour comparaison avec des situations ultérieures de la CMDB (évolutions liées à des mises en production par ex.). La configuration de référence contient un ensemble d’éléments de configuration et leurs relations. Elle sera utilisée par ex. pour effectuer un retour arrière après une mise en production en échec.

2.4

Activités

2.3.4 Configuration de référence ( configuration baseline ) Il s’agit d’une configuration d’un service, d’un

9

  • 2.4.1 Gérer et planifier

Cette activité consiste à élaborer le processus et définir les ressources qui travailleront dans le processus. Cette activité ne fait pas réellement partie du processus car il s’agit pour le propriétaire de processus de définir et de formaliser son processus et de mettre en place les moyens nécessaires pour que le processus qui sera mis en place puisse effectivement remplir ses objectifs.

  • 2.4.2 Identifier les configurations

Il s’agit, pour un périmètre donné de la CMDB, de formaliser :

l’identification des structures de configuration et de leurs inter-relations la sélection des CIs leur nommage leur étiquetage la définition de leurs attributs la définition de la documentation de configuration la définition des types d’éléments de configuration l’identification des bibliothèques de support l’identification des configurations de référence l’identification des unités de mise en production

Cette activité est à faire une première puis de manière récurrente :

pour étendre le périmètre de la CMDB à de nouveaux types d’éléments non contrôlés jusqu’à présent (approche par phase de la CMDB) pour reprendre, modifier ou descendre à un niveau de détail plus fin toute partie existante de la CMDB (approche itérative de la CMDB)

  • 2.4.3 Contrôler les configurations

Le principe à faire respecter est clair : aucun CI ne doit être ajouté, modifié, remplacé ou enlevé sans suivre une procédure de contrôle appropriée. Pour cela, il faut définir les procédures de mises à jour des CIs qui soient efficaces et utilisables par les différents acteurs du fournisseur de services.

  • 2.4.4 Historiser et générer des rapports sur les états des CIs

2.4.1 Gérer et planifier Cette activité consiste à élaborer le processus et définir les ressources

Cette activité consiste à définir formellement le changement d’état des CIs fournir les données historiques et actuelles concernant chaque CI

  • 2.4.5 Vérifier et auditer

Cette activité consiste à s’assurer qu’il

y

a

conformité

entre

les

bases

de

réference

documentées

(par

ex.

accords)

et

l’environnement d’affaires réel vérifier l’existence physique des CIs en production, dans la DML et les stocks de pièces de rechange vérifier 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

L’ambition du processus au sein de la gestion des services est de :

répondre aux évolutions des besoins d’affaires des clients tout en maximisant la valeur (des services) et en réduisant les nuisances dues aux incidents, dysfonctionnements et au travail à refaire (re-work). répondre aux demandes de changement des organisations d’affaires et de l’organisation informatique qui vont aligner les services sur les besoins d’affaires.

  • 3.1.2 Objectifs (objective) du processus

Pour réaliser cette ambition, le processus a pour objectif concret de :

s’assurer que les changements sont enregistrés puis évalués, autorisés, classés par priorité, planifiés, testés, implantés, documentés et revus de manière contrôlée.

  • 3.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de :

s’assurer que des méthodes standardisées et des procédures sont utilisées pour un traitement efficient et rapide de tous les changements.

s’assurer que tous les changements sur les items de configuration et les actifs de service sont enregistrés dans le système de gestion des configurations (CMS = Configuration Management System).

s’assurer que les risques encourus par les affaires sont optimisés de bout en bout.

  • 3.2 Périmètre

    • 3.2.1 Ce qui est dans le périmètre

Le périmètre inclut tout changement sur un service, ce qui veut dire : l’ajout, la modification ou le retrait d’un service ou d’un composant de service autorisé, planifié ou supporté, avec la documentation associée.

  • 3.2.2 Ce qui est hors périmètre

Aux deux extrémités de l’échelle de taille des changements, il y a ce qu’on appelle communément des changements qui sont hors périmètre du processus ITIL :

« changements » ayant un impact beaucoup plus large que les changements de service (tel que définis au- dessus) : ces « changements » seront gérés généralement au niveau de la direction générale et déclencheront des demandes de changement pour les services informatiques impactés dans le projet « changements » au niveau opérationnel (réparation d’imprimantes par ex.) : ces « changements » seront traités sous la forme d’incidents incidents ou dans des procédures d’exploitation

  • 3.3 Risques

Voici, au travers des indicateurs de risque suivants, quelques risques pouvant entraîner l’échec ou de mauvais résultats sur le fonctionnement du processus :

Changements non autorisés (appelés aussi « changements sauvages ») : une valeur différente de zéro est inacceptable. Interruptions non planifiées Faible taux de succès des changements : une méthodologie défaillante, absente ou mal appliquée peut être à l’origine de mauvais résultats, de même que des technologies mal maîtrisées Nombre élevés de changements urgents : beaucoup de demandeurs arrivent à faire passer leurs changements en urgence et l’organisation informatique accepte l’urgence de telles demandes Livraison des projets en retard : une méthodologie inexistante ou mal appliquée ou simplement une charge de travail trop élevée sur les équipes de développement par rapport au nombre de ressources sont souvent à l’origine de ce symptôme

11

  • 3.4 Types de demandes de changement

    • 3.4.1 Définition d’une demande de changement

Une demande de changement est une communication formelle visant à modifier un ou plusieurs éléments de configuration. En clair, c’est le livrable qui va initier le processus de gestion des changements. Une organisation doit s’assurer que les procédures et formulaires appropriés couvrent les demandes prévisibles. Il sera moins risqué et plus rapide de traiter de manière procédurée des demandes de nature identique plutôt que d’étudier et de planifier chaque demande de manière individuelle. Même s’il est impératif de traiter tous les changements par le processus et de remplir par conséquent une demande pour chaque changement, il reste néammoins impératif d’éviter une approche bureaucratique sous peine de rejet par les intervenants. Tout l’art du propriétaire de processus va consister ici à mettre en place progressivement les contraintes et le niveau de bureaucratie en prenant en compte le retour d’expérience et les avis des intervenants.

  • 3.4.2 Définition d’un modèle de changement

Un modèle de changement est une manière de pré-définir des étapes à suivre pour conduire le processus à traiter un type particulier de changement. En clair, il s’agit d’écrire et de valider une procédure de traitement qui particularise et détaille les activités du processus pour un type de demande qui arrive de manière fréquente. La procédure étant plus détaillée, les acteurs cités dans la procédure doivent respecter la procédure et n’ont plus à se préoccuper du processus général de gestion des changements. Le traitement de ces demandes particulières reste néammoins sous le contrôle du processus de gestion des changements.

  • 3.4.3 Définition d’un changement standard

Un changement standard est le résultat de la logique du modèle de changement poussée à l’extrême : il ne passe plus par le processus de gestion des changements. Il s’agit, en effet, d’un changement dont la procédure de réalisation est connue, maîtrisée et validée. Pour certains types de changement qui reviennent souvent et qui ne sont pas des changements importants, il peut être intéressant de développer une procédure de réalisation, de la valider puis de l’appliquer de manière répétitive à chaque fois qu’une demande de ce type de changement est initiée. C’est le processus de gestion des changements qui identifie de tels cas et qui décide de la mise en place de procédures standard de réalisation. A partir du moment où une telle procédure est en place pour un type de changement, ces changements sont dits standard. Pour résumer, un changement standard sur un service ou une infrastructure possède les caractéristiques suivantes :

son approche est pré-autorisée par la gestion des changements dispose d’une procédure reconnue et établie (éprouvée) est associé à un risque et un impact habituellement faibles les implications budgétaires sont connues Voici quelques exemples de changements standard :

l’installation d’un poste de travail mise à jour d’une application avec un impact mineur L’un des points importants à préciser dans la procédure standard est l’approbation de la demande. Dans le cas normal, c’est le comité consultatif des changements qui est l’autorité sur le changement. Pour un changement standard, l’autorité est déléguée, par exemple, au client (poste de travail) ou à un ingénieur d’une tierce partie (remplacement d’une imprimante en panne). Ceci restera à préciser au niveau de chacune des procédures. Certains changements standard pourront être traités dans le cadre du processus d’exécution des requêtes par le centre de services.

  • 3.4.4 Définition d’un changement urgent

Un changement urgent est un changement à implanter aussi rapidement que possible. Les critères d’appréciation de l’urgence d’un changement sont à préciser dans le processus de gestion des changements et laissés aussi largement à l’appréciation des personnes (pas uniquement le demandeur).

12

Déployer un patch de sécurité peut être considéré comme un changement urgent si l’application stricte du processus de gestion des changements implique un délai de mise en oeuvre trop long par rapport au risque de sécurité.

  • 3.4.5 Définition d’un changement normal

Par complément, un changement normal est un changement qui n’est 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 Activités clés

3.5 Activités clés Les points importants à retenir sur les activités sont les suivants :

Les points importants à retenir sur les activités sont les suivants :

Estimer et évaluer : définition de l’impact, de la priorité et de l’autorité du changement (rôle du processus) Planifier : le résultat de l’activité est la publication des dates du changement dans les deux livrables :

o

CS (Change Schedule) : calendrier des

o

changements PSO (Projected Service Outage) :

calendrier des interruptions planifiées de service Cette activité doit aussi penser aux plans de retour arrière ! Coordonner : inclut la construction du changement (développement, 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 nécessaires pour réaliser 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 réponses à ces questions peut être apportée par l’initiateur de la demande au travers du formulaire de demande de changement par exemple. Le reste des réponses doit absolument être apporté avant évaluation et estimation du changement. Sans ces informations, la prise de décision par le comité consultatif des changements devient aléatoire en terme de risques et de résultats.

  • 3.7 Principaux rôles et comités du processus

    • 3.7.1 Rôle d’autorité de changement : les différents niveaux

Il existe différents niveaux d’autorité de changement. Le schéma suivant présente ces différents niveaux (ce schéma doit être adapté à l’organisation dans lequel le processus est prévu d’être mis en place), y compris les deux extrêmes qui sont hors périmètre du processus de gestion des changements :

14

3.7.2 Rôle de gestionnaire des changements Ce rôle est associée à une personne précise dans
  • 3.7.2 Rôle de gestionnaire des changements

Ce rôle est associée à une personne précise dans l’organisation et ce rôle gère la totalité des changements. Il a les caractéristiques suivantes :

il est gestionnaire du processus de gestion des changements il est l’autorité sur les changements il se fait conseiller par le comité consultatif des changements (CAB) pour l’évaluation, la priorisation et la planification des changements (d’où probablement l’adjectif consultatif pour le CAB car le CAB conseille le gestionnaire des changements mais c’est ce dernier qui a le dernier mot) il préside les réunions du CAB

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

Il est habituellement constitué de représentants :

de tous les domaines du fournisseur de services du business (organisations d’affaires) tierces parties comme les fournisseurs externes

  • 3.7.4 Comité consultatif des changements urgents (ECAB ou Emergency Change Advisory Board)

Il s’agit d’un sous-ensemble du CAB qui prend les décisions concernant les changements urgents.

15

  • 4 Evaluation (des changements)

    • 4.1 Ambition, objectifs et objet du processus

      • 4.1.1 Ambition (goals) du processus

L’ambition du processus au sein de la gestion des services est de :

établir correctement les attentes de toutes les parties concernées (par une demande de changement)

fournir des informations complètes et fiables à la gestion des changements pour être sûr qu’un 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 réaliser cette ambition, le processus a pour objectifs concrets de :

évaluer les effets voulus d’un changement et, dans une mesure raisonnable compte-tenu des contraintes de capacité, de ressources et d’organisation, les effets négatifs potentiels. fournir des résultats de bonne qualité afin que la gestion des changements puisse prendre la décision d’approuver 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 standardisés et pertinents de déterminer la performance d’un changement dans le contexte actuel des services et de l’infrastructure 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

L’ambition du processus au sein de la gestion des services est de :

s’assurer qu’un futur service fournira de la valeur aux clients et à la gestion des affaires.

  • 5.1.2 Objectifs (objective) du processus

Pour réaliser cette ambition, le processus a pour objectifs concrets de :

fournir la preuve qu’un package d’installation mettra en place un nouveau service ou un service modifié qui délivrera les résultats et la valeur attendus par les clients dans les coûts, les capacités et la suppression des contraintes tels que prévus. valider qu’un service est adapté au besoin : il délivrera la performance requise avec la suppression des contraintes identifiées. s’assurer qu’un service est adapté à l’usage : il répond aux spécifications demandées dans des termes et des conditions d’utilisation donnés. confirmer que les besoins des clients et des parties prenantes pour le futur service ont été correctement définis et remédier précocément à toutes les erreurs et variations dans le cycle de vie du service (il est considérablement moins cher d’intervenir 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 d’apporter la preuve objective que le futur service supportera les exigences d’affaires des clients et des parties prenantes, incluant les niveaux de service. s’assurer par la qualité un package d’installation, ses constituants, le service résultant et son aptitude pour chaque mise en production. identifier, évaluer et traiter les difficultés, les erreurs et les risques au travers de la transition des services.

17

  • 6 Gestion des déploiements et des mises en production

    • 6.1 Ambition, objectifs et objet du processus

      • 6.1.1 Ambition (goals) du processus

L’ambition du processus au sein de la gestion des services est de :

déployer les packages d’installation en production et de faire fonctionner correctement le service de manière à délivrer de la valeur au client et à être capable de passer le relai à l’exploitation des services.

  • 6.1.2 Objectifs (objective) du processus

Pour réaliser cette ambition, le processus a pour objectifs concrets :

s’assurer qu’il y a des calendriers clairs et compréhensibles de déploiement et d’installation pour permettre aux projets de changements d’affaires et clients d’aligner leurs activités sur ces calendriers. s’assurer qu’un package d’installation peut être construit, installé, testé et déployé efficacement sur un groupe de configurations ou un environnement cible avec succès et dans le respect du calendrier prévu. s’assurer qu’un nouveau service ou un service modifié et ses systèmes, technologies et organisations impactés sont capables de répondre aux exigences du service, c’est-à-dire son utilité, ses garanties et niveaux de service.

s’assurer de minimiser

les impacts imprévus sur

les services en production et les organisations

d’exploitation et de support. s’assurer que les clients, les utilisateurs et les équipes informatiques impliqués dans la gestion des services sont satisfaits des pratiques de la transition des services et des résultats qu’elle produit (c’est-à- dire la documentation utilisateur et la formation).

  • 6.1.3 Objet (purpose) du processus

Pour atteindre cet objectif, le processus a pour objet de :

définir et de valider les plans de déploiement et d’installation avec les clients et les parties prenantes. s’assurer que chaque package d’installation est constitué d’un ensemble de composants de service et d’actifs associés qui soient compatibles chacun avec les autres. s’assurer que l’intégrité d’un package d’installation et de ses composants est conservée tout au long des activités de la transition des services et tracée correctement dans le système de gestion des configurations (CMS). s’assurer que tous les packages d’installation et de déploiement peuvent être tracés, installés, testés, vérifiés et/ou désinstallés ou restaurés en cas de besoin. s’assurer que les changements concernant l’organisation et les parties prenantes pendant les activités de déploiement et d’installation sont gérés. enregistrer et gérer les écarts, les risques, les difficultés créés par un nouveau service ou un service modifié et prendre les actions correctives nécessaires. s’assurer du transfert de connaissances pour permettre aux utilisateurs et clients d’optimiser leur utilisation du service afin de suppporter au mieux leurs activités d’affaires. s’assurer que les compétences et la connaissance sont transférées aux équipes d’exploitation et de support pour leur permettre de fournir, supporter et maintenir le service conformément aux garanties et niveaux de service prévus.

  • 6.2 Termes utilisés dans le processus

    • 6.2.1 Unité de mise en production

Une unité de mise en production décrit les parties d’un service ou de l’infrastructure informatique sont normalement livrées ensemble selon la politique des mises en production.

  • 6.2.2 Options de mise en production

Les trois options de mise en production cités dans le processus sont les suivants :

approche « big bang » ou échelonnée poussée (push) ou traction (pull) automatisée ou manuelle

18

  • 6.2.3 Modèle de mise en production et de déploiement

Comme pour le modèle de changement, le modèle de mise en production et de déploiement est une spécialisation du processus sur certains types courants de mises en production et de déploiements. Il s’agit, pour chacun de ces types courants, de détailler le processus sous la forme de procédures et de documents standard que l’on utilisera en lieu et place du processus dans le cas approprié. Cette approche prépare la mise en place d’outils de flux de traitement (workflow). Un modèle de mise en production et de déploiement possède les caractéristiques suivantes :

structure de mise en production : structure-type du package et des environnements cibles livrables obligatoires et facultatifs pour chaque étape environnements contrôlés de construction et de tests rôles et responsabilités pour chaque étape l’avancement-type d’une mise en production et des configurations modèles-types de calendrier de mise en production et de déploiement systèmes, outils et procédures en soutien activités de transfert de responsabilités à chaque étape de mise en production et de déploiement

  • 6.3 Activités clés

    • 6.3.1 Planifier

Cette activité consiste à définir les éléments suivants :

plans de mise en production et de déploiement à intégrer dans le plan global de transition des services critères de Go/NoGo construction et tests préalables à la mise en production planification des pilotes planification des packages de mises en production et de leurs constructions planification du déploiement planification de la logistique et de la fourniture planification financière/commerciale

  • 6.3.2 Préparer pour la construction, les tests et le déploiement

Cette activité consiste à :

planifier les ressources lancer les actions de formation

  • 6.3.3 Construction et tests

Cette activité possède un volet de fond et un volet à dérouler à chaque mise en production et déploiement :

élaborer les procédures de construction et de tests acquérir et tester les composants les plus fiables possibles fabriquer de manière standard le package de mise en production élaborer et gérer les environnements de tests dérouler les plans de tests et superviser les pilotes de service effectuer des répétitions de service (simulation la plus réaliste possible)

  • 6.3.4 Planifier et se préparer au déploiement

Cette activité consiste à conduire les actions suivantes :

évaluer ultimement (une dernière fois) avant déploiement par le groupe de déploiement développer les plans et préparer le déploiement

  • 6.3.5 Exécuter le transfert, le déploiement et le retrait

Cette activité consiste à conduire les actions suivantes :

transférer les actifs financiers vérifier la synchronisation avec la transition du business et de l’organisation déployer les processus et les supports (documentations) déployer des moyens

transférer/déployer le service

supprimer les actifs redondants

19

  • 6.3.6 Vérifier le déploiement

  • 6.3.7 Conduire le support de début de vie (ELS ou Early-Life Support)

Le support de début de vie est une situation intermédiaire avant l’exploitation effective. Cette étape permet aux ressources de déploiement à contribuer à la stabilisation du service.

  • 6.3.8 Passer en revue et terminer un déploiement

Il faut vérifier, entre autres, l’enregistrement correct et exhaustif des problèmes et erreurs connues rencontrées lors de ce changement (pour utilisation ultérieure, par ex. pour le support incidents).

  • 6.3.9 Passer en revue et clôturer la transition du service

Cette activité qui termine le processus permet de :

vérifier que toutes les activités de transition sont terminées vérifier que des métriques fiables sont en place

20

  • 7 Gestion des connaissances

    • 7.1 Ambition, objectifs et objet du processus

      • 7.1.1 Ambition (goals) du processus

L’ambition du processus au sein de la gestion des services est de :

s’assurer que la bonne information est délivrée au bon endroit ou à la bonne personne, au bon moment pour permettre des décisions éclairées.

  • 7.1.2 Objectifs (objective) du processus

Pour réaliser cette ambition, le processus a pour objectif concret de :

permettre aux organisations d’améliorer la qualité des prises de décision en s’assurant que les données et informations fiables et sécurisées 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 d’être plus efficace et améliorer la qualité de service, augmenter la satisfaction et réduire les coûts du service. s’assurer que les équipes ont une compréhension claire et commune de la valeur apportée par les services qu’ils fournissent aux clients et de la manière dont des bénéfices sont réalisés par l’utilisation de ces services. s’assurer que, à un endroit et un moment donnés, les équipes du fournisseur de services ont les informations adéquates sur :

o

qui utilise actuellement leurs services

o

les niveaux actuels de consommation

o

les contraintes de la fourniture des services

o

les difficultés rencontrées par les clients en essayant de réaliser tous les bénéfices prévus de l’utilisation des services.

  • 7.2 Concept-clé : Données-> InformatIon -> Connaissance -> Sagesse

7 Gestion des connaissances 7.1 Ambition, objectifs et objet du processus 7.1.1 Ambition ( goals

21

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

  • 7.2.1 Donnée

Une donnée est le résultat direct d’une mesure. Elle peut être collectée par un outil de supervision, par une personne ou être déjà présente dans une base de données par ex. Une donnée seule ne permet pas de prendre une décision sur une action à lancer. Par exemple, pour le mois dernier, les données suivantes ont été relevées :

1 217 incidents enregistrés au centre de services 98 changements ont été mis en production Pour être complet, le mois précédent, la donnée suivante a été enregistrée :

10 nouveaux prestataires employés à la direction informatique Le raisonnement basé sur ces données est volontairement très simplifié (peut-être trop à certaines étapes).

  • 7.2.2 Information

Une information est une donnée à laquelle un sens et une interprétation ont été donnés. Une information permet à un responsable opérationnel de prendre une décision (d’échelle locale ou à petite échelle) sur une action à mener. Par exemple, les données précédentes sont interprétées de la manière suivante :

augmentation de 240 % du nombre d’incidents par rapport au mois précédent augmentation de 15 % du nombre de changements mis en production par rapport au mois précédent l’emploi des 10 prestataires supplémentaires le mois précédent est lié à une augmentation temporaire de la charge de travail d’intégration, de test et de mise en production d’une refonte du système d’information Le responsable du centre de services peut décider de prendre un prestataire supplémentaire en renfort (à condition qu’il ait le budget évidemment) pour absorber la charge supplémentaire qui ne semble pas diminuer. Le responsable des mises en production peut, en première analyse, conclure que l’augmentation importante du nombre d’incidents n’est pas liée à la mise en production des changements, étant donné la faible augmentation du nombre de changements mis en production pendant la même période.

  • 7.2.3 Connaissance

La connaissance est le résultat d’une réflexion sur les informations analysées en se basant sur :

ses expériences, ses idées, ses valeurs, les avis d’autres personnes consultées pour l’occasion sa propre expertise et celle de ses pairs La connaissance permet aux responsables de confronter les informations au contexte de l’organisation et à d’autres contextes externes à l’organisation afin d’avoir une meilleure connaissance et une interprétation élargie des phénomènes mis en lumière par ces informations. Les décisions prises à ce niveau seront d’échelle intermédiaire (à un niveau tactique par ex.). Le responsable portant le rôle de gestionnaire des changements peut établir une corrélation entre l’arrivée des nouveaux prestataires et l’augmentation des incidents en ayant connaissance des éléments suivants :

en raison de l’urgence (elle-même liée à l’importance des retards dans les mises en production du nouveau système d’information), la dizaine de prestataires a été formée en une demi-journée au fonctionnement de l’organisation informatique, certainement trop rapidement sur l’intérêt et l’obligation de respecter le processus de gestion des changements le responsable des mises en production n’est pas forcément en phase avec son équipe (ceux qui réalisent les mises en production sur le terrain) après discussion avec quelques techniciens réalisant les mises en production, il s’avère une dégradation importante de la qualité des livraisons et, compte-tenu de l’urgence, certains contrôles ne sont plus pris en compte voire réalisés, laissant partir en production des kits d’installation de moindre qualité et fiabilité une discussion rapide avec un consultant ITIL apporte un élément nouveau : le succès du processus de gestion des changements est aussi lié à un taux de « changements sauvages » très faible La connaissance de ces éléments (entre autres) permet d’apporter une interprétation élargie du phénomène constaté : l’augmentation très importante du nombre d’incidents sur la période est très probablement liée à l’augmentation très importante du nombre de « changements sauvages » réalisés par les nouveaux prestataires formés trop rapidement aux processus en vigueur à l’organisation informatique. Ces « changements sauvages » sont, par essence, indétectables par les indicateurs de performance du processus de gestion des changements. S’il s’était contenté de son tableau de bord sur les indicateurs de performance (qui restent à un niveau correct), le gestionnaire des changements serait passé à côté de l’explication de l’explosion du nombre d’incidents et ne se serait pas remis en question alors qu’il est à l’origine du problème.

22

L’attitude qui consiste à se contenter du paradigme de son tableau de bord n’est pas la bonne. Il faut élargir ce paradigme en intégrant toute la connaissance nécessaire pour avoir du recul sur son tableau de bord. Parmi les décisions à prendre pour corriger le tir, il y a un contrôle plus important des activités réalisées par les prestataires et une action de formation plus longue. Certains prestataires, agissant trop en franc-tireur sans se préoccuper des conséquences de leurs actes techniques, peuvent aussi être remplacés par d’autres.

7.2.4

Sagesse

Cette étape ultime de la démarche permet :

d’aboutir à un état d’esprit général de discernement final sur le contenu (informations, connaissances) et de jugement de bon sens,

de

s’adapter

à

de

nouvelles situations et

de lancer les actions d’adaptation de l’organisation,

des

 

personnes, des processus et des outils

 

et,

au final,

de provoquer des changements de cap de l’organisation afin d’anticiper les grands

changements à venir et l’évolution d’un domaine Cette faculté est rencontrée chez les responsables seniors de l’organisation ainsi que chez le responsable de l’organisation informatique. Elle permet de prendre des décisions à long terme et des décisions stratégiques pour l’organisation informatique.

  • 7.3 Exemple de système de gestion de connaissances des services (SKMS)

L’attitude qui consiste à se contenter du paradigme de son tableau de bord n’est pas

23