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

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

Release and Deployment Management (4.4)

Early Life Support

Service Validation and Testing (4.5)

Knowledge Management (4.7)

Focus of activity related to service transition

Other ITIL core publication

ITIL process in this publication that supports the whole service lifecycle

E

Point to Evaluate the Service Design

BL

Point to capture Baseline

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 Prêt pour évaluation changements Evaluer le changement

Autoriser une proposition de changement

Prêt pour décision Autoriser le changement
CAB/ECAB

Demande de travaux

CMS

autorisé

Planifier les mises à jour Gestion des changements

planifié

Coordonner l’implémentation Gestion des changements Rapport d’évaluation

Demande de travaux

implementé

Revoir et cloturer le changement

Clos
*

15

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 :

Stratégie de service
Changements stratégiques Changements tactiques

Gestion de la Amélioration Gestion des Conception Exploitation Fournisseurs relation continue du niveaux de de service des services externes business service service

X

X X X X X X

Changements opérationnels

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 decisions Et a ctions

Communication, Escalade des RFC Risques et alertes

Entité responsable

Type de changement concerné

Niveau 1

Comité de direction

Risque/cout élevé

Niveau 2

DSI

Changement impactant plusieurs services ou directions

Niveau 3

CAB ou ECAB

Changement impactant un service ou une 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 :
Client

Niveau de service

Portefeuille de service

Contrat

Service ventes

Service assuré par

Service support E-commerce

Supporté par

Application

Hébergé par

Service hébergement

Utilise

Service D’infrastructure technique

Disponibilité

Expérience utilisateur

Logique Business

Messagerie

Service Données

Web services

Topologie réseau

Authentification

Service 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

CIs électroniques

CMDB 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 environnements distants

46

Le cycle en V du service
Level 1
Définir les besoins business

Critères et plan de revue du service
• Contrat, Service Package, SLP, SPI

Validation du service et des contrats

1a Level 2
Définir les attentes de service

1b
Critères et plan d’acceptation du service
• SLR • SLA v0
Test d’acceptation du service

2a Level 3
Concevoir la solution

2b
Critères et plan opérationnels de service
• SDP comprenant: • le modèle de service • les plans de capacité et de ressource Critères et plan de test de la mise en production Test d’aptitude opérationnelle

3a Level 4

3b
Test du package de mise en production

Concevoir la mise en production

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

4a Level 5
Développer la solution

4b
Tests unitaires et d’intégration

5a Critères de tests et validation
Construction et test des composants

5b

Livraisons des fournisseurs internes et externes

BL

Point de baseline Fournisseurs internes et externes

47

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 Configure Teste

L’ensemble des mises en production applicatives et hardware

 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