ITIL® - La transition des services · ITILﬁ - Transition des services A propos du document Ce...

ITIL® - La transition des servicesVersion 1.0

Mars 2017

1

ITIL® - Transition des services

A propos du documentCe document pratique est le résultat de la mise en oeuvre du référentiel ITIL® et d'autresréférentiels dans des directions informatiques en France au travers des missions qui me sontconfiées depuis 2004 ainsi que des formations que j’anime avec création de supportsoriginaux.

Il est mis à la disposition de la communauté francophone pour diffuser quelques conseils etnotes sur le passage souvent délicat de la théorie à la mise en pratique de ces référentiels.

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'auteurLa transformation d'une organisation informatique en fournisseur de services informatiquesnécessite une réflexion lucide et permanente sur les tactiques à mettre en place pour quel'opérationnel s'aligne naturellement avec les objectifs stratégiques.

Souvent, l'application brutale sans réflexion d'un référentiel de bonnes pratiques comme ITIL®ou d'un logiciel ITSM améliore peu la performance de l'organisation. Les tactiques mises enplace (organisation, processus, etc.) ne sont pas les plus pertinentes à appliquer sur uncontexte spécifique et manquent de relief (prise en compte faible de facteurs telsqu'importance, priorités, gains rapides, etc.).

De plus, face à l'évolution rapide des situations et des contraintes, le format de ces référentiels(mastodontes avec une nouvelle version tous les 3 ans ou plus) est devenu trop statique etn'est plus adapté.

Il est temps de mettre de l'agilité au sein même des référentiels de bonnes pratiques.

L'amélioration continue et le Lean jouent un rôle prépondérant dans cette nouvelle manièrede faire.

Pour partager avec l’auteur : [email protected]

Pour recommander ses compétences sur les réseaux sociaux : http://fr.linkedin.com/pub/pascal-delbrayelle/27/270/634 http://www.viadeo.com/fr/profile/pascal.delbrayelle

2

ITIL® - Transition des services

Ce document présente la phase de transition des services du référentiel de bonnes pratiques ITIL®.

Les modules présentés sont les suivants :

Module 1 : principes et politiques

Module 2 : gestion des changements

Module 3 : planification et support à la transition

Module 4 : évaluation des changements

Module 5 : test et validation des services

Module 6 : gestion des mises en production et des déploiements

Module 7 : gestion des actifs de service et des configurations

Module 8 : gestion des connaissances

3

Principes et politiquesITIL® - Transition des services

Module

1

Réf. ITSM_M0400-V010-001

4


Module

1

Réf. ITSM_M0400-V010-002

Définir un serviceLe livre "Stratégie des services" décrit le cadre de la définition d'un service. La valeur d'un service est définie par rapportau contexte des organisations clientes à l'intérieur d'un éco-système que l'on pourrait désigner sous le nomd'environnement d'affaires.

La figure suivante illustre la manière dont les actifs du fournisseur de services permettent de délivrer des services auxaffaires (comprendre : le chiffre d'affaires que réalise l'entreprise) et aux clients (les organisations clientes) :

Les ressources sont des actifs tangibles et intangibles qui sont possédés ou contrôlés par le fournisseur de services oul'organisation. Ces ressources et l'utilisation de ces ressources seront converties au final en produits et services quiseront utilisés par les clients.

Les ressources seront transformées en services en utilisant des connaissances, de l'expérience, des processus, uneorganisation et une direction qui composent eux-mêmes une catégorie particulière d'actifs appelés aptitudes.

5


Module

1Le terme actifs est utilisé dans ITIL® pour citer ressources ou aptitudes, ou les deux selon le contexte dans lequel il estcité.

Les services sont un moyen de fournir une valeur ajoutée aux clients comme le montre la figure suivante :

La valeur ajoutée des services aux organisations d'affaires est ce qu'apporte l'utilisation de ces services par rapport à lasituation où les organisations d'affaires se débrouilleraient seule sans fournisseur de services.

Elle a deux composantes : l'accroissement de performance des organisations d'affaires et la réduction des risques surcette même performance.

En contrepartie de ces services, les organisations d'affaires vont fournir une compensation au fournisseur de services(de manière concrète, les résultats financiers des affaires réalisées par les organisations clientes permettent de financerles budgets de l'organisation informatique).

Dire qu'il y a un retour positif sur "investissement" consiste à avoir une valeur ajoutée des services supérieure à lacompensation versée au fournisseur.

Utilité et garantie d'un serviceL'utilité d'un service est définie en termes de :

résultats d'affaires (résultats sur le chiffre d'affaires) qui seront supportés par le service

contraintes qui ne seront plus à gérer par les clients

Cette utilité est présente dans la manière d'améliorer ou simplement de permettre la performance d'actifs del'organisation cliente et dans la manière de contribuer à la réalisation du chiffre d'affaires de l'entreprise.

La garantie est l'assurance qu'un produit ou un service donné sera fourni ou répondra à certaines spécifications.

Trois caractéristiques de garantie sont à prendre en compte :

le service est fourni de manière conforme en termes de disponibilité et de capacité,

le service continuera à être utile aux actifs du client, même à un niveau de service dégradé lors d'interruptionsmajeures ou de désastres,

le service garantit le potentiel de création de valeur pour les actifs du client (en quelque sorte, un rendementgaranti).

6


Module

1

Réf. ITSM_M0400-V010-003

Les pratiques à mettre en place sont, par ex., les suivantes :

le déploiement d’un nouveau service ou d’un service modifié

la communication

la documentation de mise en production

la formation et

le transfert de connaissances

7


Module

1

Réf. ITSM_M0400-V010-004

Le périmètre comprend la gestion et la coordination des processus, des systèmes et des fonctions pour

packager, concevoir, tester et déployer une mise en production dans l’environnement de production et

