Transition du service

Principes

Paris - Boston - Milan - Düsseldorf - Londres - Madrid

www.orsyp.com
 Enjeux de la transition de service

 Permettre aux projets business et aux clients d’intégrer les

nouveaux changements dans les processus et services métiers

 Limiter les variations de performance dues aux changements

 Traiter les erreurs connues et minimiser les risques lors du passage

en production

 S’assurer que le service peut être utilisé conformément aux besoins

et aux contraintes exprimés

2
 Objectifs de la transition de service

 Planifier et gérer les ressources

 nécessaires à l’implémentation ou la modification d’un service

 en respectant les éléments de coût, de qualité et de délais

 Assurer un impact minimal sur les services

 Améliorer la satisfaction des utilisateurs et des clients

 Assurer un bon usage des services

 Fournir des plans clairs et complets de la transition de service

permettant d’assurer la cohérence avec les changements métiers

3
 Vue d’ensemble de la transition de service
Continual Service Improvement

Change Management (4.2)

RFC1 RFC2 RFC3 RFC4 RFC5 RFC6

Service Asset and Configuration Management (4.3)

BL BL BL BL BL BL BL

Service Transition Planning and Support (4.1)

Oversee management of organization and stakeholder change (5)

Evaluation of a Change or Service (4.6)

E1 E2 E3

Plan and Service Plan and Transfer, Review and

Service Service Build and Service
prepare testing and prepare for deploy, close service
Strategy Design test Operations
release pilots deployment retire transition

Early Life Support

Release and Deployment Management (4.4)

Service Validation and Testing (4.5)

Knowledge Management (4.7)

E Point to Evaluate the Service Design

Focus of Other ITIL core ITIL process in this
activity related publication publication that
to service supports the whole
BL Point to capture Baseline
transition service lifecycle

RFC
Request for Change 4
 Système de gestion des connaissances
des services

 SKMS : Service Knowledge Management System

 Système recensant l’ensemble des connaissances relatives au
service
 Expérience des équipes
 Enregistrements liés à l’environnement
 Contraintes des fournisseurs et partenaires

Service Knowledge
Management System Decisions
CMS – Système de gestion des
configurations

Base de gestion des configurations

 N.B. Le SKMS inclut notamment le système de gestion des

configurations
5
Transition du service
Processus

Paris - Boston - Milan - Düsseldorf - Londres - Madrid

www.orsyp.com
Transition du service
Gestion des changements

Paris - Boston - Milan - Düsseldorf - Londres - Madrid

www.orsyp.com
 Objectifs

S’assurer que tous les changements affectant le SI sont :

 Enregistrés
 Évalués
 Autorisés
 Priorisés
 Planifiés
 Testés
 Implémentés
 Documentés
 Revus

8
 Périmètre

 Toute modification apportée aux CI et actifs, tout au long du cycle

de vie du service

 Chaque organisation doit définir les types de changements hors

périmètre, par exemple :
 Les changements ayant un impact significatif sur l’organisation (à
traiter dans le cadre de programmes dédiés)
 Les changements au niveau opérationnel (changement de cartouche
d’imprimante)
 Les changements organisationnels au niveau métier

 La gestion des changements doit impliquer également les

fournisseurs externes

9
 Bénéfices

 Implémentation des changements sur la base des accords de

service, tout en optimisant les coûts

 Réduction des interruptions de service

 Implémentation rapide des changements

 Meilleure estimation de qualité, délais et coûts

 Meilleure estimation du risque de transition de service

 Meilleure productivité

 Réduction du nombre de changements « dans l’urgence »

 Réduction du temps moyen de reprise (MTRS) suite à incident

 Liaison avec le processus de gestion des changements

business

10
 CAB – Change Advisory Board
 Instances de traitement du changement

 Définition
 Comité effectuant des recommandations de l’évaluation, l’autorisation et la
définition de la priorité des changements
 Comité consultatif des changements
 Approuve les changements en fonction de l’impact et de la catégorie
 Assiste le Gestionnaire des changements dans l'analyse d’impact et l’évaluation
de la priorité des changements
 Planifie les changements
 ECAB (Emergency Committee) pour traiter les changements urgents
 Acteurs
 Gestionnaire des Changements : « président »
 Des membres du personnel informatique
 Des fournisseurs, des développeurs, des spécialistes de la maintenance
 Des clients et des utilisateurs
 Des membres du personnel de soutien
 Des experts ou des conseillers techniques
