5- ITIL V3 - Transition Du Service v1.12

Paris - Boston - Milan - Düsseldorf - Londres - Madridwww.orsyp.com

Principes

Transition du service

2

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

3

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

4

Vue d’ensemble de la transition de service

E3E2E1

BLBLBLBLBL BL BL

E

BL

RFC

RFC5RFC4RFC3RFC2RFC1 RFC6

Continual Service Improvement

Change Management (4.2)

Service Asset and Configuration Management (4.3)

Service Transition Planning and Support (4.1)

Oversee management of organization and stakeholder change (5)

Evaluation of a Change or Service (4.6)

Service

Strategy

Service

Design

Plan and

prepare

release

Build and

test

Service

testing and

pilots

Plan and

prepare for

deployment

Transfer,

deploy,

retire

Review and

close service

transition

Service

Operations

Early Life SupportRelease and Deployment Management (4.4)

Service Validation and Testing (4.5)

Knowledge Management (4.7)

Focus of

activity related

to service

transition

Other ITIL core

publicationITIL process in this

publication that

supports the whole

service lifecycle

Point to Evaluate the Service Design

Point to capture Baseline

Request for Change

5

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

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

configurations

CMS – Système de gestion des

configurations

Service KnowledgeManagement System

Base de gestion des configurations

Decisions


Processus



Gestion des changements


8

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

9

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

10

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

11

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

CAB – Change Advisory Board

12

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

Les demandes de changements

13

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é

Changement Standard

14

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

Changement Urgent

15

Activités

planifié

Clos*

Créer

une RFCProposition de

changement

(optionnel)

Autoriser une

proposition de

changement

Enregistrer

la RFC

Revoir la

RFC

Evaluer le

changement

Autoriser le

changement

Planifier les

mises à jour

Coordonner

l’implémentation

Initiateur Demandé

Gestion des

changements Prêt pour évaluation

CAB/ECAB



Rapport

d’évaluation

implementé

Revoir et cloturer

le changement

autorisé

Prêt pour

décision

Mettre

à jo

ur le

changem

ent e

t les in

form

atio

ns lié

es d

ans le

CM

S

Demande de

travaux

Demande de

travaux

16

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

….

17

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 :

Stratégie de service

Gestion de la relation

business

Conception de service

Amélioration continue du

service

Gestion des niveaux de

service

Exploitation des services

Fournisseurs externes

X X

X X X

X X

Changements stratégiques

Changements tactiques

Changements opérationnels

Changement de service

18

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

19

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?

20



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

21

Autoriser le changement

Niveau d’autorisation défini en fonction

Du type de changement

Du risque associé

Communicationdecisions

Et a ctions

Comité de direction

CAB ou

DSI

Communication,

Escalade des RFC

Risques et alertes

Niveau 1

Niveau 2

Niveau 3

Niveau 4

Entité responsable Type de changement concerné

Risque/cout élevé

Changement impactant

plusieurs services

ou directions

Changement impactant

un service ou une

direction localeECAB

Organisation locale Changement standard

22

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

23

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

24

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

25

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

26

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

27

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

Points d’attention

28

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


Gestion des actifs de service et des

configurations (SACM)


30

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é

Objectifs

SACM : Service Asset and Configuration Management

31

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

Définition

32

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 :

Service

support

E-commerce

ApplicationService

hébergement

DisponibilitéExpérience

utilisateur

Logique

BusinessMessagerie

Service

Données

Web

servicesTopologie

réseauAuthentification

Service

réseau

Service

D’infrastructure

technique

ClientNiveau de

service

Portefeuille

de service

ContratService

ventes

Service assuré par

Supporté par Hébergé par Utilise

Définition

33

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)

Concepts

34

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…

Définition

35

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

Définition

36

Exemple de structure de CMS

37

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

Activités

38

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

Rôles principaux

39

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

Rôles principaux

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

40

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

Rôles principaux


Gestion des déploiements et

des mises en production


42

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

43

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

Définitions

44

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

Principaux concepts

45

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

Définition

46

CMDB

Informations sur les CIsCIs PhysiquesDML

Enregistrements

CIs

électroniques

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

environnements distants

Relations DML et CMDB

47

Le cycle en V du service

Définir les

besoins

business

Définir les attentes

de service

Concevoir la solution

Concevoir la

mise en production

Développer la

solution

Tests unitaires

et d’intégration

Test du package

de mise en production

Test d’aptitude

opérationnelle

Test d’acceptation

du service

Validation du service

et des contrats

1a

2a

3a

4a

5a 5b

4b

3b

2b

1b

Construction et

test des

composants

Fournisseurs internes

et externes

Level 1

Level 2

Level 5

Level 4

Level 3

Critères et plan de revue du service

Critères et plan d’acceptation du service

Critères et plan opérationnels de service

Critères et plan de test de la

mise en production

BL

Critères de tests et validation

Point de baseline

Livraisons des fournisseurs

internes et externes

• Contrat, Service Package, SLP, SPI

• SLR• SLA v0

• SDP comprenant:• le modèle de service• les plans de capacité et de ressource

• Conception de la mise en production• plan de mise en production

48

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

Activités

49

Le gestionnaire des déploiements et mises en production

Planifie

Conçoit

Construit

Configure

Teste

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

modification des services concernés

L’ensemble des mises en production applicatives et hardware

Rôles principaux

50

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

Rôles principaux

51

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

Rôles principaux

52

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

Rôles principaux

Exercices


53

5- ITIL V3 - Transition Du Service v1.12

Documents

Transcript of 5- ITIL V3 - Transition Du Service v1.12