pour mettre en place le service spécifié pour répondre aux besoins des clients et des parties prenantes

8


Module

1

Réf. ITSM_M0400-V010-005

9


Module

1

Réf. ITSM_M0400-V010-006

10


Module

1

Réf. ITSM_M0400-V010-007

Voici quelques politiques permettant aux fournisseurs de services de planifier et d'implanter les meilleures pratiques detransition des services.

Ces politiques devront être définies, mises en place et suivies particulièrement par le processus de planification et desupport à la transition.

Définir et implanter une politique formelle de transition des servicesDéfinie, documentée et approuvée par la direction, cette politique générale de fonctionnement de la phase"Transition des services" doit aussi être communiquée aux équipes ainsi qu'aux fournisseurs et partenairesimpliqués.

Les principes à adopter sont les suivants :

objectifs clairs et volonté de remédier à toute non-conformité avec ces objectifs

alignement de cette politique avec la gouvernance, l'organisation et les politiques générales de gestion desservices

les sponsors et décideurs impliqués dans la conception de cette politique doivent démontrer leur volonté de mettreen oeuvre cette dernière ; cela inclut l'engagement de délivrer les résultats attendus de tout changement sur lesservices

utilisation de processus qui intègrent les équipes, mixent les compétences tout en maintenant des frontièresclaires sur autorités et responsabilités

délivrer les changements sous la forme de packages d'installation (en clair : refuser toute intervention enproduction qui ne sera pas reproductible en cas de besoin)

impliquer tôt les équipes de déploiement dans les étapes de conception du package d'installation et deplanification du déploiement

Implanter tous les changements sur les services au travers de la transition desservicesTous les changements au portefeuille des services (Service Portfolio) ou au catalogue des services sont àimplanter au travers de la gestion des changements. Les transitions ainsi gérées par le cycle de vie de la transitiondes services sont définies et agréées.

Les principes en sont les suivants :

11


Module

1un point d'entrée unique de gestion des changements en production minimise le risque de conflit entrechangements et perturbations potentielles sur l'environnement de production

les personnes qui n'ont pas autorité pour réaliser un changement ou déployer un package d'installation enproduction ne devraient pas avoir accès à l'environnement de production

la proximité avec les équipes d'exploitation (en clair : connaître les personnes et leur travail) facilite la motivation etfacilite les évolutions de l'organisation

l'accroissement de connaissance et d'expérience des services et de l'environnement de production améliorel'efficacité

chaque package d'installation doit être conçu et suivi par une demande de changement (request for change) autravers du processus de gestion des changements pour s'assurer d'un contrôle et d'une traçabilité efficaces

des procédures et méthodes standardisées sont utilisées pour une prise en charge rapide et efficace de tous leschangements dans le but de minimiser l'impact des incidents consécutifs à un changement sur la continuité desaffaires, la qualité de service et le travail de correction

toutes les mises à jour des changements et déploiements sont enregistrées et associées dans le système degestion des configurations (CMS ou Configuration Management System) aux actifs de services et items deconfiguration

Adopter standards et cadre communsBaser la transition des services sur un cadre commun de processus standard réutilisables et de systèmes pouraméliorer l'intégration des équipes impliquées dans la transition des services et pour réduire les écarts entreréalité et processus.


utiliser les meilleures pratiques de l'industrie comme base de standardisation afin de permettre l'intégration autravers de la chaîne d'approvisionnement (des services)

contrôler le cadre global de fonctionnement de la transition des services via la gestion des changements et desconfigurations (en clair : le processus de gestion des changements pilote l'ensemble des étapes de la transitiondes services pour chaque changement et les indicateurs de performance de ces deux processus permettent decontrôler l'efficacité du cadre global)

s'assurer que les processus sont adoptés et continuent à être respectés en planifiant régulièrement des revues etaudits des processus de la gestion des services

Parmi les meilleures pratiques, il est possible de citer celles-ci :

intégrer dans les processus la vérification et l'évaluation d'un service et de son profil de risque avant et aprèsdéploiement d'un package d'installation

mettre en place des systèmes supportant et automatisant les processus définis afin de réduire la résistance àl'adoption des nouvelles règles

s'assurer que la hiérarchie comprenne la nécessité de travailler avec des règles standard basées sur une réellejustification clients et d'affaires.

Maximiser le potentiel de réutilisation des processus et systèmes en placeLes processus de la transition des services sont alignés sur les processus de l'organisation et les systèmesassociés pour augmenter l'efficacité et l'efficience.

Quand de nouveaux processus sont nécessaires, ils sont développés en ayant en tête la réutilisation de l'existant.


réutiliser les processus et systèmes en place aussi souvent que possible

développer des modèles de transition qui puissent servir de base aux processus et systèmes à développer

Parmi les meilleures pratiques, il est possible de citer :

l'intégration des processus de transition des services dans le système de gestion de la qualité

la conception de modèles pouvant être déclinés facilement pour s'adapter à des circonstances spécifiques

En se basant sur des expériences concrètes, on aboutit rapidement à l'élaboration d'un modèle générique de processusde gestion des changements qui va ensuite se décliner en variantes, appelées modèles de changement dans leréférentiel ITIL®.

12


Module