11
 Les demandes de changements

 Une Demande de Changement est une demande formelle de

modification d’un ou plusieurs CIs

3 types de demandes de changement :

 Changement normal
 Changement suivant le processus normal de gestion des
changements
 Changement standard
 Changement pré-autorisé par la gestion des changements et pour
lequel il existe une procédure de mise en œuvre
 Changement urgent
 Changement devant être implémenté aussi vite que possible pour
limiter un impact fortement préjudiciable au business

12
 Changement Standard

 Caractéristique du changement standard

 Un déclencheur est défini pour initier la RFC

 Les actions sont connues, documentées et testées

 L’autorisation technique est donnée en avance

 La validation budgétaire est pré-demandée ou sous responsabilité du

demandeur

 Le risque associé au changement est faible et bien maîtrisé

13
 Changement Urgent

 Caractéristique du changement urgent

 Recours au Emergency CAB (ECAB) si nécessaire

 Réalisation du plus de test possible dans le délai imparti

 Test si nécessaire après passage en production (cohérence des

données)

 Mise en place des ressources nécessaires pour supporter les

équipes d’exploitation (appel à l’astreinte par exemple)

 Mise en place de plans de retour si échec

 En cas d’échecs répétés, s’assurer du diagnostic et de la cohérence

de la solution proposée

 Documentation du changement pouvant être effectuée a posteriori

14
Activités
Créer
une RFC
Proposition de
changement
(optionnel) Enregistrer
la RFC

Mettre à jour le changement et les informations liées dans le

Initiateur Demandé
Revoir la
RFC
Gestion des
changements Prêt pour évaluation
Evaluer le
changement
Prêt pour Demande de
décision travaux
Autoriser le

CMS
Autoriser une changement
proposition de CAB/ECAB autorisé
changement
Planifier les
mises à jour
Gestion des changements planifié Demande de
travaux
Coordonner
l’implémentation
Gestion des changements implementé
Revoir et cloturer
Rapport
le changement
d’évaluation 15
Clos
*
 Créer et enregistrer

 Créer et enregistrer les demandes de changement

 Création par l’initiateur du changement

 N’importe qui peut initier le changement
 Validation hiérarchique si nécessaire

 Elaboration d’une proposition de changement

 Si changement majeur
 Intégrant la justification financière
 Intégrant la justification business

 Enregistrement des informations :

 Numéro unique
 Origine du changement
 Description
16
 ….
 Changement de service

 Changement de service
 Addition, modification ou suppression d’un service ou composant de
service et de la documentation associée autorisé, planifié ou supporté

 Les origines des changements de service sont diverses :

Gestion de la Amélioration Gestion des

Stratégie de Conception Exploitation Fournisseurs
relation continue du niveaux de
service de service des services externes
business service service

Changements
stratégiques X X
Changements
tactiques X X X
Changements
opérationnels X X

17
 Revue de la RFC

 Procéder à la revue de la RFC

 Filtrer toute demande irréalisable

 Eliminer les demandes redondantes

 Filtrer les demandes incomplètes

 Description inappropriée
 Pas d’approbation budgétaire

18
 Evaluer le changement

 Evaluer le changement
 Analyser l’impact du changement
 Analyser les risques
 S’appuyer notamment sur les 7 R
 Par qui le changement est-il REQUIS?
 Quelle est la RAISON du changement?
 Quel RETOUR est attendu du changement?
 Quels RISQUES implique le changement?
 Quelles RESSOURCES sont nécessaires pour mener à bien
le changement?
 Qui est RESPONSABLE de la conception, du test et de
l’implémentation du changement?
 Quelles RELATIONS existent entre ce changement et les
autres?
19
 Evaluer le changement

 Evaluer le changement
 Affecter une priorité au changement
 Sur la base de l’analyse de risque
 En fonction de l’urgence estimée

 Priorité immédiate pour les corrections à chaud

 Priorité forte

 Priorité moyenne

 Priorité faible

20
 Autoriser le changement

 Niveau d’autorisation défini en fonction

 Du type de changement
 Du risque associé

Communication Communication,
decisions Escalade des RFC Entité responsable Type de changement concerné
Et a ctions Risques et alertes

Niveau 1 Comité de direction Risque/cout élevé

Changement impactant
Niveau 2 DSI plusieurs services
ou directions

CAB ou Changement impactant