1L'intérêt de procéder en deux niveaux est la conservation d'une cohérence d'ensemble de la gestion d'un changement,quel que soit sa nature et son type (de la correction applicative aux projets applicatifs et d'infrastructure). Lors del'apparition d'un nouveau type de changement à gérer, le modèle générique sera décliné en une version supplémentairesans qu'il faille refaire une conception complète de processus (coûteux et avec un risque d'incohérence avec les autresmodèles de processus).

Enfin, il est à noter que l'adoption d'un modèle générique permet de sortir des tableaux de bord (tendances desindicateurs de performance du processus) globaux et cohérents sur l'ensemble des changements, du plus petit au plusgrand.

Aligner les plans de la transition des services avec les besoins des affairesAligner la planification ainsi que les nouveaux services et services modifiés avec les besoins des oganisationsclientes et des affaires de manière à maximiser la valeur fournie par le changement.


aller au devant des clients et des utilisateurs pour expliquer comment le nouveau service ou le service modifiépourra être utilisé pour avoir un changement positif sur la conduite des affaires

fournir des informations et prévoir dans les processus la synchronisation des projets des organisations clientesavec les déploiements de packages d'installation

s'assurer que le service peut être utilisé conformément aux exigences et contraintes exprimées initialement demanière à améliorer la satisfaction des clients et de toutes les parties prenantes

superviser et mesurer l'utilisation des services ainsi que l'utilisation des applications et solutions techniques durantle déploiement et le support du début de vie pour s'assurer que tout va bien avant la clôture du changement

comparer la performance réelle des services mis en place avec les performances prévues au moment de laconception de chaque service et prendre toute action corrective si besoin


l'adoption des meilleures pratiques en matière de gestion de programmes et de projets pour planifier et piloter lesressources nécessaires afin d'intégrer les composants développés, créer un package d'installation, le tester et ledéployer avec succès en production dans les coûts, qualité et délais prévus

Etablir et maintenir la communication avec toutes les parties prenantesEtablir et maintenir la communication avec les clients, les représentants des clients (en France : les maîtrisesd'ouvrage), les utilisateurs et les fournisseurs de manière à anticiper leurs questions sur le nouveau service ou leservice modifié.


anticiper les questions des parties prenantes sur la manière d'utiliser la performance et l'utilisation du futur servicepour accompagner le changement sur la manière de traiter les affaires

communiquer les changements vers les parties prenantes afin d'améliorer leur compréhension et leurconnaissance sur le futur service

fournir des informations et de la connaissance de bonne qualité pour que tous les intervenants aient accès auxinformations sur la transition du service (plans de livraison du package d'installation et du déploiement,documentations livrées avec le package)

Mettre en place des contrôles et des disciplines efficacesEtablir des contrôles et des disciplines appropriés tout au long du cycle de vie des services pour avoir destransitions paisibles sur les services lors des changements et des déploiements.


établir et maintenir l'intégrité de tous les actifs de service et items de configurations impliqués dans une transitiontout au long de leur évolution dans la phase de transition des services.

automatiser les opérations d'audit des environnements, quand cela apporte un plus, dans l'idée de détecter le pluspossible les changements non autorisés et les écarts dans les configurations.

définir clairement "qui fait quoi, quand et où" sur toutes les activités de passage de témoin (d'une équipe à uneautre) afin de pouvoir le plus possible rendre compte de ce qui est livré par rapport à ce qui a été prévu dans lesplans et les processus.

13


Module

1définir et communiquer rôles et responsabilités lors des passages de témoin et des périodes de tests (acceptance)associés aux activités de la transition des services (c'est-à-dire la construction, les tests, le déploiement) afin deréduire les erreurs résultant d'incompréhensions et de méconnaissances.

mettre en place des processus basés sur des procédures pour la gestion des configurations, des changements etdes problèmes pour faciliter les audits et collecter les informations de gestion nécessaires à l'amélioration descontrôles.

14


Module

1

Réf. ITSM_M0400-V010-008

Mettre en place des systèmes pour le transfert de connaissances et la prise dedécisionLa transition des services se met en place avec des systèmes et des processus pour transférer lesconnaissances pour une exploitation optimale du service et permet une meilleure prise de décision au bon momentpar les bonnes personnes.

Les principes sont basés sur une focalisation sur la rédaction des documentations et sur l'accès facile aux informations etdocumentations par les bonnes personnes et au bon moment :

fournir données, informations et connaissances de bonne qualité et au bon moment aux bonnes personnes afinde minimiser le temps perdu à attendre les décisions (des personnes qui ne sont pas prévenues ou quirecherchent les informations pour prendre la décision).

s'assurer de formations et de transferts de connaissances vers les utilisateurs afin de réduire le nombre d'appelsau centre de services qui se transforment en formations par téléphone.

améliorer la qualité des données et des informations afin d'augmenter la satisfaction de toutes les partiesprenantes tout en optimisant les coûts d'exploitation et de maintenance.

améliorer la qualité de la documentation afin de réduire le nombre d'incidents et de problèmes causés par unemauvaise qualité des documentations d'utilisation, d'installation, de support et d'exploitation.

améliorer la qualité de la documentation d'installation et de déploiement afin de réduire le nombre d'incidents etde problèmes causés par une mauvaise synchronisation entre ce qui est installé en production et ce qui estdisponible en documentation durant la phase de déploiement du changement.

mettre en place un accès facile et rapide aux informations afin de réduire le temps perdu à chercher lesinformations nécessaires à ses activités, particulièrement durant des périodes critiques comme la résolution d'unincident majeur.

établir une source unique et officielle des informations et la faire partager tout au long du cycle de vie des servicesavec l'ensemble des parties prenantes afin d'augmenter la qualité des informations tout en minimisant lasurcharge de travail pour maintenir ces informations.

fournir des informations consolidées pour permettre à la gestion des changements et des mises en production deprendre des décisions pertinentes en faisant progresser un package d'installation au travers des différentsenvironnements de tests vers l'environnement de production.

Parmi les meileures pratiques, il est possible de citer :

15


Module

1fournir des interfaces et des outils de qualité pour accéder aux systèmes de gestion des connaissances (SKMS =Service Knowledge Management System) et des configurations (CMS = Configuration Management System) auxdifférents intervenants et rôles pour permettre les bonnes décisions au bon moment.

s'assurer que les informations de la gestion des configurations et des actifs de service sont gérées par desnotifications d'approbation et des transactions formalisées au travers d'outils de flux de travail (workflow tools)

Elaborer les packages d'installation et planifier leur déploiementLes packages d'installation sont conçus et élaborés dans les étapes de construction, de tests, de distribution etutilisés en environnement de production dans l'objectif de fournir les niveaux de traçabilité convenus avec unegestion des coûts efficace et efficiente.


les politiques de déploiement ont été convenues avec les organisations d'affaires et toutes les parties concernées.

les déploiements sont planifiés suffisamment à l'avance.

l'utilisation des ressources est optimisée dans les activités de la transition des services afin de réduire les coûts.

les ressources sont coordonnées durant les phases de livraison et de déploiement.

les mécanismes de distribution et d'installation sont prévus pour garantir l'intégrité des composants pendant lesétapes de livraison, de construction et de manipulation du package d'installation et d'installation en production.

les déploiements urgents sont tous gérés au travers de la procédure de gestion des changements urgents.

les risques de retour arrière ou de rattrapage d'une installation en erreur sont évalués et gérés.

les taux de succès et d'erreur des packages d'installation sont mesurés dans l'objectif d'améliorer efficacité etefficience tout en optimisant les coûts.


les versions définitives (programmes, fichiers, documentations) sont livrées dans la bibliothèque des supportsdéfinitifs (DML = Definitive Media Library) préalablement à l'installation en environnement de test de la production(appelé parfois environnement de pré-production).

les pré-requis et co-requis d'une mise en production (éléments préalables à l'installation et au fonctionnement dela mise en production : ceux indépendants du changement et ceux installés auparavant dans le cadre du mêmechangement) sont documentés et communiqués aux parties concernées (par ex. les pré-requis techniques d'unenvironnement de tests pour y dérouler un plan de tests).

Anticiper et gérer les écarts de trajectoireLes équipes sont formées à reconnaître la nécessité de réajustements par rapport à ce qui a été prévu et àappliquer les actions correctives nécessaires dans des limites connues et comprises.

En effet, la transition d'un changement peut être comparée à un voyage. Pour réussir son voyage, il faut non seulementbien le préparer mais aussi, pendant le voyage, être attentif aux conditions que l'on rencontre et adapter son voyage,certains facteurs, bien que prévisibles, ne sont pas sûrs à 100%, comme la météo par exemple.

Ainsi, il faut être capable de s'adapter aux conditions rencontrées tout en se tenant aux points essentiels de ce qui étaitprévu.


faire comprendre aux parties prenantes que la modification des plans (calendrier, réponse fonctionnelle, coûts,etc.) est nécessaire en cas de besoin et que cette attitude est encouragée.

capitaliser les expériences passées sur les corrections de plans passés afin d'en intégrer les causes dans lesfuturs plans et de réutiliser des approches qui ont fonctionné.

expliciter les écarts, ce qui a fonctionné et ce qui n'a pas marché dans les réunions de bilan avant la clôture d'unchangement, communiquer ce savoir aux acteurs et le déposer dans le systéme de gestion des connaissancesdes services (SKMS = Service Knowledge Management System).

prévoir et gérer les corrections de trajectoire eux-mêmes par les processus et procédures de la gestion deschangements.


utiliser les pratiques de gestion de projet et le processus de gestion des changements pour gérer la correctionsdes écarts.

16


Module

1éviter un processus de gestion des changements bureaucratique : il doit être plus facile de respecter le processusplutôt que de s'en passer avec toutes les conséquences que pourrait entraîner un changement non autorisé.

Gérer les ressources de manière pro-active tout au long des transitionsFournir et gérer les ressources partagées et spécialisées utilisées dans les activités de la transition des servicesafin d'éliminer les délais d'attente.


identifier dans l'organisation les ressources, les profils et les compétences nécessaires pour traiter la transitiondes services.

mettre en place des ressources dédiées pour traiter les activités critiques et ainsi réduire les délais.

Vérifier le plus tôt possible l'apport réel de valeur d'un changementMettre en place des contrôles et disciplines pour vérifier le plus tôt possible dans le cycle de vie des services qu'unnouveau service ou un service modifié sera capable de délivrer la valeur requise.


utiliser un ensemble de techniques pour maximiser la détection des erreurs de manière la plus précoce possibledans le but de réduire le coûts des rectifications (plus une erreur est détectée tard dans le cycle de vie, plus larectification coûte cher).

identifier les changements qui ne délivreront pas les bénéfices attendus et, soit modifier les exigences du service(demande initiale) soit stopper le changement avant que trop de ressources ne soient gaspillées (la décisiond'arrêter un changement en cours de traitement est difficile et douloureuse à prendre mais elle fait partie duprocessus de gestion des changements).


impliquer les clients ou les représentants des clients dans l'élaboration et la planification des tests pourcomprendre la manière de vérifier l'apport de valeur d'un service fourni aux services et processus d'affaires desclients.

impliquer aussi les utilisateurs dans l'élaboration et la planification des tests le plus possible : il faut plus baser lestests sur la manière dont les utilisateurs travaillent aujourd'hui plutôt que sur la manière d'utiliser le serviceimaginée par les concepteurs.

S'assurer de la qualité du futur service : exploitabilité et atteinte des niveaux deservice convenusVérifier et valider que le changement défini dans le dossier de conception d'un service (" package de conceptiond'un service" ou SDP = Service Design Package) et proposé aux équipes d'exploitation peut délivrer les exigencesde service et de niveaux de service et satisfaire les besoins d'affaires.


l'assurance qualité et les techniques de tests fournissent des méthodes pour s'assurer de la qualité et des risquesd'un futur service.

les environnements de tests doivent refléter le plus possible l'environnement de production tout en optimisant lesefforts de test.

la conception et l'exécution des tests devraient être gérés et réalisés indépendamment des équipes de conceptionet de développement afin d'accroître l'efficacité des tests et de respecter le principe de séparation des pouvoirs.

réaliser des évaluations indépendantes de la conception des services et du futur service afin d'identifier lesrisques devant être gérés et atténués pendant les étapes de construction, de tests et déploiement et la phased'exploitation du futur service (le processus d'évaluation des services permet d'affiner le traitement de chaquechangement afin de maximiser la probabilité que le service soit validé, notamment au travers des différents plansde tests à réaliser et au suivi des risques spécifiques du changement).


connaître les différences entre environnements de construction (ou d'intégration), de tests et de production demanière à prévoir le comportement du futur service en production à partir de son comportement dans cesenvironnements (en clair : il faut être sûr que, si le service se comporte correctement dans un environnement detest, des différences entre ce dernier et l'environnement de production ne vont pas induire un comportement

17


Module

1différent en production).

les environnements de tests doivent eux-mêmes être gérés par les processus de gestion des changements et desconfigurations et leurs adaptations éventuelles pour tester un futur service font aussi partie du changement (enclair : les installations et modifications des environnements de tests, comme les jeux de données ou leparamétrage des pré-requis sont des activités des processus de transition des services et doivent donc êtremodélisées dans les processus).

Améliorer de manière pro-active la qualité d'un futur service tout au long de satransitionPrévoir et traiter de manière pro-active (avant que le futur service n'arrive en production) la qualité du futur service(en clair : accompagner le changement afin de minimiser les risques de perturbation en production et de préparerles processus d'exploitation, comme les incidents et les problèmes, à gérer le futur service).


détecter et résoudre les incidents pendant la phase de transition pour réduire la probabilité d'incidents survenanten production en perturbant les activités clientes.

gérer de manière pro-active et réduire le nombre d'incidents, de problèmes et d'erreurs détectés dans la phase detransition afin de réduire les coûts, le travail de correction et l'impact sur les activités d'affaires des utilisateurs (enclair : améliorer la qualité des processus de transition et la stabilité des environnements de transition afind'améliorer l'efficacité et l'efficience du traitement d'un changement).

aligner la gestion des incidents, des problèmes et des erreurs pendant la transition des services avec lesprocessus en production de manière à mesurer et à gérer aisément l'impact des erreurs durant le cycle completdes services (en clair : cela permet de comparer les délais et les coûts de traitement d'une erreur et de quantifier legain de la détection et correction d'une erreur en fonction de la phase, conception, développement, tests, etc. parrapport à une détection en production).


comparer les aptitudes, performances et coûts prévus et réels d'un service pendant les phases pilote et de débutde vie du service de manière à identifier toute déviation et risque pouvant être corrigé ou atténué avant la clôturedu changement.

réaliser une évaluation indépendante du futur service pour identifier le profil de risque et établir des priorités surles risques devant être impérativement traités avant la clôture du changement, c'est-à-dire les risques de sécuritépouvant avoir un impact sur la garantie du service.

utiliser le profil de risque établi par l'évaluation du changement pour développer des tests spécifiques sur cesrisques.

définir et tester les outils de diagnostic et d'aide en collaboration avec le centre de services et les équipesd'exploitation et de support de manière à faciliter leur travail si quelque chose se passe mal en production avec lefutur service.

encourager les échanges d'informations et d'expérience entre les intervenants en phases de transition etd'exploitation afin d'améliorer le diagnostic des problèmes et leur délai de résolution, c'est-à-dire les solutions decontournement et solutions définitives.

mettre en place des procédures et des mesures de traitement des incidents, problèmes et erreurs en phase detransition qui reflètent celles utilisées en production (en clair : il faut aussi industrialiser et procédurer la gestiondes incidents, problèmes et erreurs survenant dans les environnements de transition, comme l'intégration ou lestests).

documenter toute résolution effectuée en phase de transition pour utilisation ultérieure éventuelle.

enregistrer, classer et mesurer le nombre et l'impact des incidents et problèmes à chaque phase du cycle de viedes services (tests, déploiement, production) afin d'identifier des opportunités d'identification et de résolution plusprécoces que ce qui est fait actuellement.

comparer le nombre et l'impact des incidents et problèmes entre les déploiements de manière à détecter desinitiatives d'amélioration et fixer tout problème dans la gestion de la conception et de la transition (par ex.évaluation des risques, tests, déploiement) qui amélioreront l'expérience des équipes dans les futursdéploiements.

mettre à jour les bases d'informations d'incidents et de problèmes avec les solutions de contournement etsolutions définitives identifiées en phase de transition du futur service.

18


Module

1

Réf. ITSM_M0400-V010-009

Gestion des changements Garantir que tous les changements sont autorisés et tracés

Gestion des actifs de service et Garantir que le référentiel des actifs de service et les configurations est complet etdes configurations à jour

Gestion des connaissances Améliorer la prise de décision de tout responsable par l’accès aux connaissancessur les services

Planification et support à la Planifier et gérer tous les moyens nécessaires aux transitions de servicetransition

Gestion des mises en production Assurer la traçabilité des packages de mise en productionet des déploiements Planifier et réussir les déploiements

Test et validation des services Garantir que le nouveau service ou service modifié est conforme à sesspécifications et répondra aux besoins (assurance-qualité)

Evaluation des changements Avoir un cadre cohérent et standardisé de règles pour déterminer la performancede chaque changement

19

Gestion des changementsITIL® - Transition des services

Module

2

Réf. ITSM_M0410-V010-001

Ambition (goals) du processusL'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 enré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 vontaligner les services sur les besoins d'affaires.

Objectifs (objective) du processusPour 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.

Objet (purpose) du processusPour 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 rapidede tous les changements.

s'assurer que tous les changements sur les items de configuration et les actifs de service sont enregistrés dans lesystè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.

20


Module

2

Réf. ITSM_M0410-V010-002

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

Ce qui est hors périmètreAux deux extrémités de l'échelle de taille des changements, il y a ce qu'on appelle communément des changements quisont 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éclencherontdes 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éssous la forme d'incidents incidents ou dans des procédures d’exploitation

21


Module

2

Réf. ITSM_M0410-V010-003

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

Changements non autorisés : 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 enurgence 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 detravail trop élevée sur les équipes de développement par rapport au nombre de ressources sont souvent àl'origine de ce symptôme

22


Module

2

Réf. ITSM_M0410-V010-004

Lorsqu'il s'agit d'initialiser une démarche ITIL®, la distribution des rôles de propriétaire de processus prend parfois desairs de remise de médaille. Or, il est un processus très difficile à concevoir si on veut un processus efficace dans toutesles situations : la gestion des changements. Son propriétaire ne va pas être à la fête. Mais personne ne lui a encore riendit.

Le processus doit rester efficace et ne pas être un parcours du combattant bureaucratique quel que soit son utilisation :grands et petits projets, modifications non traitées en mode projet, modifications techniques ou applicatives,modifications de l'environnement de production comme modifications sur n'importe laquelle des aptitudes de service.

Bref, les occasions et les prétextes seront nombreux dans l'utilisation au quotidien pour ne pas respecter le processus.

Voici ce qu'ITIL® recommande : déterminer rapidement si une procédure spécifique existe pour traiter la demande dechangement que l'on vient de recevoir.

Une démarche en arbre de décision alliant deux processusLa nature des demandes de changement est très variée : du projet stratégique initié par la gestion du portefeuille deservices (Change Proposal) en passant par des évolutions de service, voire même lorsqu'un utilisateur appellel'informatique pour demander à changer quelque chose (son écran ou la cartouche de toner de l'imprimante qui estvide).

Le premier niveau de tri permet de savoir s'il s'agit d'un changement standard (fréquent, bien maîtrisé et facile à traiterpour peu qu'il existe une procédure rôdée), d'un changement urgent ou d'un changement normal.

Un changement standard ne passe pas par le processus de gestion des changements, désoléUn changement standard possède sa procédure de traitement et peut être exécutée par du personnel ne nécessitant pasde compétences techniques pointues sur le domaine. Et pour cause, la procédure a été conçue, développée et testéeauparavant et la gestion des changements a pré-autorisée toute utilisation de cette procédure par le personnelexploitant. Cette demande sera donc traitée directement par le processus ITIL® d'exécution des requêtes (appelée aussifréquemment gestion des demandes utilisateurs ou des demandes de service).

Changement urgent : ne posez pas la question au demandeur, vous connaissez déjà laréponseLe critère urgent d'un changement s'évalue par rapport à des préoccupations business ou d'affaires et pas uniquementdes préoccupations du demandeur par rapport à son travail.

Le constat est simple : si on doit respecter normalement le processus, il est à peu près certain que sa mise en productionsera hors délai et cela pourra causer un tort important au business

23


Module

2.<

Dans ce cas, il faudra utiliser une procédure spécifique pour traiter ce changement urgent. Oui, il vaut mieux êtreorganisé dans ce cas-là et avoir préparé un certain nombre d'éléments histoire de ne pas perdre de temps sur deschoses évidentes (comme, par ex. pré-réserver des salles de réunion prioritairement à toute réunion en cours).

Changement normal : on passe normalement par le processus, eh oui, il en resteTous les autres changements, et ils sont encore très divers et variés, passent normalement par le processus.

Dans ce cas, le processus doit continuer à dérouler un arbre de décision pour mettre la main sur la procédure adaptée àchaque cas, si elle existe.

ITIL® suggère de sous-classifier en changement majeur, significatif et mineur. Il s'agit-là d'un exemple proposé par ITIL®mais on peut faire autrement : patch technique, patch applicatif, projet applicatif sans comité de pilotage, avec comité depilotage, etc.

Ensuite, il est possible d'utiliser des ramifications supplémentaires permettant d'aboutir à des procédures spécifiquescomme : "montée de version du micro-logiciel d'un routeur réseau de modèle XXX". Celle-là ne sera jamais traitée enchangement standard (essayez de deviner pourquoi).

Enfin, certaines demandes de changement, inédites, rares ou complexes à traiter, ne seront pas servies par uneprocédure et devront être traitées de manière génériques en respectant les activités décrites dans le processus.

Procédure oui mais, depuis 2007, cela s'appelle un modèle de processusL'irruption des concepts ISO/IEC 9000 dans ITIL® 2007 a apporté son lot de termes, dont celui de "modèle deprocessus". Ici, en l'occurrence, le modèle de changement.

Un modèle de changement permet de décrire de manière spécifique les activités du processus à mener pour un typeparticulier de demande de changement. L'utilisation d'un modèle de changement permet de gagner du temps, de laprécision et de diminuer les risques car les activités du processus sont décrites de manière plus concrète.

Définitions

Demande de changementUne demande de changement est une communication formelle visant à modifier un ou plusieurs éléments deconfiguration. 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 seramoins risqué et plus rapide de traiter de manière procédurée des demandes de nature identique plutôt que d'étudier etde 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 pourchaque changement, il reste néammoins impératif d'éviter une approche bureaucratique sous peine de rejet par lesintervenants. Tout l'art du propriétaire de processus va consister ici à mettre en place progressivement les contraintes etle niveau de bureaucratie en prenant en compte le retour d'expérience et les avis des intervenants.

Modèle de changementManière de pré-définir des étapes à suivre pour conduire un processus pour 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 processuspour un type de demande qui arrive de manière fréquente. La procédure étant plus détaillée, les acteurs cités dans laprocédure doivent respecter la procédure et n'ont plus à se préoccuper du processus général de gestion deschangements.

Le traitement de ces demandes particulières reste néammoins sous le contrôle du processus de gestion des

24


Module

2

Réf. ITSM_M0410-V010-005

Définition d'un changement standardUn changement standard est le résultat de la logique du modèle de changement poussée à l'extrême : il ne passe pluspar le processus de gestion des changements. Il s'agit, en effet, d'un changement dont la procédure de réalisation estconnue, maîtrisée et validée.

Pour certains types de changement qui reviennent souvent et qui ne sont pas des changements importants, il peut êtreintéressant de développer une procédure de réalisation, de la valider puis de l'appliquer de manière répétitive à chaquefois 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éduresstandard de réalisation.

A partir du moment où une telle procédure est en place pour un type de changement, ces changements sont ditsstandard.

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

il dispose d’une procédure reconnue et établie (éprouvée)

il 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

la mise à jour d’une application avec un impact mineur

Approbation de la demande : l’autorité est déléguée, par ex., au client (poste de travail) ou à un ingénieur d’une tiercepartie (remplacement d’une imprimante en panne)

Dès identification, un modèle de changement standard doit être développé et communiqué

Les changements standard seront traités dans le cadre du processus d’exécution des requêtes par le centre de services.

25


Module

2

Réf. ITSM_M0410-V010-006

Changement urgentIl s’agit d’un changement à implanter aussi rapidement que possible en raison des exigences de délai de la part duclient.

Exemple : déployer un patch de sécurité.

Changement normalTout changement qui n’est ni standard ni urgent est un changement normal.

Il passe « normalement » par le processus de gestion des changements.

26


Module

2

Réf. ITSM_M0410-V010-007

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 :

CS (Change Schedule) : calendrier des changements

PSO (Projected Service Outage) : calendrier des interruptions planifiées de serviceCette activité doit aussi penser aux plans de retour arrière !

Coordonner : inclut la construction du changement (développement, acquisition) et les tests

27


Module

2

Réf. ITSM_M0410-V010-008

Une grande partie des réponses à ces questions peut être apportée par l'initiateur de la demande au travers duformulaire 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 derisques et de résultats.

28


Module

2

Réf. ITSM_M0410-V010-009

CAB = Change Advisory Board

ECAB = Emergency Change Advisory Board

Rôle de gestionnaire des changementsCe 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 laplanification des changements (d'où probablement l'adjectif consultatif pour le CAB car le CAB conseille legestionnaire des changements mais c'est ce dernier qui a le dernier mot)

il préside les réunions du CAB

29


Module

2

Réf. ITSM_M0410-V010-010

Rôle d'autorité de changement : les différents niveauxIl existe différents niveaux d'autorité de changement.

Le schéma présente ces différents niveaux (ce schéma doit être adapté à l'organisation dans lequel le processus estprévu d'être mis en place), y compris les deux extrêmes qui sont hors périmètre du processus de gestion deschangements.

30

Planification et support à la transitionITIL® - Transition des services

Module

3

Réf. ITSM_M0420-V010-001


planifier et coordonner les ressources pour s'assurer que les exigences de la stratégie des services appliquéesdans la conception des services pour concevoir une approche globale sont effectivement respectées dansl'exploitation des services.

identifier, gérer et contrôler les risques de dysfonctionnements des activités de transition.

31

Planification et support à la transitionITIL® - Transition des services

Module

3

Réf. ITSM_M0420-V010-002

Objectifs (objective) du processusPour 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 lesestimations 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 afind’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’alignerleurs activités avec les plans de transition des services

Objet (purpose) du processusPour 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 etconfigurations 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 etparties prenantes appropriés.

coordonner les activités dans les projets, les interventions fournisseurs et les équipes internes quand cela s'avèrenécessaire.

32

Evaluation des changementsITIL® - Transition des services

Module

4

Réf. ITSM_M0430-V010-001

33

Evaluation des changementsITIL® - Transition des services

Module

4

Réf. ITSM_M0430-V010-002

34

Test et validation des servicesITIL® - Transition des services

Module

5

Réf. ITSM_M0440-V010-001

35

Test et validation des servicesITIL® - Transition des services

Module

5

Réf. ITSM_M0440-V010-002

36

Gestion des mises en production et des déploiementsITIL® - Transition des services

Module

6

Réf. ITSM_M0450-V010-001

37


Module

6

Réf. ITSM_M0450-V010-002


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.

Objectifs (objective) du processusPour 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 auxprojets 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 deconfigurations 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éssont 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 desupport.

s'assurer que les clients, les utilisateurs et les équipes informatiques impliqués dans la gestion des services sontsatisfaits des pratiques de la transition des services et des résultats qu'elle produit (c'est-à-dire la documentationutilisateur et la formation).


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'actifsassocié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ésde 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

38


Module

6dé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 dedé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é etprendre les actions correctives nécessaires.

s'assurer du transfert de connaissances pour permettre aux utilisateurs et clients d'optimiser leur utilisation duservice 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 pourleur permettre de fournir, supporter et maintenir le service conformément aux garanties et niveaux de serviceprévus.

39


Module

6

Réf. ITSM_M0450-V010-003

1. PlanifierCette 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 (build)

planification du déploiement

planification de la logistique et de la livraison

planification financière/commerciale

2. Préparer pour la construction, les tests et le déploiementCette activité consiste à :

planifier les ressources

lancer les actions de formation

3. Construction et testsCette activité possède un volet de fond et un volet à dérouler à chaque mise en production à gérer et chaquedé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)

40


Module

64. Planifier et se préparer au déploiementCette 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

5. Exécuter le transfert, le déploiement et le retraitCette 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 les ressources

transférer/déployer le service

supprimer les actifs redondants

6. Vérifier le déploiement

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.

8. Passer en revue et terminer un déploiementIl faut vérifier, entre autres, l’enregistrement correct et exhaustif des problèmes et erreurs connues rencontrées lors de cechangement (pour utilisation ultérieure, par ex. pour le support incidents).

9. Passer en revue et clôturer la transition du serviceCette 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

41


Module

6

Réf. ITSM_M0450-V010-004

42


Module

6

Réf. ITSM_M0450-V010-005

Modèle de mise en production et de déploiementComme pour le modèle de changement, le modèle de mise en production et de déploiement est une spécialisation duprocessus sur certains types courants de mises en production et de déploiements. Il s'agit, pour chacun de ces typescourants, de détailler le processus sous la forme de procédures et de documents standard que l'on utilisera en lieu etplace 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

43

Gestion des actifs de service et des configurationsITIL® - Transition des services

Module

7

Réf. ITSM_M0460-V010-001


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 fiablessur les configurations pour permettre aux intervenants de prendre des décisions au bon moment (c'est-à-dire pourautoriser 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 incorrectesde services et d'actifs.

optimiser les actifs de service, les configurations techniques (IT configurations), les aptitudes et les ressources.

44


Module

7

Réf. ITSM_M0460-V010-002


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 queconserver un historique de ces informations.


identifier, contrôler, enregistrer, réaliser les comptes-rendus, auditer et vérifier les items de configuration et lesactifs de service, comprenant les versions, les bases de référence (baselines), les sous-composants, leurs attributset 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 celaest approprié, les actifs de leurs clients) au travers du cycle de vie des services en s'assurant que seuls lescomposants 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 desTI en mettant en place et en utilisant un système complet de gestion des configurations (CMS = ConfigurationManagement System).

45


Module

7

Réf. ITSM_M0460-V010-003

CI = Configuration Item

CMS = Configuration Management System

CMDB = Configuration Management DataBase

46


Module

7

Réf. ITSM_M0460-V010-004

DML = Definitive Media Library

47


Module

7

Réf. ITSM_M0460-V010-005

48


Module

7

Réf. ITSM_M0460-V010-006

49


Module

7

Réf. ITSM_M0460-V010-007

1. Gérer et planifierCette 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 deformaliser son processus et de mettre en place les moyens nécessaires pour que le processus qui sera mis en placepuisse effectivement remplir ses objectifs.

2. Identifier les configurationsIl 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 (approchepar phase de la CMDB)

pour reprendre, modifier ou descendre à un niveau de détail plus fin toute partie existante de la CMDB (approcheitérative de la CMDB)

50


Module

7

Réf. ITSM_M0460-V010-008

3. Contrôler les configurationsLe principe à faire respecter est clair : aucun CI ne doit être ajouté, modifié, remplacé ou enlevé sans suivre uneprocédure de contrôle approprié.

Pour cela, il faut définir les procédures de mises à jour des CIs qui soient efficaces et utilisables par les différents acteursdu fournisseur de services.

4. Historiser et générer des rapports sur les états des CIsCette activité consiste à

définir formellement le changement d’état des CIs

fournir les données historiques et actuelles concernant chaque CI

5. Vérifier et auditer

51

Gestion des connaissancesITIL® - Transition des services

Module

8

Réf. ITSM_M0470-V010-001


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


permettre aux organisations d'améliorer la qualité des prises de décision en s'assurant que les données etinformations fiables et sécurisées soient disponibles tout au long du cycle de vie des services.


permettre au fournisseur de services d'être plus efficace et améliorer la qualité de service, augmenter lasatisfaction 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'ilsfournissent 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 informationsadéquates sur :

qui utilise actuellement leurs services

les niveaux actuels de consommation

les contraintes de la fourniture des services

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

52


Module

8

Réf. ITSM_M0470-V010-002

1. DonnéeUne 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).

2. InformationUne 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) surune 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 lacharge 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'ilait 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 nombred'incidents n'est pas liée à la mise en production des changements, étant donné la faible augmentation du nombre dechangements mis en production pendant la même période.

53


Module

83. ConnaissanceLa 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'autrescontextes externes à l'organisation afin d'avoir une meilleure connaissance et une interprétation élargie desphé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 desnouveaux 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 nouveausystème d'information), la dizaine de prestataires a été formée en une demi-journée au fonctionnement del'organisation informatique, certainement trop rapidement sur l'intérêt et l'obligation de respecter le processus degestion des changements

le responsable des mises en production n'est pas forcément en phase avec son équipe (ceux qui réalisent lesmises en production sur le terrain)

après discussion avec quelques techniciens réalisant les mises en production, il s'avère une dégradationimportante de la qualité des livraisons et, compte-tenu de l'urgence, certains contrôles ne sont plus pris en comptevoire 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 gestiondes 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èsimportante du nombre de « changements sauvages » réalisés par les nouveaux prestataires formés trop rapidement auxprocessus en vigueur à l'organisation informatique.

Ces « changements sauvages » sont, par essence, indétectables par les indicateurs de performance du processus degestion des changements.

S'il s'était contenté de son tableau de bord sur les indicateurs de performance (qui restent à un niveau correct), legestionnaire des changements serait passé à côté de l'explication de l'explosion du nombre d'incidents et ne se seraitpas remis en question alors qu'il est à l'origine du problème.

L'attitude qui consiste à se contenter du paradigme de son tableau de bord n'est pas la bonne. Il faut élargir ceparadigme 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 lesprestataires 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.

4. SagesseCette é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 dejugement de bon sens,

de s'adapter à de nouvelles situations et de lancer les actions d'adaptation de l'organisation, des personnes, desprocessus 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 del'organisation informatique.

Elle permet de prendre des décisions à long terme et des décisions stratégiques pour l'organisation informatique.

54


Module

8

Réf. ITSM_M0470-V010-003

SKMS : Service Knowledge Management System

55

ITIL® - La transition des services · ITILﬁ - Transition des services A propos du document Ce...

Documents

Transcript of ITIL® - La transition des services · ITILﬁ - Transition des services A propos du document Ce...