Niveau 3 un service ou une
ECAB
direction locale

Niveau 4 Organisation locale Changement standard

21
 Planifier le changement

 Les changements autorisés sont recensés

 Dans le calendrier des changements

 CS – Change Schedule
 Planning prévisionnel des changements
 Dates d’implémentation prévues

 Dans l’indisponibilité prévue

 PSO – Projected Service Outage
 Indisponibilité planifiée suite à application des
changements

22
 Coordonner l’implémentation

 Prise en charge par les équipes techniques

 Pilotage de la conception et du test

 Conception technique de la solution
 Livraison du matériel
 Rédaction de la documentation associée
 Test technique de la solution
 Préparation des procédures de retour arrière

 Pilotage de l’implémentation effective

23
 Revoir et clôturer

 Revue post-implémentation (PIR)

 Incidents en période d’observation
 Atteinte des objectifs du changement
 Satisfaction des utilisateurs et clients
 Effets de bord
 Respect des délais et des coûts
 Bon fonctionnement des plans d’installation ou de retour arrière, si
besoin

 Mise à jour au besoin de la RFC si objectifs non atteints

 Clôture de la RFC sinon

24
 Indicateurs

 Nombre d’incidents causés par les changements

 Nombre de spécifications inexactes des changements

 Nombre de changements non autorisés

 Pourcentage de réduction en termes de temps et de coût pour

traiter les changements

 Pourcentage d’amélioration dans l’estimation des durées, de la

qualité, des coûts et de l’impact des changements

 Fréquence des changements

 Satisfaction utilisateurs par rapport au traitement des RFC

 Pourcentage de changements suivant les procédures définies

 Pourcentage de changements urgent/standard/normal

25
 Rôles principaux

 Gestionnaire des changements

 Affecte une priorité à la RFC en dialoguant avec l’initiateur

 Définit l’ordre du jour du CAB avec les RFC à traiter

 Prépare et anime les réunions du CAB et du ECAB

 Autorise les changements

 Met à jour les plannings (SC et PSO)

 Coordonne la conception, le test et l’implémentation

 Met à jour les enregistrements correspondants

 Assure la revue des changements

 Identifie les tendances liées au traitement des changements

 Clôture les RFCs

 Produit le reporting des changements

26
 Points d’attention

 Résistance au « changement »

 Processus trop bureaucratique entraînant un contournement

 Goulot d’étranglement, surcharge de travail

 Périmètre trop ambitieux

 Gestion des configurations insuffisante pour évaluer les impacts

 Difficultés liées à la coordination des mises en production sur

différents sites/systèmes

 Manque d’implication du management

27
 Recommandations

 Implémentation en parallèle
 Gestion des changements
 Gestion des actifs de service et des configurations (SACM)
 Gestion des mises en Production

 Conduire des audits réguliers de conformité

 S’assurer de la fiabilité du CMS

 Impliquer le centre de services dans le suivi des changements

 Former le personnel aux bénéfices de la Gestion des

Changements

 Produire des « success stories » en cas de haute conformité

 Introduire des clauses contractuelles relatives à la Gestion des

Changements auprès des prestataires externes
28
Transition du service
Gestion des actifs de service et des
configurations (SACM)

Paris - Boston - Milan - Düsseldorf - Londres - Madrid

www.orsyp.com
 Objectifs

1. Définir et contrôler les composants de services et d’infrastructure

2. Maintenir à jour les informations relatives à la configuration des

services et de l’infrastructure :
 Historique
 Etat courant
 Etat planifié

 SACM : Service Asset and Configuration Management

30
 Définition

 Elément de Configuration Configuration Item (CI)

 Item de l’architecture qui est, ou sera, sous le contrôle de la gestion

de configuration

 les composants diffèrent en complexité, taille et type - d’un système

complet à un simple module ou composant hard mineur

 les composants devraient être sélectionnés par le biais de critères de

sélection, groupés, classifiés et identifiés de manière à être
facilement gérables et traçables tout au long du cycle de vie du
service

31
 Définition

 Le modèle de configuration
 Modèle des services, actifs et infrastructure précisant les relations
entre CIs

 Permet de consolider l’analyse d’impact des changements

 Permet d’optimiser l’utilisation des actifs et les coûts

Exemple : Niveau de Portefeuille

Client
service de service

Service
Contrat
ventes

Service assuré par

Service Supporté par Hébergé par Service Utilise Service

support Application hébergement D’infrastructure
E-commerce technique

Expérience Logique Service Web Topologie Service

Disponibilité Messagerie Authentification
utilisateur Business Données services réseau réseau
32
 Concepts

 Types de CIs

 Les CIs du cycle de vie de service (Business case, plans de cycle

de vie de service, plans de test…)

 Les CIs de service (ressources financières, humaines, infrastructure,

informations…)

 Les CIs organisationnels (politiques organisationnelles, contraintes

réglementaires…)

 Les CIs internes (composants fournis par les projets internes…)

 Les CIs externes (accords avec les partenaires, produits de

fournisseurs,…)

 Les CIs interfaces (élements nécessaires pour fournir le service de

bout en bout)

33
 Définition

 Système de gestion des configurations

CMS – Configuration Management System

 Système contenant l’ensemble des informations relatives aux CIs sur le

périmètre défini

 Le CMS maintient les relations entre tous les composants du service et

 Les incidents
 Les problèmes
 Les erreurs connues
 Les changements
 Les documentations de mise en production
 Les employés de l’entreprise
 Les fournisseurs
 Les clients…
34
 Définition

 CMDB Configuration Management Data Base

 Base de données de la gestion des configurations et des actifs

 Elle contient la description et les relations entre tous les CI

gérés

35
Exemple de structure de CMS

36
 Activités

1. Gestion et planification
 Stratégie, Principes, Périmètre, Objectifs, Rôles et responsabilités

2. Identification des configurations

 Sélection, Identification et Marquage des CI (inventaire)

3. Contrôle
 Additions, Modification, Suppressions

4. Status et reporting
 Données courantes et historiques de chaque composant

5. Vérification et audit
 Vérifier l’existence physique des éléments de configuration

37
 Rôles principaux

 Le(s) gestionnaire(s) des Actifs de service / Configurations

 Met en œuvre les politiques et standards de gestion des actifs /
configurations

 Planifie, implémente et optimise le système de gestion des actifs /

configurations

 Communique sur les procédures de gestion des actifs / configurations

 Gère le plan et le processus de gestion des actifs / configurations

 Propose et implémente les interfaces avec les autres processus

 Planifie l’alimentation du CMS, le gère et le maintient

 Fournit le reporting relatif à la gestion des actifs / configurations

 Recueille les budgets pour optimiser l’infrastructure

38
 Rôles principaux

 L’analyste des configurations

 Crée les processus et procédures

 S’assure de la validité et de la maintenance des informations

 Assure des audits réguliers des actifs et du CMS

 L’administrateur des configurations

 Contrôle l’identification, le stockage et la suppression de tous les CIs

 Fournit l’information sur le statut des CIs

 Administre le processus de contrôle de la configuration

 L’administrateur du CMS
 Recommande les solutions logicielles les plus adaptées au contexte

 Assure l’intégrité et la performance opérationnelle du système de

gestion de la configuration
39
 Rôles principaux

 Le comité de contrôle des configurations

Configuration Control Board

 Assure l’application des politiques de gestion de la configuration tout

au long du cycle de vie du service

 Définit et contrôle les baselines

 Passe en revue les changements de configuration

 Initie les changements de configuration requis

NB : le comité de contrôle des configurations peut être combiné au CAB

40
Transition du service
Gestion des déploiements et
des mises en production

Paris - Boston - Milan - Düsseldorf - Londres - Madrid

www.orsyp.com
 Objectifs

 Assurer que des plans clairs et exhaustifs permettant de dérouler

les changements en accord avec les besoins clients

 Construire, tester, installer et déployer efficacement les mises en

production

 Fournir lors des mises en production les niveaux de service requis

 Limiter l’impact de la mise en production sur les services et

l’organisation

 Assurer la satisfaction des clients et utilisateurs sur les pratiques de

transition de service

42
 Définitions

 Unité de mise en production Release unit

 Une unité de mise en production décrit la partie d’un service ou d’une

infrastructure IT qui est normalement livrée en production comme un
tout en accord avec la politique de mise en production de l’entreprise

 L’unité de mise en production peut varier en fonction du type d’actif

ou de composant considéré

 Mise en production groupée Release Package

 Est composée d’une ou plusieurs unités de mise en production

 Il intègre l’ensemble des changements requis pour assurer le service :
 Modification de l’infrastructure technique
 Formation des équipes support
 Documentation d’exploitation
 Mise à jour des services dépendants
43
 Principaux concepts

 Big Bang vs Par Phase

 Big Bang : le service est implanté à tous les utilisateurs en une
opération
 Par Phase : le service est implanté sur une première base
d’utilisateurs puis l’implantation est poursuivie selon un calendrier
de bascule

 Approche Push vs Pull

 Push : le service est implanté à partir d’un centre vers les
emplacements cibles, à l’initiative du centre et non des utilisateurs
cible
 Pull : le service est mis à disposition des utilisateurs sur un
emplacement central. Les utilisateurs sont libres d’installer le service
selon leur désir

 Automatisé vs Manuel 44
 Définition

 Bibliothèque des supports définitifs

DML – Definitive Media Library

 Bibliothèque sécurisée dans laquelle sont stockées et protégées

toutes les versions définitives autorisées des CIs logiciels

 Une ou plusieurs bibliothèques logicielles ou zones de stockage de

données, séparée(s) des zones de développement, de test ou de
production

 Elément essentiel au processus de gestion des déploiements et

mises en production

 Elle peut contenir des Cis tels que de la documentation ou des

licences

45
 Relations DML et CMDB

DML CIs Physiques Informations sur les CIs

CMDB
CIs
électroniques
Enregistrements

Construction d’une
nouvelle mise en
production

Test de la nouvelle
mise en production

Mise en oeuvre de la
nouvelle mise en
production
Déploiement aux 46
environnements distants
 Le cycle en V du service

Définir les Critères et plan de revue du service Validation du service

Level 1 besoins et des contrats
business
• Contrat, Service Package, SLP, SPI

1a 1b

Définir les attentes Critères et plan d’acceptation du service Test d’acceptation

Level 2 de service du service
• SLR
• SLA v0
2a 2b

Critères et plan opérationnels de service Test d’aptitude

Level 3 Concevoir la solution
opérationnelle
• SDP comprenant:
• le modèle de service
3a • les plans de capacité et de ressource 3b
Critères et plan de test de la
Concevoir la mise en production Test du package
Level 4 mise en production de mise en production
• Conception de la mise en production
• plan de mise en production
4a 4b

Développer la Tests unitaires

Level 5 solution et d’intégration

5a 5b
Critères de tests et validation Construction et
test des
composants Livraisons des fournisseurs
internes et externes

BL Point de baseline
Fournisseurs internes 47
et externes
 Activités
1. Planification

2. Préparation à la construction des packages, tests et déploiement

3. Construction des packages et tests

4. Test du service et pilote

5. Planification et préparation du déploiement

6. Transfert, déploiement et retrait des anciens actifs

7. Vérification du déploiement

8. Soutien précoce (Early Life Support : ELS)

9. Revue et fermeture

48
 Rôles principaux

 Le gestionnaire des déploiements et mises en production

 Planifie
 Conçoit
 Construit
L’ensemble des mises en production applicatives et hardware
 Configure
 Teste

 Crée les packages en vue de l’implantation ou de la

modification des services concernés

49
 Rôles principaux

 Le gestionnaire du packaging et de la construction

 Etablit la configuration définitive de la mise en production

 Construit la mise en production définitive

 Teste la mise en production définitive avant le déroulement des tests

indépendants (pré-production)

 Etablit et communique sur les erreurs connues associées et les

solutions de contournement

 Livre le package définitif au processus de validation finale

50
 Rôles principaux

 Equipe de déploiement
 Assure le déploiement physique de la mise en production

 Coordonne la documentation et la communication associée à

l’implantation, notamment la formation et la fourniture de procédures
et modes d’emploi utilisateurs et support

 Planifie le déploiement avec la gestion des changements

 Fournit un support technique durant les phases de déploiement

 Assure la capitalisation sur l’efficacité de la mise en production

 Enregistre les indicateurs liés aux mises en production et les

compare aux SLAs

51
 Rôles principaux

 Support de début de vie (Early life support)

 Fournit un support technique et fonctionnel avant l’acceptation finale
par l’exploitation des services

 Assure la fourniture de la documentation support adéquate

 Prononce l’acceptation du package pour support initial

 Adapte, complète et optimise les composants livrés

 Documentation utilisateur / Documentation Support

 Supervise les incidents et problèmes liés à la mise en production

 Produit un reporting sur la performance du service durant la phase de

support initial

52
Transition du service
Exercices

53