ITIL Fondamentaux

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

A propos de la Bibliothèque ITSM Les publications de la Bibliothèque ITSM couvrent les meilleures pratiques de la Gestion Informatique. Les publications suivantes sont disponibles ou le seront bientôt. Introduction, Fondations et Pratiques Foundations of IT Service Management based on ITIL® (V2, Arabic, Chinese, German, English, French, Italian, Japanese, Korean, Dutch, Brazilian Portuguese, and Russian; Danish and Spanish) Foundations of IT Service Management based on ITIL® (V3, English, Dutch) IT Service Management – An Introduction (V2, being replaced by V3, only a few languages left) IT Service Management – An Introduction (V3, English, Dutch) IT Services Procurement based on ISPL – An Introduction (Dutch) Project Management based on PRINCE2™ 2005 Edition (Dutch, English, German)Release & Control for IT Service Management, based on ITIL® – A Practitioner Guide (English) ISO/IEC 20000 – An Introduction (English; Brazilian, Japanese, Chinese, Spanish and German due 2008) Gestion des Services Informatiques – meilleures pratiques IT Service Management – best practices, part 1 (Dutch) IT Service Management – best practices, part 2 (Dutch) IT Service Management – best practices, part 3 (Dutch) IT Service Management – best practices, part 4 (Dutch) IT Service Management, Global Best Practices – Volume 1 (English) Dossiers & Instruments de Gestion Metrics for IT Service Management (English)Implementing Metrics for IT Service Management (English) Six Sigma for IT Management (English) The RfP for IT Outsourcing – A Management Guide (Dutch) Service Agreements – A Management Guide (English) Frameworks for IT Management (English, German, Japanese) IT Governance based on COBIT® – A Management Guide (English, German) Implementing ISO/IEC 20000 Certification – The Roadmap (English) Guides de poche IT Service Management – A summary based on ITIL® (V2, Dutch) IT Service Management based on ITIL V3 – A Pocket Guide (V3, English, Dutch) IT Service Management from Hell!! (V2, English) IT Service Management from Hell. Based on Not-ITIL (V3, English) ISO/IEC 20000 – A Pocket Guide (English, German, Japanese, Italian, Spanish, formerly BS 15000 – A Pocket Guide) IT Services Procurement based on ISPL – A Pocket Guide (English) IT Service CMM – A Pocket Guide (English) Six Sigma for IT Management – A Pocket Guide (English) Frameworks for IT Management – A Pocket Guide (English, Dutch) Pour toutes demandes de renseignements sur la Bibliothèque ITSM, veuillez consulter les sites suivants : http://www.itsmbookshop.com or www.vanharen.net.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

IV

Colophon Titre :

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Rédaction :

Jan van Bon (chief editor) Arjen de Jong (co-author, Inform-IT) Axel Kolthof (co-author, Inform-IT) Mike Pieper (co-author, Inform-IT) Ruby Tjassing (co-author, Inform-IT) Annelies van der Veen (co-author, Inform-IT) Tieneke Verheijen (co-author, Inform-IT)

Maison d’édition Van Haren Publishing, www.vanharen.net ISBN :

978 90 8753 058 7

Copyright:

© Van Haren Publishing 2009

Edition :

Première édition, première impression, Janvier 2009

Conception Et mis en page

CO2 Premedia bv, Amersfoort – NL

Édition française : Première impression, première édition, 2009 © Van Haren Publishing 2009 Aucune partie de la présente publication ne peut être reproduite sous quelque forme que ce soit, par impression, photographie, microfilm et par tout autre moyen sans l’autorisation écrite de l’éditeur. Although this publication has been composed with much care, neither author, nor editor, nor publisher can accept any liability for damage caused by possible errors and/or incompleteness in this publication. © Crown copyright. Published under license from the Controller of Her Majesty’s Stationery Office. ITIL Glossaries/Acronyms © Crown Copyright Office of Government Commerce. Reproduced with the permission of the Controller of HMSO and the Office of Government Commerce. ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office. TRADEMARK NOTICES ITIL® and PRINCE2™ are Registered Trade Marks and Registered Community Trade Marks of the Office of Government Commerce, and are Registered in the U.S. Patent and Trademark Office. COBIT® is a registered trademark of the Information Systems Audit and Control Association (ISACA)/IT Governance Institute (ITGI). The PMBoK® is a registered trademark of the Project Management Institute (PMI). Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

V

Avant-propos Je suis très fier de présenter cette mise à jour minutieuse de “Les fondamentaux de la gestion des services informatiques selon ITIL V3”. Suite à la nouvelle édition tant attendue d’ITIL®, lancée en juin 2007, ce guide sur les fondamentaux d’ITIL se devait d’être complètement revu pour se conformer à son objectif : fournir une introduction simple aux ouvrages de la vaste bibliothèque d’ITIL, pour en faciliter la compréhension et favoriser la diffusion de ce référentiel en tant que standard industriel. En outre, nous sommes les premiers sur le marché à proposer ce service. Ce guide met l’accent sur le cycle de vie des services, selon la définition d’ITIL. Les informations sur le cycle de vie sont extraites de la vaste documentation disponible dans les ouvrages de référence, et sont concentrées dans la première partie du livre. Les informations concernant les processus et les fonctions, qui sont également décrits dans les ouvrages de référence, sont regroupées dans la seconde partie. Cette approche permet aux lecteurs de bien saisir la structure du cycle de vie, tout en mettant à leur disposition toutes les informations concernant les processus et les fonctions. Ce livre a été réalisé de la même façon que les autres publications de la bibliothèque ITSM : une grande équipe d’experts, de rédacteurs et de relecteurs ont contribué à produire un texte très complet. Puis beaucoup d’efforts ont été fournis pour revoir le manuscrit. En fait, le contenu de l’ouvrage a été développé dans le cadre d’un projet d’édition plus vaste, couvrant non seulement ITIL, mais aussi de manière plus générale, la gestion de services informatiques. Ce projet a donné lieu à ce volume de la bibliothèque ITSM “Gestion des services informatiques - Une Introduction”, un ouvrage de plus de 500 pages sur l’ITSM, ITIL, ISO/IEC 20000 et de nombreuses autres normes et cadres de travail concernant la gestion des services informatiques. Tout le contenu concernant ITIL V3 s’intègre dans cette collection et a permis de constituer cette introduction exhaustive à ITIL. Pendant plusieurs années, le livre “Les fondamentaux de gestion des services informatiques selon ITIL” a servi de référence à une importante série de guides de gestion, qui trouvent facilement leur place dans toute bibliothèque. Nous espérons que cette nouvelle édition poursuive ce chemin. Jan van Bon Rédacteur en chef de la bibliothèque ITSM

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

VI

Remerciements Cette publication est le fruit de la coopération de nombreux experts du secteur, venants de différents pays, représentant aussi bien les utilisateurs, les fournisseurs, les autorités, les formateurs que les examinateurs. Elle repose sur un ouvrage itSMF publié pour la première fois aux Pays-Bas en avril 1999, conçu pour servir d’introduction à la gestion de services informatiques. Au départ le livre fut commencé par Georges Kemmerling (Quint Wellington Redwood), associé à une équipe itSMF néerlandaise, guidée par le rédacteur en chef, Jan van Bon. Depuis 1999, cette équipe, composée de co-auteurs et de relecteurs s’est enrichie pour améliorer l’ouvrage, par une série de nouvelles éditions, reflétant les développements de la gestion des services informatiques. En mai 2002, la première traduction est publiée en anglais. Cette première édition allait bientôt être suivie par une seconde, enrichie et révisée par des membres sélectionnés de l’itSMF, en coopération avec l’IPESC (itSMF International Publications Committee), chacun représentant une section de l’itSMF. Cette édition globale a également fait l’objet d’une révision de la part de plusieurs experts, aussi bien membres de fournisseurs que de clients, ainsi que par des représentants de l’OGC (Office of Government Commerce. Cet ouvrage fut la première publication approuvée par l’itSMF, ainsi qu’à recevoir le soutien de toute la communauté itSMF et à être acceptée en tant qu’introduction de haute qualité à ITIL® et à la gestion des services informatiques. L’ouvrage a rendu d’excellents services en facilitant la compréhension des meilleures pratiques de gestion des services informatiques, autour des publications ITIL, dans de nombreux pays. Depuis 2002, d’autres traductions sont apparues. Chacune étant le fruit d’un développement et d’une révision de la part d’une équipe d’experts se trouvant dans chaque pays, si possible associée à une section de l’itSMF. Dans tous les cas, les experts se sont tous accordés sur la terminologie avant de traduire le texte. Les traductions ont été fournies en anglais, allemand, français, espagnol, russe, chinois, japonais, italien, coréen, portugais brésilien, arabe et danois. En 2004, l’ouvrage a été scindé en deux publications séparées : la première couvre le vaste secteur de la gestion des services informatiques (correspondant à une Introduction), et la seconde sert principalement à comprendre les fondamentaux d’ITIL (correspondant aux Fondamentaux ). En 2007, les deux livres ont été largement réécrits suite à d’importantes modifications dans la gestion des services informatiques. Nous avons alors décidé de créer une publication exhaustive qui contiendrait les contenus des deux ouvrages, que nous avons ensuite scindés en deux : le premier ouvrage traite de la gestion des services informatiques ; le second est un extrait du premier et ne couvre qu’ITIL. Une équipe d’auteurs et de rédacteurs experts a produit le texte mis à jour (voir le Colophon). Comme pour toute publication de la bibliothèque ITSM, une grande équipe de relecteurs a été constituée, représentant des experts issus de différentes disciplines, des d’utilisateurs, des formateurs, des consultants, des leaders internationaux dans l’industrie des services informatiques ainsi que des experts individuels.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

VII

Tous ces experts sont profondément impliqués dans la mise en œuvre d’ITIL au quotidien. La plupart d’entre eux avaient déjà collaboré à la révision de l’un ou plusieurs ouvrages sur ITIL, ou bien étaient impliqués dans le projet de mise à jour d’ITIL. Ce texte principal donna également naissance à une troisième publication : un guide de poche concernant les référentiels de gestion de services informatiques. De cette façon, les relecteurs travaillèrent en réalité sur trois publications à partir d’un seul manuscrit. Les relecteurs du manuscrit Les fondamentaux de la gestion des services informatiques selon ITIL V3 sont : John van Beem, ISES International, Pays-Bas Aad Brinkman, Apreton, Pays-Bas Peter Brooks, PHMB Consulting, itSMF Afrique du Sud Rob van der Burg, Microsoft, Pays-Bas Judith Cremers, Getronics PinkRoccade Educational Services, Pays-Bas Robert Falkowitz, Concentric Circle Consulting, itSMF Suisse Rosario Fondacaro, Quint Wellington Redwood, Italie Peter van Gijn, LogicaCMG, Pays-Bas Jan Heunks, ICT Partners, Pays-Bas Linh Ho, Compuware Corporation, États-Unis Ton van der Hoogen, ToTZ Diensten, Pays-Bas Kevin Holland, NHS, Royaume-Uni Matiss Horodishtiano, Amdocs, itSMF Israël Wim Hoving, BHVB, Pays-Bas Brian Johnson, CA, États-Unis Georges Kemmerling, Quint Wellington Redwood, Pays-Bas Kirstie Magowan, itSMF Nouvelle-Zélande Reiko Morita, Ability InterBusiness Solutions, Inc., Japon Jürgen Müller, Marval Benelux, Pays-Bas Ingrid Ouwerkerk, Getronics PinkRoccade Educational Services, Pays-Bas Ton Sleutjes, CapGemini, Pays-Bas Maxime Sottini, Innovative Consulting, itSMF Italie Takashi Yagi, Hitachi Ltd., itSMF Japon Leurs contributions sont fortement appréciées et, suite à leur révision détaillée, ils ont contribué à améliorer de façon significative la qualité de l’ouvrage. Les éditeurs sont extrêmement reconnaissants à Claude Durand (Trésorier de l’itSMF France) et à Romain Hennion de Thyses (ITIL Service Manager et Rédacteur en Chef d’itSMF Mag), pour leur dévouement sur cette édition française. Nous avons non seulement gagné un livre de référence sur la gestion des services, mais aussi le plaisir de partager leur approche professionnelle et leur extrême courtoisie sur ce projet. Étant donné le désir de recueillir le consensus le plus large dans le secteur de la gestion des services informatiques, nous accueillons volontiers tout matériel additionnel et contributions de la part de professionnels des services informatiques, qui ont travaillé avec la version 3

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

VIII

d’ITIL. Les rédacteurs en discuteront. Et lorsque que leurs travaux seront pertinents, ceux-ci seront intégrés dans les nouvelles éditions. Tout commentaire peut être envoyé au Rédacteur en Chef de la bibliothèque ITSM, Monsieur Jan van Bon, par e-mail à l’adresse suivante : [email protected].

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

IX

Table des matieres Avant-propos���������������������������������������������������������������������������������������������������������������������V Remerciements����������������������������������������������������������������������������������������������������������������VI

1 Introduction........................................................................................................1 1.1 1.2 1.3 1.4 1.5 1.6

Aperçu historique.......................................................................................................1 Pourquoi ce livre.........................................................................................................2 Organisations.............................................................................................................2 Différences avec les éditions précédentes................................................................4 Structure de l’ouvrage................................................................................................5 Commet utiliser cet ouvrage......................................................................................6

PARTIE 1  LE CYCLE DE VIE DES SERVICES

7

2 Introduction au cycle de vie des services......................................................9 2.1 2.2 2.3 2.4 2.5

Introduction à ITIL......................................................................................................9 Gouvernance informatique....................................................................................... 10 Maturité organisationnelle........................................................................................ 11 Bénéfices et risques des référentiels ITSM............................................................. 14 Cycle de vie des services : Concept et vue d’ensemble......................................... 15

3 Phase de cycle de vie : la stratégie des services........................................21 3.1 3.2 3.3 3.4 3.5 3.6

Introduction.............................................................................................................. 21 Concepts de base.................................................................................................... 24 Processus et autres activités...................................................................................32 Organisation.............................................................................................................46 Méthodes, techniques et outils�������������������������������������������������������������������������������53 Mise en œuvre���������������������������������������������������������������������������������������������������������58

4 Phase de cycle de vie : la conception des services....................................71 4.1 4.2 4.3 4.4 4.5 4.6

Introduction.............................................................................................................. 71 Concepts de base��������������������������������������������������������������������������������������������������� 76 Processus et autres activités����������������������������������������������������������������������������������79 Organisation.............................................................................................................88 Méthodes, techniques et outils................................................................................89 Mise en œuvre���������������������������������������������������������������������������������������������������������92

5 Phase de cycle de vie : la transition des services.......................................97 5.1 5.2 5.3 5.4 5.5 5.6

Introduction.............................................................................................................. 97 Concepts de base....................................................................................................99 Processus et autres activités.................................................................................100 Organisation���������������������������������������������������������������������������������������������������������� 104 Méthodes, techniques et outils.............................................................................. 110 Mise en œuvre........................................................................................................ 110

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

X

6 Phase de cycle de vie : l’exploitation des services................................... 113 6.1 6.2 6.3 6.4 6.5 6.6

Introduction............................................................................................................ 113 Concepts de base.................................................................................................. 114 Processus et autres activités................................................................................. 118 Organisation���������������������������������������������������������������������������������������������������������� 126 Méthodes, techniques et outils.............................................................................. 140 Mise en œuvre........................................................................................................ 141

7 Phase de cycle de vie : l’amélioration continue des services..................145 7.1 7.2 7.3 7.4 7.5 7.6

Introduction............................................................................................................ 145 Concepts de base.................................................................................................. 147 Processus et autres activités................................................................................. 152 Organisation........................................................................................................... 155 Méthodes, techniques et outils.............................................................................. 159 Mise en œuvre........................................................................................................ 166

PARTIE 2­  FONCTIONS ET PROCESSUS

177

8 Introduction aux fonctions et aux processus............................................179 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8

Introduction............................................................................................................ 179 Gestion des processus.......................................................................................... 180 Équipes, rôles et positions en ITSM (Gestion des Services Informatiques)�������� 184 Outils utilisés en ITSM............................................................................................ 184 Communication dans des organisations de service informatique........................ 185 Culture.................................................................................................................... 186 Processus, projets, programmes et portefeuilles.................................................. 186 Fonctions et processus dans les phases du cycle de vie..................................... 188

9 Fonctions et Processus dans la Stratégie des services...........................189 9.1 Gestion financière.................................................................................................. 189 9.2 Gestion du Portefeuille des Services (SPM).......................................................... 195 9.3 Gestion de la demande.......................................................................................... 198

10 Fonctions et processus dans la Conception des services...................... 203 10.1 Gestion du catalogue des services.......................................................................203 10.2 Gestion des niveaux de service............................................................................. 207 10.3 Gestion de la capacité........................................................................................... 211 10.4 Gestion de la disponibilité...................................................................................... 218 10.5 Gestion de la continuité des services informatiques.............................................226 10.6 Gestion de la sécurité informatique....................................................................... 231 10.7 Gestion des fournisseurs....................................................................................... 237

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

XI

11 Fonctions et Processus dans la Transition des Services.........................241 11.1 Planification et support de la transition................................................................. 241 11.2 Gestion des changements..................................................................................... 246 11.3 Gestion des actifs de service et des configurations �������������������������������������������256 11.4 Gestion des mises en production et des déploiements ....................................... 267 11.5 Validation et tests des services............................................................................. 276 11.6 Évaluation��������������������������������������������������������������������������������������������������������������283 11.7 Gestion des connaissances...................................................................................286

12 Fonctions et Processus dans l’exploitation des services����������������������� 291 12.1 Gestion des événements .......................................................................................291 12.2 Gestion des incidents............................................................................................297 12.3 Gestion des demandes..........................................................................................303 12.4 Gestion des problèmes..........................................................................................306 12.5 Gestion des accès.................................................................................................. 313 12.6 Surveillance et contrôle.......................................................................................... 316 12.7 Opérations informatiques...................................................................................... 321 12.8 Centre de services................................................................................................323

13 Fonctions et processus dans l’amélioration continue des services������ 329 13.1 Processus d’amélioration CSI................................................................................329 13.2 Rapport des services.............................................................................................339 Références.....................................................................................................................343 Glossaire........................................................................................................................345 Index...............................................................................................................................405

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

XII

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 1

Introduction 1.1 Aperçu historique Le développement des technologies de l’information a eu un énorme impact sur les métiers au cours de cette dernière décennie. Depuis l’émergence de matériels informatiques extrêmement puissants, de logiciels à usages multiples et de réseaux très rapides, tous connectés les uns aux autres au niveau mondial, les organisations ont fortement développé leurs produits et leurs services informatiques. Aussi, leur mise sur le marché a été très rapide. Ces développements ont marqué la transition de l’ère Industrielle à l’ère Informatique. Dans l’ère informatique, tout est devenu plus rapide, plus dynamique et tout y est connecté. Les organisations hiérarchiques traditionnelles éprouvent souvent des difficultés pour s’adapter à ce marché extrêmement fluctuant. Les organisations ont alors tendance à devenir plus plates et plus flexibles. Elles passent d’une structure en silos verticaux, à des processus horizontaux. Les pouvoirs décisionnels sont de plus en plus confiés aux employés. C’est dans ce contexte que les processus opérationnels de gestion des services informatiques voient le jour. Pour les organisations, l’énorme avantage d’une structure qui repose sur des processus, est de favoriser une approche orientée client. Cela augmente de façon significative l’alignement entre l’organisation des services informatiques (responsable de la fourniture de l’information) et le client (responsable de l’utilisation de ces systèmes informatiques pour leur métier). Au cours des dernières années, cette tendance a fait l’objet de toutes les attentions et porte le nom d’Alignement Métier-IT (Business IT Alignement ou BITA). Plus les organisations acquièrent de l’expérience en matière d’approche orientée processus en gestion des services informatiques, plus il devient évident que tout processus doit être géré de façon cohérente. Parallèlement, il est certain que l’introduction d’une méthode de travail orientée processus entraîne de grands changements dans les organisations hiérarchiques et orientées projets. La culture et la gestion du changement deviennent des éléments critiques pour bien structurer toute organisation.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

2

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Une autre leçon importante à tirer est que l’organisation des services informatiques ne doit pas se perdre dans une culture de processus. De même, une organisation uniquement orientée projets ou orientée processus, n’apporte pas une structure optimale. L’équilibre est, comme d’habitude, le mot magique. Il est également évident qu’une approche orientée client exige la mise en place d’une approche bout-en-bout et centrée sur le client : rien ne sert de savoir que “le serveur est encore en production” si le système informatique n’est pas disponible pour l’utilisateur. Les services informatiques doivent être envisagés dans un contexte plus large. Il devient vite nécessaire d’adopter une approche de type cycle de vie, intégrant le cycle de vie des services et la gestion des services informatiques. Étant donné que le métier dépend toujours plus de l’information, la qualité des services informatiques dans les entreprises est de plus en plus sujette à des exigences internes et externes. Le rôle des normes devient de plus en plus important, et les référentiels de meilleures pratiques aident au développement d’un système de gestion visant à satisfaire ces exigences. Les organisations qui ne contrôlent pas leurs processus ne seront pas capables d’atteindre de bons résultats concernant leur cycle de vie des services et leur gestion de bout-en-bout de ces services. En outre, celles qui n’ont pas une structure interne ordonnée n’atteindront pas non plus de bons résultats. Voilà pourquoi tous ces aspects sont traités simultanément dans cet ouvrage.

1.2 Pourquoi ce livre Ce livre fournit des informations détaillées aux responsables des questions stratégiques de l’information ainsi qu’au (plus grand) groupe de ceux chargés de mettre en place et de fournir des systèmes d’information. Ces arguments reposent sur la description du cycle de vie des services, tel que décrit dans la version 3 d’ITIL et sur la présentation des processus associés. Les ouvrages ITIL de base traitent ces questions avec exhaustivité. Ils permettent une étude approfondie des meilleures pratiques actuelles. Cet ouvrage Les fondamentaux fournit au lecteur une introduction claire pour aborder la vaste bibliothèque d’ouvrages de base sur ITIL, afin de favoriser leur compréhension et de participer à la diffusion d’ITIL comme standard industriel. Une fois la structure ITIL assimilée, le lecteur pourra utiliser les ouvrages de base pour une compréhension plus approfondie et être guidé dans sa pratique quotidienne.

1.3 Organisations Plusieurs organisations participent à l’évolution d’ITIL comme description des “meilleures pratiques” appliquées à la gestion des services informatiques.

OGC Au départ, ITIL appartenait au CCTA, une organisation gouvernementale britannique. Le 1er avril 2001, le CCTA a été intégré à l’Office of Government Commerce (OGC), qui est ainsi devenu le nouveau propriétaire d’ITIL. Le but de l’OGC est d’aider ses clients (au sein du gouvernement britannique) à moderniser leurs activités de fourniture en services et à les améliorer, en optimisant, entre autre, l’utilisation de l’informatique : “L’OGC entend la fourniture au sein du gouvernement, et à contribuer à d’importantes améliorations de rentabilité. L’OGC cherche alors à promouvoir l’utilisation des meilleures pratiques” dans de nombreux domaines, tels que la gestion de projets, la gestion des programmes, la fourniture, la gestion des risques et

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction

3

la gestion des services informatiques. C’est pourquoi l’OGC a également publié plusieurs séries d’ouvrages (bibliothèques) écrits par des experts (internationaux) issus de différentes entreprises et organisations.

itSMF Cette publication s’adresse à toute personne impliquée dans la gestion des services informatiques ou qui s’y intéresse. Une organisation professionnelle, travaillant au développement de la gestion des services informatiques, a été créée spécifiquement à cet effet. Ainsi, en 1991, le IT Service Management Forum (forum de gestion de services informatiques – itSMF), à l’origine appelé IT Infrastructure Forum (Forum d’infrastructure informatique – ITIMF), a vu le jour sous forme d’association, au Royaume-Uni. En 1994, suivant l’exemple britannique, une association consœur s’est établie aux Pays-Bas. Depuis lors, des organisations itSMF indépendantes ont été montées dans plus de quarante pays, réparties dans le monde entier, et le nombre de chapitres continue de grandir. Toutes les organisations itSMF opèrent sous l’égide de l’association-chapeau, itSMF International (itSMF-I). L’itSMF s’adresse à tous les professionnels de la gestion des services informatiques. Elle assure la promotion, les échanges d’informations et d’expériences, dont les organisations informatiques peuvent se servir pour améliorer leur fourniture de services. L’itSMF s’occupe également de l’utilisation et de la qualité de plusieurs standards et méthodes qui font référence dans ce domaine. ITIL en est l’un d’eux. L’itSMF International a également passé un accord avec l’OGC et le Groupe APM pour promouvoir l’utilisation d’ITIL. Le forum de gestion des services informatiques (itSMF) est une organisation à but non lucratif, globale, indépendante, reconnue à un niveau international, consacrée à la gestion des services informatiques. L’itSMF est entièrement la propriété de ses membres et principalement dirigée par ceux-ci. De plus en plus de chapitres nationaux voient le jour, chacun ayant un haut degré d’autonomie, mais tous adhèrent à un code de conduite commun. L’itSMF exerce une très grande influence en contribuant à l’adoption des meilleures pratiques industrielles ainsi qu’aux standards internationaux, travaillant en partenariat avec une grande variété d’organisations internationales gouvernementales et de normalisation. L’itSMF International est l’organisme de contrôle des chapitres nationaux ; il établit les politiques et fournit des directives pour promouvoir les objectifs généraux de l’itSMF, pour favoriser l’adoption des meilleures pratiques d’IT Service Management (gestion des services informatiques – ITSM) et pour garantir l’adhésion aux politiques et standards de l’itSMF. Cet ouvrage Les fondamentaux est une publication d’itSMF International, dans la collection de la bibliothèque ITSM. Ce livre est conforme à la mission d’itSMF International : La mission d’itSMF International consiste à favoriser le développement de la gestion des services Informatiques (ITSM), en appliquant une stratégie, et en coordonnant ses efforts avec des partenaires qui apportent d’expertise et de support financier

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

4

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Cette mission se décline dans les activités suivantes : Activités de publication itSMF : - publier du matériel de support concernant les meilleures pratiques acceptées - publier du matériel qui représente les “nouvelles perspectives” dans le secteur de l’ITSM - garantir qu’à travers toutes les activités, y compris la publication de matériel pertinent, l’itSMF aide les organisations à mettre en place des solutions qui seront vraiment sources de valeur. En publiant cette introduction exhaustive sur la gestion des services informatiques selon ITIL, l’itSMF International apporte une contribution précieuse à son développement.

Groupe APM En 2006, l’OGC a signé un contrat pour la gestion des droits ITIL, la certification des examens ITIL et l’accréditation des organisations de formation avec le Groupe APM (APMG), une organisation commerciale. L’APMG définit la certification et l’accréditation pour les examens ITIL, et a publié le nouveau système de certification (voir Section 2.1 : examens ITIL).

Organismes examinateurs La fondation Néerlandaise Stichting Examen Instituut voor Informatica (Institut pour les Examens Informatiques – EXIN) et le Information Systems Examination Board anglais (comité d’examens des systèmes informatiques – ISEB, qui fait partie de la British Computer Society (société britannique d’informatique – BCS) ont collaboré au développement et à la diffusion d’une certification pour la gestion des services informatiques. Ces deux organisations ont longtemps été les seules à gérer les examens ITIL. Le contrat passé entre l’APMG et l’OGC attribue la responsabilité des examens ITIL exams à l’APMG. Pour favoriser la fourniture d’examens ITIL dans le monde, l’APMG a accrédité un certain nombre de comités d’examens : EXIN, BCS/ ISEB, et le Loyalist College, Canada.

1.4 Différences avec les éditions précédentes Le livre “Les fondamentaux de gestion de services informatiques – selon ITIL V2” a longtemps joué un rôle clé quant à la diffusion des concepts de gestion de services informatiques et ITIL. L’ouvrage a été traduit en treize langues. Il est considéré comme l’introduction la plus utile aux meilleures pratiques. Les éditions précédentes de l’ouvrage Les fondamentaux se concentraient sur le contenu des trois livres de la série ITIL (Version 2) : Support des services, fourniture des services et gestion de la sécurité, en les plaçant dans un contexte plus général de gestion de la qualité. La principale différence entre les versions 2 et 3 d’ITIL se trouve dans l’approche Cycle de Vie, introduite avec ITIL version 3. Tandis que la version 2 se concentrait sur les pratiques regroupées en Fourniture, Soutien et Sécurité des Services IT, la version 3 englobe tout le cycle de vie de services IT. Le développement continu des meilleures pratiques a entraîné la disparition de plusieurs termes lors du passage de la version 2 à la version 3 de l’introduction à ITIL et l’ajout d’un grand nombre de nouveaux termes dans la version 3. Puisque beaucoup de ces concepts font partie du périmètre de la formation ou de l’examen concernant la gestion des services informatiques, ils ont été

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction

5

inclus dans les descriptions correspondantes. Pour obtenir une liste définitive de ces concepts, les lecteurs devraient consulter les différents programmes de formation et d’examens.

1.5 Structure de l’ouvrage Ce livre commence par une introduction sur l’histoire et les grands principes de la gestion des services informatiques ainsi que le contexte d’ITIL (Chapitre 1). Celle-ci décrit les parties concernant le développement des meilleures pratiques, les normes régissant la gestion des services informatiques ainsi que les prémices et les standards utilisés. Le coeur du livre se divise en deux parties : la première traite du cycle de vie des services, la seconde développe toutes les fonctions et processus d’ITIL. La première partie commence avec le Chapitre 2, introduisant le cycle de vie des services, dans le contexte de la gestion des services informatiques et de la gouvernance informatique. Elle détaille les principes de la maturité d’une organisation, ainsi que les avantages et les risques d’adopter un référentiel de gestion des services. Ce chapitre conclue sur une introduction au cycle de vie des services. Dans les Chapitres de 3 à 7, chacune des phases du cycle de vie des services est traitées en détails, selon la structure d’ITIL : la stratégie des services, la conception des services, la transition des services, l’exploitation des services, et l’amélioration continue des services. Ces chapitres proposent une vue détaillée des caractéristiques du cycle de vie des services, leur construction et ses éléments constituants. Les points principaux de chaque phase sont présentés de façon cohérente pour en clarifier la lecture et la clarté, et faire en sorte que le texte soit clair et facile à lire. Chaque section s’appuie systématiquement sur une même structure cohérente : • Introduction • Concepts de base • Processus et autres activités • Organisation • Méthodes, techniques et outils • Mise en œuvre La seconde partie commence avec le Chapitre 8, en introduisant les fonctions et les processus auxquels se réfèrent chacune des phase du cycle de vie. Ce chapitre fournit des informations générales sur les principes des processus, des équipes, des rôles, des fonctions, des positions, des outils et tout autre élément digne d’intérêt. Ensuite, les processus et les fonctions sont décrits en détails dans les Chapitres de 9 à 13. Les 27 fonctions et processus sont regroupés selon l’ouvrage ITIL de base, qui contient une description détaillée de chacun d’eux. Chaque processus ou fonction est décrit de la façon suivante : • Introduction • Activités, méthodes et techniques • Interfaces, entrées et sorties • Métrique et indicateurs-clé de performance (KPI) • Mise en œuvre, avec les facteurs-clés de succès (CSF), les défis, les risques et les pièges

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

6

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les Annexes fournissent des sources utiles pour le lecteur. Une liste des références et des sources est fournie ainsi que le glossaire officiel ITIL. Le livre se termine par un sommaire exhaustif des termes pertinents qui aideront le lecteur à définir des éléments du texte.

1.6 Commet utiliser cet ouvrage Les lecteurs avant tout intéressés par le cycle de vie des services peuvent se concentrer sur la première partie du livre, puis ne prendre en considération que ce dont ils ont besoin quant aux fonctions et processus de la seconde partie. Les lecteurs avant tout intéressés aux fonctions et aux processus, et qui ne sont pas encore prêts à gérer une approche de cycle de vie, ou qui préfèrent une approche par processus, peuvent lire les chapitres d’introduction, puis se concentrer sur les fonctions et les processus qui les intéressent. Les lecteurs qui préfèrent une introduction complète à ITIL, notamment par l’exploration de son périmètre et de ses principales caractéristiques, peuvent commencer par la première partie du cycle de vie, et enrichir leur lecture par les fonctions et processus décrits dans la seconde partie. En cela, cette nouvelle édition du livre “Fondamentaux” fournit un support à une variété d’approches de la gestion des services informatiques selon ITIL.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

PARTIE 1

LE CYCLE DE VIE DES SERVICES

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 2

Introduction au cycle de vie des services 2.1 Introduction à ITIL Dans les années 80, la qualité des services fournis aux départements du gouvernement britanniques, par les sociétés informatiques tant internes qu’externes, était tellement mauvaise, que le gouvernement demanda à la CCTA (Central Computer and Telecom Agency – l’agence pour l’informatique centrale et les télécommunications, maintenant l’Office of Government Commerce – Le Ministère britannique du commerce, OGC) de développer une approche standard pour fournir des services informatiques efficaces et efficients. Cette approche se devait d’être indépendante des fournisseurs (qu’ils soient internes ou externes). Le résultat fut le développement et la publication de l’IT Infrastructure Library (bibliothèque d’infrastructure des technologies de l’information – ITIL). ITIL rassemble les “meilleures pratiques” adoptées par les fournisseurs de services informatiques. ITIL offre une approche méthodique pour fournir des services informatiques de qualité. Il fournit également une description détaillée de la plupart des processus principaux mis en œuvre au sein d’une organisation informatique. Il inclut des listes de contrôle de tâches et des procédures. Il détaille les responsabilités. Le tout servant de base à la fourniture de services sur mesure, répondant aux exigences de chaque organisation. Parallèlement, l’ampleur des sujets traités par ITIL permet de fournir un guide de référence utile, pour développer de nouveaux objectifs d’amélioration, permettant à toute organisation informatique de grandir et de mûrir. Au cours des années, ITIL est devenu beaucoup plus qu’une série d’ouvrages utiles traitant de la gestion des services informatiques. Le cadre des meilleures pratiques de gestion de services informatiques est promu et même développé par des consultants, des formateurs et des fournisseurs de technologies ou de produits. Depuis les années 90, ITIL représente non seulement un cadre théorique, mais aussi l’approche et la philosophie que partagent les personnes travaillant de façon pratique avec ITIL.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

10

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Etant lui-même un référentiel étendu de meilleures pratiques de gestion des services informatiques, les avantages et les inconvénients de tout référentiel s’appliquent également à ITIL. Bien entendu, ITIL a été développé pour les avantages précités. Les nombreuses indications contenues dans les meilleures pratiques permettent néanmoins d’éviter des problèmes potentiels ou, s’ils surviennent, d’y apporter des solutions.

Examens ITIL En 2007, le groupe APM a lancé un nouveau programme de certification ITIL, qui repose sur ITIL V3.ITIL V2 sera maintenu pendant une période de transition, jusqu’en 2009. La version 2 d’ITIL prévoit des qualifications sur trois niveaux : • Certification Foundation en gestion de services informatiques • Certification Practitioner en gestion de services informatiques • Certification Manager en gestion de services informatiques. Jusqu’en 2000, environ 60 000 certifications avaient été délivrées. En 2006, ce nombre a dépassé le demi-million. Un nouveau système de qualification a été mis en place pour la version 3 d’ITIL. Celui-ci comprend quatre niveaux de certification : • Fondamentaux • Intermédiaire (Cycle de Vie & Aptitudes) • Diplôme ITIL • Avancé – diplôme professionnel avancé de Gestion des Services Pour plus ample information sur les systèmes de qualification, voir : http://www.itil-officialsite.com/Qualifications/ITILV3QualificationScheme.asp

2.2 Gouvernance informatique Avec la croissance du rôle de l’information, des systèmes d’information et de la gestion des services informatiques, les besoins en gestion de l’informatique se sont également développés. Ceux-ci se concentrent sur deux aspects : d’une part la conformité avec les politiques internes et externes, la législation et la réglementation, d’autre part la fourniture de valeur ajoutée aux parties prenantes de l’organisation. La gouvernance informatique est encore une discipline très jeune, qui ne dispose que de quelques standards et de référentiels reconnus. Par contre, de nombreuses définitions de la gouvernance informatique sont disponibles. L’une d’elle fait l’objet d’un consensus, celle de Van Grembergen : La gouvernance informatique consiste en un référentiel qui englobe des structures, des processus et des mécanismes relationnels. Les structures impliquent l’existence de fonctions à responsabilités, telles que les dirigeants informatiques et les responsables de budgets, ainsi qu’une variété de comités informatiques. Les processus se réfèrent à la prise de décision stratégique pour les IT, et à leur surveillance. Les mécanismes relationnels comprennent la participation et les partenariats métier / informatique, un dialogue stratégique et un apprentissage partagé.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction au cycle de vie des services

11

Il faut clairement distinguer la gouvernance de la gestion. Nous suggérons que la gouvernance facilite la création d’un cadre au sein duquel d’autres personnes peuvent gérer leurs tâches de manière efficace (Sohal & Fitzpatrick). La gouvernance informatique et la gestion informatique sont donc deux entités distinctes. La gestion des services informatiques peut être considérée comme faisant partie de la gestion informatique. Dès lors, la gouvernance informatique s’inscrit dans la gestion du métier ou de l’information. Bien que de nombreux référentiels soient appelés référentiels de gouvernance informatique tels que COBIT, voire ITIL lui-même, la plupart d’entre eux sont en réalité des référentiels de gestion. Il existe au moins une norme de gouvernance informatique : la norme locale australienne de Corporate governance of information and communication technology (AS8015).

2.3 Maturité organisationnelle Dès l’introduction en 1973 par Richard Nolan de son modèle par niveaux, appliqué aux technologies de l’information au sein des organisations, nombreux sont ceux qui ont utilisé des modèles d’amélioration par étapes. Ceux-ci ont rapidement été reconnus comme étant des instruments adaptés aux programmes d’amélioration, aidant ainsi les organisations à gravir les échelons de la maturité. Des dizaines de variations sur ce thème peuvent se trouver facilement, allant des métiers tels que le développement des logiciels, l’acquisition, l’ingénierie des systèmes, les tests de logiciels, le développement de sites Internet, le stockage de données et l’ingénierie de la sécurité jusqu’aux centres de services et à la gestion des connaissances. Bien entendu, beaucoup apprécièrent le principe kaizen (l’amélioration fonctionne mieux par petites étapes). L’application la plus séduisante du modèle de Nolan fut sont intégration par le Software Engineering Institute (l‘institut d’ingénierie de logiciels – SEI) de l’Université Carnegie Mellon, aux États-Unis, dans le Software Capability Maturity Model (Modèle de maturité des aptitudes de logiciel – SW-CMM). Le CMM fut alors copié et appliqué à la plupart des cas précédemment mentionnés, élevant CMM au rang de standard de modélisation de la maturité. De nouvelles éditions de CMM suivirent, y compris le CMMI (CMM Intégration). Plus tard, ces modèles furent appliqués aux modèles de gestion de la qualité, tels que le European Foundation for Quality Management (fondation européenne pour la gestion par la qualité – EFQM). Outre ces modèles plus généraux de gestion par la qualité, citons plusieurs pratiques courantes dans d’autres industries, telle que Six Sigma et TQM, complémentaires de ITIL. Les normes disponibles, ainsi que les référentiels reposant sur les meilleures pratiques, offrent des conseils pour que chaque organisation atteigne l’excellence opérationnelle en termes de gestion des services. Les organisations, selon leur propre stade de développement, doivent s’appuyer sur un type de conseil particulier.

Modèle de maturité : CMMI Dans l’industrie de l’informatique, le processus d’amélioration de la maturité des processus est plus connu sous le nom générique de Capability Maturity Model Integration (intégration du

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

12

Les fondamentaux de la gestion des services informatiques selon ITIL V3

modèle de maturité des aptitudes – CMMI). Cette méthode d’amélioration des processus fut développée par le Software Engineering Institute (SEI) de l’Université Carnegie-Mellon. CMMI fournit aussi bien un modèle par étapes qu’un modèle continu. Dans la représentation continue, les améliorations sont mesurées à l’aide de niveaux d’aptitude. La maturité est mesurée pour un processus donné au sein d’une organisation. Dans la représentation par étapes, les améliorations sont mesurées à l’aide de niveaux de maturité, pour un ensemble de processus au sein d’une organisation. Les niveaux d’aptitude dans la représentation continue de CMMI sont les suivants : 1. Processus incomplet – un processus qui n’est pas réalisé, en tout ou partie 2. Processus réalisé – un processus qui satisfait les objectifs spécifiques du processus 3. Processus géré – un processus réalisé (selon le niveau d’aptitude 1) dont l’infrastructure de base a été mise en place pour soutenir le processus 4. Processus défini – un processus géré (selon le niveau d’aptitude 2), conçu sur mesure à partir d’un ensemble de processus standards de l’organisation, selon les exigences spécifiques de l’organisation, et qui contribue à la production et à la mesure du travail, ainsi qu’à d’autres informations d’amélioration pour les actifs des processus organisationnels 5. Processus géré quantitativement – un processus défini (selon le niveau d’aptitude 3) qui est contrôlé au moyen de techniques statistiques et d’autres techniques quantitatives 6. Processus optimisé – un processus géré quantitativement (selon le niveau d’aptitude 4) qui est amélioré sur la base d’une compréhension des causes communes de variations inhérentes au processus Le modèle de représentation par étapes de CMMI définit cinq niveaux de maturité, chacun constituant un seuil de base pour l’étape suivante, dans le cadre de l’amélioration continue des processus, et qui sont désignés par les chiffres de 1 à 5. • Initial – les processus sont ad hoc et chaotiques • Géré – les projets de l’organisation garantissent que les processus sont planifiés et exécutés selon la politique de l’organisation. • Défini – les processus sont bien caractérisés et compris, et sont décrits selon des standards, des procédures, des outils et des méthodes. • Géré quantitativement – l’organisation et les projets ont défini des objectifs quantitatifs associés à la qualité et à la performance des processus. Ceux-ci sont utilisés comme critères de gestion des processus. • Optimisé – se concentre sur l’amélioration continue de la performance des processus, selon un processus incrémental et innovant, ainsi que des améliorations technologiques. De nombreux autres modèles de maturité reposent sur ces structures, tels que les modèles de maturité du Gartner. La plupart de ces modèles se concentrent sur le niveau de maturité des aptitudes. D’autres, comme le World Class IT Maturity Model de KPMG, adoptent une approche différente.

Standard : ISO/IEC 20000 Le développement et la continuité d’un système de qualité, conforme aux prérequis de la série ISO 9000 (ISO-9000:2000), peuvent être considéré comme des outils permettant à l’organisation d’atteindre et de maintenir le niveau de maturité recherché (ou “géré” selon le CMM des services informatiques). Ces normes ISO mettent l’accent sur la définition, la description et la conception

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction au cycle de vie des services

13

des processus. Une norme ISO spécifique a été créée pour les organisations de gestion de services informatiques : la norme ISO 20000 (voir Figure 2.1).

Système de gestion Responsabilité du management

Exigences de la documentation

Compétence, Sensibilisation et Formation

Planifier et mettre en place la Agir Act gestion des services

Plan Planifier Faire

Planifier et mettre en place des services nouveaux ou modifiés

Check Vérifier

Processus de Fourniture de Service • Gestion de la Capacité • Gestion de la Continuité et de la Disponibilité

• Gestion de Niveaux de service • Reporting de Service • Gestion de la Sécurité Informatique • Budgétisation et Comptabilité pour les Services informatiques

Control Processes

• Configuration Management • Change Management

Processus de Mise en Production • Gestion de Mise en Production

Processus de gestion de relations Processus de résolution • Gestion des Incidents • Gestion des Problèmes

• Gestion de relations avec le métier • Gestion de fournisseurs

Figure 2.1  Vue d’ensemble du système de gestion des services ISO/IEC 20000

Maturité client L’évaluation de la maturité d’une organisation ne peut se réduire aux fournisseurs de services. Le niveau de maturité du client (Figure 2.3) est également important. S’il existe de grandes différences de maturité entre le fournisseur et le client, il faudra alors les prendre en considération pour éviter toute disparité entre les approches, les méthodes et les attentes mutuelles. En particulier, cela influence la communication entre le client et le fournisseur.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

14

Communication horizontale Commu

nication

mauvais

e

u at M

Co

atio

nic

u mm

ise

uva

a nm

rit

M

é Métier

ité

ur

at

Fournisseur de service IT

Figure 2.2  Communication et niveaux de maturité : client et fournisseur

2.4 Bénéfices et risques des référentiels ITSM La liste suivante identifie certains avantages et problèmes éventuels, liés à l’utilisation des meilleures pratiques de gestion des services informatiques. Cette liste ne prétend pas être exhaustive, mais elle fournit une base permettant de prendre en compte certains bénéfices pouvant être obtenus, et quelques unes des erreurs pouvant être commises lors de l’utilisation des référentiels de gestion des services informatiques, reposant sur des processus communs : Bénéfices pour le client/l’utilisateur : • La fourniture de services informatiques s’oriente davantage vers le client. Les accords sur la qualité des services améliorent les relations. • Les services sont mieux décrits, dans le langage du client, et offrent des détails plus appropriés. • La qualité, la disponibilité, la fiabilité et les coûts des services sont mieux gérés. • La communication avec l’organisation informatique est améliorée en définissant des points de contact. Avantages pour l’organisation informatique : • L’organisation informatique développe une structure plus claire, devient plus efficace et se concentre davantage sur les objectifs de l’entreprise. • L’organisation informatique contrôle davantage l’infrastructure et les services dont elle est responsable. Les changements sont plus faciles à gérer. • Une structure efficace de processus fournit un cadre de travail pour une externalisation efficace des éléments des services informatiques. • L’adoption des meilleures pratiques encourage un changement culturel, en évoluant vers une démarche de fourniture de services. Elle favorise l’introduction de systèmes de gestion de la qualité, reposant sur la série de normes ISO 9000 ou ISO/IEC 20000. • Des référentiels fournissent des cadres cohérents de référence pour la communication interne ainsi qu’avec les fournisseurs, et aussi pour la standardisation et l’identification de procédures.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction au cycle de vie des services

15

Problèmes/erreurs potentiels : • L’introduction peut prendre beaucoup de temps et demander des efforts importants. Elle peut exiger un changement de culture au sein de l’organisation. Une introduction trop ambitieuse peut déboucher sur des frustrations car les objectifs ne sont jamais atteints. • Si les structures des processus deviennent un objectif en soi, la qualité du service peut être compromise : dans ce cas, les procédures inutiles ou trop complexes sont perçues comme des obstacles bureaucratiques, qu’il faut éviter autant que possible. • Aucune amélioration des services informatiques n’est envisageable si les acteurs ne comprennent pas ce que devraient fournir les processus appropriés, les indicateurs de performance et la façon dont les processus peuvent être contrôlés. • L’amélioration de la fourniture de services et les réductions des coûts ne sont pas suffisamment visibles car aucune donnée de base n’est disponible pour établir des comparaisons et/ou les cibles identifiées ne sont pas correctes. • Une mise en œuvre réussie passe par une implication et un engagement du personnel à tous les niveaux de l’organisation. Déléguer le développement des structures des processus à un département spécialisé risque d’isoler celui-ci au sein de l’organisation. Ce dernier pourrait alors prendre des orientations que les autres départements n’acceptent pas. • Si les investissements en termes de formation et d’outils de support ne suffisent pas, le bienfondé des processus et du service ne seront pas perçus. Il est probable que des ressources et du personnel supplémentaires soient nécessaires à court terme, si l’organisation est déjà surchargée par les activités de routine de gestion des services informatiques, qui n’utilisent pas forcément les meilleures pratiques.

2.5 Cycle de vie des services : Concept et vue d’ensemble Le rôle et la taille du système d’information ont grandi ensemble, et ils évolué depuis le lancement de la version 2 d’ITIL (en 2000/02). Les technologies de l’information (TI) font partie d’un nombre croissant d’actifs et de services, qu’ils soutiennent. Dans le monde des affaires, le rôle de la fourniture d’information a aussi changé : le rôle des TI ne consiste plus seulement à fournir des supports, mais à servir de base à la création d’une valeur pour le métier. La version 3 d’ITIL intègre et fournit des notions sur ce nouveau rôle des TI, dans toute leur complexité et leur dynamique. Dans ce but, une nouvelle approche de la gestion des services a été choisie. Celle-ci ne se concentre pas sur les processus mais sur le cycle de vie des services.

Concepts de base Avant de décrire le cycle de vie des services, il convient de définir certains concepts de base.

Bonne pratique ITIL est présenté comme une bonne pratique (littéralement : une méthode correcte). Il s’agit d’une approche ou d’une méthode qui a fait ses preuves dans la pratique. Ces bonnes pratiques constituent un soutien valide pour les organisations, souhaitant améliorer leurs services informatiques. Dans ces cas, la meilleure chose à faire est de sélectionner un standard ou une méthode générique qui soit accessible à tous, ITIL, COBIT, CMMI, PRINCE2® et ISO/IEC 20000, par exemple. L’un des bénéfices de ces standards génériques, librement accessibles, est qu’ils peuvent être appliqués à plusieurs environnements et situations de la vie réelle. De

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

16

Les fondamentaux de la gestion des services informatiques selon ITIL V3

plus, une offre complète de formation est disponible pour ces standards ouverts. Ce qui facilite grandement la formation du personnel. Les connaissances propres à l’organisation constituent également une autre source de bonnes pratiques. En revanche, ce type de savoir présente l’inconvénient d’être spécifique à un contexte donné et particulier à une organisation. Il peut donc être difficile d’adopter ou de reproduire ces connaissances, qui ne seront peut-être pas très efficaces lors de leur utilisation.

Service Un service crée de la valeur pour le client. ITIL définit un service comme suit : Un service est un moyen de fournir de la valeur aux clients en leur permettant d’atteindre facilement les résultats souhaités sans en assumer les coûts ou les risques spécifiques. Les résultats sont possibles à partir de la performance des tâches données, et ils sont limités par un certain nombre de contraintes. Les services mettent en valeur les performances et réduisent la pression des contraintes. Cela augmente les chances de voir se réaliser les résultats escomptés.

Valeur La valeur est à la base du concept de service. Du point de vue du client, la valeur consiste en deux composants de base : l’utilité et la garantie. L’utilité décrit ce que le client reçoit, et la garantie explique comment il le reçoit. Les concepts d’utilité et de garantie sont décrits dans la section “Stratégie de services”.

Gestion des services ITIL définit la gestion des services comme suit : La gestion des services est un ensemble d’aptitudes organisationnelles spécialisées pour fournir de la valeur aux clients sous forme de services. ITIL expose certains des principes fondamentaux de la gestion des services qui intègrent les fonctions et les processus décrits dans les ouvrages ITIL de base. Les principes suivants aident à concevoir un système de gestion des services : • Spécialisation & coordination – L’objectif de la gestion des services est de rendre les aptitudes et les ressources disponibles via des services utiles et acceptables aux clients quant à leur qualité, coûts et risques. Le fournisseur de services prend à sa charge la responsabilité et la gestion des ressources, en soulageant ainsi les clients, qui peuvent alors se concentrer sur les compétences de base de leur métier. La gestion des services coordonne l’exercice de la responsabilité de la gestion des services, au regard de certaines ressources. Utilité et garantie font office de guide. • Principe client-fournisseur – La gestion des services implique toujours un client interne et un fournisseur interne, dont le rôle consiste à seconder le client interne afin de réaliser des activités pour leur compte. Les clients internes peuvent être des consultants, des conseillers ou des fournisseurs de services. Les clients internes agissent comme intermédiaires entre des fournisseurs de services et des clients, associés à des utilisateurs. Habituellement, ces clients internes sont des membres du personnel du fournisseur de services. Ils peuvent aussi être des

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction au cycle de vie des services

17

systèmes en libre service ou des processus pour les utilisateurs. La valeur pour les clients est créée grâce à des accords entre les fournisseurs et les clients internes. • Encapsulation – Les intérêts du client se concentrent sur la valeur d’utilisation ; celui-ci préfère qu’on lui épargne tous les détails techniques et la complexité de la structure. Le principe d’encapsulation consiste à cacher ce dont le client n’a pas besoin et à montrer ce qui lui apporte de la valeur et lui est utile. Trois principes sont étroitement liés à cela : – la séparation des intérêts – la modularité : une structure modulaire claire – la libre association : indépendance réciproque des ressources et des utilisateurs.

Systèmes ITIL décrit les concepts des structures organisationnelles s’inspirant de la théorie des systèmes. Le cycle de vie des services dans la version 3 d’ITIL est un système ; toutefois, une fonction, un processus ou une organisation constituent aussi des systèmes. Définition d’un système : Un système est un groupe de composants qui interagissant les uns avec les autres, liés les uns aux autres ou dépendant les uns des autres, et qui forment un tout unifié, opérant ensemble pour un but commun. Le feedback et l’apprentissage sont deux aspects clés de la performance des systèmes ; ils changent les processus, les fonctions et les organisations en systèmes dynamiques. Le feedback peut mener à l’apprentissage et à la croissance, non seulement à l’intérieur d’un processus, mais aussi au sein d’une organisation dans son ensemble. À l’intérieur d’un processus, par exemple, le feedback concernant la performance d’un cycle est, à son tour, une entrée pour le cycle du processus suivant. Au sein des organisations, il peut y avoir un feedback entre les processus, les fonctions et les phases du cycle de vie. Derrière ce feedback se trouve un but commun : les objectifs du client.

Fonctions et processus La distinction entre fonctions et processus est importante dans le cadre d’ITIL. Qu’est-ce qu’une fonction ? Une fonction est une subdivision d’une organisation spécialisée pour accomplir un type spécifique de travail, et qui est responsable de fournir résultats spécifiques. Les fonctions sont des subdivisions indépendantes, disposant des aptitudes et des ressources requises pour fournir leur résultats avec performance. Elles disposent de leurs propres pratiques et de leurs propres connaissances. Qu’est-ce qu’un processus ? Un processus est un ensemble structuré d’activités conçues pour accomplir un objectif défini. Les processus conduisent à un changement orienté par des objectifs, et utilisent le feedback pour identifier des actions d’auto-amélioration et d’auto-correction.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

18

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les processus possèdent les caractéristiques suivantes : • Ils peuvent être mesurés – car ils sont orientés vers la performance • Ils produisent des résultats spécifiques • Ils fournissent des résultats aux clients ou aux parties prenantes • Ils répondent à un événement spécifique – un processus est en effet continu et itératif, mais il est déclenché par un événement spécifique. Il est parfois difficile de déterminer si quelque chose est une fonction ou un processus. Selon ITIL, le fait qu’il s’agisse d’une fonction ou d’un processus dépend entièrement de la conception organisationnelle. Un bon exemple de fonction est un centre de services, un bon exemple de processus est la gestion des changements. La structure hiérarchisée des fonctions peut conduire à une organisation en silos, dans laquelle la fonction est orientée sur elle-même. Cela ne contribue pas au succès de l’organisation dans son ensemble. Les processus reposent sur une structure hiérarchisée de fonctions ; les fonctions partagent souvent plusieurs processus. Ainsi, les processus évitent l’apparition de silos fonctionnels, et contribuent à garantir une meilleure coordination entre les fonctions.

Le cycle de vie des services La version 3 d’ITIL aborde la gestion des services du point de vue du cycle de vie des services. Le cycle de vie des services est un modèle organisationnel qui fournit des notions sur les thèmes suivants : • la façon dont la gestion des services est structurée • la façon dont les divers composants sont liés les uns aux autres • l’impact que des changements sur un composant aura sur les autres composants du système, et sur tout le système de cycle de vie. C’est pourquoi la nouvelle version d’ITIL met l’accent sur le cycle de vie des services et sur la façon dont les composants de la gestion des services sont liés les uns aux autres. Les processus (aussi bien les anciens processus que l’on connait bien, que les nouveaux) font également l’objet d’un développement dans les phases du cycle. Ils décrivent comment les choses changent. Le cycle de vie des services consiste en cinq phases. Les cinq nouveaux ouvrages ITIL décrivent respectivement chacune de ces phases : 1. Stratégie des services – la phase de conception, développement et mise en œuvre de la gestion des services, envisagés comme des ressources stratégiques. 2. Conception des services – la phase de conception pour le développement de services informatiques appropriés, comprenant l’architecture, les processus, la politique et la documentation ; le but de la conception est de satisfaire les besoins présents et futurs du métier. 3. Transition des services – la phase de développement et d’amélioration des aptitudes, pour passer à la production des services nouveaux ou modifiés. 4. Exploitation des services – la phase d’accomplissement de l’efficacité et de l’efficience, pour la production des services et la fourniture de support, afin de garantir la création de valeur pour le client et le fournisseur de services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction au cycle de vie des services

19

5. Amélioration continue des services – la phase de la création et de conservation de la valeur pour les clients, grâce à une amélioration de la conception, ainsi que par l’introduction et l’exploitation des services. La stratégie des services est l’axe du cycle de vie des services (Figure 2.3) qui traverse toutes les autres phases ; c’est la phase de prise de décision et d’établissement d’objectifs. Les phases de conception des services, de transition des services et d’exploitation des services mettent en œuvre cette stratégie. Leur thème continu est l’ajustement et le changement. La phase d’amélioration continue des services représente l’apprentissage et l’amélioration. Elle englobe toutes les phases du cycle. Cette phase lance des programmes et des projets, et elle leur attribue une priorité en fonction des objectifs stratégiques de l’organisation.

de

ices Serv

Se rv ic e

vices

o pl Ex

ition des Servic es

S er

ITIL V3

ns Tra

Stratégie d es

Con ce pt i

on

Continue d tion es

s

Am

ora éli

ita tio nd es Services

Figure 2.3  Le cycle de vie des services

Le cycle de vie des services est une combinaison de nombreuses perspectives sur la réalité des organisations. Elle offre davantage de flexibilité et de contrôle. Le schéma dominant du cycle de vie des services est la succession de la stratégie des services, de la conception des services, de la transition des services et de l’exploitation des services ; puis, par le biais de l’amélioration continue des services, on retourne à la stratégie des services, et ainsi de suite. Toutefois, le cycle englobe de nombreux modèles. Selon les tâches et les responsabilités, un gestionnaire peut choisir sa propre perspective de contrôle. Si vous êtes responsable de la conception, du développement ou de l’amélioration des processus, la meilleure perspective consiste à partir des processus. Si vous êtes responsable de la gestion des SLA (accords sur les niveaux des services ou conventions de service), des contrats et des services, la perspective du cycle de vie des services et ses différentes phases va certainement satisfaire vos besoins.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

20

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Bibliothèque ITIL La bibliothèque officielle, et nouvellement conçue d’ITIL, englobe les composants suivants : • Bibliothèque de base : les cinq publications traitant du cycle de vie des services – Stratégie des services – Conception des services – Transition des services – Exploitation des services – Amélioration continuelle des services Chaque livre couvre une phase du cycle de vie des services et englobe divers processus. Les processus sont toujours décrits en détail dans l’ouvrage qui traite des applications clés de tel ou tel processus. • Portefeuille complémentaire : – Guide d’introduction – Guides des éléments clés – Aides à la certification – Livres blancs – Glossaire

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 3

Phase de cycle de vie : la stratégie des services 3.1 Introduction Dans cette section, nous présentons une introduction à la notion de cycle de vie. La stratégie des services fournit des conseils quant à la conception, au développement et à la mise en œuvre de la gestion des services, envisagée comme une ressource stratégique. La stratégie des services est décisive lors d’une approche par processus, tout au long du cycle de vie des Services ITIL, pendant les phases de conception, de transition, d’exploitation et d’amélioration continue des services. La stratégie des services s’attache à un périmètre plus vaste que celui du référentiel ITIL. Les organisations qui utilisent déjà ITIL, peuvent se servir de cette section comme d’un guide pour développer une vue d’ensemble stratégique de leurs capacités, selon ITIL. Elles peuvent également tenter d’améliorer la synchronisation entre les stratégies TI et le business. Considérons d’abord la raison pour laquelle quelque chose devrait être fait, avant de penser à la façon dont cela sera fait. Le pourquoi est plus important du point de vue du client et de son métier. Ce chapitre offre un ensemble de conseils qui aideront à définir les objectifs et les attentes, du point de vue du client et du marché. Une stratégie des services aide également à identifier, à sélectionner et à identifier des opportunités. Une stratégie des services claire contribue à garantir qu’une organisation possède les attributs nécessaires pour gérer les coûts et les risques dans les portefeuilles des services. Les sujets abordés sont les suivants : définir le concept de stratégie, les actifs de services, les catalogues de services ; mettre en œuvre la stratégie via le cycle de vie des services ; les différents types de fournisseurs de services ; la gestion financière ; la gestion du portefeuille de services ; le développement organisationnel et les risques stratégiques.

Qu’est-ce que la stratégie ? La stratégie est un terme qui vient du monde militaire, qui la définit d’abord comme la distribution et l’application des ressources militaires afin d’atteindre les objectifs d’un plan. Dans la gestion des services, la stratégie doit aussi maintenir le lien entre les politiques et les tactiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

22

Le but de la stratégie des services est d’identifier les concurrents, puis de les affronter en se distinguant par la fourniture de performances supérieures. Les fournisseurs de services très performants, selon ITIL, se distinguent par les éléments suivants : • Orientation marché – savoir où et comment entrer en concurrence • Aptitudes distinctives – créer des actifs distinctifs et profitables que le business met à profit • Anatomie de la performance – points de vue organisationnels mesurables et faisables, tels que percevoir les services comme des actifs stratégiques qui nécessitent une amélioration constante

Les quatre P de la stratégie Si un fournisseur de services connaît vraiment les objectifs de ses services et comprend les facteurs distinctifs de ses produits, il peut alors se lancer dans la gestion des services selon leurs cycles de vie. La stratégie des services forme l’épine dorsale du cycle. Nous pouvons commencer par ce que nous appelons les quatre P (d’après Mintzberg, 1994) ; la stratégie s’appuie sur une perspective, un positionnement, un plan et des modèles (schéma) : • perspective – avoir une vision et des objectifs clairs • positionnement – avoir une place bien définie • plan – délimiter une notion précise de la façon dont l’organisation devrait se développer • modèle (pattern) – maintenir une cohérence dans les décisions et les actions

Perspective

Modèle

STRATÉGIE

Position

Plan

Figure 3.1  Les quatre P de la stratégie, d’après Henry Mintzberg

Perspective La stratégie, en tant que perspective, fournit la vision et l’objectif d’une organisation. Elle détermine les caractéristiques distinctives du fournisseur de services et ses interactions avec le client. La stratégie, en tant que perspective, définit les convictions, les valeurs et les objectifs qui régissent le comportement de toute l’organisation. Une perspective stratégique détermine la direction qui permet au fournisseur de services d’atteindre ses objectifs.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

23

Pour tester les perspectives, posez les questions suivantes : • Sont-elles claires et mémorables ? • Sont-elles adaptées à la promotion et à la conduite des activités ? • Établissent-elles des limites dans lesquelles les personnes sont libres de mener des expériences ? Positionnement La stratégie, en tant que positionnement, permet de prendre les décisions qui garantissent que les services seront fournisseur d’un marché spécifique. Le fournisseur de services doit absolument être conscient de son positionnement sur un marché. La stratégie en tant que positionnement définit les caractéristiques distinctives du fournisseur de services aux yeux du client. Plusieurs positionnements sont possibles : • positionnement axé sur la diversité – un catalogue limité de services, mais possédant un tel niveau de détail que différents clients ayant des besoins semblables peuvent être servis de manière adéquate. • positionnement axé sur le besoin – un vaste catalogue de services fournissant la plupart des services à un type spécifique de client. • positionnement axé sur l’accessibilité – possibilité de fournir des services aux clients ayant des caractéristiques spécifiques, tels que l’emplacement, la dimension ou la structure. Pour tester le positionnement de l’organisation, posez les questions suivantes : • L’organisation aide-t-elle les gestionnaires à tester la pertinence d’une procédure donnée ? • L’organisation établit-elle des limites claires au delà desquelles le personnel ne peut pas opérer ? • Y a-t-il un degré de liberté à l’expérimentation à l’intérieur de ces contraintes ? Plan La stratégie, en tant que plan, formule des recommandations sur la manière dont une organisation gère son développement. La stratégie, en tant que plan, met l’accent sur la planification de l’action de l’organisation au sein d’un marché concurrentiel. La gestion des services est un ensemble coordonné de plans permettant aux fournisseurs de services de planifier et de mettre en œuvre les stratégies de service. Modèles (pattern) La stratégie est un ensemble de modèles (schéma) car elle définit les activités à réaliser dans les délais impartis. La stratégie en tant que modèles (pattern) représente les procédures d’une organisation. Conséquences de la perspective, du positionnement et du plan de la stratégie, des modèles caractéristiques sont créés, et conduiront à des succès récurrents.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

24

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Mission et objectifs La spécialisation et la coordination sont nécessaires dans une approche par le cycle de vie. Cela est rendu possible par le feedback et la surveillance pendant les différentes phases du cycle. Le schéma dominant du cycle de vie des services s’appuie sur l’ordre chronologique suivant : de la stratégie des services à la conception des services, à la transition des services, à l’exploitation des services et de nouveau à la stratégie des services via l’amélioration continue des services. La stratégie des services aide les organisations à réfléchir et à faire du business d’une manière stratégique. La mise en œuvre de la stratégie se fait au moyen d’actifs stratégiques. Enfin, une approche pluridisciplinaire est nécessaire pour répondre à des questions telles que : • Quel type de services doit-on offrir et à qui ? • Comment pouvons-nous nous distinguer de la concurrence ? • Comment pouvons-nous justifier des investissements stratégiques ? • Comment allons-nous vraiment créer de la valeur pour le client et nos parties prenantes ? • Comment pouvons-nous allouer des ressources de façon efficiente dans un portefeuille de services ? • Comment pouvons-nous recourir à la gestion financière pour garantir un aperçu et un contrôle de la création de valeur ? Pour survivre, les organisations doivent comprendre comment créer de la valeur pour elles-mêmes et pour le client. La mission de la phase de stratégie des services est de développer la capacité d’obtenir et de maintenir un avantage stratégique. Les objectifs associés sont les suivants : • Définir les objectifs stratégiques • Déterminer les axes d’opportunités de croissance • Définir la priorité des investissements • Définir des résultats, apprendre ce qu’est l’efficience • Créer des actifs stratégiques • Identifier les concurrents • Dépasser les concurrents en fournissant des performances distinctives • Élaborer des plans qui garantiront la suprématie par rapport aux concurrents, maintenant et dans le futur Le développement et l’application de la stratégie des services exigent une révision permanente, tout comme tous les autres composants du cycle. Si la stratégie est efficace, les efforts alors déployés dans toutes les autres phases du cycle de vie seront couronnés de succès.

3.2 Concepts de base Utilité et garantie La valeur ne se discerne pas seulement dans les résultats métier du client. En effet, elle repose dans une large mesure de la perception du client. Le cas échéant, il s’agit de la différence entre la valeur économique et la perception économique. La perception dépend de l’image que le client a de lui-même, des attributs de la valeur et de son expérience personnelle. Il est important de ne pas

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

25

oublier que la définition et la distinction de la valeur se trouvent surtout dans l’esprit du client. La valeur économique ne correspond pas forcément aux perceptions économiques du client. La version 3 d’ITIL s’appuie sur deux concepts pour définir la valeur d’un service. L’utilité d’un service représente l’effet positif pour les clients ; la garantie représente l’assurance de cet effet positif. La valeur du service est une combinaison de l’utilité et de la garantie, qu’ITIL définit comme suit : • Utilité – adaptation au besoin. Les attributs du service qui ont un effet positif sur la performance des activités, des objets et des tâches ayant un résultat spécifique. L’utilité se traduit par une augmentation potentielle du bénéfice. • Garantie – adaptation à l’utilisation. Disponibilité et fiabilité dans les domaines de la continuité et de la sécurité. La garantie représente l’assurance de la fourniture cet effet positif. L’utilité est ce que le client reçoit et la garantie s’attache à la manière dont cela sera fourni. Il est conseillé d’envisager ces deux aspects séparément pour aboutir à une conception et à un développement les meilleurs possibles. UTILITÉ Performance soutenue?

OU

v/f

Contraintes supprimées?

Adapté au besoin?

ET Suffisamment disponible? Suffisamment large? Suffisamment continue? Suffisamment sécurisé ?

ET

Adapté au fonctionnement? v/f

T/F

Valeur créée

T: TRUE F: FALSE

GARANTIE

Figure 3.2

Communiquer l’utilité et la garantie Pour communique autour de l’utilité d’un service, il est nécessaire de s’appuyer sur certains résultats ou de prévenir certains risques et coûts. Les clients souhaitent fortement externaliser la gestion des actifs qui retirent des ressources financières de leurs actifs de base. Ils veulent également éviter un manque de capacité. Les clients sont incapables d’utiliser des services qui ne sont pas adaptés à leur utilisation. La garantie assure l’utilité d’un service en assurant que ce service soit disponible et qu’il offre suffisamment de capacité, de continuité et de sécurité : • Disponibilité – la disponibilité est l’aspect le plus fondamental de la fourniture de services à un client. Elle confère au client l’assurance que les services sont disponibles selon les conditions convenues. • Capacité – sans la surveillance efficace des problèmes de capacité, les fournisseurs de services ne sont pas en mesure d’offrir l’utilité de la plupart des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

26

• Continuité – la continuité assure que le service supporte le business, même en cas de moments très difficiles ou de sinistre. • Sécurité – la sécurité assure aux clients qu’ils peuvent faire usage du service de manière sûre et sécurisée. La création de valeur naît d’une combinaison des conséquences de l’utilité et de la garantie. Toutes deux sont nécessaires à la création de valeur pour le client. La Figure 3.3 représente les effets que la combinaison de l’utilité et de la garantie produit sur les actifs du client.

Ga

ran

Zone équilibré Valeur élevée

tie

éle

i

Ut

vée

Influence minimale sur les résultats du métier, avec une sécurité élevée

Ut

Influence importante sur les résultats du métier, avec une sécurité faible

Ga

ran

e

é ilit

ée

lev

é lité

bl fai

tie

fai

ble

Valeur basse

Figure 3.3  Ressources et aptitudes sont les bases de la création de valeur

Structures de service Le processus de création de valeur est tellement complexe que les modèles traditionnels de services sont inadéquats. Plutôt que de se concentrer sur une chronologie fixe des activités dans une chaîne, pendant la phase de stratégie des services, il faut focaliser son attention sur le systèmemême de création de valeur. La gestion de services symbolise des schémas de coopération. ITIL définit le réseau de création de valeur comme suit : Un réseau de création de valeur est un réseau de relations qui génère de la valeur corporelle et incorporelle par le biais d’échanges complexes et dynamiques entre deux ou plusieurs organisations. Les questions suivantes sont à se poser lors de la construction d’un modèle de service : • Qui sont les participants à ce service ? • Quels sont les modèles dans les échanges et les transactions ? • Quel est l’impact ou quels sont les produits à fournir depuis chaque transaction et pour chaque participant ? • Quelle est la meilleure façon de créer de la valeur ?

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

27

Actifs de service Ressources et aptitudes Les ressources et les aptitudes sont des types d’actif. Les organisations les utilisent pour créer de la valeur sous la forme d’actifs et de services. Les ressources comprennent les entrées directes pour la production. La direction, l’organisation, les personnes et les connaissances convertissent les ressources en valeur. Les aptitudes représentent la capacité d’une organisation à coordonner, gérer et appliquer des ressources pour produire de la valeur. Les ressources reposent souvent sur les expériences ; elles sont mobilisatrices de connaissances, elles reposent sur les informations et sont profondément embarquées dans les systèmes, les technologies, les processus et les personnes d’une organisation. Il est plus simple d’acquérir des ressources que des aptitudes. Les aptitudes se développent au cours des années : le développement d’aptitudes distinctives est stimulé par un élargissement et un approfondissement des expériences acquises selon le nombre et la variété des clients, des marchés, des contrats et des services. L’expérience s’obtient par la résolution des problèmes, la gestion des situations, la gestion des risques et l’analyse des erreurs. Les fournisseurs de services doivent développer des aptitudes distinctives pour continuer d’offrir à leurs clients des services que la concurrence peut difficilement copier. Les fournisseurs de services doivent également investir massivement dans l’éducation et la formation, s’ils veulent continuer à développer leurs actifs stratégiques. Les aptitudes seules ne peuvent pas produire de la valeur sans des ressources adéquates et appropriées. La capacité productive d’un fournisseur de services dépend de la disponibilité des ressources. Les aptitudes servent à développer, à mettre en œuvre et à coordonner la capacité productive.

Types d’actifs Les ressources et les capacités forment la base de la valeur d’un service (voir Figure 3.4). Les types d’actif sont décrits comme suit : • Gestion – la gestion est un système qui comprend la direction, l’administration, la politique, la performance, les réglementations et les motivations ; cette couche cultive, coordonne et supervise les autres types d’actif. • Organisation – les actifs organisationnels sont des configurations actives de personnes, de processus, d’applications et d’infrastructures qui mettent en œuvre toutes les activités de l’organisation ; cette couche comprend les hiérarchies fonctionnelles, les réseaux sociaux de groupes, d’équipes et d’individus ainsi que tous les systèmes qu’ils utilisent pour travailler ensemble, afin d’atteindre les objectifs collectifs. • Processus – les algorithmes, les méthodes, les procédures et les routines qui définissent la mise en œuvre et la gestion des activités et des interactions constituent les actifs du processus. • Connaissances – les actifs de connaissances sont des accumulations de réalisations, d’expériences, d’informations, de notions et de propriétés intellectuelles associées à des activités et à des contextes spécifiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

28

Fournisseur de service APTITUDES GESTION

RESSOURCES CAPITAL FINANCIER

ORGANISATION PROCESSUS

INFRASTRUCTURE APPLICATIONS

CONNAISSANCE

INFORMATION ACTIFS DE SERVICE

PERSONNES

VALEUR

SERVICES

RÉSULTATS DU CLIENT

ACTIFS DU CLIENT

Client

Figure 3.4  Ressources et aptitudes sont les bases de la création de valeur

• Personnes – les personnes, en tant qu’actifs, représentent la capacité de créer, d’analyser, de percevoir, d’éduquer, d’évaluer, de diriger, de communiquer, de coordonner, de susciter l’empathie et la confiance. • Informations – les actifs d’informations sont des collections, des modèles et des abstractions significatives de données appliquées dans un contexte de clients, de contrats, de services, d’événements, de projets et de production. • Applications – les actifs d’applications sont très variés et comprennent les objets, l’automatisation et les outils utilisés pour soutenir la performance d’autres types d’actifs ; les applications tirent leur valeur de leurs relations avec les autres actifs. • Infrastructures – les actifs d’infrastructures existent sous la forme d’échelons définis par leurs relations avec d’autres actifs qu’ils supportent (en particulier, les personnes et les applications) • Capital financier – les actifs financiers sont nécessaires pour soutenir la propriété ou l’utilisation de tous les types d’actifs.

Type de fournisseur de services ITIL fait une distinction entre les différents types de fournisseur de services. La plupart des aspects de la gestion de services s’appliquent à tous les types de fournisseur ; cependant, des aspects, tels que les clients, les contrats, la concurrence, les marchés et les revenus, diffèrent pour chaque type. ITIL définit les trois archétypes suivants : Type I – fournisseur de services interne Type II – unité de services partagés Type III – fournisseur de services externe

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

29

Type I – Fournisseur de services interne Les fournisseurs de type I fournissent leurs services à l’intérieur de leurs propres domaines d’activités stratégiques (Business Unit). Les fournisseurs de type I (figure 3.5) se trouvent dans les organisations où les départements TI, R&D, marketing ou de production déterminent la position concurrentielle de l’organisation, et pour lesquels un haut niveau de contrôle est nécessaire.

Métier, siège

Fonction métier

Marketing, R&D, Planning stratégique, gouvernance

Enduits (Département métier)

Plastiques (Département métier)

Textiles (Département métier)

Ressources Humaines Finance & administration Gestion Après-vente IT

Ressources Humaines Finance & administration Gestion Après-vente IT

Ressources Humaines Finance & administration Gestion Après-vente IT

Figure 3.5  Fournisseurs de type I

Les avantages de ce type de fournisseur : • Lignes de communication courtes – contact étroit avec le client permettant d’éviter certains coûts et risques. • Orientation client – spécialisation en une gamme limitée de besoins business permettant une forte orientation vers le client. • Droits de décision limités – le droit de décider revient au gestionnaire du domaine d’activité stratégique (business unit). Inconvénients : • Opportunités de croissance limitées- la croissance est liée à la croissance du domaine d’activité stratégique (business unit). Concurrence : • Marché ouvert- les fournisseurs sont hors du domaine d’activité stratégique (business unit) Objectif : • Contribuer à créer de la valeur – atteindre l’excellence fonctionnelle et un retour pour le domaine d’activité stratégique (business unit) à laquelle ils appartiennent.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

30

Métier, siège Fonction métier Enduits (Département métier)

Plastiques (Département métier)

Textiles (Département métier)

Services Métier (Département à services partagés) Ressources Humaines

Catalogue de services Catalogue de services Catalogue de services Catalogue de services Catalogue de services

Finance & administration Service après-vente Logistique Technologie informatique

BU: Business Unit

SSU: Shared Services Unit

Figure 3.6  Fournisseurs de type II

Type II – Unité de services partagés Les fonctions telles que les finances, les TI, les ressources humaines et la logistique ne sont pas toujours à la base d’un avantage concurrentiel d’une organisation et ne nécessitent pas d’être maintenues au niveau entreprise. Les services de telles fonctions partagées sont souvent regroupés en une unité autonome appelée unité de services partagés (Shared Services Unit – SSU). Les fournisseurs de type II fournissent des services aux domaines d’activités stratégiques (business unit) opérant sous la même stratégie collective. Les avantages d’une unité de services partagés (voir Figure 3.6) sont les suivants : • Prix plus bas – par rapport aux fournisseurs de services externes, grâce à des profits collectifs, à des accords et à une comptabilité internes. • Autorité de prise de décision plus vaste – les décisions peuvent être prises hors du domaine d’activité stratégique (business unit). • Possibilité de standardiser – la possibilité de développer un standard qui pourrait servir à plusieurs domaines d’activités stratégiques (business unit). • Position concurrentielle – la possibilité de défier la concurrence Inconvénients : • Remplaçable – les clients peuvent comparer le fournisseur avec les fournisseurs de services externes. Objectif : • Se maintenir au niveau des meilleures pratiques de l’industrie, cultiver le marché, formuler des stratégies business, s’efforcer d’atteindre l’efficience opérationnelle et de développer des aptitudes distinctives.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

31

Métier, siège Fonction métier Textiles Plastiques Enduits (Département Métier) (Département Métier) (Département Métier) Fournisseurs externes Alpha SA Catalogue des services

Beta SARL

Catalogue des services

Gamma SARL

Catalogue des services Catalogue des services

Delta SARL

Catalogue des services

Figure 3.7  Fournisseur de type III

Type III – Fournisseur de services externe Les fournisseurs de type III fournissent des services aux clients dans des environnements business concurrentiels qui nécessitent des structures flexibles. Les clients proviennent de lieux divers. Avec des fournisseurs de type III, les clients en concurrence ont accès aux mêmes actifs (voir Figure 3.7). Les avantages de ce type de fournisseur : • flexibilité accrue – davantage de liberté pour exploiter davantage d’opportunités. • prix compétitifs – davantage d’opportunités pour faire varier les prix. • minimiser les risques du système – répartir les risques sur un réseau plus vaste. Inconvénients : • risques majeurs pour les clients • coûts supplémentaires Objectif : • offrir aux clients une flexibilité et des connaissances, des expériences, de l’amplitude, un périmètre, des aptitudes et des ressources externes. Les clients prennent en considération les aspects suivants quand ils choisissent un type de fournisseur ou en changent (voir Figure 3.8) : 1. Coûts de transaction : a. Coûts totaux d’un fournisseur de services b. Doit-on maintenir les activités en interne (agrégation) ? c. Doit-on externaliser (désagrégation) ?

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

32

2. Facteurs stratégiques 3. Compétences de base 4. Aptitudes de gestion des risques

Type I

De/à

Type I

Réorganisation fonctionnelle

Type II

Agrégation

Type III

Sourcing interne

Type II

Type III

Désagrégation

Externalisation

Réorganisation niveau siège

Sourcing interne

Externalisation

Reconfiguration valeur nette

Figure 3.8  Le choix du type de fournisseur effectué par le client

3.3 Processus et autres activités Activités Les sections suivantes traitent des quatre activités principales du processus de stratégie des services selon la définition d’ITIL (voir Figure 3.9) : 1. Définir le marché : a. comprendre le client b. comprendre les opportunités c. classer et visualiser les services 2. Développer l’offre 3. Développer les actifs stratégiques 4. Préparer la mise en œuvre

Définir le marché : Dans le contexte de la gestion de services, les organisations s’intéressent à la stratégie à partir de deux perspectives différentes, bien que complémentaires. Il y a des stratégies pour les services et des services pour les stratégies. Une des perspectives suggère que les stratégies soient développées pour les services qui seront offerts. L’autre perspective présente la gestion des services comme une compétence pour une stratégie business donnée.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

33

Définir le marché

Préparer la mise en œuvre

Processus de Stratégie des Service

Développer des actifs stratégiques

Développer l’offre

Figure 3.9  Les activités du processus de la stratégie des services

Comprendre le client Pour les professionnels de la gestion des services, il est essentiel de connaître la performance des actifs du client. Sans une notion de ces actifs, il ne peut y avoir de base sur laquelle déterminer la valeur d’un service. Comprendre les opportunités Les objectifs non supportés des clients peuvent représenter une opportunité de développement de services pouvant être offerts comme solutions au problème du client. Lorsque le business change, de nouvelles opportunités se créent. Le Configuration Management System (Système de gestion des configurations – CMS) peut rendre viable une cartographie des résultats d’un client, exprimés en services et en actifs de service. Avoir un aperçu du business du client et bien connaître ses objectifs sont des facteurs essentiels pour développer de fortes relations business avec le client. Les Business Relation Managers (gestionnaires des relations avec le business – BRM) sont responsables de cela. Ils sont étroitement liés au client et gèrent les opportunités au moyen d’un portefeuille de clients. Les BRM travaillent en étroite collaboration avec les chefs de produit, qui sont responsables du développement et de la gestion des services tout au long du cycle de vie. Les chefs de produit se concentrent sur les produits et maintiennent des contacts avec le business via un portefeuille de services. Classer et visualiser les services Les services varient en premier lieu en fonction du contexte et de la manière dont ils créent de la valeur. Les archétypes de service servent de modèles business pour les services. Ils définissent la façon dont les fournisseurs de services se comportent pour le compte de leurs clients. Les actifs du client représentent le contexte dans lequel la valeur est créée car ils sont liés aux résultats business que le client souhaite.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

34

Le client possède plusieurs types d’actif qui dépendent d’une variété de facteurs. La combinaison d’un archétype de service et d’un actif client (voir Ux-Ay dans les Figures 3.10 et 3.11) représente une entrée dans le catalogue de services. Divers services peuvent être associés à un même archétype.

Types de service (Principe de Portefeuille) Service d’Accès / Leasing Services gérés Services de réparation Services de surveillance Services administrative Services d’évaluation Services de transformation Services de création Services de communication

U1 U2 U3 U4 U5 U6 U7 U8 U9

Archétypes de Service (Principe d’Agence)

Actifs du client (contexte de valeur)

Leasing, License, Fourniture Gestion, Opération, Maintenance Recouvrement, résolution, réparation Stockage, protection, surveillance Processus, Fourniture, Administration

Catalogue de service

Analyse, Évaluation, Audit Modification, Transformation, Transport Conception, Développement, Ingénierie Connexion, Intégration

A1

Gestion

A2

Organisation

A3

Processus

A4

Connaissance

A5

Personnes

A6

Information

A7

Applications

A8

Infrastructure

A9

Actifs financiers

U = Utilité A = Actif

Figure 3.10  Modèle business de fournisseur de services et actifs client

Le même archétype peut être utilisé pour servir un ensemble d’actifs clients, selon une stratégie de service basée sur l’utilité. Cela constitue une variation de positionnement qui repose sur le besoin et l’accès. La stratégie du fournisseur de services détermine les contenus du catalogue des services. La stratégie des services a pour résultat une collection spécifique de modèles (stratégie délibérée), ou bien une collection de modèles peut rendre attirante une stratégie spécifique du service (stratégie émergente). La méthode visuelle est utile à la communication et à la coordination entre les fonctions et les processus de la gestion des services. Une bonne synchronisation entre le contexte de création de valeur (actifs client) et les concepts de création de valeur (archétype de service) aide à prévenir les insuffisances en matière de performance.

Développement de l’offre Le marché des clients Le marché se définit par une opportunité de contribuer aux résultats business, au moyen de services. Chaque marché représente une série d’opportunités pour les fournisseurs de services, qui proposent un ou plusieurs services à un client.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

35

Actifs client a1

a2

a3

a4

a5 Basé sur les actifs

Archétype de service

u1

u2

Basé sur l’utilité

u3

u4

u5

Figure 3.11  Positionnement basé sur les actifs et basé sur l’utilité

Définition des services selon les résultats Une définition des services qui repose sur les résultats garantit que les gestionnaires perçoivent tous les aspects de la gestion des services du point de vue du client. Les services constituent une façon d’apporter de la valeur aux clients, en facilitant les résultats des clients, sans que ceux-ci doivent en assumer les coûts et les risques. Une définition bien formulée du service débouche sur des processus de gestion des services efficaces et efficients. Pour vous assurer que vos définitions des services soient valables, posez les questions suivantes : • Quel type de services offrons-nous ? (type de service) • Qui sont nos clients ? (type de service) • A quel type de résultats contribuons-nous ? (utilité) • Comment ces résultats créent-ils de la valeur pour les clients de nos clients ? (utilité) • Quelles contraintes nos clients rencontrent-ils ? (utilité) Il est impossible de produire de la valeur sans une définition complète de la valeur.

Portefeuille de services, pipeline et catalogue des services Le portefeuille des services représente les accords et les investissements que le fournisseur de service passe avec tous les clients et tous les marchés : les obligations contractuelles, le développement des services, l’amélioration continue des services et les services de troisième niveau (visibles ou invisibles aux clients). Le portefeuille des services représente également toutes les ressources qui sont actives lors des différentes phases du cycle de vie des services. Un aspect important de la gouvernance de la gestion du portefeuille de services (Service Portfolio Management – SPM) est que chaque phase a besoin de ressources pour conclure des projets, des initiatives et des contrats. Voir la section

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

36

concernant Les processus et les activités pour avoir une brève explication du SPM, ou au Chapitre 9 pour une description détaillé du SPM et des méthodes du SPM. Résumé : Le portefeuille de services représente les opportunités et la disponibilité d’un fournisseur de services à servir les clients et le marché. Le portefeuille de services peut être divisé en trois sousensembles de services : - le catalogue des services - les services à l’étude - les services retirés Les sections suivantes expliquent les composants individuels du portefeuille de services.

Catalogue de services

Pipeline de services Portefeuille de services

Services retirés

Figure 3.12  Le portefeuille de services

Le catalogue des services est l’expression de la capacité opérationnelle du fournisseur, selon le contexte d’un client ou d’une sortie sur un marché. Le catalogue des services présente deux aspects : le catalogue des services business et le catalogue des services techniques (voir au Chapitre 9 pour plus de détails). La partie concernant le catalogue des services business est définie comme la cartographie des processus business critiques avec les services informatiques sous-jacents, conservant le détail des relations entre ces composants, soutenant un point de vue client du catalogue des services. Le catalogue technique des services est l’aspect du portefeuille des services qui n’est pas visible pour le client, contenant le détail de la composition technique des services, soutenant le point de vue fournisseur de services du catalogue des services. Le catalogue des services est constitué par les services qui sont actifs et approuvés lors de la phase d’exploitation des services. Le catalogue des services divise les services en composants. Il communique la politique, les guides de bonnes pratiques et la responsabilité ; il comprend les prix, les accords sur les niveaux de service et les conditions de livraison.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

37

Le catalogue des services décrit la part du portefeuille dans lequel les coûts sont amortis ou les profits sont perçus. Le catalogue des services sert aussi d’outil de visualisation pour les décisions faites par le SPM. La fourniture des services et la capacité à les fournir de façon satisfaisante sont également abordées dans le catalogue. Les actifs clients et les résultats business déclenchent des questions quant aux attentes concernant l’utilité et la garantie. Si des éléments dans le catalogue concernent le fait de savoir si ces attentes peuvent être satisfaites ou non, cela aboutira à un contrat ou à un accord de service. Les éléments du catalogue sont regroupés en lignes de service (Line of Service – LOS) basées sur les modèles les plus répandus d’activité business (voir Figure 3.13).

Gestionnaire de Produit Types de service Services populaires, demandés

Gestionnaire des relations

Catalogue de Service

Sources de demande Demande bien servie

Service réalisable

Demande peu servie

Services à retirer

Demande pas servie

Figure 3.13  Catalogue des services, directeurs de produit, lignes de service et gestion de la demande

L’approbation de la transition des services est nécessaire pour ajouter ou retirer des services du catalogue pour les raisons suivantes : • Si un élément doit être ajouté au catalogue, il faut que cet élément soit disponible si un client le demande. La due-diligence est nécessaire pour vérifier que le service proposé est complet et dispose d’un support. • Les éléments du catalogue des services se trouvent principalement dans la phase d’exploitation des services, avec les obligations contractuelles relatives au client. Une évaluation de tous changements à apporter au catalogue sera effectuée pour vérifier que toutes les obligations nécessaires ont été satisfaites. • L’ajout d’éléments dans le catalogue implique la disponibilité des aptitudes et des ressources aptes à satisfaire une demande spécifique d’un client. Le catalogue des services est un outil de stratégie essentiel en ce sens qu’il peut être vu comme une projection virtuelle des aptitudes réelles dont dispose le fournisseur de services. De nombreux clients s’intéressent uniquement à ce que le fournisseur puisse s’engager à faire à ce moment précis.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

38

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les services à l’étude correspondent à des services qui sont encore en développement pour un marché ou un client donné. Ces services seront appliqués lors de la phase d’exploitation, via la phase de transition des services, après que les phases de conception, de développement et de tests soient terminées. Les services à l’étude représentent la croissance et l’anticipation stratégique à venir. Ils renseignent sur la santé générale d’un fournisseur et indiquent comment de nouveaux concepts et des idées d’amélioration sont alimentés au moyen de la stratégie des services, de la conception des services et de l’amélioration continue des services. Une bonne gestion financière est nécessaire pour financer les services à l’étude. Certains services du catalogue sont des services retirés, cela signifie qu’ils ont été supprimés progressivement ou tout simplement retirés. La suppression progressive des services est un composant de la transition des services. Elle intervient pour garantir que tous les accords avec les clients seront maintenus et que les actifs des services supprimés ne font plus l’objet d’obligations contractuelles.

Développer des actifs stratégiques Les fournisseurs de services doivent considérer la gestion des services comme un actif stratégique. La gestion des services commence avec les aptitudes qui coordonnent et gèrent les ressources pour soutenir un catalogue des services. Les aptitudes et les ressources se renforcent mutuellement et sont modifiées jusqu’à l’obtention d’un niveau de service supérieur.

La gestion des services en tant que système de contrôle en boucle fermée La gestion des services est l’aptitude d’une organisation à fournir des services aux clients. Les services peuvent améliorer la performance des actifs clients. Des améliorations dans la conception des services, dans la transition des services et dans l’exploitation des services augmentent le potentiel de performance des clients et réduit les risques pour les clients. Les services dérivent des actifs de service. Le potentiel des services est converti en performance potentielle pour les actifs du client. Une augmentation du potentiel de performance stimule souvent la demande additionnelle en termes d’échelle et de périmètre. Cette demande se traduit par une augmentation de l’utilisation des actifs de service et justifie le maintien d’activités de maintenance et de mise à jour. Selon cette perspective, la gestion de services est un système de contrôle en boucle fermée ayant les fonctions suivantes : • Développer et maintenir les actifs de services. • Comprendre le potentiel de performance des actifs clients. • Élaborer les actifs de services sur la base des actifs clients au moyen de services. • Concevoir, développer et adapter les services.

La gestion de services en tant qu’actif stratégique Pour que la gestion des services se développe en actif de service, le réseau de création de valeur dans lequel le fournisseur de services opère doit d’abord être identifié. Ce réseau pourrait exister au sein d’une seule organisation, comme cela est souvent le cas pour les fournisseurs de type I et II. Le plus souvent, le réseau de création de valeur s’étend au-delà des limites de l’organisation et comprend les clients, les fournisseurs et les partenaires externes.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

39

Des actifs stratégiques sont dynamiques de par leur nature et doivent continuer à s’exécuter dans des conditions business et des objectifs organisationnels changeants. Il s’ensuit que les actifs stratégiques doivent avoir une capacité pédagogique. La gestion des services doit faire attention à l’interaction entre les actifs du client et les actifs de service (voir Figure 3.14).

Unité métier Aptitudes Ressources

+ Potentiel de performance –

Risque Demande

+ Services +

Potentiel de service

+

Frais de service Capacité inutilisée

+ + Retour Chiffre + coûts + sur actifs d’affaires Récompense + Produits Accord avec et services le client + Valeur Compensation Revenue + + Clients/ Contrat avec marchés le fournisseur

Département de service

Valeur

–

Risque

Aptitudes Resources

–

+

Chiffre d’affaires

Produits et services + Chiffre Valeur + d’affaires + Fournisseurs/ partenaires Chiffre d’affaires

Value Network

Figure 3.14  La gestion des services en tant qu’actif stratégique constitue un système de contrôle en boucle fermée.

Augmentation du potentiel du service Les actifs de service d’un fournisseur de services représentent le potentiel de service dont disposent les clients. L’un des objectifs de base de la gestion des services est l’amélioration du potentiel des services, des aptitudes et des ressources. Exemple : la formation du personnel augmente le potentiel des services suite à l’amélioration des aptitudes. Cette amélioration des aptitudes est évidente dans les aspects suivants : – Le personnel a plus de connaissances pour surveiller et analyser le cycle de vie. – Les ressources sont améliorées car du personnel est ajouté aux compétences de base et les heures de disponibilité du centre d’assistance sont augmentées. Augmentation du potentiel de la performance Les services d’un fournisseur de services représentent le potentiel pour améliorer la performance des actifs clients. Visualiser et définir le potentiel de performance des services pour faire en sorte que toutes les décisions soient concentrées sur la création de valeur pour le client.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

40

Les fondamentaux de la gestion des services informatiques selon ITIL V3

ITIL pose un certain nombre de questions de base : • Quel est notre marché ? • Que souhaite le marché ? • Avons-nous quelque chose d’unique à offrir au marché ? • Avons-nous le bon portefeuille pour un marché donné ? • Avons-nous le bon catalogue pour un client donné ? • Est-ce que chaque service est conçu pour conduire au résultat souhaité ? • Est-ce que la mise en œuvre de chaque service est telle qu’elle mène au résultat désiré ? • Avons-nous les bons modèles et les bonnes structures pour être un fournisseur de services ?

Préparer la mise en œuvre Audit stratégique Avant de formuler une stratégie des services, le fournisseur doit d’abord examiner ses aptitudes distinctives. • Quels sont nos services les plus distinctifs ? • Quels sont nos services les plus lucratifs ? • Quels sont nos clients et les parties prenantes les plus satisfaits ? • Quelles sont nos activités les plus efficaces ? De cette façon, les points forts et les points faibles peuvent être examinés, les facteurs critiques de succès (Critical Success Factors – CSF) peuvent être déterminés, les risques et les opportunités peuvent être définis. Fixer les buts Des objectifs clairs garantissent des prises de décision cohérentes. Pour fixer ses buts et ses objectifs, une organisation doit savoir ce que le client veut réaliser. ITIL définit trois différents types d’information qui déterminent les objectifs d’un service : • Les tâches – quelle est la tâche du service à fournir ? • Les résultats – quel type de résultats le client espère-t-il obtenir ? • Les contraintes – quels sont les facteurs restrictifs pour le client, afin d’obtenir ces résultats. Il est essentiel d’observer ce qui a de la valeur aux yeux du client. Regardez le service de l’extérieur. Commencez par les objectifs business communs car ils conduisent à une meilleure compréhension de l’utilité du service et à sa garantie. Les clients n’achètent pas des services ; ils achètent la satisfaction d’un besoin spécifique.

Définir les facteurs critiques de succès Pour chaque marché, il y a des facteurs critiques de succès qui déterminent le succès ou l’échec d’une stratégie des services. Ces facteurs ne sont pas influencés par les besoins du client, ou par les tendances du business, les règlements de la concurrence, les fournisseurs, les standards, ou les meilleures pratiques et technologies. ITIL soutient que les facteurs critiques de succès, aussi appelés facteurs stratégiques de l’industrie (Strategic Industry Factors – SIF), ont tous les caractéristiques générales suivantes : • Ils sont définis en termes d’aptitudes et de ressources • Ils semblent être la clé du succès des leaders du marché

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

41

• Ils sont définis au niveau du marché • Ils sont la base de la concurrence entre rivaux • Ils sont dynamiques • Ils requièrent généralement des investissements considérables et des temps de développement importants • Leur valeur se calcule au moyen de la combinaison d’autres facteurs Les facteurs critiques de succès changent ou sont influencés par un ou plusieurs des facteurs suivants : • clients • concurrence • fournisseurs • organisations de régulation Dans chaque marché, les fournisseurs de services ont besoin d’une série d’actifs de base pour soutenir le portefeuille clients avec un portefeuille des services (voir Figure 3.15).

Taille du marché

Portefeuille des services

Portefeuille des clients

Facteurs critiques de succès

Figure 3.15  Facteurs critiques de succès dans un marché

Les facteurs critiques de succès sont décisifs pour réussir sur un marché. Ils sont également utiles pour évaluer la position stratégique d’un fournisseur de services. Cela signifie que les facteurs critiques de succès doivent être encore plus définis en termes de propositions de valeur spécifiques faites au client. Exemple : pour être compétitif sur un marché, il faut peut-être avoir une grande disponibilité ; une tolérance aux pannes de l’infrastructure informatique est essentielle et une capacité adéquate est requise pour garantir la continuité.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

42

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Dans de nombreux marchés, l’efficacité économique constitue un facteur critique de succès courant, tandis que dans d’autres marchés, c’est la connaissance d’un domaine spécialisé ou la fiabilité de l’infrastructure qui constituent des critères beaucoup plus importants. ITIL conseille de mener une analyse stratégique pour chaque marché, chaque client important et chaque portefeuille des services, dans le but de déterminer les positions stratégiques actuelles et les positions stratégiques qui mèneront au succès. Enquête sur le potentiel business Les fournisseurs de services peuvent être actifs sur plus d’un marché. L’un des composants de la planification stratégique est l’analyse de la présence sur plusieurs marchés : une analyse des points forts et des points faibles, des opportunités et des risques sur chaque marché. Les fournisseurs de services analysent également l’extension possible du marché potentiel. Les fournisseurs déterminent quels sont les besoins des clients qui peuvent être satisfaits de façon efficace et efficiente par leurs services, tout en décidant quels marchés servir et quels marchés ignorer. En premier lieu, identifier les marchés suivants : • Les marchés qui peuvent être servis avec les actifs existant ; • Les marchés qu’il faut éviter avec les actifs existants. Ensuite déterminer les marchés sélectionnés : • Quelle est l’offre de services (portefeuille des services) • Quels clients (portefeuille clients) • Facteurs critiques de succès • Modèles de service et actifs de service • Services à l’étude et catalogue des services Synchronisation avec les besoins du client Il est essentiel de comprendre les relations entre le client et le marché. Les clients peuvent couvrir un ou plusieurs marchés. Les marchés peuvent inclure un ou plusieurs clients. • Le marché des fournisseurs de Type I est interne à l’unité organisationnelle dont il fait partie. • Le marché des fournisseurs de Type II est interne à l’entreprise, mais il se répartit sur les unités business (business units). • Le marché des fournisseurs de Type III se compose de plus d’une entreprise. Expansion et croissance Quand il arrive que les stratégies des services soient liées à un marché, il est plus facile de prendre des décisions quant aux portefeuilles, aux conceptions, à la production et aux améliorations à long terme. La croissance et l’expansion d’une entreprise sont moins risquées quand elles reposent sur des aptitudes de base et sur des performances qui ont fait leurs preuves. Les stratégies gagnantes d’expansion sont souvent basées sur l’utilisation efficace des actifs de service et des portefeuilles clients.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

43

La croissance sur un marché spécifique est rendue possible par : • l’extension des contrats existants • l’augmentation des demandes • l’extension au moyen de services complémentaires

Processus La version 3 d’ITIL distingue trois processus au niveau stratégique • la gestion financière • la gestion de la demande • la gestion du portefeuille des services Ces processus seront brièvement décrits ici ; des informations détaillées sont disponibles au chapitre 9 de ce volume.

Gestion financière La gestion financière est un composant à part entière de la gestion des services. Elle fournit des informations essentielles de gestion, qui sont requises pour garantir une fourniture efficace et rentable des services. Une gestion financière efficace permet à l’organisation de rendre compte de tous les frais de façon responsable, à imputer directement aux services. Comment pouvons-nous recourir à la gestion financière pour obtenir des informations sûres, quant à la création de valeur ? L’évaluation des services garantit que le business comprend précisément ce qui est fourni au moyen des TI. L’utilité et la garantie doivent être traduites en montants monétaires, afin de calculer la valeur. ITIL définit deux concepts essentiels de valeur pour une évaluation des services : la valeur d’approvisionnement (les coûts de production) et le potentiel de valeur de service (une composante de valeur ajoutée). Un des objectifs de la gestion financière est de garantir l’obtention d’un financement correct pour la fourniture et l’achat de services. Un plan fournit la traduction et la qualification financière de la demande anticipée pour les services informatiques. ITIL divise la planification en trois zones principales, chacune représentant les résultats financiers nécessaires à une transparence continue et à l’évaluation des services : Planification opérationnelle et financière, planification de la demande, planification légale et environnementale. Une planification soignée assure que les données et les modèles financiers fourniront des informations correctes quant au développement de la demande et de la fourniture des services. Analyse des investissements L’objectif de l’analyse des investissements (analyse des investissements des services) consiste à fournir une indication de la valeur d’un service, à partir de la valeur obtenue et des coûts encourus, pour tout le cycle de vie. Comptabilité La gestion financière construit un pont entre les systèmes financiers communs et la gestion des services. Une fonction comptable, tournée vers le service, permet d’obtenir beaucoup plus de

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

44

Les fondamentaux de la gestion des services informatiques selon ITIL V3

renseignements et donc de mieux comprendre la fourniture et la consommation des services, ainsi que la production de données qui sont directement pertinentes pour le processus de planification. Dynamique des coûts variables (Variable Cost Dynamics – VCD) La dynamique des coûts variables (VCD) se concentre sur l’analyse et la compréhension des nombreuses variables qui influencent les coûts des services. L’analyse de la dynamique des coûts variables (VCD) peut servir à analyser l’impact anticipé d’événements, tels que les acquisitions, les désinvestissements et les changements apportés au portefeuille des services, ou bien des alternatives de services. Décisions fondamentales pour la gestion financière Certains concepts de gestion financière ont un impact significatif sur le développement des stratégies des services. ITIL décrit un certain nombre de ces concepts, afin que chaque organisation puisse décider les options qui sont les plus adaptées à leurs propres stratégies des services. • Remboursement des coûts, centre de valeur ou centre de comptabilité ? • Facturation : facturer ou ne pas facturer • Liste de contrôle de la mise en œuvre de la gestion financière Pour plus de renseignements sur la gestion financière, consulter le chapitre 9. Un des grands défis lors de la recherche de financements pour les projets ITIL consiste à identifier un objectif business spécifique qui soit dépendant de la gestion des services. Pour une description des techniques de retour sur investissement (Return on Investment – ROI), post-ROI et le dossier business, consulter la section sur les Méthodes, techniques et outils, plus loin dans ce chapitre.

Gestion de la demande (Demand Management – DM) La gestion de la demande est un aspect essentiel de la gestion des services, en harmonisant l’offre avec la demande. Le but de la gestion de la demande est de prédire de façon aussi précise que possible l’achat de produits, et si possible, de les réguler. Une demande mal gérée représente un risque pour les fournisseurs de services car une capacité excessive engendrera des coûts qui ne seront pas compensés par une création de valeur. D’un autre côté, une capacité insuffisante a un impact sur la qualité des services fournis et limite la croissance des services. Les accords de niveaux de service (Service Level Agreements – SLA), les prévisions de demande, la planification et une coordination étroite avec le client, minimisent l’incertitude de la demande, mais ils ne peuvent pas l’éliminer complètement. La gestion des services pose un problème supplémentaire : celui de la synchronisation de la production et de la consommation. L’exploitation des services n’est pas possible sans l’existence de la demande pour le produit à consommer. Gestion de la demande basée sur les activités Les processus business sont la source principale de la demande de services. Les modèles d’activité business (Patterns of Business Activity – PBA) influencent le modèle de la demande. Il est primordial d’étudier le business du client pour identifier, analyser et enregistrer ces modèles, qui servent de fondations solides à partir desquelles une stratégie de gestion des capacités peut être créée.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

45

Packages de services Les services de base fournissent les résultats de base pour le client. Ils représentent la valeur que le client souhaite et pour laquelle il est prêt à payer. Les services de base servent de base pour les propositions de création de valeur destinées au client. Les services de support rendent possible cette proposition de valeur (services de faisabilité ou facteurs de base) ou l’améliorent (services d’amélioration ou facteurs de stimulation). L’ensemble de ces services de base et de support constitue un aspect essentiel d’une stratégie de marketing. Les fournisseurs de services doivent faire une analyse approfondie des conditions principales au sein de leur environnement business, des besoins spécifiques du client ou des types de clients qu’ils servent, ainsi que des alternatives disponibles pour les clients. Ces décisions sont stratégiques car elles comprennent la vision à long terme, qui permettra la création continue de valeur pour les clients sous la forme de méthodes business, de normes et de standards, de technologies et de réglementations, au sein d’une industrie changeante. L’ensemble des services de support et des services de base influence la production des services, et elle représente un défi pour les phases de conception, de transition et d’amélioration continue. Les packages de services s’accompagnent d’un ou plusieurs packages de niveaux de services (Service Level Packages – SLP). Chaque package de niveaux de services (SLP) couvre un niveau donné d’utilité et de garantie, selon la perspective des résultats et des actifs du client ainsi que des modèles d’activité business (PBA). Chaque SLP peut fournir un ou plusieurs modèles de demande. Consulter le chapitre 9 pour plus de renseignements sur la gestion de la demande.

Gestion du portefeuille des services (Service Portfolio Management – SPM) SPM est une méthode servant à gérer tous les investissements de gestion des services. L’objectif de SPM est de créer le maximum de valeur tout en gérant les risques et les coûts. SPM commence par la documentation des services standardisés de l’organisation, et en particulier, par le catalogue des services. Pour que ce soit financièrement possible, le portefeuille doit trouver le juste équilibre entre les services à l’étude et ceux au catalogue. Valeur business du SPM La valeur d’une stratégie de portefeuille de services représentera la capacité d’anticiper les changements en maintenant la stratégie et la planification. SPM est un processus dynamique continu qui comprend les méthodes de travail suivantes : • Définir – dresser l’inventaire des services et des dossiers business, et valider les données du portefeuille ; la nature cyclique du processus SPM implique que cette phase, non seulement dresse l’inventaire des services, mais aussi revalide continuellement les données. • Analyser – maximiser la valeur du portefeuille ; synchroniser, établir les priorités et équilibrer l’offre et la demande ; c’est au cours de cette phase que les objectifs stratégiques prennent forme. • Approuver – compléter le portefeuille proposé, autoriser les services et les ressources ; prendre des décisions pour le futur.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

46

• Établir la charte – communiquer les décisions, allouer les ressources et établir la charte des services. Consulter le chapitre 9 pour une description plus détaillée du processus de gestion du portefeuille de services.

3.4 Organisation Les organisations TI sont des systèmes complexes, au sein d’un système encore plus complexe : le métier, les clients et l’industrie. Le principe des coûts de transaction est une façon simple, mais efficace, qui permet aux organisations de justifier leur existence, sachant que l’organisation est en mesure de gérer ses coûts de transaction. La combinaison d’une quantité adéquate de ressources, d’une stratégie bien définie et de caractéristiques distinctives, permettent à l’organisation de fournir de meilleurs services sur un marché concurrentiel, et de justifier l’acquisition de ressources supplémentaires. Voir Figure 3.16 pour une illustration de ce cycle.

Capacité d’acquérir des ressources

Permet à l’organisation de créer

Une stratégie organisationnelle

Ce qui augmente son/sa

Investissements des ressources dans le développement

Aptitudes

Permet à l’organisation de créer

Niveau de spécificité

Figure 3.16  Cycle organisationnel de création de valeur

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

47

Le développement d’une organisation Il n’y a pas qu’une seule façon d’organiser une entreprise. Les facteurs extérieurs ont un impact significatif sur la stratégie des services d’une organisation. Une stratégie des services constitue le projet d’ensemble implicite de la conception, des dimensions et du périmètre d’une organisation. Les organisations sont caractérisées par un style de gestion dominant. Celui-ci correspond aux besoins de l’organisation à un moment donné. ITIL décrit cinq phases reconnaissables de développement organisationnel, selon le degré de centralisation et de décentralisation. Il est essentiel de connaître la situation dans laquelle se trouve l’organisation, ainsi que l’ensemble des opportunités qui s’offrent à cette organisation.

Phase 1 : Réseau Dans la phase 1, une organisation se concentre sur la fourniture rapide, informelle et ad hoc des services. L’organisation est orientée vers la technologie et elle n’est pas à l’aise avec les structures formelles. Pour les organisations au stade 1, l’innovation et l’esprit d’entreprise constituent des valeurs organisationnelles importantes. Quand la demande des services augmente, ce modèle cesse d’être efficace. Une structure en réseau est un regroupement qui coordonne les activités au moyen d’accords, plutôt qu’une hiérarchie ou une autorité formelle. Les membres du personnel travaillent ensemble pour compléter leurs aptitudes. Avantages d’une structure en réseau : • Absence de coûts bureaucratiques élevés associés aux organisations complexes ; • Organisation plate avec peu de directeurs ; • Flexibilité permettant de modifier ou de changer rapidement la structure. Inconvénients d’une structure en réseau : • Les directeurs doivent surveiller l’intégration des activités ; • Problèmes significatifs de coordination ; • Opportunités d’externalisation des activités fonctionnelles. Conseil : Un changement de style de direction est nécessaire pour relever ces défis.

Phase 2 : Direction Une équipe de direction forte peut résoudre la crise de la phase 1. La direction assume la responsabilité de la stratégie et guide les gestionnaires pour qu’ils assument leurs propres responsabilités fonctionnelles. La phase 2 se concentre sur l’établissement de structures hiérarchiques (supervision) qui différencient les activités fonctionnelles. La communication se fait plus formelle et plusieurs processus de base sont introduits. Un tournant se produit si une crise autonome émerge, due à une centralisation qui empêche toute prise de décision. Celle-ci annule la liberté d’expérimenter et d’innover. Conseil : Dépasser ce défi en délégant davantage. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

48

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Phase 3 : Délégation Au cours de la phase 3, des efforts sont faits pour améliorer l’efficacité technique et pour laisser de la place à l’innovation, afin de réduire les coûts et améliorer les services. Une structure organisationnelle décentralisée est adoptée, dans laquelle la responsabilité passe de la propriété fonctionnelle (supervision) à la propriété de processus. La phase 3 présente l’inconvénient d’une absence de concordance entre les objectifs de la propriété fonctionnelle et de la propriété des processus. Les propriétaires fonctionnels ont le sentiment de perdre le contrôle. Pour cette raison, le processus est généralement abandonné. Conseil : Améliorer la coordination au sein de l’organisation en mettant en place des systèmes et des programmes formels.

Phase 4 : Coordination Au cours de la phase 4, l’accent est mis sur l’utilisation de systèmes formels, comme moyens d’améliorer la coordination. Des processus de centralisation des fonctions techniques et de décentralisation de la gestion de services émergent, dans le but d’améliorer les temps de réponse aux demandes du marché. Conseil : Si tout est en ordre à l’intérieur, l’étape suivante est pour le métier l’amélioration de la coopération avec le client.

Phase 5 : Collaboration Au cours de la phase 5, l’accent est mis sur l’amélioration de la coopération avec le business. Une structure couramment utilisée est une structure matricielle, avec un flux de responsabilités fonctionnelles (supervision) sur une ligne verticale, et le flux de responsabilités produit ou client sur une ligne horizontale. Une organisation avec une structure matricielle assume toutes les fonctions dont elle a besoin. Avantages d’une structure matricielle : • Minimiser et dépasser les barrières fonctionnelles. • Diminuer le temps de réponse aux changements de produits ou de besoins clients. • Favoriser la communication entre les spécialistes fonctionnels. • Créer des opportunités d’apprentissage mutuel entre les membres des équipes chargées des différentes functions. • Utiliser les compétences du personnel spécialisé qui peut se passer d’un produit à un autre et d’un client à un autre. Inconvénients d’une structure matricielle : • Manque d’une structure de surveillance que le personnel peut utiliser pour construire un modèle stable d’attentes. • Rôles conflictuels pouvant démoraliser le personnel. • Situation de conflits pouvant se vérifier entre les équipes chargées des fonctions et les équipes chargées du produit ou du client.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

49

Du groupe de travail au département Si un groupe de travail grandit et atteint la taille d’un département, alors le groupe peut être divisé selon des attributs. Voir table 3.1 pour une vue d’ensemble des structures organisationnelles de base. Structure de base Fonction

Produit

Marché ou client

Géographie

Processus

Description

Considérations Stratégiques

L’organisation par fonction est la meilleure façon de se spécialiser. Regroupement des ressources et minimiser les redondances. Les entreprises concentrées sur des produits nouveaux et divers préfèrent l’organisation par produit. Ce type d’organisation se trouve surtout dans des industries de transformation. L’organisation par marché ou client permet une différentiation par une connaissance des exigences du client et une capacité de réponse plus élevées.

• Spécialisation • Développement des standards • Petite échelle • Focus sur les produits • Produit phare • Connaissance

• Service unique pour chaque segment • Service après-vente • Pouvoir chez le client • Service rapide L’organisation géographique est privilégiée • Services sur site lorsque les services sont fournis à proximité. • Proche au client, pour la fourniture Réduit les frais de déplacement et de distribution et le support. en tirant profit de la connaissance du la situation • L’organisation est vue comme une locale. entreprise locale L’organisation par processus est privilégiée • Besoin de réduire le temps d’un lorsque les processus sont gérés de bout en bout. cycle de production • Excellence de processus

Tableau 3.1  Structure basique d’organisation

Conception de l’organisation La stratégie est la clé de la conception d’une organisation. La stratégie détermine les objectifs et les critères à chaque étape du processus de conception. La première étape business consiste à déterminer la structure du département pour concevoir les processus de base. (Figure 3.17). Forces stratégiques

Partenariat

Concentré sur le processus

Structure organisationnelle

Elevé

Collaboration

Contrôle et harmonisation

Coordination

Processus et décentralisation Délégation

Structure et centralisation Rapidité et créativité

Directive Faible Réseau

Figure 3.17  Associer les forces stratégiques avec le développement de l’organisation

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

50

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Culture de l’organisation La culture d’une organisation est un ensemble de valeurs et de normes collectives qui déterminent les trajectoires des interactions internes et externes. Une culture collective contribue à l’efficacité d’une organisation. Deux types de valeurs coexistent : • Valeurs finales – les résultats attendus en termes de qualité, d’excellence, de fiabilité, d’innovation et de rentabilité. • Valeurs instrumentales – le comportement attendu en termes de standards, de respect de la tradition et de l’autorité, de traitement soigné et régulier ainsi que de modération. Il est possible d’analyser la culture d’une organisation de gestion des services comme suit : • Déterminer les valeurs finales et les valeurs instrumentales ; • Voir si les objectifs, les normes et les réglementations transmettent au personnel les valeurs de la culture de l’organisation ; • Évaluer si le nouveau personnel est immédiatement accepté dans la culture de l’organisation.

Stratégie de sourcing Le but de la stratégie des services est d’améliorer les compétences de base. Parfois, il est plus efficace d’externaliser certains services. Ceci est appelé le principe de séparation des intérêts (Separation of Concerns – SoC). Celui-ci résulte de la recherche d’une stratégie de différenciation, par la redistribution des ressources et des aptitudes. Le risque d’une externalisation des services est lié à la cession d’une activité à un concurrent : • Substitution – le vendeur peut remplacer l’organisation de sourcing ; • Perturbation – le vendeur peut nuire à votre réputation ; • Caractéristique distinctive – vous pouvez devenir dépendant d’une autre organisation.

Structures d’externalisation La dynamique de l’externalisation des services exige que les organisations définissent formellement les dispositions d’une stratégie d’externalisation. Cela comprend également la structure et le rôle des parties intéressées ainsi que l’impact de l’externalisation sur la prise de décision. Les formes génériques d’externalisation suivantes peuvent être délimitées : • Externalisation interne : – Type 1 Interne – fourniture de services par le personnel interne ; ce type offre le plus de contrôle, mais le volume est limité. – Type 2 Services partagés – travailler avec des Domaines d’Activités Stratégiques (Business Unit) internes offre des coûts inférieurs que le Type 1 et davantage de standardisation, mais le volume est encore limité. • Externalisation traditionnelle : – Externalisation complète d’un service – un seul contrat avec un fournisseur de services améliore les capacités de volume mais limite les aptitudes d’excellence (best-in-class). • Externalisation multi-vendeur : – Principal – Un seul contrat avec un fournisseur de services travaillant avec des fournisseurs multiples ; amélioration des aptitudes et des risques mais augmentation de la complexité. – Consortium – Une sélection de fournisseurs multiples ; l’avantage réside dans l’excellence et plus de surveillance ; l’inconvénient est le risque de devoir travailler avec la concurrence.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

51

– Externalisation sélective – Un groupement de fournisseurs de services sélectionnés et gérés via un récepteur de services. C’est la structure la plus difficile à gérer. – Co-externalisation – Une variation de l’externalisation sélective par laquelle le bénéficiaire des services combine une structure de services internes ou partagés avec des fournisseurs externes  ; dans ce cas, le bénéficiaire des services se comporte comme un intégrateur de services. En ce qui concerne l’externalisation de services, un équilibre doit être trouvé entre les risques acceptables et le contrôle.

Externalisation avec des fournisseurs multiples Il semble que l’externalisation avec des fournisseurs multiples soit une bonne méthode car l’organisation peut maintenir de fortes relations avec chaque fournisseur, tandis que les risques sont répartis et les coûts sont contrôlés. Le défi est la gouvernance et la gestion de ces relations. Liste de contrôles pour la sélection des fournisseurs : Compétences prouvées- le personnel, l’utilisation des technologies, l’innovation, l’expérience et toute éventuelle certification. • Antécédents (track record) – qualité, valeur financière, dévouement. • Dynamique de relation – la vision et la stratégie sont-elles conformes à celles de l’organisation ? • Qualité des solutions – les services ont-ils été fournis comme requis ? • Aptitudes générales – stabilité financière, ressources, systèmes de gestion, périmètre et gamme de services.

Interfaces avec le fournisseur de services (Service Provider Interfaces – SPI) Plusieurs guides de bonnes pratiqueset points de référence sont nécessaires pour soutenir le développement des relations business. Les interfaces avec le fournisseur de services (SPI) offrent ces points de référence. Pendant les négociations des contrats, les responsabilités et les niveaux de service devraient être négociés : • Identification des points d’intégration des différents processus de gestion ; • Identification des rôles et des responsabilités spécifiques ; • Identification des informations de gestion pertinentes pour le client. Les propriétaires de processus possèdent les SPI (interfaces avec le fournisseur de services), les définissent et les maintiennent. La définition des SPI comprend : • Les pré requis technologiques (par ex. les standards d’outils de gestion ou les protocoles prescrits) • Les exigences en matière de données (par ex. les événements ou les enregistrements spécifiques), les formats (lay-out des données), les interfaces (par ex. API, ports du pare-feu), et les protocoles (par ex. SNMP, XML) • Les exigences non-négociables • Les rôles/responsabilités requis • Les temps de réponse et les chemins d’escalade

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

52

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Gouvernance de sourcing La gouvernance est un référentiel pour l’autorité de décision, qui encourage le comportement souhaité en matière de sourcing. La différence entre la gouvernance et la gestion est que la gestion concerne la prise de décisions et la mise en œuvre des processus ; la gouvernance concerne la prise des bonnes décisions. La gouvernance est souvent oubliée, elle constitue donc le lien le plus fragile dans la stratégie de sourcing des services. Quelques interventions simples suffisent pour faire les premiers pas vers la gouvernance : • Établir une organisation de gouvernance – les décisions peuvent être prises au bon niveau ; • Différentier les domaines de gouvernance – faire des distinctions entre les domaines importants, tels que la fourniture des services, la communication et la gestion des contrats ; • Établir une matrice fixe de décision – les matrices RACI ou RASIC sont les formes les plus répandues de matrices de décision. ISO/IEC 20000 est la première norme internationale formelle conçue spécifiquement pour la gestion des services informatiques. Elle fournit une base pour la structure de gestion entre les fournisseurs internes et externes, et minimise donc les risques encourus avec le sourcing de services. Il est notamment utile dans les environnements multisource.

Facteurs critiques de succès Les facteurs d’une stratégie d’externalisation dépendent souvent : • Des résultats escomptés • Du modèle optimal pour la fourniture de services • Du meilleur site depuis lequel les services seront fournis Approche recommandée de la stratégie : • Analyser les compétences de gestion de services internes de l’organisation ; • Comparer ces résultats avec les standards de l’industrie (benchmark) ; • Examiner les aptitudes réelles de l’organisation à apporter une valeur stratégique. Pour mesurer les effets du sourcing, l’organisation doit effectuer une évaluation initiale de ses métriques de performance, avant de commencer toute mise en œuvre. Cela peut se faire avec deux types de métriques : • Métrique business – économies financières, amélioration du niveau de service, efficacité des processus business. • Métrique client – disponibilité et consistance des services, davantage de fourniture et de qualité des services.

Rôles et responsabilités Un rôle clé dans la mise en œuvre de la stratégie de sourcing est celui de Directeur de Sourcing, qui répond au Directeur TI et gère la mise en œuvre du sourcing. Autres rôles importants : • Directeur de la gestion des services – supervise le fournisseur pour le compte du business. • Gestionnaire de contrat – gère le contrat de services selon la perspective du fournisseur. • Directeur de produit – gère les services au sein de l’organisation du fournisseur de services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

53

• Propriétaire de processus – gère les modèles de processus qui ont été développés pour le compte des utilisateurs. • Représentants business – représentent les intérêts des clients et gèrent les relations de sourcing selon cette perspective.

3.5 Méthodes, techniques et outils Les services sont des systèmes sociotechniques, composés d’actifs de service, envisagés comme des éléments opérationnels. Les interactions entre deux sous-systèmes, sous forme de dépendances (passives) et d’influences (actives), sont primordiales pour la performance de la gestion de services, comme système de création de valeur. L’efficacité de la stratégie des services dépend d’une relation bien gérée entre les sous-systèmes sociaux et techniques. Il est essentiel d’identifier et de gérer ces dépendances et ces influences. Les révisions de conception des services, de transition des services, d’exploitation des services et de l’amélioration continue des services doivent comprendre une analyse de toute défaillance éventuelle ou un manque de synchronisation entre les deux sous-systèmes. L’intérêt d’une approche équilibrée est évident quand on considère ce qui suit : • les améliorations quant à la conception et à la réalisation des activités, des tâches et des interfaces peuvent compenser les insuffisances en matière de ressources humaines. • investir en connaissances, aptitudes, comportement et expérience peut compenser une mauvaise conception des systèmes. • automatiser les activités de routine peut réduire les décalages non souhaités et soulager la pression au travail par une simple mise au point technique. La conception des systèmes sociotechniques est un point crucial en matière de gestion des services. Il est important de savoir que les services sont beaucoup plus qu’une série d’activités produisant une certaine valeur. Ils sont des systèmes avec des interactions complexes entre différents facteurs de production et d’actifs de service.

Automatisation des services L’automatisation peut avoir un impact significatif sur la performance des actifs de service tels que la gestion, l’organisation, les personnes, les processus, les connaissances et les informations. La gestion des services peut bénéficier de l’automatisation dans les domaines suivants : conception et modélisation, catalogues de services, modèles d’identification et d’analyse, classification, investigation et optimisation. Pour se préparer à l’automatisation, ITIL recommande de suivre les étapes suivantes : • Simplifier les processus de service avant l’automatisation, mais faire attention à ne perdre aucune information essentielle. • Clarifier le flux des activités, l’attribution des tâches, les besoins d’information et d’interaction. • Dans des situations de libre-service, réduire la zone de contact que les utilisateurs ont avec les systèmes et les processus sous-jacents.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

54

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Ne pas précipiter la mise en œuvre de l’automatisation quand celles-ci impliquent des tâches et des interactions qui sont complexes ou qui ne sont pas des routines.

Analyse de services et instrumentation L’analyse de services revient à intégrer des informations dans un contexte de modèles. La compréhension des modèles d’information permet de répondre aux questions suivantes : • Comment cet incident influence-t-il le service ? • Comment cet incident influence-t-il le business ? • Comment devrions-nous répondre ? Dans ce cas, la séquence Données-Informations-Connaissances-Sagesse (Data-InformationKnowledge-Wisdom – DIKW) peut être utilisée. Cette série décrit la valeur ajoutée pouvant être apportée aux données en les observant dans ce contexte. L’instrumentation décrit les technologies et les techniques utilisées pour évaluer le comportement des éléments de l’infrastructure. L’instrumentation peut rassembler une vaste quantité de données de base, mais il faut comprendre davantage le contexte pour déterminer la pertinence réelle des données et les saisir en tant qu’informations. Pour saisir les données en tant qu’informations, il faut comprendre les relations entre les données et les voir dans le contexte approprié. Cela peut se faire sur la base de quatre questions : qui, quoi, quand et où. Cela est comparable à la série gestion des événements, – pannes, -performances.

Interfaces avec les services Caractéristiques d’interfaces correctes de service La conception des interfaces de service est essentielle pour la gestion des services. Les interfaces de service satisfont les exigences de base de garantie, tels que : • Les interfaces doivent être faciles à trouver et à utiliser. • Les interfaces doivent être disponibles et ce, dans une forme qui garantisse les opportunités de choix et de flexibilité aux utilisateurs. • Les interfaces doivent avoir une capacité suffisante pour éviter les temps d’attente en cas d’utilisation simultanée par de nombreux utilisateurs. • Les interfaces doivent être accessibles à des utilisateurs ayant différentes aptitudes ou compétences et différents niveaux d’expérience ou de handicap.

Combinaisons de service et technologie Les progrès en matière de technologie de la communication influencent l’interaction entre les fournisseurs de services et leurs clients. La technologie contribue à la communication avec le client de cinq façons différentes : 1. Communication sans technologie – telle que les services de conseil. 2. Communication assistée par la technologie – seul le fournisseur a accès à la technologie ; par exemple, un agent d’un aéroport qui utilise un terminal d’ordinateur pour enregistrer des clients. 3. Communication facilitée par la technologie – le client et le fournisseur ont tous deux accès à la même technologie.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

55

4. Communication effectuée à l’aide de la technologie – le fournisseur de services et le client sont distants géographiquement ; par exemple, un client qui reçoit des informations via un centre de services. 5. Communication générée par la technologie – le client voit le fournisseur de services uniquement sous la forme de technologie, via une interface en libre service, ce qui convient aux activités de routine, comme les distributeurs de billets de banque.

Canaux libre service L’automatisation ajoute de la valeur à la capacité. La capacité des canaux pour le libre service a un coût marginal bas, une montée en charge illimitée, ne se fatigue pas, offre des performances cohérentes et illimitées, et une disponibilité de 24/7 pour un coût relativement bas.

Outils pour la stratégie des services Simulation La dynamique du système (system dynamics) est une méthodologie pour comprendre et gérer les problèmes complexes des organisations informatiques. Elle offre une méthode pour gérer et modeler les processus de feedback, les fournitures et les flux, les retards et tout autre problème complexe. C’est un outil pour évaluer les conséquences de nouvelles politiques et de nouvelles structures avant de les mettre en pratique. La dynamique du système peut fournir un aperçu quant aux situations suivantes : • Piège des aptitudes – Pour inciter le personnel à travailler davantage, l’organisation fait inconsciemment en sorte qu’un niveau toujours plus élevé de tension soit nécessaire pour atteindre le même niveau de performance. • Piège des outils – Bien que les outils soient souvent très utiles, ils demandent également le développement de connaissances et d’expériences. Les organisations négligent l’impact d’une pression sur le travail à court terme, accrue par des formations, de l’apprentissage et des activités pratiques, ce qui ajoute des risques supplémentaires involontaires. • Piège du pompier – Quand une organisation récompense les gestionnaires pour avoir éteint rapidement les incendies, la performance peut être compromise à long terme ; dans ce cas, il pourrait être bénéfique de ne pas récompenser l’extinction des incendies.

Modélisation analytique La modélisation analytique couvre une très vaste gamme d’éléments. La stratégie des services ainsi que les autres fonctions et les processus du cycle de service, peuvent bénéficier de la connaissance dérivant de la modélisation analytique, pour améliorer la performance à la lumière des contraintes techniques, financières et de temps. Six Sigma, PMBOK® et PRINCE2® offrent des méthodes éprouvées, qui reposent sur des modèles analytiques. Elles doivent être évaluées et adoptées dans le contexte de la stratégie des services et de la gestion des services.

Retour sur investissement L’un des plus grands défis concernant la recherche de financement pour les projets ITIL est l’identification d’un objectif business spécifique, qui soit dépendant de la gestion des services. Dans ce but, cette section couvrira les trois techniques suivantes : • dossier business – une façon d’identifier les objectifs business qui sont dépendants de la gestion des services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

56

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• préprogramme ROI (retour sur investissement) – techniques pour analyser quantitativement les investissements dans la gestion des services • post-programme ROI (retour sur investissement) – techniques pour analyser rétroactivement les investissements dans la gestion des services

Dossier business Un moyen de justifier les investissements concernant les initiatives de gestion des services est de réaliser un dossier business. Un dossier business est un instrument de prise de décision, de support et de planification qui envisage les conséquences éventuelles de toute action business. Les conséquences peuvent être aussi bien qualitatives que quantitatives. Le cœur d’un bon dossier business est souvent une analyse financière. L’impact business doit être directement lié aux objectifs business. Un objectif business est la raison pour laquelle une initiative de la gestion des services est prise en considération. Un objectif stratégique, associé à une productivité croissante, peut, par exemple, s’appuyer sur l’introduction de produits compétitifs. Tandis qu’un dossier business repose généralement sur l’analyse des coûts, de nombreux autres éléments sont également importants pour initier une gestion des services.

Préprogramme ROI (retour sur investissement) Etablir un budget consiste à financer maintenant des investissements, pour engendrer des entrées croissantes de liquidités, ou de diminuer les sorties. Les décisions concernant l’établissement d’un budget peuvent être divisées en deux catégories : • Décisions sélectives (NPV) – puisque vous devez dépenser de l’argent pour en gagner, la valeur temps de l’argent (actualisation des flux de trésorerie) a un rôle à jouer ; les décisions de budgétisation des capitaux peuvent s’appuyer sur les analyses des flux de trésorerie. • Décisions préférentielles (IRR) – les décisions peuvent aussi se reposer sur des approches préférentielles. Dans ce chapitre, une distinction est faite entre deux approches : La valeur nette actuelle (Net Present Value – NPV) et le taux de rendement interne (Internal Rate of Return – IRR). La valeur nette actuelle est la différence entre les entrées et les sorties de liquidités et c’est cette différence qui va déterminer si un investissement a de la valeur. Avec le taux de retour interne, les rendements sur l’ensemble du cycle de vie d’un service sont comparés avec les entrées de liquidités (taux de retour). Les deux approches doivent permettre de décider si une initiative de gestion des services pourra surmonter un obstacle financier déterminé au préalable (c’est-à-dire un retour minimum). Pour les programmes de gestion des services, la valeur nette actuelle offre les avantages suivants par rapport à la méthode du taux de retour interne. • En général, la valeur nette actuelle est plus facile à utiliser. • Le taux de rendement interne accepte que le taux de rendement soit, en réalité, celui du programme. Cette affirmation est assez équivoque pour des environnements ayant une expérience minime des programmes de gestion des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

57

Quand la valeur actuelle nette et le taux de rendement interne ne s’accordent pas sur l’intérêt réel d’un projet, alors la valeur nette actuelle (NPV) représente le meilleur choix. Le NPV formulera l’hypothèse la plus réaliste pour le taux de rendement.

Post-programme ROI (retour sur investissement) Si une initiative de gestion des services est lancée sans une analyse du retour sur investissement préalable, il est recommandé d’effectuer l’analyse rétroactivement. Le calcul du retour sur investissement (ROI) de la gestion des services est illustré dans le modèle de base de la Fig. 3.18.

Déterminer les coûts du programme

Objectifs du Programme

Collection des données

Effets isolés du programme

Conversion des données en argent

Calculer le retour sur investissements (ROI)

Identifier des bénéfices qualitatifs

Communiquer les résultats

Figure 3.18  Approche post-programme ROI

L’approche post-programme ROI (retour sur investissement) comprend les étapes suivantes : • Objectifs du programme – les objectifs doivent être clairs car ils déterminent la profondeur et le périmètre de l’analyse du retour sur investissement. • Collecte des données – des exemples comprennent les métriques pour la qualité du service, les coûts de transition, les enquêtes de satisfaction client, etc. • Isolement des effets du programme – plusieurs techniques sont disponibles pour garantir l’efficacité du programme ; par exemple, l’analyse future, qui dénote ce qui aurait pu se passer si le programme n’avait pas commencé. • Conversion monétaire des données – pour calculer le retour sur investissement, les données doivent être représentées par des valeurs monétaires, pour faire en sorte que les valeurs puissent être comparées avec les coûts. • Détermination des coûts du programme – tous les coûts du programme ITIL sont calculés (y compris, par exemple, les coûts de planification, de conception et de mise en œuvre, les coûts technologiques et les coûts de formation). • Calcul du retour sur investissement – voir les techniques de la valeur nette actuelle et du taux de rendement interne, précédemment décrits.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

58

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Identification des bénéfices qualitatifs – les bénéfices qualitatifs commencent par la façon dont ils sont définis dans le dossier business ; les bénéfices qualitatifs sont vérifiés une deuxième fois pendant la phase d’amélioration continue des services.

Modèles et analyses de la livraison des services Les organisations qui analysent les méthodes existantes pour la fourniture des services peuvent se servir des différents modèles pour l’analyse : • Services gérés – La variante la plus traditionnelle de gestion d’un financement, par le domaine d’activité stratégique qui a besoin de services. C’est la variante la plus coûteuse car les coûts du service sont complètement couverts par le domaine d’activité stratégique. • Services partagés – Fourniture de services multiples à un ou plusieurs domaines d’activité stratégique, en utilisant une infrastructure et des ressources communes. Économies de coûts par l’utilisation accrue des ressources existantes. • Services basés sur l’utilité – Ce modèle optimise la combinaison de services fournisseur sur la même Infrastructure pour faire en sorte que plusieurs services puissent être fournis en utilisant les mêmes ressources. Ceci est possible en fournissant des services qui reposent sur l’utilité, en fonction de la quantité, de la fréquence et des périodes selon les besoin des clients. Ce modèle est le plus rentable et le plus subtil, car il requiert un niveau de connaissance et d’aptitude que la plupart des organisations n’ont pas. Ces économies de coûts sont possibles grâce à une compréhension plus approfondie de l’architecture technologique et des besoins du client, permettant de combiner services et architecture, de façon à utiliser au maximum les ressources existantes. • On-shore, off-shore ou near-shore ? – Déterminer quelles combinaisons de services onshore, near-shore ou off-shore sont correctes pour une organisation donnée à un moment donné. Si une organisation n’a pas conscience de ses principaux composants de coûts de service et de la dynamique des coûts variables, il lui sera alors difficile de prendre une décision d’externalisation, qui soit logique et factuelle. L’analyse des coûts de la fourniture des services (analyse des coûts de l’approvisionnement de services) est l’estimation statistique des différentes formes de fourniture et la définition du modèle le plus avantageux. • Analyse des coûts de fourniture des services (Service Provisioning Cost Analysis) – Approche stratégique de classification des différentes formes de fourniture (et souvent fournisseurs) de services, pour trouver le modèle le plus avantageux.

3.6 Mise en œuvre De la stratégie à la tactique et à la production Mise en œuvre basée sur le cycle de vie Les positionnements stratégiques sont convertis en plans, associés à des objectifs et à des buts définitifs, qui reposent sur le cycle de vie. Les plans sont un moyen d’atteindre ces positionnements. Les plans garantissent que chaque phase du cycle de vie des services dispose des aptitudes et des ressources nécessaires pour atteindre les positionnements stratégiques. Le cycle de vie fournit la cohérence et le contexte pour le développement des aptitudes et des ressources nécessaires.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

59

Les plans traduisent les intentions de la stratégie en actions, au moyen de la conception, de la transition et de l’exploitation des services ainsi que de l’amélioration continue des services (CSI). La stratégie des services fournit des entrées à chaque phase du cycle de vie. L’amélioration continue des services est le feedback par lequel la mise en œuvre de la stratégie peut être surveillée pendant tout le cycle de vie. (Voir Figure 3.19).

Amélioration continue

Transition de Services

Stratégie de Services Situations

Perspective Stratégie de Services

Exploitation de Services

on ati or e éli inu Am cont

Conception de Services

é co liora nt inu tion e

Plans

Am

Modèles

Figure 3.19  Stratégie mise en œuvre dans le cycle de vie des services

La stratégie des services définit le portefeuille des services qui sont offerts et les clients pour lesquels un support est donné, sur un marché spécifique. Les clients et les fournisseurs de services doivent faire face aux risques stratégiques, qui surviennent à cause d’incertitudes. Il est essentiel de traduire les risques en opportunités et en défis, en fonction du degré d’harmonisation entre les aptitudes de la gestion des services et les besoins du client. La stratégie des services implique l’amélioration continue, pour être certain que les éléments du cycle de vie sont bien associés à des opportunités et à des défis.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

60

Des hypothèses de nouvelles stratégies dérivent des modèles de mise en œuvre du cycle de vie des services. Ce développement du bas vers le haut de la stratégie des services, ainsi que l’approche traditionnelle du haut vers le bas, comprend une planification fermée et un système de gestion pour les stratégies de services. Ce processus de feedback et d’apprentissage est un facteur critique de succès pour que la gestion des services apporte les changements et les innovations nécessaires. (Voir Figure 3.20).

Mise en œuvre de la stratégie

Exigences deconception des services

Stratégie des Services • Portefeuille de Services • Catalogue de Services

Exigences de transition des services

Exigences d’exploitation des services

Mesure et évaluation

Conception des services

Transition des services

Continual Service Improvement

Exploitation des services Mesure et évaluation

Figure 3.20  Planification en boucle fermée et système de surveillance pour la stratégie

Stratégie et conception Les stratégies des services sont mises en œuvre via la fourniture et le support du portefeuille de contrats, sur un marché spécifique. Les contrats spécifient les termes et les conditions par lesquels la valeur est fournie au client, par le biais des services fournis. Puisque chaque service est lié à un ou plusieurs marchés, la conception du service est liée aux catégories d’actif du client et aux modèles de service. Ils comprennent les entrées globales pour la phase de conception des services. Modèles de service Les facteurs dérivés de l’utilité et de la garantie que veut le client, influencent la structure et la dynamique des modèles. Les modèles de service décrivent la manière dont les actifs de service interagissent avec les actifs clients et créent de la valeur pour un portefeuille spécifique de contrats. La structure et la dynamique ont des conséquences pour la phase d’exploitation des services qui sera évaluée pendant la phase de transition des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

61

Service models are developed by the market (see Figure 3.21)

Taille du marché

Portefeuille des services

Portefeuille des clients

Portefeuille des contrats

Modèles des services

Actifs de service

Modèles des services

Déterminer / influencer

Figure 3.21  Service models are developed by the market

Conception orientée-résultat Les attributs d’un service constituent les caractéristiques qui définissent la forme et la fonction du service, du point de vue du client. C’est un défi pour la conception des services de déterminer les attributs qui seront adoptés. Cf. les résultats business, par exemple, sur la base du modèle Kano. L’utilisation d’un modèle développé par Noriaki Kano aide à comprendre les préférences du client. Le modèle Kano regroupe les attributs d’un service informatique en secteurs tels que les facteurs de base, les facteurs de stimulation, les facteurs de performance, etc. Conception orientée-contraintes Dresser une liste de contraintes et visualiser les interactions exige une équipe de spécialistes du business et des technologies. Ceux-ci peuvent observer et enregistrer les interactions entre les clients, les fournisseurs, les partenaires et les conseillers. Ces cinq éléments du cycle de vie fournissent des entrées pour ces contraintes. Cette méthode offre un moyen pour la stratégie des services de communiquer les défis et les opportunités à la phase de conception des services. Des modèles de services sont développés par le marché. (Figure 3.21)

Stratégie et transition La stratégie des services dépend des aptitudes dynamiques des fournisseurs de services, qui permettent de répondre efficacement aux défis et aux opportunités des clients et des marchés. Les plans stratégiques coûtent toujours de l’argent. Toute décision, telle que l’introduction d’un nouveau service, la pénétration sur de nouveaux marchés et la fourniture de services à de nouveaux clients comporte toujours des coûts et des risques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

62

Les fondamentaux de la gestion des services informatiques selon ITIL V3

La transition des services représente l’une des principales composantes de la gestion des services, avec des processus tels que la gestion des changements, la gestion des configurations et le déploiement des services. La capacité d’apporter des changements rapides dans les portefeuilles des services et dans les contrats, constitue un facteur critique de succès sur certains marchés et pour certaines stratégies. La transition des services est donc un élément important de la gestion des services.

Stratégie et exploitation La dernière phase de la stratégie concerne la phase de l’exploitation du service. Par conséquent, le développement de stratégies doit toujours prendre en compte ce qui est réalisable au niveau de l’exploitation. D’un autre côté, l’exploitation doit comprendre le type de résultat nécessaire pour mener à bien une stratégie donnée, et elle doit fournir le support adéquat. Modèles de déploiement Il s’agit d’organiser les actifs de service en modèles les plus efficaces pour fournir de la valeur au client à chaque segment du catalogue des services. Les modèles de déploiement dans la phase d’exploitation des services définissent les stratégies opérationnelles pour les clients. Hébergement du portefeuille des contrats Le besoin de fournir des contrats de service influence les modèles de déploiement. Les contrats de service englobent le contexte dans lequel le portefeuille des services fournit des services ayant de la valeur pour le client. Chaque contrat représente les accords passés avec un client quant à l’utilité et la garantie des services. La prise de décision en interne demande une coordination étroite entre la stratégie des services et l’exploitation des services. La stratégie sur un marché donné influence le contenu du portefeuille client et du portefeuille des services. Les perspectives spécifiques, les positionnements, les plans et les modèles (les 4 P) déterminent l’offre de services, les accords contractuels et les conditions relatives, ainsi que les clients auxquels ils seront fournis. La combinaison des portefeuilles des services et du portefeuille client génère le portefeuille des contrats.

Stratégie et amélioration continue des services Perspective de qualité L’expérience montre que les métriques des accords sur les niveaux de service (SLA) sont nécessaires mais ne suffisent pas à mesurer la qualité des services qui sont fournis au client. La qualité des services, telle que la ressentent les clients, repose sur l’utilité et la garantie fournies. La qualité des services dépend de l’impact positif du service (utilité) et de la certitude de cet impact (garantie). Les nombreuses définitions de la qualité peuvent se résumer selon quatre grandes perspectives : • niveau d’excellence • rapport qualité-prix • conformité aux spécifications • satisfaction ou dépassement des attentes

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

63

La perspective dominante influence l’évaluation et la gestion des services, notamment dans le contexte de la gestion des niveaux de services. L’une des principales décisions est la définition de l’importance de la qualité des services. La qualité en elle-même sert de base pour les stratégies dans un marché donné. Par conséquent la définition de la qualité influence les décisions et les objectifs stratégiques. Celle-ci a un impact sur la conception et la mise en œuvre d’un service. Elle influence également les mesures de performances internes, les politiques et les motivations que les gestionnaires emploient. Facteurs de garantie Des différences et des similitudes coexistent dans les méthodes de production des actifs et des services ; comment la valeur qu’ils créent est transmise au client, comment la vérifier et comment obtenir cette certitude ? Certains facteurs sont visibles et mesurables (facteurs tangibles), alors que d’autres sont beaucoup plus difficiles à déceler (facteurs intangibles). Fiabilité : • Applications et infrastructures – pour obtenir la garantie d’une valeur pour le client, les services doivent être fiables. Ceci est une entrée essentielle de la stratégie des services pour la conception et l’exploitation des services. La fourniture des services à un haut niveau de fiabilité peut servir de base pour le positionnement de la stratégie. La fiabilité d’un service dépend de la fiabilité des actifs de service sous-jacents et de leur configuration. La fiabilité d’un actif dépend, à son tour, d’une série de facteurs, tels que la qualité de la conception, le développement, l’installation, etc. • Personnes et processus – la fiabilité en termes de disponibilité sert de facteur important pour tous les actifs et les infrastructures de service, aussi bien pour les personnes que pour les processus. Si le personnel du support n’est pas disponible, alors le service peut faillir. Par conséquent, il est également important de gérer la disponibilité de toutes les composantes. Il est difficile de définir la fiabilité et la disponibilité des personnes et des processus. Un indicateur, tel que l’intervalle moyen entre les défaillances (Mean Time Between Failure – MTBF), est beaucoup plus difficile à calculer que les composants du matériel informatique ou des réseaux. Le MTBF enregistre la fiabilité de l’actif d’un service : plus le MTBF est élevé, plus la fiabilité est grande. Facilité de maintenance : Les services doivent être rapidement restaurés quand ils ne sont plus disponibles aux utilisateurs. Le temps moyen de restauration du service (Mean Time to Restore Service – MTRS) est le temps de reprise dans lequel une fonction (service, système ou composant) redevient opérationnelle après une panne. Le MTRS dépend de plusieurs facteurs, tels que la configuration des actifs du service, le MTRS des composants individuels, la compétence du personnel de support, les ressources disponibles, les règles de la politique, les procédures et la redondance. Les analyses de la façon dont le MTRS répond à chaque facteur sont utiles pour améliorer la performance et la conception des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

64

DETECTED Enregistrement Diagnostique

Réparation

Résolution

Restauration

INCIDENT

TIME TO DETECT

INCIDENT

Délai d’enregistrement

Temps de Diagnostique

Délai de réparation

Délai de restauration

Temps de restauration

Durée écoulée, Temps entre les défaillances

Temps d’indisponibilité, Temps de restauration Facteur de facilité de maintenance

Facteur de fiabilité

Temps entre les incidents système

Figure 3.22  Opportunités d’amélioration dans le cycle de vie d’un incident

Le MTRS peut diminuer si on réduit chacun des composantes du cycle de vie (voir Figure 3.22). Consulter le chapitre 10, Gestion de la disponibilité, pour plus de détails sur son utilisation. Redondance La redondance est une façon d’augmenter la fiabilité et la durabilité des systèmes. ITIL définit quatre types de redondance pouvant être utilisées ensemble ou séparément. La redondance active et passive (pour les services essentiels) et la redondance diverse et homogène (pour les actifs de services semblables et spécifiques) Un support peut être fourni par différentes méthodes d’infrastructure qui augmentent l’accessibilité des services. Consulter le chapitre 10 pour plus de détails. Interactions entre les facteurs d’accessibilité Les différents facteurs qui contribuent à rendre les services très accessibles ont un effet réciproque. (Voir Figure 3.23). Fiabilité

Disponibilité

Diversité

Redondance

Facilité d’accès

Capacité

Facilité de maintenance

Densité

Figure 3.23  interaction entre les facteurs qui influencent l’accessibilité des services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

65

Bénéfices, goulots d’étranglement et risques Complexité Les organisations informatiques sont des systèmes complexes. Cela explique pourquoi certaines organisations ne sont pas favorables au changement. Les organisations ne sont pas toujours en mesure d’anticiper les conséquences à long terme des décisions et des actions. Cela débouche souvent sur une aversion aux changements de politique. Sans les processus d’apprentissage continu, les décisions d’aujourd’hui finissent souvent par devenir les problèmes de demain. Une réaction naturelle consiste à diviser les services en processus qui sont gérés par des groupes ayant des connaissances, des expériences et des ressources spécialisées. Tout se passe bien tant que la connexion mutuelle ne se perd pas. Les processus de gestion des services sont un moyen, et non une fin en soi. Coordination et contrôle Les personnes qui prennent les décisions ont souvent un temps, une attention et une capacité limités. Ils délèguent donc les rôles et les responsabilités à des équipes et à des individus qui sont spécialisés dans les systèmes, les processus, les performances et les résultats spécifiques. La gestion des services est une série interconnectée de compétences spécialisées qui sont définies dans des processus et des phases du cycle de vie. Une hausse du niveau de spécialisation implique une augmentation de la coordination. Une coordination améliorée passe par la coopération et la surveillance entre les équipes et les individus. Les problèmes liés à la coopération exigent une façon de connecter ces groupes les uns avec les autres en dépit d’intérêts et d’objectifs différents, voire conflictuels. Cela s’applique également à la coopération entre le fournisseur de services et le client. Solutions possibles : • Trouver des accords favorables à tous. • Maintenir les vues partagées et les buts convergents de la gestion des services, qui sont définis dans les stratégies des services, les objectifs, la politique, les récompenses et les motivations. • Utiliser des processus collectifs, qui intègrent les groupes et les fonctions ; utiliser des applications qui intègrent les processus et des infrastructures partagées qui intègrent les applications. Les perspectives de contrôle reposent sur les objectifs d’un ou plusieurs processus de gestion des services ou des phases du cycle de vie. Elles aident les gestionnaires à se concentrer sur ce qui important et pertinent pour les processus qu’ils contrôlent, et elles garantissent que des informations de haute qualité sont disponibles pour assurer l’efficacité et l’efficience.

Préserver la valeur Performances faibles Les clients matures ne s’intéressent pas uniquement à l’utilité et à la garantie qu’ils reçoivent pour le prix qu’ils paient. Ils veulent connaître le coût total d’utilisation (Total Cost of Utilization – TCU). Le concept de TCU repose sur le principe des coûts de transaction. Non seulement les

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

66

Les fondamentaux de la gestion des services informatiques selon ITIL V3

clients voient les coûts de consommation réelle, mais ils ont aussi conscience de tous les autres coûts indirects du processus. La création de valeur pour les clients est un objectif clairement visible pour les fournisseurs. La création de valeur pour leurs parties prenantes est également très importante. Avec les fournisseurs de type I, ces deux objectifs sont étroitement connectés. Avec les fournisseurs de type III, ils peuvent facilement diverger, voire entrer en conflit. L’exclusion des coûts cachés est un défi, un facteur critique de succès et un risque. Efficacité et efficience opérationnelles Les services doivent avoir une utilisation bénéfique selon la perspective du client et du fournisseur de services. Cet intérêt commun est essentiel pour que les services soient faisables économiquement. Le fournisseur comme le client doit donc tirer une valeur économique du service. La valeur est intangible et, en ce sens, difficile à prédire. Il faut donc créer de l’efficience sur la base d’un résultat désiré. L’efficacité représente la qualité de la création d’un effet désiré et spécifique. Dans le contexte des services, les deux effets représentent l’utilité et la garantie. Une augmentation de l’efficience d’un processus aboutit à la disponibilité d’une plus grande capacité pour les autres demandes du marché, par laquelle une demande supplémentaire peut être absorbée avec les mêmes ressources. Des améliorations dans la conception et l’exploitation des services peuvent se traduire par ce type de profit, caractéristique de l’efficience. Ainsi coexistent un feedback et une interaction forte entre l’efficience et l’efficacité souhaitée. Une efficience croissante peut déboucher sur une efficacité croissante, qui peut, à son tour, déboucher sur une augmentation de l’efficience jusqu’à ce qu’un certain seuil d’optimisation soit atteint. Réduire les coûts cachés Les coûts cachés concernent les coûts de transaction. Ceux-ci comprennent, par exemple, les ressources du fournisseur pour définir les besoins du client, les préférences des utilisateurs, les critères de qualité et les prix. La standardisation, les services partagés et la réutilisation, associés à la segmentation et aux niveaux de services différentiés, contribuent à recouvrer certains coûts de transaction. Confirmation des coûts cachés Les services offrent une alternative attrayante pour l’acquisition d’actifs. Ils apportent au client l’utilité d’un actif tandis qu’ils peuvent externaliser les opérations de maintenance et de réparation (Maintenance and Reparation Operations – MRO). Les services de MRO appartiennent à une catégorie différente de services. La standardisation des processus de gestion des services pour une industrie spécifique aboutit à un plus haut niveau d’efficience et de flexibilité avec la consolidation, la désagrégation et la configuration flexible de processus business, de composants d’infrastructure et de ressources humaines.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

67

Utilisation efficace des actifs incorporels Les actifs incorporels ne peuvent pas se toucher du doigt. Ils permettent de bénéfices futurs. Les actifs incorporels et englobent l’innovation, les systèmes uniques, les processus, les conceptions et les compétences. La combinaison des actifs corporels et financiers assure la création d’une valeur économique pour le propriétaire. Les actifs corporels comprennent les actifs rivaux (ou actifs rares) : actifs physiques, ressources humaines et actifs financiers. L’utilisation spécifique de ce type d’actif garantit qu’ils ne peuvent pas être utilisés ailleurs. Par exemple : les personnes qui aident le client, l’espace d’équipement, le capital financier investi. D’un autre côté, les actifs incorporels ne sont pas litigieux car ils sont mis en place simultanément pour différentes demandes. L’utilisation des actifs incorporels, tels que les technologies basées sur Internet et l’automatisation,sur des logiciels basés sur peuvent augmenter l’extension des systèmes de services. L’utilisation efficace de processus et de systèmes de gestion des connaissances permet, dans ce contexte, de réduire virtuellement les coûts. Selon le point de vue de la gestion des services, une structure des modèles de services, des conceptions et des infrastructures peuvent être analysés pour déterminer le rapport d’éléments incorporels et d’éléments corporels. Dès que possible, des éléments corporels devraient être remplacés par des éléments incorporels pour faire évoluer la conception des services.

Mesurer l’efficacité Les mesures concentrent l’organisation sur ses objectifs stratégiques, elles permettent de suivre la progression et fournissent du feedback à l’organisation. La plupart des organisations informatiques savent bien surveiller les données, mais ne savent pas bien fournir des indications quant à l’efficacité des services qu’ils offrent. Les questions “quoi” et “où” peuvent généralement trouver des réponses précises, mais les questions “comment” et “pourquoi” sont perçues comme étant moins importantes. Il est essentiel d’effectuer les bonnes analyses et de les modifier dès que la stratégie change. Dans ce cas, les organisations peuvent appliquer la méthode de gestion des connaissances mentionnée précédemment : données-informations-connaissances-sagesse (DIKW).

Risques La mise en œuvre de la stratégie comporte des changements dans le portefeuille des services. Ce qui conduit alors à la gestion des risques associés. Les décisions concernant les risques doivent être équilibrées pour que les bénéfices potentiels fournissent plus de valeur à l’organisation que les coûts encourus pour gérer risques. Par exemple : l’innovation peut être risquée, mais elle peut aussi déboucher sur des bénéfices plus grands en termes d’amélioration des services. Lors des analyses, il peut être utile de visualiser les types de risque positif qui sont liés aux opportunités, aux investissements et aux innovations, par rapport aux risques négatifs tels l’absence d’exploitation des opportunités, l’échec des investissements appropriés et l’ignorance des opportunités d’innovation.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

68

Définition du risque ITIL définit le risque comme suit : Un risque produit un résultat incertain, autrement dit, une opportunité positive ou une menace négative. L’objectif de la gestion des risques est de garantir que l’organisation utilise, de façon rentable, un référentiel de risques, qui consiste en une série d’étapes bien définies. (Voir Figure 3.24).

Définir une structure

Intégration et revue

Identification des risques

Assurance de gains d’efficacité

Identification des éventuels propriétaires des risques

Mise en place de réponses

Evaluation des risques

Définition de niveaux de risque acceptables (tolérance/appétit)

Gestion des risques

Identification de contre-mesures appropriées Analyse des risques

Figure 3.24  Référentiel générique pour la gestion des risques

L’objectif est de soutenir la meilleure prise de décision grâce à une bonne compréhension des risques et de leurs impacts probables. Il y a deux phases distinctes : l’analyse et la gestion des risques : • Analyse des risques – l’analyse des risques implique la collecte d’informations concernant l’exposition aux risques, de manière à ce que l’organisation prenne les bonnes décisions et contrôle les risques de façon appropriée. • Gestion des risques – la gestion des risques garantit l’existence de processus centrés sur la surveillance des risques. Elle assure également que les informations concernant les risques sont fiables, actuelles et disponibles, que le juste équilibre de contrôle est appliqué au traitement des risques et que la prise de décision est supportée par un référentiel d’analyse et d’évaluation des risques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la stratégie des services

69

Transfert des risques La gestion des risques joue un rôle essentiel dans la gestion des services (Figure 3.25). Les services réduisent le risque pour le business du client mais ils comportent également des risques pour les fournisseurs. Les clients dédommagent les fournisseurs de services pour ces risques de plusieurs façons : en premier liau en payant les services (ce qui n’est pas possible avec les fournisseurs de Type I). La Gestion des Services comme filtre des risques Niveau de risque acceptable pour le client Risques côté fournisseur

Activités métier

Actifs client

Risques côté demandeur

Actifs de service

Opérations de service

Risques acceptables pour le fournisseur

Figure 3.25  La gestion des risques joue un rôle essentiel dans la gestion des services.

Les fournisseurs doivent s’assurer d’un dédommagement suffisant tout en restant raisonnable. Les coûts sont factuels, mais les prix sont politiques. Cela veut dire que certains investissements, par exemple, peuvent générer un profit sur une certaine période de temps. De plus, avec des services et des clients nouveaux, les risques peuvent payer pour eux-mêmes sous la forme de nouveaux clients (extension) ou de demande d’autres services (périmètre). Les augmentations ou les évolutions du portefeuille client doivent être précédées d’une évaluation des risques que le fournisseur de services est disposé à assumer pour le compte du client. L’analyse et la gestion des risques doivent être appliquées aux services à l’étude et au catalogue des services pour identifier, contenir et réduire les risques dans les phases du cycle de vie.

Risques pour les fournisseurs de services Les risques pour les fournisseurs de services se produisent quand une incertitude de la part du business client est associée avec des incertitudes dans leurs opérations, et ont un effet contraire via le cycle de vie. Il est utile de communiquer les risques en termes financiers pouvant servir comme indicateurs plutôt que comme mesures. ITIL reconnaît les types de risques suivants : • Risques de contrat (un contrat comprend des accords liant les parties – business et fournisseurs de services – de façon légale et formelle) – Les risques qui empêcheront le fournisseur de services de satisfaire ses accords contractuels sont des risques stratégiques car, non seulement ils menacent la production actuelle, mais ils compromettent également la confiance pour les interactions futures. Il se peut que l’impact des risques des contrats et les faiblesses et les dangers sous-jacents ne se limitent pas à une seule fonction du processus. Le client ne fait

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

70

Les fondamentaux de la gestion des services informatiques selon ITIL V3

aucune distinction parmi les causes des risques. La coordination pendant tout le cycle de vie est nécessaire pour gérer les risques de façon efficace. • Risques de conception – les clients s’attendent à ce que des services aient un impact sur la performance de leurs actifs, qui, dans leur perspective, représente une utilité. Il y a toujours un risque que les services donnent des résultats indésirables. Ceci est un risque pour la performance. Une mauvaise performance est normalement le résultat d’une mauvaise conception. • Risques opérationnels – chaque organisation traite de risques opérationnels. Dans une perspective de gestion des services, il y a deux types de risque à distinguer : les risques pour les unités business et les risques pour les unités de services. • Risques du marché – une gestion efficace des services aide à réduire les risques concurrentiels en augmentant l’échelle et le périmètre de la demande pour un catalogue des services. Une autre approche consiste à modifier les contenus du catalogue des services pour faire en sorte que les clients puissent trouver la profondeur et l’ampleur qu’ils recherchent. Les risques du marché peuvent être réduits grâce à : – La différentiation – du point de vue du client, les actifs qui sont rares et complémentaires sont intéressants. Les fournisseurs de services peuvent donc se concentrer sur la fourniture d’actifs importants qui n’ont pas été fournis par d’autres. Les marchés non servis et peu servis offrent des opportunités attrayantes. – La consolidation – la consolidation de la demande réduit les risques financiers pour les fournisseurs de services ainsi que les risques opérationnels pour les clients.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 4

Phase de cycle de vie : la conception des services 4.1 Introduction Objectif : La conception des services suit la stratégie des services dans le cycle de vie. Elle couvre la conception et le développement des services, ainsi que les processus associés. Elle se réfère non seulement aux services complètement nouveaux, mais aussi à la fourniture de services modifiés. Selon ITIL, l’objectif le plus important de la conception des services est : La conception des services nouveaux ou modifiés pour leur introduction dans un environnement de production. Les objectifs de la conception des services comprennent, mais ne se limitent pas à : • Contribuer aux objectifs business • Contribuer à économiser du temps et de l’argent, chaque fois que cela est possible • Minimiser ou prévenir les risques • Contribuer à répondre aux besoins présents et futurs du marché • Évaluer et améliorer l’efficacité et l’efficience des services informatiques • Supporter le développement de politiques et de standards concernant les services informatiques • Contribuer à la qualité des services informatiques Pour garantir que les services développés satisfont les attentes du client, les actions suivantes sont entreprises : • Le nouveau service est ajouté dès le début de la phase de conception du portefeuille des services. Et il est mis à jour pendant tout le processus. • Les exigences de niveau de service (Service Level Requirement – SLR) doivent être claires avant la fourniture des services. • L’équipe de gestion de la capacité modélise ces exigences au sein de l’infrastructure existante.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

72

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Si une nouvelle infrastructure est nécessaire ou si davantage de support est requis, alors la gestion financière doit être impliquée. • Avant le début de la phase de mise en œuvre, une analyse d’impact sur le business (Business Impact Analysis – BIA) et une évaluation des risques doivent être effectuées. Cela fournira des informations précieuses pour la gestion de la continuité des services informatiques, la gestion de la disponibilité et la gestion de la capacité. • Le centre des services doit être informé de la fourniture de nouveaux services avant que ceux-ci ne soient effectivement fournis. • La transition des services établit un plan pour la mise en œuvre du service. • La gestion des fournisseurs doit être informée en cas d’achats à faire. Pour satisfaire les demandes et les besoins changeants du business, une conception de services informatiques efficaces et efficients repose sur un processus d’équilibre entre les fonctionnalités, les ressources (humaines, techniques et financières) et le temps disponibles. Il s’agit d’un processus continu dans toutes les phases du cycle de vie des services informatiques. La phase de conception des services dans le cycle de vie commence par la formulation d’exigences nouvelles ou modifiées de la part du client. En dernier lieu, à la fin du processus de conception, une solution de service doit être conçue, pour satisfaire les besoins, avant de transférer le service aux processus de transition. Une bonne préparation et une combinaison efficace et efficiente du personnel, des processus, des produits (services, technologie et outils) et des partenaires – les quatre P d’ITIL – sont indispensables pour réaliser avec succès les plans et les projets de conception. La dépendance mutuelle des départements implique que les services informatiques ne peuvent pas être conçus, transmis ou mis en œuvre de façon isolée. Chaque personne au sein de l’organisation doit être informée des composants sous-jacents et des relations mutuelles de la fourniture des services informatiques, ainsi que tout département impliqué. Ce processus requiert une approche holistique et une communication claire ; il exige que chaque personne accède aux plans informatiques, qui doivent être corrects, les plus récents et sans équivoque ; les informations appropriées doivent également être fournies.

Aspects de la conception Pour permettre à l’organisation d’atteindre le plus haut niveau de qualité possible, tout en maintenant une focalisation constante sur les améliorations, une approche structurée orientéerésultats est nécessaire, pour chacun des cinq différents aspects de la conception suivants : dans ce cas, orientée-résultats signifie visant à satisfaire les souhaits des clients/utilisateurs. Les cinq aspects sont les suivants : 1. solution de service (y compris les exigences fonctionnelles, les ressources et les capacités) 2. portefeuille des services (systèmes de support et outils) 3. architecture (technologique et gestion) 4. processus 5. systèmes de mesure et métriques

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

73

La conception des solutions de service Une approche de conception structurée est nécessaire pour produire un nouveau service, avec les bons coûts, fonctionnalité, qualité, et dans le bon délai. Les processus doivent être itératifs et incrémentaux pour satisfaire les exigences et les souhaits changeants des clients. Les thèmes suivants devraient être pris en compte : • Analyse des exigences business. • Révision des services et des infrastructures informatiques existantes et développement des services alternatifs. • Conception des services sur la base de nouvelles exigencies. • Les contenus des critères d’acceptation d’un service (Service Acceptance Criteria – SAC) doivent être inclus dans la conception initiale. • Évaluation des coûts des alternatives. • Frais et coûts convenus. • Évaluation et confirmation des bénéfices pour le business. • Décider des solutions, des résultats et des objectifs souhaités (SLR). • Surveiller les services à la lumière des stratégiques générales. • Garantir que la gouvernance informatique, la gouvernance d’entreprise et les contrôles de sécurité sont satisfaits. • Garantir que le service fonctionne efficacement et qu’il répond aux exigencies. • Des accords de support sont nécessaires pour fournir le service. • Assembler le package de conception de service ; cela comprend tous les aspects du service et les exigences pour toutes les phases successives du cycle de vie.

La conception du portefeuille des services Le portefeuille des services est le système de gestion le plus critique pour soutenir tous les processus. Il décrit la fourniture des services en termes de valeur pour le client et doit comprendre toutes les informations et les statuts du service. Dans tous les cas, le portefeuille donne une réponse définitive quant à la phase dans laquelle se trouve le service. Vous trouverez plus loin une vue générale du portefeuille des services, qui met l’accent sur les différentes phases. Il est important de remarquer que le client ne dispose que d’un aperçu du catalogue des services ; voir Figure 4.1. Les autres sections du portefeuille ne sont pas accessibles au client. Bien que le portefeuille des services soit conçu pendant la phase de conception des services (voir le processus de gestion du catalogue des services), le portefeuille des services est géré par la stratégie des services. De plus amples informations sur le portefeuille sont disponibles au chapitre traitant de la stratégie des services.

La conception de l’architecture Les activités de conception de l’architecture comprennent l’élaboration des projets d’ensemble pour le développement et le déploiement d’une infrastructure informatique, les applications et les données (selon les besoins de l’entreprise). Notons que pendant cet aspect de la conception, la fourniture des services de qualité et de valeur élevées n’est possible que par du personnel, des processus et des partenaires impliqués dans cet aspect de la production. ITIL décrit cette conception de l’architecture comme suit :

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

74

Base de données de Gestion de la Connaissances des Services

Portefeuille de Services Cycle de vie des services Statut des services: Exigences Défini Analysé Approuvé Privilégié Conçu Développé Construit Testé Mis en Production Opérationnel Retiré, supprimé

Pipeline de services

Catalogue de services Services retirés, supprimés

Section visible pour équipe client/ support du portefeuille de services (le catalogue de services, avec une sélection des champs visible)

Figure 4.1  Contenu du portefeuille des services

La conception de l’architecture est le développement et la maintenance des politiques informatiques, des stratégies, des architectures, des conceptions, des documents, des plans et des processus pour le déploiement, la mise en œuvre et l’amélioration des services et des solutions informatiques appropriées au sein d’une organisation. La conception d’une architecture n’est pas simple et divers besoins – parfois conflictuels – doivent être pris en compte. Dans tous les cas, il faut s’assurer : • qu’elle répond aux besoins de l’entreprise, de ses produits et de ses services • de trouver un bon équilibre entre innovation, risques et coûts • qu’elle est conforme aux référentiels, stratégies, politiques, etc. • qu’il y a une coordination entre les concepteurs, les planificateurs, les stratèges, etc. Chaque entreprise est un système complexe de fonctions, de processus, de structures et de sources d’informations. L’architecture de l’entreprise doit offrir des indications sur la façon dont ces thèmes sont reliés les uns aux autres pour atteindre les objectifs de l’entreprise. L’architecture d’entreprise est, par nature, aussi grande et complexe. Il existe plusieurs référentiels pour développer des architectures d’entreprise. L’architecture d’entreprise doit comprendre les éléments suivants : • Architecture des services – traduit les applications, l’infrastructure, l’organisation et les activités de support en services pour le business. • Architecture des applications – garantir le développement de plans pour le développement des applications individuelles. • Architecture des informations – décrit comment les sources d’information sont gérées et distribuées.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

75

• Architecture des infrastructures informatiques – décrit la structure, la fonction et la distribution géographique du matériel informatique et des logiciels. • Architecture de l’environnement – décrit tous les aspects, les types et les niveaux des contrôles de l’environnement. En plus d’un composant technique (applications, logiciel de système, informations et données, systèmes d’infrastructure et d’environnement), une architecture de gestion devra également être développée. Pour ce faire, les cinq éléments suivants doivent être pris en considération : le secteur (besoins, exigences), le personnel, les processus, les outils et la technologie (produits informatiques qui sont utilisés pour fournir les services). Les souhaits et les besoins du client doivent constituer les éléments principaux, la technologie passe en second.

La conception des processus La base d’ITIL s’appuie sur un travail avec des processus définis. En définissant les activités, les entrées et les sorties, il est possible de travailler de façon plus efficace et plus efficiente, et surtout d’une façon plus orientée client. En évaluant ces processus, l’organisation améliore davantage son efficacité et son efficience. La prochaine étape est l’établissement de normes et de standards. De cette façon, l’organisation associe les exigences de qualité avec les sorties. Cette approche correspond au cycle de gestion Planifier-Faire-Vérifier-Agir de Deming. Chaque processus doit avoir un propriétaire qui est responsable du processus et de ses améliorations. La conception des services offre au propriétaire du processus un support dans le processus de conception, en normalisant les termes et les modèles et en garantissant que les processus sont cohérents et intégrés. ITIL décrit un processus comme suit : Un processus est une série structurée d’activités conçues pour atteindre un but spécifique. Un processus produit des sorties définies à partir d’une ou plusieurs entrées. Un processus comprend tous les rôles, les responsabilités, les ressources et les contrôles de gestion nécessaires pour fournir des sorties fiables ; il sert également à définir des politiques, des standards, des guides de bonnes pratiques, des activités, des procédures ; si nécessaire, un processus définit également des instructions de travail. Un processus consiste en la mise en œuvre d’activités et la surveillance de la mise en œuvre. Le contrôle des processus est défini comme : Le contrôle des processus consiste en la planification et la régulation d’un processus, dans le but d’exécuter ce processus de façon efficace, efficiente et cohérente.

La conception des systèmes de mesure et des métriques Pour guider et gérer le processus de développement de façon efficace, des évaluations périodiques doivent être effectuées. Le système d’évaluation choisi doit être synchronisé avec la capacité et la maturité des processus qui font l’objet de l’évaluation. Le choix est important car le système aura un impact sur le comportement lors de la fourniture des services. Des processus non matures ne permettent pas des évaluations précises. Quatre notions servent de base à l’évaluation d’un processus, à savoir le progrès, l’accomplissement, l’efficacité et l’efficience. Au fur et à mesure

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

76

Les fondamentaux de la gestion des services informatiques selon ITIL V3

que les processus se développent, les unités de mesure doivent également se développer. Ainsi, en ce qui concerne les processus matures, l’accent doit être mis sur l’évaluation de l’efficacité et de l’efficience. Des informations supplémentaires sont disponibles au chapitre 13, consacré à l’amélioration continue des services.

Valeur de la conception des services Une bonne conception des services offre les bénéfices suivants : • Coût total de possession (Total Cost of Ownership – TCO) réduit • Qualité de la fourniture des services améliorée • Cohérence du service améliorée • Mise en œuvre plus simple des services nouveaux ou modifiés • Synchronisation améliorée des services avec les besoins business • Efficacité des performances améliorée • Administration informatique améliorée • Gestion des services et processus informatiques plus efficaces • Prise de décision plus simple

Contraintes et opportunités de la conception Bien que les concepteurs de service soient libres, il faut comprendre qu’ils dépendent des ressources internes (y compris les ressources financières disponibles) et des circonstances externes (par exemple, ISO, SOX et COBIT). De plus, le processus de conception offre l’occasion d’améliorer l’efficacité et l’efficience des installations informatiques, par l’utilisation d’une approche d’architecture orientée-service, si on considère la réduction des temps de fourniture des solutions au business qui en résulte. Il est important que les services soient mis à jour dans le catalogue des services (partie du portefeuille des services et le système de gestion des configurations (Configuration Management System – CMS). En général, cela rendra l’organisation en mesure de lier les installations informatiques aux objectifs (gestion des services business). Ce qui lui permettra de prédire l’impact de la technologie sur le business et inversement. La gestion des services business (Business Service Management – BSM) permet à l’organisation de : • Synchroniser les installations informatiques avec les objectifs business ; • Allouer des priorités aux activités informatiques sur la base de leur impact sur le business ; • Augmenter la productivité et la profitabilité ; • Soutenir la gouvernance d’entreprise ; • Améliorer les avantages concurrentiels ; • Augmenter la qualité de la fourniture des services et la satisfaction client.

4.2 Concepts de base Modèles de conception des services Le modèle à utiliser pour développer les services informatiques dépend largement du modèle choisi pour la fourniture des services informatiques. Avant d’adopter un modèle de conception, il

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

77

convient d’avoir une vue d’ensemble des capacités et des équipements informatiques disponibles. Cette vue d’ensemble devrait se concentrer sur les éléments suivants : • déclencheurs et demandes business • le scope et les aptitudes du fournisseur des services actuel • les exigences et les buts du nouveau service • le périmètre et les aptitudes des fournisseurs externes actuels • la maturité des organisations et de leur processus • la culture des organisations • l’infrastructure informatique, les applications, les données, les services et autres composants • le niveau des gouvernances informatique et d’entreprise • le budget et les ressources disponibles • les niveaux du personnel et les compétences disponibles Des indications sur les points précédents aideront à définir les opportunités pour l’organisation et si elle est en mesure de passer à l’étape suivante de la fourniture des services nouveaux ou modifiés. La façon d’aborder l’étape suivante devrait reposer sur les déclencheurs business et sur les aptitudes de l’organisation informatique (et de ses partenaires).

Options de fourniture des services informatiques L’écart (entre la situation actuelle et la situation souhaitée) ne doit pas nécessairement être comblé par l’organisation elle-même. Il existe plusieurs stratégies à prendre en compte pour l’externalisation de certains ou de tous les services ; chacune présentant des avantages et des inconvénients. Les stratégies les plus répandues sont résumées dans le Tableau 4.1. Le choix de l’une de ces stratégies de fourniture des services dépend de la situation spécifique dans laquelle se trouve l’organisation. Divers aspects jouent un rôle dans cette décision. Les capacités internes disponibles et les besoins de l’organisation, le personnel (culture) ont un impact significatif sur la stratégie de fourniture. Quelle que soit la stratégie choisie, il faudra toujours évaluer et revoir les performances pour, en fin de compte, pouvoir toujours satisfaire les demandes changeantes du marché.

Options de conception et de développement pour les services informatiques Pour prendre la bonne décision sur la conception et à la fourniture des services informatiques, il est essentiel de comprendre les étapes du cycle de vie actuel, les méthodes et les approches pour le développement du service. Un aperçu des aspects suivants des approches du cycle de vie pour le développement des services est essentiel : • la structure (jalons) • les activités (workflow, tâches) • les modèles primaires associés aux méthodes choisies aboutissant à des perspectives différentes (perspectives des processus, des données, des événements et des utilisateurs)

Développement rapide d’application Il faut comprendre les différences entre le développement de systèmes structurés et orientés-objets et les principes de base du développement rapide d’application (Rapid Application Development – RAD) pour reconnaître l’impact du choix d’une solution logicielle sur la structure de l’approche du cycle de vie.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

78

Stratégie de fourniture Internalisation, Approvisionnement interne (‘insourcing’)

Externalisation (‘outsourcing’)

co-sourcing

multi-sourcing

Externalisation de processus métier (Business process outsourcing, BPO) Fournisseur des services applicatifs (Application service provision, ASP) Externalisation de processus de connaissance (Knowledge process outsourcing, KPO)

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Caractéristiques Les capacités internes sont utilisées pour la conception, le développement, la maintenance, l’exécution, et/ou l’offre de support du service. L’engagement d’une organisation externe pour la conception, le développement, la maintenance, l’exécution, et/ou l’offre de support du service. Une combinaison d’inet d’outsourcing, avec plusieurs fournisseurs qui travaillent ensemble sur les étapes de cycle de vie. Plusieurs organisations signent des accords formels pour créer un partenariat stratégique (pour créer de nouvelles opportunités sur le marché). Un fournisseur externe reprend le processus de métier, ou partie, aux frais réduits, comme le centre d’appels. Fourniture des services aux clients à l’aide des réseaux et de l’infrastructure informatique Étape suivante l’externalisation de type BPO. Plutôt qu’offrir de la connaissance comme un composant d’un processus, toute la connaissance de la discipline d’un métier sera gérée.

Avantages - contrôle direct - liberté de choix - connaissance des processus internes

Inconvénients - frais et délai de fourniture de services - dépendance sur ressources et compétences internes

- focus sur - gestion moins directe compétences cœur - m  anque de de métier connaissance des - réduction des coûts compétences du à longue terme fournisseur

- délai de fourniture des services - gestion améliorée

- complexité des projets - propriété intellectuelle et protection des droits de reproduction

- extension des opportunités sur le marché - réponse compétitives à ces opportunités - fonctionnalité à guichet unique - accès aux compétences spécialisées - accès aux solutions complexes et coûteuses - support et mises à jour inclus - connaissance et expertise - réduction des coûts

- complexité des projets - choc des cultures

- perte de connaissance - perte du lien avec le Métier

- accès limité aux actifs, et non aux connaissances - choc des cultures - perte de connaissance interne - perte du lien avec le Métier

Tableau 4.1  Les strategies les plus répandues

Les approches traditionnelles de développement reposent sur le principe que les besoins du client sont déterminés au début du cycle de vie et que les coûts de développement sont contrôlés en gérant les changements. Les approches RAD commencent avec la notion que le changement est inévitable et que décourager les changements dénote tout simplement d’une passivité face au marché. L’approche RAD est une approche de développement incrémentale et itérative. L’approche incrémentale implique qu’un service est conçu morceau par morceau. Les parties sont développées séparément et sont livrées une à une. Chaque pièce est supportée par l’une des fonctions business et ensemble elles supportent le tout. Le gros avantage de cette approche est son

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

79

délai de fourniture plus court. Cependant, le développement de chaque partie exige que toutes les phases du cycle de vie soient continues. L’approche itérative implique que le cycle de vie soit répété plusieurs fois pendant la phase de conception. Des prototypes de l’ensemble du processus sont utilisés pour comprendre mieux les besoins spécifiques du client, après quoi la conception est adaptée. Il est possible de combiner les deux approches. Une organisation commence par spécifier les besoins du service en entier, puis fait une conception incrémentale et développe l’application. Les approches RAD, telles que le processus unifié et la méthode de développement de système dynamique -(Dynamics System Développent Method – DSDM), répondent à la demande des clients de maintenir les coûts bas pendant le projet de développement. Ainsi la méthode DSDM implique l’utilisateur dans le processus de développement d’un système logiciel, satisfaisant les attentes (demandes) qui peuvent être modifiées, tout en respectant les délais de fourniture et le budget. Les approches RAD ne représentent pas seulement des gains importants de temps, mais encore elles réduisent les risques liés au développement et à la mise en œuvre. Bien que plus difficiles à gérer que les approches traditionnelles et exigeant davantage de compétences et d’expérience de la part du personnel, ces approches contribuent de façon positive à la mise en œuvre et à l’acceptation générale de l’organisation. Elles aident également les concepteurs à anticiper les demandes changeantes de l’organisation plus rapidement, leur permettant ainsi de modifier la conception. À la différence des approches traditionnelles, les équipes RAD sont plus petites et sont composées de généralistes. De plus, il est plus facile d’insérer des décisions critiques pendant le processus.

Solutions commerciales prêtes à l’emploi De nombreuses organisations choisissent des solutions logicielles standard pour satisfaire les besoins et les demandes. Un cadre est nécessaire pour sélectionner, modifier et mettre en œuvre des packages de ce genre et surtout, il faut connaître, dès le début, les exigences de gestion qui ont été formulées aux niveaux opérationnels. Il est également important, du point de vue de la fourniture des services, de bien comprendre les avantages et les inconvénients de tels packages. En outre, pour définir les exigences fonctionnelles, il est aussi essentiel de définir les exigences quant au produit, au fournisseur et à l’intégration du package des services.

4.3 Processus et autres activités Processus Cette section fournit une description des processus et des activités de conception des services qui sont responsables de la fourniture d’informations importantes pour la conception d’un service nouveau ou modifié. Une approche structurée orientée-résultats associée aux cinq aspects mentionnés précédemment, garantit une fourniture des services de la plus haute qualité et une cohérence au sein de l’organisation dans son ensemble. Consulter le chapitre 10 de cet ouvrage pour une description plus détaillée des processus.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

80

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Toutes les activités de conception comprises dans cette phase du cycle de vie viennent des besoins et des demandes du client et reflètent la stratégie, la planification et la politique de la stratégie des services. Chaque phase du cycle de vie sert d’entrée pour la phase suivante du cycle de vie. La stratégie des services fournit des entrées importantes pour la conception des services, qui, à son tour, fournit des entrées pour la phase de transition. Elle constitue donc l’épine dorsale du cycle de vie des services. Pour développer des services efficaces et efficients, satisfaisant les besoins des clients, le processus de conception des services doit comprendre les sorties des autres domaines et des autres processus. Les sept processus étroitement liés et contenus dans la phase de conception des services sont les suivants : • gestion du catalogue des services • gestion des niveaux de services • gestion de la capacité • gestion de la disponibilité • gestion de la continuité des services informatiques • gestion de la sécurité des informations • gestion des fournisseurs

Gestion du catalogue des services (Service Catalog Management – SCM) La gestion du catalogue des services est une composante importante du portefeuille des services. Les deux forment l’épine dorsale du cycle de vie des services, en fournissant des informations à toutes les autres phases. Bien que le portefeuille général soit associé à la stratégie des services, il nécessite la coopération de toutes les phases successives. Dès que le service est prêt à être utilisé, la conception des services définit les spécifications qui peuvent être incluses dans le portefeuille des services. Le but final de la gestion du catalogue des services est le développement et la maintenance d’un catalogue des services comprenant tous les détails précis, les statuts de tous les services existants et les processus business qu’ils soutiennent, ainsi que ceux qui sont en cours de développement. Il comprend également la partie du portefeuille qui est visible au client.

Gestion des niveaux de service (Service Level Management – SLM) La gestion des niveaux de service représente le fournisseur de services informatiques face au client et donne une représentation interne du client au fournisseur de services informatiques. Le but de ce processus est d’établir des responsabilités pour garantir que les niveaux de fourniture sont atteints, aussi bien pour les services existants que les services futurs, conformément aux cibles convenues. SLM comprend la planification, la coordination, la fourniture, la négociation, la surveillance et la rédaction d’accords sur les niveaux de service (SLA), y compris la révision de la fourniture effectuée, pour garantir que la qualité satisfait, et autant que possible, dépasse les conditions requises convenues. Un SLA est un accord écrit entre un fournisseur de services et un client qui enregistre les buts et les responsabilités des deux parties. Ce processus soutient la gestion du catalogue des services en fournissant des informations et des tendances concernant la satisfaction du client.

Gestion de la capacité La gestion de la capacité est le pivot de toutes les conceptions concernant les questions de performance et la capacité informatique. Le but de la gestion de la capacité est de garantir que la

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

81

capacité correspond aux besoins actuels et futurs du client (enregistrés dans un plan de capacité). Le processus de gestion de la capacité est motivé par les conditions requises par le client et qui sont enregistrées dans le SLA. Il est essentiel de synchroniser la gestion de la capacité, le portefeuille des services et la gestion des niveaux de service (SLM) au sein du cycle de vie de la conception des services. La gestion de la capacité fournit ainsi des informations quant aux ressources existantes et futures par laquelle l’organisation décide quels composants seront renouvelés, quand et comment ils le seront. Pour sa part, la gestion de la capacité doit aussi disposer d’une vue concernant les plans de l’organisation tels qu’ils ont été élaborés lors de la phase de stratégie des services.

Gestion de la disponibilité La disponibilité et la fiabilité des services informatiques influencent la satisfaction des clients et la réputation du fournisseur. La gestion de la disponibilité est donc essentielle et doit entrer en jeu dès le début du cycle de vie, à l’instar de la gestion de la capacité. La gestion de la disponibilité comprend tout le processus de conception, de mise en œuvre, d’évaluation, de gestion et d’amélioration des services informatiques ainsi que leurs composants. Le but de ce processus est de garantir que le niveau de disponibilité des services nouveaux ou modifiés correspond aux niveaux convenus avec le client. Pour ce faire, la gestion de la disponibilité met en œuvre des activités proactives et réactives qui comprennent la surveillance et la rédaction des métriques disponibles ; elle doit maintenir le système d’information de la gestion de la disponibilité, qui comprend toutes les informations nécessaires et sert de base au plan de disponibilité.

Gestion de la continuité des services informatiques (IT Service Continuity Management – ITSCM) La gestion de la continuité des services informatiques (ITSCM) jour un rôle précieux dans le support du processus de la planification de la continuité business. Les organisations appliquent ce processus comme un moyen de focaliser l’attention sur les exigences de continuité et de reprise, et pour justifier la décision de mettre en œuvre un plan de continuité. Le but final d’ITSCM est de soutenir la continuité business en garantissant que les installations informatiques requises puissent être restaurées dans les délais convenus. Le processus met l’accent sur les occurrences pouvant être considérées somme des sinistres (calamités). Dans un premier temps, l’accent est mis uniquement sur les questions liées aux TI qui soutiennent le processus business. Les catastrophes moins significatives seront gérées via le processus de gestion des incidents.

Gestion de la sécurité informatique La gestion de la sécurité informatique garantit que la politique de sécurité informatique satisfasse la politique et les exigences de sécurité globale de l’organisation issues de la gouvernance d’entreprise. La sécurité n’est pas vraiment une étape du cycle de vie. La sécurité informatique est un processus continu et inhérent à tous les services. Ce processus rend conscient toute l’organisation au regard de la fourniture des services. La gestion de la sécurité informatique doit comprendre l’ensemble des TI et la sécurité du business pour être en mesure de gérer les aspects existants et futurs de la sécurité du business. Le système de gestion de la sécurité informatique (Information

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

82

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Security Management System – ISMS) sert de base au développement rentable d’un programme de sécurité informatique qui soutient les objectifs business.

Gestion des fournisseurs Le processus de gestion des fournisseurs attire l’attention sur tous les fournisseurs et sur les contrats pour soutenir la fourniture des services au client. Le but est de garantir un niveau constant de qualité au juste prix. Toutes les activités de ce processus sont issues de la stratégie des fournisseurs et de la politique générée par la stratégie des services. Pour obtenir la cohérence et l’efficacité pendant la mise en œuvre de la politique, il faut établir une base de données de fournisseurs et de contrats comprenant les fournisseurs, les contrats et aussi l’exécution des services supportés. Tout cela devrait se faire avec un regard sur la fourniture des services informatiques de valeur et de haute qualité. Le processus de gestion des fournisseurs doit être synchronisé avec les demandes de l’organisation, les besoins de la gestion de la sécurité informatique et l’ITSCM.

Activités En plus des sept processus mentionnés précédemment, trois activités se différencient au sein du processus de conception des services. Notamment : • Développement des conditions requises • Gestion des données et des informations • Gestion de l’application

Développement des conditions requises Types de condition requise ITIL présume que l’analyse des processus business existants et futurs aboutit à des exigences fonctionnelles qui entrent dans la catégorie des services informatiques (comprenant applications, données, infrastructure, environnement et compétences). On distingue trois types d’exigence par système, notamment : • Exigences fonctionnelles – elles décrivent les questions pour lesquelles un service est fourni et peut s’exprimer comme des tâches ou des fonctions, qui permettent l’élaboration d’un composant. Plusieurs modèles peuvent être pris en considération pour spécifier les exigences fonctionnelles, tels que : − diagramme de contexte du système − modèle de cas d’emploi • Exigences de gestion et opérationnelles – Elles définissent les exigences non fonctionnelles du service informatique. Les exigences servent de base pour les premiers systèmes, les estimations de coûts et le support pour la viabilité du service proposé. Les exigences émanant de la gestion et de l’exécution sont reconduites sur un grand nombre d’aspects de la qualité : − facilité de gestion − efficience − disponibilité et fiabilité − capacité et performance − sécurité − installation − continuité − contrôlabilité

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

83

− facilité de maintenance − facilité d’exploitation − mesurabilité et reporting • Exigences de facilité d’utilisation – Elles garantissent que les services satisfont les attentes des utilisateurs en termes de facilité d’utilisation et de convivialité. Pour ce faire, il faut procéder comme suit : − développer des standards de performance pour les évaluations − définir des scénarios de test À l’instar des exigences opérationnelles et de gestion, il est possible d’adopter les exigences de facilité d’utilisation pour tester la conformité des applications par rapport aux exigences de facilité d’utilisation. Recherche de conditions requises Plusieurs techniques de recherche existent pour aboutir à des exigences plus claires. Étant donné que les clients sont souvent peu sûrs de leurs exigences, l’aide d’un conseiller est parfois nécessaire. Cette personne doit avoir conscience d’être vue comme quelqu’un du département informatique qui dicte les exigences. Un certain degré d’attention est donc nécessaire. Voici quelques méthodes de recherche possibles : • interviews • ateliers • observation • analyse de protocole • suivi rapproché • analyse de scénario • prototypes • utilisation des prototypes

Problèmes lors du développement des exigences Plusieurs problèmes peuvent se produire lors du développement des exigences. • manque de pertinence des objectifs du service • manque de clarté • conflits entre les exigences • incertitude de la part des utilisateurs • niveaux de détail incohérents Pour faire face aux problèmes, il est important de nommer des participants. Trois groupes doivent être impliqués dans l’établissement des exigences. • le client • la communauté des utilisateurs • l’équipe chargée du développement Documentation des exigences Le document relatif aux exigences sert de base au processus. Ce document contient toutes les exigences individuelles dans un modèle standard. Les exigences pouvant venir des utilisateurs doivent aussi être incluses. Chaque exigence doit être formulée selon le modèle SMART

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

84

Les fondamentaux de la gestion des services informatiques selon ITIL V3

(Spécifique, Mesurable, Atteignable, Réaliste et à Temps). De plus, une vérification s’impose pour garantir qu’elles sont claires, non ambiguës, raisonnables et synchronisées avec les objectifs du client et qu’elles ne sont pas en conflit avec les autres conditions requises. Il est alors possible d’enregistrer le résultat dans le catalogue des besoins, qui devrait être un composant du portefeuille des besoins dans le portefeuille général des services. Les exigences des utilisateurs devraient y être incluses et étiquetées avec un numéro d’identification, la source, le propriétaire, la priorité (par ex. selon l’approche MoSCoW (Must have, Should have, Could have, Would have, c’est-à-dire : doit avoir, devrait avoir, pourrait avoir, aurait), description, processus business impliqué, etc. L’analyse des besoins est un processus itératif. En d’autres termes, les besoins changent au cours du processus de développement des services. Il est donc également important que les utilisateurs soient impliqués pendant tout le processus.

Gestion des données et des informations Les données sont l’un des aspects les plus critiques devant être contrôlé pour développer, fournir et soutenir des services informatiques efficaces. Les facteurs de succès de la gestion des données comprennent : • les utilisateurs ont accès aux informations dont ils ont besoin pour leur travail • les informations sont partagées au sein de l’organisation • la qualité des informations est maintenue à un niveau acceptable • les aspects légaux concernant les données sensibles, la sécurité et la confidentialité sont pris en compte. Des actifs de données gérés de façon inefficace présente un certain nombre de risques : la collecte d’informations et de données qui ne sont pas nécessaires ; l’accent sera mis sur des informations périmées ; beaucoup d’informations ne sont plus accessibles ou sont accessibles à qui n’est pas autorisé à y accéder. Périmètre Dans le domaine des données et des informations, on distingue quatre types de gestion : • Gestion des sources de données – les sources devraient être claires et les responsabilités doivent être confiées à la bonne personne. Ce processus est également désigné comme l’administration des données. Cette activité comprend les responsabilités suivantes : − définir le besoin d’information − développer un inventaire de données et un modèle de données d’entreprise − identifier les manques et les ambigüités − maintenir un catalogue − évaluer les coûts et les récompenses des données de l’organisation • Gestion des données et des technologies de l’information – ce secteur traite de la gestion informatique et comprend des aspects tels que la conception de bases de données et la gestion des bases de données. Il est abordé dans le chapitre sur l’exploitation des services. • Gestion des processus de l’information – le cycle de vie des données (processus de création, de collecte. d’accès, de modification, de stockage, d’élimination et d’archivage des données) doit être contrôlé. Ce processus est souvent associé au processus de gestion des applications.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

85

• Gestion des standards et de la politique des données. L’organisation doit formuler des standards et une politique pour la gestion des données en tant que composante de la stratégie des services. Gestion des données et cycle de vie des services Pour comprendre l’utilisation des données dans les processus business, il est recommandé de suivre une approche de cycle de vie traitant de sujets tels que : • Quelles données avons-nous à tel moment et comment sont-elles classées ? • Quelles données devrait-on collecter via les processus business ? • Comment stocker et maintenir ces données ? • Comment accéder à ces données et qui devrait le faire ? • Comment disposer de ces données et qui devrait le faire ? • Comment protéger la qualité des données ? • Comment rendre les données encore plus accessibles et disponibles ? Les données ont des implications importantes ; et pas seulement pour les organisations pour lesquelles l’approvisionnement en données est au cœur du business, comme par exemple dans le cas d’un bureau de presse tel que Reuters. Les données sont de plus en plus perçues comme étant une propriété commune, ayant une valeur qui s’exprime en termes financiers. Pour ce, plusieurs opportunités existent : • Évaluation des données selon leur disponibilité – cette approche traite des processus business qui ne seraient pas possibles si certaines données n’étaient pas disponibles pour l’organisation, et qu’est ce que cela coûterait pour l’organisation. • Évaluation des données perdues – cette approche examine les coûts de remplacement des données en cas de perte ou de destruction. • Évaluation des données du point de vue du cycle de vie des données – cette approche met l’accent sur des problèmes tels que le mode de création des données, la façon dont elles sont rendues disponibles ; la façon dont elles sont archivées ; le cycle de vie diffère (et par conséquent, les coûts) selon la demande, ou lorsque des étapes sont effectuées par une partie interne ou externe. Classification des données Les données peuvent être classées en trois catégories : • Données opérationnelles – ces données sont nécessaires au fonctionnement continu de l’organisation et sont les moins spécifiques. • Données tactiques – ces données sont nécessaires, entre autres, pour la gestion du niveau ou pour un niveau supérieur ; il s’agit de données trimestrielles, émanant des systèmes d’information de gestion. • Données stratégiques – elles concernent les tendances à long terme par rapport aux informations externes (marché). Propriétaire de données Les responsabilités du propriétaire de données comprennent : • Définir qui crée, révise, lit et élimine les données • Donner son accord sur la façon de stocker les données pour les modifier

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

86

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Approuver les niveaux de sécurité • Convenir d’une description business et d’un objet Intégrité des données Lors de la définition des services informatiques, il est important de prendre en compte les besoins de la gestion et des données opérationnelles. Notamment dans les domaines suivants : • Restauration de données perdues • Accès contrôlé aux données • Mise en œuvre d’une politique d’archivage des données • Surveillance périodique de l’intégrité des données.

Gestion de l’application Une application est définie par ITIL comme étant : Une application est un logiciel ayant des fonctions spécifiques qui offrent un support direct à l’exécution des processus et/ou procédures business. Les applications, conjointement avec les données et les infrastructures, comprennent les composants techniques des services informatiques. Il est essentiel de fournir les applications qui correspondent aux besoins des clients. Les organisations passent souvent beaucoup de temps sur les besoins fonctionnels du nouveau service et peu de temps sur la conception des exigences de gestion et les exigences opérationnelles (non-fonctionnelles) d’un service. Cela signifie que lorsque le service est réalisé, il satisfait les besoins fonctionnels mais pas les attentes du business et du client en ce qui concerne la qualité et la performance. Deux approches alternatives sont nécessaires pour mettre en œuvre la gestion de l’application : • Cycle de vie du développement des services est une approche systématique de résolution de problèmes pour soutenir le développement d’un service informatique. Elle comprend les étapes suivantes : − étude de faisabilité − analyse − conception − tests − mise en œuvre − évaluation − maintenance • Maintenance de l’application – l’autre approche examine tous les services en bloc pour garantir un processus continu de gestion et de maintenance des applications. Toutes les applications sont décrites de façon cohérente dans le portefeuille des applications, qui est synchronisé avec les besoins des clients. Référentiels d’application Le référentiel d’application comprend tous les aspects de gestion et ceux opérationnels et fournit des solutions pour toutes les exigences de gestion et celles opérationnelles d’une application.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

87

Les activités liées à l’architecture doivent être planifiées et gérées séparément des projets de logiciel qui reposent sur les systèmes individuels. Les concepteurs d’applications doivent se concentrer sur une application, tandis que les développeurs de référentiels se concentrent sur plus d’une application et sur les opportunités. Une méthode qui est souvent employée consiste à distinguer différents types d’applications. Par exemple, toutes les applications ne peuvent pas être utilisées sur une plateforme Microsoft Windows, associée à un serveur UNIX dans lequel il faut utiliser HTML, des Java-applets et des JavaBeans. Les différents types d’application peuvent être perçus comme une famille d’applications. Toutes les applications d’une même famille reposent sur le même référentiel d’application. Dans ce concept, la première étape de la phase de conception de l’application est l’identification du bon référentiel. Au fur et à mesure que les référentiels arrivent à maturité, diverses décisions peuvent être prises. S’il n’est pas mature, la bonne stratégie consiste alors à collecter et analyser les besoins qui ne coïncident pas avec le référentiel existant. Sur la base des besoins de l’application, il est possible de définir les nouveaux besoins pour le référentiel de l’application ; après quoi, le référentiel peut être modifié pour satisfaire tous les besoins. Outils de Génie logiciel assisté par ordinateur (Computer Assisted/Aided Software Engineering – CASE) L’un des aspects de l’alignement général est le besoin d’aligner les applications avec leurs structures de support sous-jacentes. Traditionnellement, les environnements de développement possèdent leurs propres outils d’aide au développement de logiciels (CASE) qui, par exemple, offrent les moyens de spécifier les besoins, de dessiner des diagrammes de conception ou de générer des applications. Ils sont aussi un espace dans lequel les éléments créés sont stockés et gérés. Développement des applications Après la phase de conception, l’application doit faire l’objet d’un développement. L’application et l’environnement doivent tous deux être préparés pour le lancement. La phase de développement de l’application comprend les aspects suivants : • conventions cohérentes de codage • guides structurelles indépendantes pour les applications • tests en situation réelle • liste de contrôle de la phase de construction pour le management • organisation des rôles dans l’équipe pour la structure Le développement d’une application produit entre autre : • des scripts pour commencer et arrêter une application • des scripts pour surveiller les configurations du matériel et du logiciel • les spécifications de l’unité de mesure pouvant être obtenue à partir de l’application • objectifs et besoins des SLA • besoins opérationnelles et documentation • besoins de support

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

88

Les fondamentaux de la gestion des services informatiques selon ITIL V3

4.4 Organisation Rôles et responsabilités Les organisations très performantes prennent les bonnes décisions rapidement et de façon précise, pour les exécuter avec succès. Pour ce faire, il est essentiel de définir clairement les rôles et les responsabilités. Ceci concerne également le processus de conception des services. Un des modèles possibles pouvant servir ici est le modèle RACI. RACI est l’acronyme des quatre rôles principaux suivants : • Responsable – la personne qui doit exécuter la tâche. • Accountable – une seule personne, qui est responsable de chaque tâche. • Consulted – les personnes qui donnent des conseils. • Informed – les personnes qui sont informées de la progression du projet Lors de l’établissement d’un système RACI, les étapes suivantes sont nécessaires : • Identifier les activités et les processus • Identifier et définir les rôles fonctionnels • Organiser des réunions et déléguer les codes RACI • Identifier les écarts et les chevauchements potentiels • Distribuer l’ensemble et s’assurer du feedback • Veiller au bon suivi des rôles et responsabilités

Compétences Malgré le fait que chaque position comporte en soi les aptitudes et les compétences spécifiques (voir Rôles ci-après), le responsable devra : • Avoir conscience des priorités et des objectifs business • Avoir conscience du rôle joué par les TI • Posséder les compétences de service • Avoir conscience de ce que les TI fournissent aux clients • Avoir les compétences et les connaissances nécessaires pour mener à bien la fonction

Rôles Cette section contient une description des rôles et des responsabilités concernant les plus importants postes du processus de conception des services. Ces rôles peuvent être combinés en fonction de la taille de l’organisation. Les rôles les plus importants sont : • Le propriétaire du processus – il est responsable de la mise en œuvre du processus conformément aux accords et de la réalisation des objectifs établis. Les tâches sont : − documenter et publier le processus − définir les indicateurs-clés de performance (Key Performance Indicators – KPI) et, si nécessaire, les réviser − améliorer l’efficacité et l’efficience du processus − fournir des entrées au plan d’amélioration des services − examiner les processus, les rôles et les responsabilités • Le gestionnaire de la conception des services – il est responsable de la coordination globale et de fournir les entrées des conceptions des services. Les tâches comprennent : − Garantir que la stratégie des services correspond au processus de conception et que les conceptions satisfont les besoins établis ;

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

89

− Concevoir les aspects fonctionnels des services ; − Produire et maintenir la documentation de la conception ; − Évaluer l’efficacité et l’efficience du processus de conception. • Le gestionnaire du catalogue des services – il est responsable de la production et de la maintenance du catalogue des services. De plus, le gestionnaire du catalogue des services doit : − garantir que les services sont enregistrés dans le catalogue des services − garantir que les informations incluses sont mises à jour et cohérentes avec les informations du portefeuille des services − garantir que le catalogue est sécurisé et qu’il y a des copies de sauvegarde • Le gestionnaire des niveaux de service – ses principales responsabilités sont les suivantes : − disposer d’indications quant aux demandes changeantes du client et du marché − garantir que les besoins existants et futurs du client ont été identifiés − négocier et prendre des accords sur la fourniture des services − aider à la production et à la maintenance d’un portefeuille correct des services − garantir que les objectifs ratifiés dans les contrats sous-jacents sont synchronisés avec l’accord sur les niveaux des services (Service Level Agreement -SLA) • Le gestionnaire de la disponibilité – est responsable de : − garantir que les services existants sont disponibles comme convenus − aider à enquêter et diagnostiquer tous les incidents et les problèmes − contribuer à la conception de l’infrastructure informatique − améliorer de façon proactive la disponibilité des services • Le gestionnaire de la sécurité – ses principales tâches sont les suivantes : − concevoir et maintenir la politique de sécurité des informations − communiquer aux les parties intéressées les questions concernant la politique de sécurité − aider à l’analyse de l’impact business − effectuer les analyses des risques et la gestion des risques avec la gestion de la disponibilité et l’ITSCM Les postes de responsabilité suivantes sont également à inscrire dans le processus : • Planificateur des TI • Concepteur/architecte informatique • Gestionnaire de la continuité des services • Gestionnaire de la capacité • Gestionnaire des fournisseurs

4.5 Méthodes, techniques et outils Considérations technologiques Il est extrêmement important qu’une personne garantisse que les outils à utiliser supportent les processus et non le contraire. Plusieurs outils et techniques peuvent être utilisés pour soutenir les conceptions des services et de composants. Non seulement ils permettent les conceptions de matériel informatique et de logiciels, mais aussi le développement des conceptions d’environnement, de processus et de données. Une grande variété d’outils et de techniques offrent les bénéfices suivants : • vitesse du processus de conception Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

90

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• conformité avec les standards • développement de prototypes et de modèles • prise en compte de divers scénarios (que se passerait-il si ...?) Le processus de conception peut être simplifié en utilisant les outils qui fournissent des images graphiques du service et de ses composants ; à partir des processus business, en passant par le service et les SLA, jusqu’à l’infrastructure, l’environnement, les données, les applications, les processus, les accords sur les niveaux opérationnels (Operational Level Agreement – OLA), les équipes, les contrats et les fournisseurs. Si l’outil contient également des informations financières et s’il est associé à un arbre de métrique, le service peut être sauvegardé et géré pendant toutes les phases de son cycle de vie. Non seulement ces outils facilitent le processus de conception, mais ils supportent également toutes les phases du cycle de vie des services, notamment : • gestion de tous les niveaux du cycle de vie des services • tous les aspects du service et les performances • gestion des coûts • gestion du portefeuille et du catalogue des services • un système de gestion des configurations (Configuration Management System – CMS) et un système de gestion des connaissances des services (Service Knowledge Management System – SKMS) Les activités génériques suivantes peuvent être réalisées : • garantir la présence d’un cycle de vie générique des actifs informatiques • formaliser les relations entre les différents types d’actifs informatiques • définir les rôles et les responsabilités • garantir la réalisation d’une étude pour comprendre le TCO (coût total de possession) d’un service informatique Les actifs d’applications comprennent également : • Définir une stratégie d’acquisition pour les actifs informatiques et analyser comment elle peut être synchronisée avec la stratégie informatique et les stratégies business. • Documenter le rôle que joue l’application dans l’approvisionnement des services informatiques. • Déterminer les standards pour l’utilisation des diverses approches de la conception des applications. Les actifs de données/informations comprennent également : • Garantir que les conceptions de données sont réalisées à la lumière de : − l’importance de la normalisation − du besoin de données ayant une valeur qualitative − de la valeur des données pour l’organisation Les actifs d’infrastructures informatiques comprennent également : • Établir des standards pour l’acquisition et la gestion des TI et des infrastructures environnementales (électricité, espace, middleware, systèmes de bases de données, etc.)

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

91

• Déterminer les activités pour l’utilisation optimale des actifs d’infrastructures informatiques ; • Spécifier les besoins en outils et décrire comment ils devraient être utilisés. Les actifs de compétences comprennent également : • Formaliser comment les compétences pourraient être considérées comme des actifs pour l’organisation ; • Garantir que les compétences sont documentées. Pour établir les interfaces et les dépendances, il est possible d’ajouter les points suivants : • Formaliser les interfaces que l’acquisition et la gestion des actifs informatiques ont avec les fonctions et les processus hors de la sphère informatique. • Formaliser le contrôle de la qualité dans l’acquisition et la gestion des actifs informatiques.

Outils de gestion des services Des outils garantissent que les processus de conception des services fonctionnent efficacement. Ils améliorent l’efficacité et fournissent des informations précieuses de gestion sur l’identification de points faibles possibles. Le bénéfice à long terme réside dans l’utilisation d’outils pour réduire les coûts et augmenter la productivité, dans l’intérêt d’améliorer la qualité de la fourniture des services informatiques. De plus, l’utilisation d’outils permet la centralisation des processus essentiels, ainsi que l’automatisation et l’intégration des processus de gestion des services de base. Les considérations sur l’évaluation des outils de gestion des services comprennent : • Structure des données, gestion et intégration des données • Conformité avec les standards internationaux • Flexibilité de mise en œuvre, utilisation et partage des données • Support à la surveillance des niveaux des services L’outil sert à soutenir le processus plutôt que le contraire. Si possible, il est recommandé qu’un outil complètement intégré soit acquis pour soutenir les nombreux processus de gestion des services. Si cela n’est pas possible, alors les interfaces entre les différents outils devraient être prises en considération. Lors du processus de sélection, il est conseillé d’employer un énoncé des exigences (Statement of Requirements – SoR). Les exigences devraient être prises en compte selon l’analyse MoSCoW : • M – doit avoir ceci • S – devrait avoir ceci • C – pourrait avoir ceci • W – n’aura pas ceci maintenant, mais aimerait l’avoir dans le futur. L’outil doit être flexible afin de pouvoir soutenir les droits d’accès individuels. Il faut déterminer qui a accès aux données et avec quels objectifs. De plus, il faut décider sur quelle plateforme l’outil pourra fonctionner. Pendant la première considération, il est opportun de vérifier la valeur de crédit du fournisseur et s’il offre un support (formation) de plusieurs mois, voire plusieurs années. Dans ce processus, il est important de comprendre qu’une solution ne satisfait presque jamais 100% des exigences. La règle du 80/20 est sans doute plus réaliste dans ce référentiel. En d’autres termes, l’outil satisfera très certainement 80% des exigences définies.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

92

Les fondamentaux de la gestion des services informatiques selon ITIL V3

4.6 Mise en œuvre Considérations sur la mise en œuvre La section suivante comprend des considérations sur la mise en œuvre de la conception des services. Les interfaces de la conception des services avec les autres phases du cycle de vie des services sont également abordées.

Analyse de l’impact du business L’analyse de l’impact du business (BIA) est une source précieuse d’informations pour définir les besoins du client ainsi que l’impact et les risques d’un service. Le BIA est un élément essentiel du processus de continuité business qui dicte la stratégie à adopter afin de réduire les risques et les reprises après une catastrophe. Le BIA se compose de deux parties : d’un côté, l’étude de l’impact de la perte d’un processus ou d’une fonction business ; d’un autre côté l’arrêt de l’effet de cette perte. Le BIA doit être conduit pour soutenir la définition de la stratégie de continuité business et permettre de mieux comprendre la fonction et l’importance du service. De cette façon, l’organisation définit, entre autres choses : • les services critiques • le temps acceptable d’indisponibilité du service • le niveau acceptable d’indisponibilité du service • les coûts de la perte du service • les périodes critiques du business & du service

Mise en œuvre de la conception des services Le processus, la politique et l’architecture pour la conception des services informatiques, d’après la description contenue dans cet ouvrage, doivent être documentés et utilisés pour concevoir et mettre en œuvre les services informatiques appropriés. En principe, il est recommandé de mettre en œuvre tous les processus en même temps car tous les processus sont liés les uns aux autres et sont souvent dépendants les uns des autres. Ce qui est nécessaire en dernier lieu est une série intégrée de processus que les services informatiques gèrent et surveillent pendant tout le cycle de vie. Puisque les organisations mettent rarement tout en œuvre en même temps, le processus dont on a le plus besoin doit être mis en œuvre en premier, avec l’acceptation que tous les processus sont liés les uns aux autres. Cela dépend également de la maturité de la gestion des services informatiques de l’organisation. Les priorités de mise en œuvre doivent correspondre aux objectifs du programme d’amélioration des services (SIP). Si, par exemple, la disponibilité des services informatiques est un point important, alors l’organisation doit se concentrer sur les programmes qui améliorent la disponibilité ; dans ce cas, les processus de gestion des incidents, des problèmes, des changements et de la disponibilité. Plusieurs autres processus, tels que la gestion de la capacité, de la sécurité et de la continuité, influencent également la disponibilité, comme l’illustre l’interdépendance des processus ITIL. Il faut utiliser une méthode structurée de gestion des projets pendant la phase de mise en œuvre. Le modèle CSI en est un bon exemple. Le succès de la conception des services et le succès de l’amélioration des processus de conception des services doivent être évalués. Les résultats doivent ensuite être analysés et enregistrés. S’il ne satisfait pas les exigences, alors un ajustement sera

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

93

certainement nécessaire. Des évaluations doivent être effectuées au cours de tout le processus. Une des méthodes possibles est le tableau de bord équilibré (Balanced Scorecard), développé par Robert Kaplan et David Norton comme méthode d’évaluation des activités business en termes de stratégie et de vision, qui permet de donner une bonne image de la performance d’une organisation.

Conditions requises Plusieurs conditions sont à remplir pour les processus nouveaux ou révisés. Celles-ci constituent souvent des exigences pour d’autres processus. Par exemple, avant que la gestion des niveaux des services (Service Level Management – SLM) puisse concevoir un accord sur les niveaux d’un service (SLA), il faut établir un catalogue des services business (un utilisant le langage du métier du client) ainsi qu’un catalogue technique des services. Un autre exemple est le fait que la gestion des problèmes dépende d’un processus mature de la gestion des incidents. Ces faits dépassent l’ITSM : la gestion de la disponibilité et de la capacité nécessite des informations du business plan. Il existe d’autres exemples de ce genre qu’il faut prendre en compte avant de pouvoir atteindre la maturité d’un processus.

Facteurs clés de succès et KPI On recommande que chaque fournisseur de services informatiques se concentre sur un certain nombre de facteurs clés de succès et sur les indicateurs clés de performance (KPI). Ils devraient être définis dès le début du programme d’amélioration continue des services. Les indicateurs clés de performance (KPI) du processus de conception des services sont les suivants : • Pourcentage des spécifications des exigences de la conception des services produites à temps • Pourcentage des spécifications des exigences de la conception des services produites dans les limites du budget • Pourcentage des paquets de transition des services produits à temps • Exactitude de la conception des services • Exactitude des SLA, des OLA et des contrats

Défis Exemples de défis à affronter pendant la phase de mise en œuvre : • Le besoin de synchroniser l’architecture, la stratégie et la politique existantes • L’utilisation des différentes technologies et applications • Exigences du client changeantes ou peu claires • Manque de conscience et de connaissance de la fourniture des services • Résistance au travail systématique • Utilisation insuffisante des ressources Pour gagner les défis, les questions suivantes doivent être prises en compte : • Indications quant aux exigences et aux priorités du client ; • Communication adéquate avec les partis concernées, mais aussi savoir écouter ; • Impliquer autant de personnes que possible dans le processus de conception ; • Garantir l’implication de la direction et du personnel.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

94

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Risques Il y a plusieurs risques pendant la phase de conception des services, notamment : • Si le niveau de maturité dans l’un des processus est bas, il est impossible d’atteindre un haut niveau de maturité dans les autres processus. • Les exigences business ne sont pas claires pour le personnel informatique. • Trop peu de temps est imparti à la conception des services. • La synchronisation entre infrastructure, client et partenaire n’est pas bonne, ce qui signifie que les exigences ne peuvent être satisfaites. • La phase de conception des services n’est pas claire ou n’est pas disponible dans son ensemble.

Interfaces avec les autres phases du cycle de vie Toutes les activités de la phase de conception des services sont issues des besoins et des exigences du client et sont donc en ce sens un reflet de la stratégie, des plans et de la politique produits par la première phase du cycle de vie : la stratégie des services. La phase de conception des services dans le cycle de vie commence par la formulation des besoins nouveaux ou modifiés du client. En dernier lieu, à la fin du processus de conception, une solution de service doit être conçue pour satisfaire ces besoins avant qu’ils ne commencent le processus de transition et le package de service. Pendant la phase de transition, le service sera évalué, structuré, testé et le déploiement se fera ; après quoi, la mise en œuvre sera transférée à l’exploitation des services. La figure 4.2 montre clairement que les sorties de chaque phase constituent les entrées de la phase suivante dans le cycle de vie. La stratégie des services fournit des entrées importantes pour la conception des services, qui, à son tour, fournit des entrées pour la phase de transition. Le portefeuille des services fournit les informations à tous les processus dans chaque phase du cycle de vie. Il constitue donc l’épine dorsale du cycle de vie des services. Le portefeuille des services doit être un composant du système de gestion des connaissances des services (SLMS) et doit être incluse en tant que document dans le système de gestion des configurations (CMS). Cela sera décrit avec plus de détails dans la section suivante Transition des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la conception des services

95

Exigences

Portefeuille de Services Catalogue de Services

Stratégie de Services Stratégies Politiques Ressources & contraintes Objectifs des Exigences

Conception de Services Conception de solution Architectures Standards Package de Conception de Service (SDP) Transition de Services Plan de transition Solutions testées Système de Gestion de la Connaissances de Service

Métier/ Clients

Services opérationnels

Amélioration Continue de Services Plans et actions d’amélioration

Exploitation de Services Plans opérationnels

Figure 4.2  Les relations les plus importantes, les entrées et les sorties de la conception des services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

96

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 5

Phase de cycle de vie : la transition des services 5.1 Introduction Ce chapitre explique comment les spécifications de la conception des services peuvent être converties de façon efficace en un service nouveau ou modifié.

Objectifs Les objectifs de la transition des services consistent à : • Soutenir le processus de changement du business (client). • Réduire les variations de performance et les erreurs connues du service nouveau ou modifié. • Garantir que le service satisfait les exigences des spécifications du service. Les objectifs de la transition des services comprennent : • Les moyens nécessaires pour effectuer, planifier et gérer le nouveau service. • Garantir un impact minimum pour les services qui sont déjà en production. • Améliorer la satisfaction client et stimuler l’utilisation correcte du service et de la technologie s’y rapportant.

Périmètre ITIL définit le périmètre de la transition des services comme suit : La transition des services comprend la gestion et la coordination des processus, des systèmes et des fonctions nécessaires à la construction, aux tests et au déploiement d’une mise en production ; elle établit le service spécifié selon les exigences du client et de la partie prenante. La transition des services comprend généralement les étapes suivantes : • planification et préparation • construction et tests • tous les pilotes • planification et préparation du déploiement • déploiement et transition • révision et clôture de la transition des services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

98

Bien que la gestion des changements, la gestion des actifs de services et des configurations ainsi que la gestion des connaissances supportent toutes les phases du cycle de vie des services, l’ouvrage ITIL sur la transition des services couvre spécifiquement ces thèmes. La mise en production et la gestion du déploiement, la validation et les tests de services ainsi que l’évaluation font partie du périmètre de la transition des services.

Valeur pour l’entreprise Une transition des services efficace garantit que les services nouveaux ou modifiés sont mieux alignés avec les opérations métiers du client. Notamment : • La capacité du métier de réagir rapidement et de façon adéquate aux changements survenant dans le marché. • Les changements dans l’entreprise suite à des reprises, des contrats, …. sont bien gérés. • Les changements et les mises en production se soldent par un succès pour l’entreprise. • Une meilleure conformité du métier et des règlementations. • Moins de déviations entre les budgets planifiés et les coûts reels. • Une meilleure connaissance des risques possibles pendant et après l’entrée d’un service. • Une productivité accrue de la part du personnel du client.

Amélioration Continue des Services

Gestion des changements RFC1

RFC3

RFC2

RFC4

RFC5

RFC6

Gestion des Actifs de Services et des Configurations BL

BL

BL

BL

BL

BL

BL

Planification de la Transition de Services et support

Surveiller les changements dans la gestion de l’organisation et des parties prenantes

Evaluation d’un Changement de Service E1

Stratégie des Services

Conception des Services

Planifier et préparer les mises en production

E2

Construire et tester

Tester des services et des pilotes

E3 Planifier et préparer pour déploiement

Gestion des Déploiements et des Mises en Production

Réviser et clôturer la transition des services

Transférer, déployer, supprimer

Exploitation de Services

Support de début de vie (ELS)

Validation et Testing des Services

Gestion de Connaissance Focus sur les activités liées à la transition de Services

Autres livres du noyau d’ITIL

Processus d’ITIL soutenant tout le cycle de vie

E

Point d’évaluation pour la conception de services

BL

Repère pour établir des bases de référence

RFC

RFC Demande de Changement

Figure 5.1 Le périmètre de la transition des services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

99

Optimisation Une transition des services est efficace et efficiente si la transition livre ce que le métier a demandé dans les limites du budget et des autres ressources nécessaires. De plus, il est important que la phase et les plans de mise en production associés soient coordonnés avec le business, la gestion des services et la stratégie informatique. C’est la raison pour laquelle il est important que les résultats de la transition correspondent aux spécifications de la conception des services. Quelles sont les différences entre les valeurs réelles et celles des spécifications ? Ces dernières peuvent influencer certains aspects tels que le temps, l’argent, la qualité et les risques.

5.2 Concepts de base Les politiques suivantes sont importantes pour une transition des services efficace et elles s’appliquent à toutes les organisations. L’approche doit encore être ajustée aux conditions qui différent d’une organisation à l’autre : • Définir et mettre en œuvre les guides de bonnes pratiques et les procédures pour la transition des services – définit et documente les politiques pour la transition des services. L’équipe de gestion doit approuver les politiques. L’équipe de management doit faire passer les politiques à l’organisation, aux fournisseurs des services et aux partenaires. • Mettre toujours en œuvre tous les changements via la transition des services – tous les changements apportés au portefeuille ou au catalogue des services subissent le processus de gestion des changements et la phase de transition des services. • Utiliser les référentiels et les standards – baser les transitions de services sur des référentiels, des processus et des systèmes généralement acceptés. Ceci encourage la coopération entre les parties impliquées dans la transition des services et garantit qu’elles parlent la même langue. • Réutiliser les processus et les systèmes existants – les processus de transition des services doivent être alignés avec les processus et les systèmes que l’organisation applique déjà. Ceci encourage l’efficacité et l’efficience. Si de nouveaux processus sont développés, la réutilisation est un critère de conception important. • Coordonner les plans de transition des services avec les besoins du business – coordonner les plans de transition et les services nouveaux ou modifiés avec les besoins de l’organisation du client. • Créer des relations avec les parties prenantes et les maintenir – pendant la transition des services, établir des relations avec le client (représentants), avec les utilisateurs et les fournisseurs, pour tracer leurs attentes quant au service nouveau ou modifié. • Prévoir des contrôles efficaces – prévoir des mécanismes de contrôle adéquats pour tout le cycle de vie afin de garantir une transition en douceur des changements et des mises en production des services. • Livrer des systèmes pour le transfert de connaissances et le support des décisions – la transition des services développe des systèmes et des processus pour transférer les connaissances nécessaires à une fourniture efficace des services et pour permettre la prise de décision. • Planifier les packages de mise en production et de déploiement – les packages de mise en production doivent être clairs, traçables, clairement planifiés, conçus, construits, testés, livrés, distribués et déployés pour toutes les personnes concernées. • Anticiper et gérer les changements de direction – garantir la formation du personnel pour voir quand les ajustements de direction sont nécessaires pendant la transition. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

100

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Gérer les ressources de façon proactive – livrer (et gérer) les ressources partagées et spécialisées pour les différentes activités de la transition des services pour éviter les retards. • Garantir l’implication dès le début du cycle de vie – consulter les parties prenantes afin que tout service, nouveau ou modifié, soit réellement livré comme convenu. • Garantir la qualité d’un service nouveau ou modifié – vérifier et confirmer que les changements proposés peuvent livrer les exigences de service requises. • Améliorer de façon proactive la qualité pendant une transition des services – planifier et améliorer de façon proactive la qualité d’un service nouveau ou modifié.

5.3 Processus et autres activités Cette section explique les processus et les activités d’une transition des services : • planification et support de la transition • gestion des changements • gestion des actifs de service et des configurations • gestion des déploiements et des mises en production • validation et tests des services • évaluation • gestion des connaissances des services Certains de ces processus et activités sont répartis dans plusieurs phases du cycle de vie des services, mais ils figurent dans cette section car ils sont au centre de la phase de transition des services. Consulter le chapitre 11 de cet ouvrage pour une description plus détaillée de ces processus. Les sections suivantes ne présentent qu’un bref résumé des processus.

Planification et support de la transition La planification et le support de la transition garantissent la planification et la coordination des ressources afin de réaliser la spécification de la conception des services. De plus, le processus garantit l’identification, la gestion et la minimalisation des risques qui peuvent interrompre le service pendant la phase de transition. Le périmètre de la planification de la transition consiste en : • Spécifications et exigences de conception du département de la production dans le processus de planification de la transition ; • Gestion de : − planification − activités de support − progrès de la transition − changements − problèmes − risques − déviations − processus − systèmes et outils supportés

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

101

• surveillance de la performance de la transition des services • communication avec le client, les utilisateurs et les parties prenantes Les activités de planification et de support sont : 1. établir la stratégie de transition 2. préparer la transition des services 3. planifier et coordonner la transition des services 4. support

Gestion des changements L’objectif du processus de la gestion des changements est de garantir que les changements sont déployés d’une façon contrôlée, évalués, priorisés, testés, mis en œuvre et documentés. Un changement peut se produire pour plusieurs raisons : réduction des coûts, amélioration des services, défaillance de la fourniture de services ou changement dans l’environnement. Un changement est l’ajout, la modification ou la suppression d’un service, ou d’un composant d’un service, autorisé, planifié ou supporté et de la documentation associée. Le processus de gestion des changements doit garantir que : • des méthodes et des procédures normalisées sont utilisées • tous les changements sont tracés dans la CMDB • les risques pour le business sont pris en compte De façon générale, les activités de gestion des changements comprennent : • planification et gestion des changements • planification de la mise en production • communication • autorisation aux changements • élaboration d’un plan de reprise • rédaction de rapports • évaluation de l’impact • amélioration continue Les activités spécifiques pour la gestion des changements individuels comprennent : • créer et enregistrer • revoir les RFC • déterminer et évaluer les changements • autoriser les changements • planifier les mises à jour • coordonner la mise en œuvre • évaluer et clôturer le changement

Gestion des actifs de service et des configurations (Service Asset and Configuration Management – SACM) SACM gère les actifs de services afin de soutenir les processus de gestion des autres services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

102

Les fondamentaux de la gestion des services informatiques selon ITIL V3

L’objectif est : la définition des composants de service et d’infrastructure ainsi que la maintenance des enregistrements de configurations correctes. Pour cela, il est important que : • L’intégrité des actifs de services et des éléments de configuration (CI) soit protégée. • Tous les actifs et les CI soient classés par catégorie dans la gestion des configurations. • Les processus de gestion business et des services soient supportés de façon efficace. SACM peut être impliqué dans les actifs et les CI non-informatiques, tels que les produits du travail supportant le développement des services. Le périmètre du processus comprend également les actifs et les CI (Configuration Items, éléments de configuration) des autres fournisseurs (actifs partagés), dans le sens où ils sont importants pour le service. Les activités SACM sont : • gestion et planification • identification des configurations • gestion des configurations (contrôle) • compte rendu et vérification des statuts • vérification et audits

Gestion des déploiements et des mises en production La gestion des déploiements et des mises en production vise à construire, tester et déployer les services spécifiés dans la conception de services et à assurer que le client utilise le service de façon efficace. L’objectif de la gestion des déploiements et des mises en production est de garantir : • qu’il existe des plans de déploiement et de mise en production • que les packages de mise en production (composition) sont déployés avec succès • que l’organisation informatique transfère la connaissance aux clients • que les services subissent le minimum d’interruption Les activités du processus de gestion des déploiements et des mises en production comprennent principalement : • la planification • la préparation de la construction, des tests et du déploiement • la construction et les tests • les tests et les pilotes des services • la planification et la préparation pour le déploiement • le transfert, le déploiement et le retrait • la vérification du déploiement • le support anticipé • la révision et la clôture

Validation et tests de services Les tests de service apportent une contribution importante à la fourniture de services informatiques de qualité. Les tests garantissent que les services, nouveaux ou modifiés, sont adaptés au besoin et adaptés à l’utilisation.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

103

Le but de la validation et des tests des services est de livrer un service qui soit une valeur ajoutée pour le business du client. Quand les services ne sont pas correctement testés, des incidents, des problèmes et des coûts supplémentaires se vérifient. Les objectifs de la validation et des tests des services sont de garantir que : • la mise en production satisfait les attentes du client • les services sont adaptés au besoin et adaptés à l’utilisation • les spécifications (exigences) du client et autre partie prenante sont définies La validation et les tests des services s’appliquent pendant tout le cycle de vie des services et ce, dans le but de tester la qualité du service (parties). Les tests supportent principalement le processus de déploiement et de mise en production. Le processus d’évaluation utilise les résultats des tests. Les activités du processus de test ne suivent pas un ordre fixe et peuvent être mises en œuvre en parallèle. Dans ce cas, elles comprennent : • la gestion de la validation et des tests • la planification et la conception • la vérification du plan de test et de la conception • la préparation de l’environnement des tests • les tests • l’évaluation des critères de sortie et les rapports • le nettoyage et la clôture Il existe de nombreuses techniques et d’approches de test, notamment : la révision de documents, la simulation, les tests de scénario et de laboratoire ainsi que les jeux de rôle. Le meilleur choix dépend du type de service, du profil risque, du but final et du niveau de test.

Évaluation L’évaluation est un processus générique dont le but est de vérifier si la performance de quelque chose est acceptable ; par exemple, si ce quelque chose a le bon rapport qualité/prix, s’il est continu, s’il est utilisé, s’il a été payé, etc. Dans le contexte de la transition des services, l’objectif de l’évaluation est la définition de la performance d’un changement apporté à un service. L’évaluation fournit d’importantes entrées pour l’amélioration continue des services et pour l’amélioration future de la gestion de développement et de changement des services. Le processus d’évaluation se compose des activités suivantes : • planifier l’évaluation • évaluer la performance prévue • évaluer la performance réelle

Gestion des connaissances Le but de la gestion des connaissances est l’amélioration de la qualité de la prise de décision en garantissant que des informations fiables et sûres sont disponibles pendant le cycle de vie des services. Voir également le modèle DIKW au chapitre 11. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

104

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les objectifs de la gestion des connaissances comprennent : • Permettre au fournisseur de services d’améliorer l’efficience et la qualité des services. • Garantir que le personnel du fournisseur de services a accès aux informations appropriées. La gestion des connaissances sert pendant tout le cycle de vie des services, mais surtout pendant la transition des services. Une transition réussie dépend, en large mesure, des informations disponibles et des connaissances des utilisateurs, du centre de services, du support et du fournisseur. Un partage efficace des connaissances exige le développement et la maintenance d’un Service Knowlegde Management System (système de gestion des connaissances du service – SKMS). Ce système devrait être disponible à toutes les parties prenantes des informations et répondre aux exigences en matière d’information. La gestion des connaissances comprend les activités, les méthodes et les techniques suivantes : • stratégie de la gestion des connaissances • transfert de connaissances • gestion des données et des informations • utilisation de SKMS (système de gestion des connaissances du service)

Autres activités La communication est au cœur de toute transition des services. Plus le changement est grand et plus le besoin de communication se fait sentir, quant aux raisons de ce changement, aux avantages possibles, aux plans de mise en œuvre et aux effets qu’il entraîne. Les autres activités opérationnelles de la transition des services, telles que la gestion des changements organisationnels et la gestion des parties prenantes, sont expliquées dans la section Organisation.

5.4 Organisation Dans l’ensemble, les activités d’un processus ne sont pas effectuées par un seul département. Les différentes activités, par exemple, de SACM (gestion des actifs et des configurations de services), sont effectuées par les départements tels que exploitation, gestion des applications, gestion du réseau et gestion du système. Les activités d’un processus sont donc liées aux différents départements informatiques et à leur personnel respectif. Les rôles et les responsabilités sont également définis.

Rôles génériques Propriétaire du processus – le propriétaire du processus garantit que toutes les activités du processus sont effectuées et : • Il est responsable de la stratégie du processus, et aide à la conception. • Il fournit la documentation du processus, les guides de bonnes pratiques et les procédures ainsi que leur application. • Il garantit la présence des ressources adéquates.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

105

Propriétaire du service – il est responsable, face au client, de l’initiation, de la transition et de la maintenance d’un service, et : • Il est la personne à contacter et il garantit que le service répond aux besoins. • Il détermine les points à améliorer et fournit les données et les rapports pour la surveillance du service. • Il est responsable de la fourniture du service auprès de la DSI.

Contexte organisationnel Les interfaces avec les autres départements et les tierce parties dans la transition des services doivent être clairement définies et connues. Les programmes, les projets, la conception de services et les fournisseurs des services, tous contribuent à la transition des services. La transition des services est activement gérée par un gestionnaire de transition des services. Le gestionnaire de transition des services est responsable de la gestion quotidienne et du contrôle des équipes de transition des services et de leurs activités. Un exemple d’organisation de la transition des services est illustré à la Figure 5.2. Bureau de Gestionde Service / Planification IT

Planification et Support

Gestionnaire de la Transition des Services

Changement et SACM

Évaluation de la Performance et du risque

Gestion de la Connaissance des Services

Test Support

Includes capacity and resource management Rôles permanents de transition de services Peut être fait par une autre équipe de l’organisation du fournisseur de service May be appointed for a specific release

Reports to Service Provider Director

Mise en Production et Déploiement2

Gestion des tests des services

Équipe de test 1

Équipe de test 2

Équipe de Mise en Production 1

Équipe de Mise en Production 2

Package de mise en production et construction

Package de mise en production et construction

Equipe de déploiement

Equipe de déploiement

Support de 3 début de vie

Support de 3 début de vie

Gestion des environnements de construction et de test 1 Indépendant de la mise en production et du déploiement 2 Indépendant de la gestion des tests de services 3 Contient la surveillance des produits et des problèmes, de la gesti on des problèmes, l’émission de RFC, du reporting sur la performance et l’évaluation des risques

Figure 5.2 Exemple d’organisation de la transition des services

Rôles et responsabilités de la transition des services Cette section décrit un certain nombre de rôles et de responsabilités au sein de la transition des services, bien que certains rôles reviennent à d’autres phases du cycle de vie. En fonction de la taille de l’organisation et du périmètre du service qui est changé, certains de ces rôles peuvent être effectués par une seule personne. Les responsabilités du gestionnaire des actifs de services comprennent : • Formuler les objectifs du processus et mettre en œuvre la politique, les standards, les plans et les procédures du processus. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

106

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Évaluer les systèmes de gestion des actifs existants et mettre en œuvre les nouveaux systèmes. • Indiquer le périmètre et la fonction du processus, les éléments devant être gérés et les informations devant être établies. • Se charger de la communication concernant le processus et le faire connaître. • Se charger des ressources et de la formation. • Identifier et nommer les conventions des actifs. • Évaluer l’utilisation d’outils. • Établir les interfaces avec les autres processus. • Planifier l’achèvement de la base de données des actifs. • Rédiger des rapports. • Aider lors des audits et se charger des actions correctives. Les responsabilités du gestionnaire des configurations comprennent : • Formuler les objectifs du processus et mettre en œuvre la politique, les standards, les plans et les procédures du processus. • Évaluer les systèmes de gestion des actifs existants et mettre en œuvre les nouveaux systèmes. • Indiquer le périmètre et la fonction du processus, les éléments devant être gérés et les informations devant être établies. • Se charger de la communication concernant le processus et le faire connaître. • Se charger des ressources et de la formation. • Etablir l’identification et les règles de nommage des Configuration Items (éléments de configuration – CI). • Évaluer l’utilisation d’outils. • Établir les interfaces avec les autres processus. • Évaluer les systèmes de gestion des configurations (CMS) et mettre en place les nouveaux systèmes. • Planifier la saisie de CMS dans la Configuration Management Data Base (base de données de gestion des configurations – CMDB). • Rédiger des rapports. • Aider lors des audits et se charger des actions correctives. Les responsabilités du gestionnaire des changements (qui peuvent être déléguées à d’autres personnes) comprennent : • Recevoir, enregistrer et prioriser (en collaboration avec l’initiateur) les Requests For Change (demandes de changement – RFC), rejeter les RFC basés sur les critères. • Préparer et présider les réunions CAB et ECAB. • Décider qui assiste à telle ou telle réunion, qui reçoit les RFC et ce qui doit être change. • Publier les plans de changement des calendriers des changements (SC). • Tenir les journaux des changements. • Clôturer les RFC. • Réviser les changements mis en œuvre. • Rédiger des rapports. Le Change Advisory Board (comité consultatif sur les changements – CAB) est un organisme de conseil. Les rôles et les responsabilités spécifiques du CAB seront expliqués au chapitre 11.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

107

Les responsabilités du gestionnaire du packaging de mise en production et de la construction comprennent : • La configuration finale de la mise en production • La construction de la mise en production définitive et les tests associés (pour les tests indépendants) • Signaler les pannes connues et les solutions de contournement • Donner les entrées pour l’accord final sur la mise en œuvre Le gestionnaire du déploiement a les responsabilités suivantes : • Mise en œuvre finale du service. • Coordination de toute la documentation de mise en production, des notes de mise en production et de la communication • Planification du déploiement, en association avec la gestion des changements, la gestion des connaissances et le SACM, • Fournir des conseils pendant le processus de mise en production, • Donner le feedback concernant l’efficacité d’une mise en production, • Enregistrer les métriques de déploiement à garantir dans le cadre des SLA, ITIL reconnaît les rôles suivants dans la phase de transition des services du cycle de vie des services, mais ils se trouvent hors du périmètre de cet ouvrage et des examens Foundation d’ITIL : • analyste des configurations • gestionnaire des configurations • gestionnaire des CMS • équipe de gestion des configurations • autorité de changement • gestionnaire de l’évaluation des risques • gestionnaire des connaissances du service • support des tests • support de début de vie • gestion de la construction et de l’environnement des tests

Gestion des changements organisationnels Tout changement significatif apporté à un service comporte un changement dans l’organisation. Cela peut varier du transfert d’un membre du personnel à un autre département à de grands changements, tels que la façon de travailler au sein de l’organisation. Par exemple : une société de vente par correspondance ne vend plus ses produits par le biais d’un catalogue imprimé mais via un site Internet. Les aspects suivants sont importants pour la gestion des changements organisationnels : • Le cycle émotionnel de changement – Une des causes principales d’échec des changements est de ne pas prendre suffisamment en compte la façon dont les changements affectent les personnes. Il convient donc d’examiner les phases émotionnelles que les personnes peuvent traverser avant d’accepter tout changement. Les phases émotionnelles sont : le choc, les manquements au devoir, le blâme externe, le blâme personnel et l’acceptation. • Le rôle de la transition des services dans les changements organisationnels -La gestion des changements est la responsabilité des gestionnaires et des chefs de département concernés

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

108

Les fondamentaux de la gestion des services informatiques selon ITIL V3

par un changement spécifique. Toutefois, le gestionnaire de la transition des services ou du propriétaire du processus est une partie importante du changement, par conséquent, la transition des services joue un rôle important dans les changements organisationnels. La transition des services doit : − Avoir conscience des cultures différentes aux niveaux organisationnel et individual. − Inclure une participation active dans le changement des attitudes des personnes (qui sont actives au sein du cycle de vie). − Offrir un support aux individus pour que la mise en œuvre des changements soit exécutée de façon cohérente − Évaluer si l’organisation informatique est suffisamment capable. − Garantir que le changement est accepté par la majorité des personnes dans leur méthode de travail quotidian. − S’assurer que le transfert de connaissances, la formation, la construction d’équipe, l’amélioration du processus et l’évaluation du personnel sont suffisamment compétents. • Planification et mise en œuvre des changements organisationnels – Lors de la planification et de la conception des changements, l’organisation elle-même et les personnes sont souvent trop peu prises en compte ; on se concentre sur les seuls aspects techniques du changement. C’est la raison pour laquelle il est important que les plans du projet indiquent également les changements organisationnels causés par le changement. • Produits – La stratégie des services et la conception des services aboutissent à plusieurs produits de travail qui soutiennent la gestion des changements organisationnels pendant la phase de transition des services, par exemple : − analyse des parties prenantes − évaluations de l’organisation et des compétences − modèles de processus de gestion de services − conseils pour les processus et les procédures − plan de communication − matrice RACI (Responsible, Accountable, Consulted, Informed – Acteur, Responsable, Consulté, Informé) • Évaluation de préparation aux changements organisationnels – Une bonne pratique consiste à établir une liste de contrôles pour vérifier si l’organisation satisfait les exigences de la transition en termes de rôles et de compétences. • Surveillance des progrès – Des recherches et des études doivent être menées régulièrement à différents niveaux de l’organisation pour vérifier l’efficacité et le succès d’un programme de transition des services. Utiliser les résultats de ces recherches pour définir les progrès réalisés quant à la transition. Cela servira également au personnel pour savoir qu’ils sont entendus et que leur contribution compte pour la transition. • Gérer les changements organisationnels dans le sourcing – Le sourcing des services informatiques est l’un des changements organisationnels les plus conséquents. Ils comportent de nombreuses conséquences pour le personnel qui doit être pris en compte et préparé attentivement, notamment : − le choc pour le personnel − les changements dans la façon dont l’entreprise et le fournisseur des services traitent l’un avec l’autre − le changement de lieu géographique et tous les risques associés

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

109

• Méthodes et techniques pour les changements organisationnels – Il existe de nombreuses méthodes, techniques et bonnes pratiques pour la gestion des changements, telles que “Les changements en huit étapes” de J.P. Kotter et la théorie de Rosabeth Moss Kanter sur les raisons pour lesquelles les personnes résistent à tout changement. Il est important de les utiliser au mieux.

Gestion des parties prenantes La gestion des parties prenantes est un facteur critique de succès essentiel dans la transition des services. C’est la raison pour laquelle une stratégie devrait être développée dans la phase de conception de services. Expliquer : • qui sont les parties prenante • quels sont leurs intérêts • quelle influence ont-elles • comment sont-elles incluses dans le projet ou le programme • quelles informations sont partagées avec elles Une carte des parties prenantes est un outil utile pour tracer les différents intérêts des parties prenantes. (Voir Figure 5.3).

Parties prenantes

Direction stratégique

Financier

Changements opérationnels

Interface avec les clients

Sécurité environnementale

Situation compétitive

Partenaire métier

Equipes projets

Clients Presse et média

Syndicats

Collaborateurs Organismes législatifs

Figure 5.3 Matrice des parties prenantes

Une analyse des parties prenantes aider à identifier les besoins et les intérêts des parties prenantes ainsi que l’influence finale et le pouvoir qu’elles auront lors de la transition. Enfin, il faut également prendre en compte le renouvellement des parties prenantes pendant le cycle de vie.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

110

Les fondamentaux de la gestion des services informatiques selon ITIL V3

5.5 Méthodes, techniques et outils La technologie jour un rôle important dans le support à la transition des services. Elle peut être divisée en deux catégories : • Les systèmes de gestion des services informatiques : − les référentiels de l’entreprise qui offrent des possibilités d’intégration pour faire le lien avec la CMDB et les autres outils − les outils du système, du réseau et de la gestion des applications − le tableau de bord des services et les outils de rédaction de rapports • La technologie et les outils ITSM spécifiques − la gestion des connaissances des services − les outils de collaboration, les systèmes de gestion des contenus et les outils de workflow − les outils pour l’exploitation, l’extraction et la transformation des données − les outils pour mesurer et informer − les outils pour tester (gérer les tests) − les outils de publication − la technologie de mise en production et de déploiement En outre, des outils spécialisés sont disponibles pour la gestion des changements, la gestion des configurations et la gestion des mises en production, tels que : • La gestion des configurations ; • Les outils pour contrôler la version ; • Les systèmes de gestion des documents ; • Les outils de conception ; • Les outils de distribution et d’installation ; • Les outils de construction et de déploiement. Une description plus élaborée des divers outils pour la transition des services et des processus sous-jacents sort du périmètre de cet ouvrage.

5.6 Mise en œuvre La mise en œuvre de la transition des services dans une situation greenfield (à partir de zéro) ne peut être réalisée qu’en établissant un nouveau fournisseur de services. La plupart des fournisseurs de services mettent l’accent sur l’amélioration de la transition des services (processus). Pour l’amélioration de la transition des services (processus), les cinq aspects suivants sont également importants : 1. Justification – les bénéfices d’une transition des services efficace ne sont pas toujours visibles pour le client. Collecter des preuves de dommages causés par une phase de transition des services inefficace peut justifier l’établissement ou l’amélioration de la transition des services. Prendre en considération des aspects tels que : les coûts de changements non réussis ou d’erreurs dans les services dans l’environnement de production qui auraient pu être évités si un processus correct de tests avait été utilisé. 2. Conception – les facteurs à prendre en compte lors de la conception de la transition des services sont : − les standards et les guides de bonnes pratiques auxquels la conception doit correspondre − les relations avec les autres services de support (gestion RH, télécom et gestion des

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: la transition des services

111

installetions), la gestion des projets et des programmes, les clients, les utilisateurs finaux et autres parties prenantes − le budget et les moyens 3. Introduction – l’expérience nous a enseigné qu’il n’est pas raisonnable d’appliquer une transition des services améliorée ou récemment mise en œuvre (et par conséquent qui n’a pas fait ses preuves) à des projets courants. Même dans le meilleur des cas, les avantages ne dépassent pas les inconvénients dûs aux perturbations du projet. 4. Aspects culturels – le seul fait de formaliser des procédures existantes comportera des changements culturels au sein de l’organisation. Il faut prendre cela en compte et ne pas seulement penser au personnel qui est directement concerné par la transition des services, mais considérer toutes les parties prenantes. 5. Risques et avantages – ne pas prendre de décision quant à l’introduction ou l’amélioration de la transition des services sans connaître les risques et les avantages que cela comporterait.

Relations avec les autres phases du cycle de vie Bien que cet ouvrage présente la transition des services comme une phase plus ou moins définie du cycle de vie, cela ne signifie pas qu’on puisse l’observer séparément. Sans les entrées de la conception de services et les sorties de l’exploitation de services, la transition des services n’a pas de raison d’être.

Flux d’expérience et support

Conception des Services

Transition des Services

Exploitation des Services

Figure 5.4 Flux de connaissances et d’expérience de et vers les autres phases du cycle de vie.

Il y a également les entrées et les sorties de connaissances et d’expérience depuis et vers la transition des services. Ce flux de connaissances et d’expérience fonctionne dans les deux sens : • A contre-courant – Par exemple, l’exploitation de services a des expériences pratiques en commun avec la transition des services quant aux comportements de services analogues dans l’environnement de production. Les expériences de la transition des services fournissent des indications pour l’évaluation de la conception. • Avec le courant – La conception de services fournit les connaissances nécessaires à la transition des services pour mettre en œuvre un changement (par ex. les différentes conceptions) et la transition des services fournit des expériences de production (par ex. dérivant des tests) qui pourront se révéler utiles pour la gestion quotidienne du service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

112

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Défis et facteurs critiques de succès Pour réussir une transition des services, plusieurs défis doivent être relevés, notamment : • Prendre en compte toutes les parties prenantes (et leurs différentes perspectives) et maintenir des relations qui pourraient se révéler importantes au sein de la transition des services. • Le manque d’harmonisation et d’intégration des processus et des disciplines qui influencent la transition des services. • Trouver un équilibre entre un environnement opérationnel stable et la capacité de répondre aux besoins changeants du business avec flexibilité. • Trouver un équilibre entre pragmatisme et bureaucratie. • Créer un environnement stimulant la normalisation et le partage de connaissances. • Créer une culture dans laquelle chacun répond à la coopération et aux changements culturels. • Garantir que la qualité des services correspond à la qualité du business. • Trouver un équilibre entre prendre des risques et éviter les risques ; cet équilibre doit correspondre à celui du business. • L’intégration avec les autres phases, processus et disciplines du cycle de vie. • Une définition claire des rôles et des responsabilités. • Disposer des outils corrects pour gérer l’infrastructure informatique. • Développer des systèmes, des outils, des processus et des procédures de bonne qualité pour la transition des services.

Risques Les risques potentiels de la transition des services sont : La démotivation du personnel suite aux changements de rôles et de responsabilités : • les dépenses non prévues • la résistance aux changements • le manque de partage de connaissances • une faible intégration entre les processus • un manque de maturité et d’intégration des systèmes et des outils Enfin, certaines circonstances de la transition des services présentent des risques supplémentaires, par exemple, suite à un manque d’argent ou de ressources, ou suite à des problèmes politiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 6

Phase de cycle de vie : l’exploitation des services 6.1 Introduction Des processus bien conçus et bien mis en œuvre ont peu de valeur si leur réalisation est désorganisée. Et les améliorations de services seront impossibles si les activités quotidiennes de mesure des performances et de collectes de données ne sont pas accomplies de façon systématique pendant l’exploitation des services.

Objectifs Les buts de l’exploitation des services sont de coordonner et d’accomplir les activités et les processus nécessaires à la fourniture et à la gestion des services pour les utilisateurs et les clients du business à un niveau convenu. L’exploitation des services est également responsable de la gestion des technologies nécessaires à la fourniture et au support des services.

Périmètre L’exploitation des services concerne la réalisation de toutes les activités nécessaires à la fourniture et au support des services. Elles comprennent : • les services • les processus de gestion des services • les technologies • les personnes.

Optimisation des performances de l’exploitation des services L’exploitation des services peut être améliorée de deux façons : • Amélioration incrémentale à long terme – elle repose sur la révision des performances et des sorties de tous les processus, de toutes les fonctions et des sorties à long terme de l’exploitation des services ; l’emploi de nouveaux outils ou les changements apportés au processus de conception en sont des exemples. • Amélioration actuelle à court terme des situations existantes dans le cadre des processus, des fonctions et des technologies d’exploitation des services – il s’agit de moindres changements qui sont mis en œuvre pour changer la signification fondamentale d’un processus ou d’une technologie ; la mise au point, la formation et le transfert de personnel en sont des exemples.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

114

Les fondamentaux de la gestion des services informatiques selon ITIL V3

6.2 Concepts de base L’exploitation des services est responsable de l’exécution des processus qui optimisent les coûts et la qualité des services dans le cycle de vie de la gestion des services. En tant que partie de l’organisation, l’exploitation des services doit garantir que le client (business) atteint ses buts. De plus, elle est responsable du fonctionnement efficace des composants soutenant le service.

Fonctions, groupes, équipes, départements et divisions Le livre sur l’exploitation des services fait référence, avec divers termes, à la manière dont les gens sont organisés pour accomplir des processus ou des activités : • Fonction – un concept logique qui s’applique aux personnes et aux actions automatisées qui accomplissent un processus délimité, une activité ou une combinaison de processus ou d’activités. • Groupe – un certain nombre de personnes qui sont d’une certaine manière similaires ; dans ce livre, groupe se réfère aux personnes qui accomplissent des activités similaires. • Équipe – un groupe plus formel de personnes travaillant ensemble pour accomplir un but commun ; par exemple, des équipes de projets ou des équipes pour le développement d’applications ; celles-ci ne se trouvent pas nécessairement au sein de la même structure organisationnelle. • Département – une structure organisationnelle formelle qui accomplit une série d’activités définies. • Division – se réfère à un certain nombre de départements regroupés, souvent situés dans un lieu géographique ou une ligne de produits. • Rôle – se réfère à une série de comportements ou d’actions qui sont accomplis dans un contexte spécifique par un individu, une équipe ou un groupe. Un responsable système peut, par exemple, assurer le rôle de gestionnaire des problèmes et un département de la gestion technique peut remplir le rôle de point d’observation technique.

Réalisation d’un équilibre dans l’exploitation des services Les procédures et les activités ont lieu dans un environnement qui change continuellement. Ceci peut engendrer un conflit entre le maintien de la situation courante et les réactions aux changements dans l’environnement business ou technique. En conséquence, l’un des rôles clés de l’exploitation des services est la gestion de ce conflit. Elle doit tenter d’établir un équilibre entre les priorités conflictuelles.

La vue interne du service informatique par opposition à la vue externe du business La vue que l’informatique est une partie des services informatiques (la vue externe du business) est opposée à l’idée que l’informatique est une série de composants technologiques (la vue interne du service informatique). Ceci est à l’origine du principal conflit dans toutes les phases du cycle de vie de la gestion des services. La vue externe de l’informatique concerne la manière dont les utilisateurs et les clients vivent les services. La vue interne de l’informatique concerne la manière dont les organisations informatiques gèrent les composants informatiques et les systèmes pour fournir les services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

115

Les deux approches sont nécessaires pour fournir des services. L’organisation, qui se focalise exclusivement sur les exigences du business sans réfléchir à la manière dont elle fournira les services, ne tiendra pas au final ses promesses. Une organisation qui se focalise exclusivement sur les systèmes internes sans réfléchir sur les services qu’elle soutient, va en fin de compte soutenir des services coûteux et peu utiles. L’enjeu est de trouver un équilibre entre ces deux extrêmes. (Voir Figure 6.1.). Une organisation ici est déséquilibrée et risque de ne pas répondre aux exigences du métier

Une organisation ici est bien équilibrée mais risque de ne pas répondre complètement aux exigences du métier

Focus extrême vers l’interne

Focus extrême vers l’externe

Figure 6.1  Réalisation d’un équilibre entre le foyer externe et interne

Stabilité par opposition à réactivité D’un côté, l’exploitation des services doit garantir que l’infrastructure informatique est stable et disponible. Au même moment, l’exploitation des services doit reconnaître que les exigences du business et de TI changent. Certains changements s’effectuent graduellement et peuvent être planifiés. Ils ne compromettent pas la stabilité. La fonctionnalité de la plateforme, la performance et l’architecture changeront sur de longues années. Cependant, certains changements peuvent surgir rapidement, parfois sous une pression extrême. Par exemple, un département business peut gagner un contrat qui exige subitement des services informatiques supplémentaires et plus de capacité. Afin de construire une organisation informatique dans laquelle stabilité et réactivité sont équilibrées, il faut : • Investir dans des technologies et des processus adaptables, par exemple, virtualisation de serveurs et technologie applicative. • Construire un solide processus de gestion des niveaux de services, qui soit actif dès la phase de conception des services jusqu’à la phase d’amélioration continue des services du cycle de vie de la gestion des services informatiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

116

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Encourager l’intégration entre la gestion des niveaux de services et les autres processus de conception des services, pour que les besoins du business correspondent aux activités informatiques opérationnelles et aux composants de l’infrastructure informatique. • Amorcer des changements dans le cycle de vie de la gestion des services informatiques le plus tôt possible ; ils peuvent être pris en compte dans les exigences fonctionnelles et managériales. • Impliquer l’informatique le plus tôt possible dans le processus de changement en cas de changements du business ; ce qui contribue à garantir l’extension, la cohérence et les services informatiques qui comportent les changements du business. • S’assurer que les équipes de l’exploitation des services fournissent une entrée pour la conception et l’amélioration de l’architecture et des services informatiques. • Mettre en œuvre et utiliser la gestion des niveaux de services pour éviter que le business et les gestionnaires de l’informatique négocient officieusement des accords.

Qualité de service par opposition aux coûts du service L’exploitation des services doit fournir des services informatiques aux clients et aux utilisateurs, continuellement et au niveau convenu. Au même moment, elle doit maintenir les coûts et l’utilisation des ressources à un niveau optimal. De nombreuses organisations subissent de fortes pressions pour améliorer la qualité du service, tout en limitant les coûts. Réussir un équilibre optimal entre les coûts et la qualité est une tâche clé de la gestion des services. Nombre d’organisations laissent ceci à l’équipe de l’exploitation des services, qui manquent d’autorité, mais la stratégie des services et la phase de conception des services sont plus appropriées pour cela. Des exigences des niveaux de services et une compréhension claire des buts et des dangers du business des services peuvent aider à garantir que le service est fourni à des coûts convenables.

Réactive par opposition à proactive Une organisation réactive ne fait rien tant qu’aucun stimulant externe ne la force à agir. Par exemple, elle ne développe une nouvelle application que lorsqu’un nouveau besoin du business l’exige. Une organisation proactive recherche toujours de nouvelles opportunités pour améliorer la situation actuelle. Généralement, un comportement proactif est regardé d’une manière positive, car il permet à l’organisation de garder un avantage compétitif dans un environnement qui ne cesse de changer. Une attitude trop active peut coûter cher et distraire le personnel. Pour un résultat optimal, il faut trouver un juste équilibre entre un comportement réactif et proactif.

Fourniture d’un service Tous les membres du personnel d’exploitation des services doivent être conscients qu’ils fournissent un service au business. Il ne faut pas les former uniquement à fournir et soutenir les services informatiques, mais il faut également leur apprendre l’attitude avec laquelle ils devront fournir ces services.

Faire participer l’équipe technique dans la conception et la transition Il est très important que le personnel d’exploitation des services soit associé à la conception de services et à la transition des services, et, si nécessaire, à la stratégie des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

117

L’une des méthodes pour établir un équilibre dans l’exploitation des services consiste à s’appuyer sur une série efficace de processus de conception des services. Ceci va conférer à la gestion des opérations informatiques : • Une définition claire des buts et des critères de performance des services informatiques. • Un lien entre les spécifications des services informatiques et les performances de l’infrastructure informatique. • Une définition des exigences de performances opérationnelles. • Une planification des services et de la technologie. • La capacité de modélisation de l’impact des changements sur les exigences de la technologie et du business. • Un modèle des coûts appropriés pour la revue du retour sur investissement (ROI), et les stratégies de diminution des coûts.

Santé opérationnelle Une organisation peut déterminer sa propre santé opérationnelle en isolant quelques caractéristiques vitales des dispositifs ou des services qui sont essentiels à la réalisation d’une fonction cruciale pour le business. Considérez, par exemple, l’utilisation d’une bande passante sur un segment du réseau, ou l’utilisation de la mémoire d’un serveur important. Si la valeur de ces caractéristiques se trouve dans la gamme normale du système, le système est sain, et n’exige aucune attention supplémentaire. Cependant, il est nécessaire de vérifier minutieusement les systèmes de temps en temps, pour chercher d’éventuels problèmes qui n’affectent pas directement les caractéristiques vitales. La santé opérationnelle dépend également de la faculté de prévenir les incidents et les problèmes. Investir pour cela dans une infrastructure fiable et bien entretenue. Créer une conception solide de la disponibilité et employer une gestion des problèmes proactive. Finalement, la santé opérationnelle dépend de la capacité d’identifier et de localiser efficacement les défauts qui se sont présentés, pour que leur impact sur le service soit faible. Ceci exige également une solide gestion des incidents et des problèmes.

Communication Les équipes et les départements informatiques, tout comme les utilisateurs, les clients internes et les équipes d’exploitation des services, doivent communiquer entre eux. Une bonne communication peut éviter des problèmes. Toute communication doit avoir un but ou un résultat particulier. Toutes les équipes et tous les départements doivent avoir une politique de communication claire. L’exploitation des services exige divers types de communication : • communication opérationnelle de routine • communication entre équipes • rapports sur la performance • communication pendant les projets • communication en cas de changements • communication en cas d’exceptions • communication en cas d’urgences

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

118

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• formation sur les processus nouveaux ou ajustés et conceptions de services • communication de la stratégie des services et de la conception des services avec les équipes d’exploitation des services

Documentation La gestion de l’exploitation des services et toutes les équipes et les départements de la gestion technique et des applications sont impliqués dans l’enregistrement et le maintien des documents suivants • manuels des processus pour tous ceux qui les concernent • manuels des procédures techniques • planification des documents tels que les plans de capacité et de disponibilité • mortefeuille des services • instructions de travail pour les outils de gestion des services, afin qu’ils soient • conformes aux exigences de la rédaction des rapports

6.3 Processus et autres activités Cette section accorde une attention particulière aux processus suivants : • gestion des événements • gestion des incidents • gestion des problèmes • satisfaction des demandes • gestion des accès • surveillance et contrôle • opérations informatiques En plus, il y a d’autres processus qui soutiennent ou seront exécutés lors de l’exploitation des services, mais qui sont gérés par d’autres phases du cycle de vie de la gestion des services : • gestion des changements • gestion de la capacité • gestion de la disponibilité • gestion financière • gestion des connaissances • gestion de la continuité des services informatiques (ITSCM) • reporting des services et mesure

Processus de gestion des évènements Un événement est un fait qui affecte la gestion de l’infrastructure informatique ou la fourniture d’un service informatique. En général, les événements sont des notifications générées par un service IT, un élément de configuration ou un outil de monitoring. Pour une exploitation des services efficace, l’organisation doit connaître l’état de son infrastructure, et être capable de trouver les déviations des performances normales ou prévues. Un bon suivi et des systèmes de contrôle fournissent des informations pour cela.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

119

La gestion des événements examine tous les événements qui se produisent dans l’infrastructure informatique afin de surveiller au quotidien les performances, et ce qui peut être automatisé pour identifier et escalader des situations imprévues. La gestion des événements s’applique à tout aspect de gestion des services qui doit être géré et qui peut être automatisé. Les activités les plus importantes du processus de gestion des événements sont : • événement en cours • notifications d’événements • détection des événements • filtration des événements • la portée des événements (classification des événements) • corrélation des événements • déclencheur • sélection de réponse • évaluation de l’action • clôture de l’événement Il n’y a pas d’enregistrement standard pour la gestion des événements, les métriques doivent être adaptées de manière appropriée.

Processus de gestion des incidents Le processus de gestion des incidents se concentre sur la restauration des défaillances des services le plus tôt possible pour les clients, pour que l’effet soit minimal sur le business. Les incidents peuvent être des défaillances, des questions ou des demandes. La gestion des incidents comprend tout évènement interrompant ou pouvant interrompre un service ; elle englobe donc aussi les événements rapportés par les clients, soit par l’intermédiaire d’un centre de services soit à travers divers outils. Le processus de gestion des incidents consiste en les étapes suivantes : • identifier • enregistrer/journaliser • catégorisation • prioriser • procéder au premier diagnostic • escalader • investigation et diagnostic • résoudre et restaurer • clôturer

Processus d’exécution des demandes L’exécution des demandes est le processus de prise en charge des demandes de service, où un processus séparé est utilisé pour lancer le besoin d’une requête. La plupart du temps, il concerne de petits changements qui passent d’abord par le centre de services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

120

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les buts du processus d’exécution des demandes sont : • Offrir aux utilisateurs un canal qui leur permet de lancer des demandes et d’obtenir des services standard ; pour cela, une approbation convenue et un processus de qualification sont necessaries. • Fournir des informations aux clients sur la disponibilité des services et la procédure pour les obtenir. • Fournir des composants de services standard (comme les licences et les supports de logiciels). • Fournir une aide quant aux informations générales, les réclamations ou les remarques. L’exécution des demandes se compose des activités, méthodes et techniques suivantes : • choix du menu • approbation financière • autres approbations • exécution • clôture

Processus de gestion des problèmes La gestion des problèmes est responsable de l’analyse et à la solution des causes des incidents. De plus, elle développe des activités proactives pour prévenir les accidents présents et futurs, utilisant ce qu’on appelle un sous processus des erreurs connues qui permet un diagnostic plus rapide quand de nouveaux incidents se produisent. La gestion des problèmes comprend toutes les activités nécessaires pour un diagnostic des causes sous-jacentes des incidents, et pour déterminer des solutions à ces problèmes. Elle doit aussi garantir que la solution est mise en œuvre au travers de procédures de contrôle appropriées (c’està-dire avec la gestion des changements et la gestion des mises en production). La gestion des problèmes se compose de deux processus importants : • Gestion des problèmes réactive • Gestion des problèmes proactive La gestion des problèmes réactive consiste en : • détection • journalisation • catégorisation • priorisation • investigation et diagnostic • détermination des solutions de contournement • identification d’une erreur connue • trouver une solution • clôture • revue des problèmes majeurs • fautes dans l’environnement du développement

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

121

Processus de la gestion des accès La gestion des accès est le processus permettant aux utilisateurs autorisés l’accès à un service, tout en limitant l’accès aux utilisateurs non autorisés. Dans certaines organisations, ceci est connu aussi comme gestion des droits ou des identités. La gestion des accès garantit que cet accès est toujours disponible aux moments convenus. Ceci est assuré par la gestion de la disponibilité. Une demande de services via le service d’assistance initialise la gestion des accès. La gestion des accès consiste en : • vérification • établissement les droits • surveillance de l’état d’identité • journalisation et traçabilité de l’accès • supprimer ou limiter les droits

Surveillance et contrôle La surveillance et le contrôle des services sont basés sur un cycle continuel de surveillance, de rédaction de rapports et d’adoption d’actions. Le cycle est critique pour la fourniture, le support et l’amélioration des services.

Boucle de contrôle Le modèle le plus connu pour la description du contrôle est la boucle de contrôle. Bien que ce soit un modèle simple, il a beaucoup d’applications complexes dans la gestion des services informatiques. Il y a deux types de boucles de contrôle : • systèmes de boucle ouvert • systèmes de boucle fermé Il y a deux niveaux de surveillance : • surveillance et contrôle internes • surveillance et contrôle externes En pratique, plusieurs organisations ont des combinaisons de surveillances internes et externes, mais dans de nombreux cas, elles ne sont pas liées. Il existe plusieurs types d’outils de surveillance ; la situation détermine quel type de surveillance est adopté.

Opérations informatiques Les opérations informatiques réalisent les activités opérationnelles quotidiennes nécessaires pour gérer l’infrastructure informatique.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

122

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Gestion de console / salle de contrôle La salle de contrôle est le point central de coordination qui contrôle les différents événements et activités opérationnelles de routine ; elle détecte les incidents et rapporte l’état des performances des composants technologiques. Une salle de contrôle rassemble tous les points d’observation critiques dans l’infrastructure informatique, de sorte qu’ils sont surveillés et contrôlés depuis un lieu central avec un minimum d’effort. La salle de contrôle combine plusieurs activités comme la gestion de console, la prise en charge des événements, l’ordonnancement des travaux et le support en dehors des horaires de travail. Dans certaines organisations, le centre de services est une partie de la salle de contrôle.

Ordonnancement des travaux (Job scheduling) Les opérations informatiques effectuent les routines standard, les requêtes ou les rapports que la gestion technique et les équipes de gestion des applications ont transféré comme partie du service ou comme partie des tâches quotidiennes de maintenance de routine.

Sauvegarde et restauration La sauvegarde et la restauration sont essentiellement un composant d’une continuité bien planifiée. La conception de services doit aider à garantir qu’il y a de bonnes stratégies de sauvegarde pour chaque service. La transition de services doit aider à garantir qu’elles sont testées correctement. L’essentiel pour une sauvegarde est de garantir que l’information soit restaurée.

Autres activités opérationnelles Le reste de cette section se concentre sur un certain nombre d’activités opérationnelles qui garantissent que la technologie correspond aux buts du service et du processus. Parfois ces activités sont décrites comme étant des processus, mais en réalité elles concernent une série d’activités techniques spécialisées qui aident à garantir que la technologie nécessaire à la fourniture du support aux services fonctionne de manière efficace et efficiente.

Gestion du mainframe Les mainframes sont la partie centrale de nombreux services, et leurs performances servent de référence pour les services et les attentes des utilisateurs et des clients. La manière dont les équipes de gestion de l’ordinateur principal sont organisées varie considérablement. Dans certaines organisations, une équipe de spécialistes est chargée de tous les aspects de la gestion de l’ordinateur principal. Pour d’autres organisations, ceci est effectué par plusieurs équipes ou départements.

Gestion du serveur et support La plupart des organisations utilisent des serveurs pour offrir de services flexibles et accessibles pour héberger les applications ou les bases de données, assurer les services client/serveur, le stockage, l’impression et la gestion des fichiers.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

123

L’équipe ou le département du serveur doit accomplir les procédures et activités suivantes : • support du le système d’exploitation • gestion des licences pour tous les éléments de configuration • troisième niveau d’assistance • conseil à l’approvisionnement • sécurité du système • définition et gestion de serveurs virtuels • capacité et performance

Gestion des réseaux Puisque la plupart des services informatiques sont dépendants de la connectivité, la gestion des réseaux est critique à la fourniture de services. Le personnel de l’exploitation des services accède à d’importants composants de service, via la gestion des réseaux. La gestion des réseaux est responsable de tous les réseaux locaux (LAN), réseaux métropolitains (MAN) et réseaux étendus (WAN) au sein d’une organisation.

Stockage et archivage Plusieurs services exigent le stockage des données pour une durée spécifique. Souvent, ces données sont mises à disposition en tant qu’archives distantes, quand elles ne sont plus nécessaires chaque jour. Et ce, non seulement par souci de conformité à la règlementation et la législation externes, mais aussi parce que les données sont précieuses pour l’organisation pour plusieurs raisons. Le stockage et l’archivage exigent non seulement une gestion des composants de l’infrastructure, mais aussi une politique qui indique l’endroit où les données doivent être stockées, pendant combien de temps, et qui peut y accéder.

Gestion des bases de données La gestion des bases de données doit travailler en étroite collaboration avec les équipes ou les départements de gestion des applications clefs. Dans certaines organisations, les fonctions peuvent être combinées ou rassemblées a sein d’une seule structure de gestion. La gestion des bases de données doit garantir une performance, une sécurité et une fonctionnalité optimales des bases de données. Les gestionnaires des bases de données ont, entre autres, les responsabilités suivantes : • La conception et la maintenance des standards des bases de données et des politiques. • La conception, la création et les tests des bases de données.

Gestion des services d’annuaire Un service d’annuaire est un logiciel spécialisé qui gère l’information sur les ressources disponibles sur un réseau, accessible aux utilisateurs. C’est la base pour offrir l’accès à ces ressources, et pour détecter et prévenir un accès non autorisé. Les services d’annuaire considèrent toute ressource comme un objet du serveur de l’annuaire, et les nomment. Chaque nom sera lié à une adresse d’un réseau de ressources, pour que les utilisateurs n’aient pas à se rappeler des adresses complexes et déroutantes.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

124

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Support des postes de travail Plusieurs utilisateurs ont l’accès aux services informatiques au moyen d’un ordinateur de bureau ou un ordinateur portable (poste de travail). Le support des postes de travail est responsable pour tous les ordinateurs de bureau et portables, des logiciels et des équipements périphériques dans une organisation. Les responsabilités spécifiques comprennent : • Politique et procédures du support de postes de travail – par exemple, politique de licence, utilisation personnelle des ordinateurs de bureaux et portables, etc. • Maintenance du poste de travail – comme la mise en œuvre des mises en production, mises à jour, modifications et correctifs ponctuels • Support concernant les problèmes de connectivité (ensemble avec la gestion des réseaux) – pour les travailleurs distants et le personnel du terrain.

Gestion du middleware Le middleware connecte les composants logiciels ou les intègre avec les applications et systèmes distribués ou autres. Le middleware permet un transfert efficace des données entre applications. C’est pour cette raison que le middleware est important pour les services qui dépendent de multiples applications ou ressources de données. Ceci est spécialement pertinent dans le contexte d’une Architecture Orientée Service (Service Oriented Architecture – SOA).

Gestion Internet/web Nombre d’organisations utilisent Internet pour leurs opérations business, et sont donc profondément dépendantes de la disponibilité et de la performance de leurs sites web. Dans ces cas, une équipe séparée de support Internet/web est nécessaire. L’équipe a, entre autres, les tâches suivantes : • la conception de l’architecture des services Internet et web • la spécification des standards pour le développement et la gestion d’applications basées sur le web, contenu, sites web et pages web ; ceci est généralement abordé lors de la conception des services • la maintenance de tout le développement web et des applications de gestion • le support des interfaces avec un système patrimonial ou un système central de traitement • la surveillance et la gestion des performances qui reposent sur le web, comme la simulation de l’expérience utilisateur, le benchmarking et la virtualisation

Gestion des installations et du centre informatique La gestion des installations se réfère à la gestion de l’environnement physique des opérations informatiques, qui sont généralement situés dans des centres informatiques ou salles d’informatique. Ceci est un sujet étendu et complexe. L’exploitation des services ne fournit qu’une vue générale des rôles et des activités les plus importants, et insiste sur le rôle de la gestion des installations dans la gestion d’un centre informatique. Stratégies d’un centre informatique (datacenter) La gestion d’un centre informatique est un travail plus vaste que l’organisation d’une salle ouverte où des groupes techniques installent et gèrent des équipements pour lesquels ils utilisent leur propres méthodes et procédures. Ceci exige une série de processus et de procédures et concerne tous les groupes informatiques à chaque phase du cycle de vie de la gestion de services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

125

informatiques. Les activités d’un centre informatique sont déterminées par des décisions de stratégie et de conception sur la gestion et le contrôle, et sont accomplies par les opérateurs.

Gestion de la sécurité informatique et exploitation des services La conception des services considère la gestion de la sécurité informatique comme processus. La gestion de la sécurité informatique est responsable d’élaborer une politique, des standards et des procédures qui garantissent la protection des actifs de l’organisation, les données, l’information et les services informatiques. Les équipes de l’exploitation des services jouent un rôle dans l’application des règlements de cette politique, des standards et procédures, et travaillent étroitement avec les équipes ou les départements qui sont responsable de la gestion de la sécurité informatique. Le rôle de l’équipe de l’exploitation des services consiste en : • Politique et rédactions des rapports – le personnel opérationnel vérifie les journaux des systèmes, les registres, les alertes des événements/surveillance, les détections de hacker et les rapports de failles de sécurité réelles ou potentielles ; pour cela, il travaille étroitement avec la gestion de la sécurité informatique ; c’est ainsi qu’un système d’équilibre et de vérification voit le jour, qui garantit une détection efficace et un contrôle des questions de sécurité. • Assistance technique – parfois le personnel de la sécurité informatique a besoin d’un soutien pour sa recherche d’incidents de sécurité, pour l’élaboration des rapports ou pour rassembler les preuves légales qui seront utilisées pour des actions disciplinaires ou des poursuites judiciaires. • Gestion de la sécurité opérationnelle – pour des raisons opérationnelles, le personnel technique nécessite l’accès à des zones techniques importantes (mots de passe système racine, entrée physique dans des centres informatiques des salles de communications, etc.) ; il est crucial que toutes ces activités soient vérifiées et enregistrées afin de pouvoir détecter et éviter tout évènement de sécurité. • Sélection et inspection – pour garantir que chaque membre du personnel de l’exploitation des services satisfait aux exigences de sécurité de l’organisation, les antécédents de chaque membre sont vérifiés ; l’antécédent des fournisseurs de services et des parties tierces peut également être vérifié d’un point de vue de la sécurité. • Formation et sensibilisation – Le personnel d’exploitation des services doit être formé régulièrement sur la politique de sécurité et les procédures d’une organisation ; cela permet de les sensibiliser ; cette formation doit inclure des détails sur les actions disciplinaires.

Amélioration de l’activité opérationnelle Le personnel d’exploitation des services doit rechercher continuellement des opportunités d’amélioration des processus afin d’augmenter la qualité des services ou l’efficacité de la fourniture des services. Ceci peut être effectué au moyen des activités suivantes : • automatiser les tâches manuelles • revoir les activités improvisées ou les activités • audits opérationnels • recourir à la gestion des incidents et problèmes • communiquer • éduquer et former

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

126

6.4 Organisation Fonctions Une fonction est un concept logique qui s’applique aux personnes et aux activités automatisées qui réalisent un processus délimité, une activité ou une combinaison de processus ou d’activités. Figure 6.2 montre les fonctions de l’exploitation des services nécessaires pour gérer un environnement informatique opérationnel stable.

Gestion des Opérations informatiques Centre de Services

Gestion Technique

Mainframe

Serveur

Réseau

Contrôle des Opérations informatiques Surveillance et Monitoring Job Scheduling Backup et Restore Imprimerie et Output Services Généraux Data Centers Sites de Secours Consolidation Contrats

Gestion des Applications

Applications financières

Applications RH

Applications métier

Stockage

Base de données

Service d’annuaire

Desktop

Middleware

Internet/Web

Figure 6.2  Fonctions de l’exploitation des services

Fonctions et activités En raison de leur caractère technique et de leur nature spéciale, certaines fonctions, équipes, groupes et départements sont souvent nommés d’après les activités qu’ils accomplissent. La gestion des réseaux est donc souvent effectuée par un département de gestion des réseaux. Cependant,

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

127

ceci n’est pas une règle absolue. Peu d’options sont disponibles lorsque des activités sont attribuées à une équipe ou un département : • Une activité peut être effectuée par plusieurs équipes ou departments. • Un département peut effectuer plusieurs activités. • Une activité peut être effectuée par des groupes.

Centre de services Un centre de services est une unité fonctionnelle composée de membres du personnel qui s’occupent de divers événements des services. Des demandes peuvent parvenir à travers des appels téléphoniques, par Internet ou comme événements d’infrastructure rapportés automatiquement. Le centre de services est une partie très importante du département informatique de l’organisation. Il devrait être le premier point de contact des utilisateurs informatiques, il traite toutes les requêtes des incidents et services. Souvent, le personnel utilise des outils logiciels pour enregistrer et gérer les événements.

Justification et rôle du centre de services De nombreuses organisations considèrent le centre de services comme la meilleure ressource pour un support de premier niveau des problèmes informatiques. Un centre de services comporte les avantages suivants : • Un service client amélioré, une perception client améliorée du service et une satisfaction améliorée du client. • Une accessibilité accrue en raison d’un point unique de contact, de communication et d’information • Les demandes des clients et des utilisateurs sont mieux et plus rapidement résolues • Coopération et communication améliorées. • Une meilleure focalisation sur le service et une approche du service proactive. • Réduction d’impact négatif pour le business. • Une meilleure gestion et un meilleur contrôle de l’infrastructure. • Une meilleure utilisation des ressources pour le support informatique, et une productivité accrue du personnel. • Davantage d’informations pertinentes pour la prise des decisions. • Il s’agit un bon premier poste pour le personnel informatique.

Objectifs du centre de services Le but principal du centre de services est de rétablir le service normal pour les utilisateurs le plus tôt possible. Ceci comporte la résolution d’erreurs techniques, la satisfaction des demandes de service ou la réponse à une question.

Structure organisationnelle d’un centre de services Il y a toutes sortes de manières de structurer un centre de services. La solution varie pour chaque organisation. Les options les plus importantes sont : • centre de services local • centre de services centralisé • centre de services virtuel

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

128

• service 24/7, dit follow the sun • groupes de centres de services spécialisés

Utilisateur

Utilisateur

Utilisateur

Utilisateur

Centre de Services

Gestion Technique

Gestion des Applications

Gestion des Opérations informatiques

Support externe, tiers

Exécution des requêtes

Figure 6.3  Un centre de services local

Centre de Service virtuel

Centre de Services Paris

Centre de Services San Fransisco Centre de Services Rio de Janeiro Centre de Service virtuel Centre de Services Sydney

Centre de Services Beijing

Centre de Services Londres

Système de Gestion de Connaissances de Services

Figure 6.4  Un centre de services virtuel

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

129

Personnel du centre de services Il est important de garantir la disponibilité du nombre correct des membres du personnel, de sorte que le centre de services puisse satisfaire les demandes du business à tout moment. Le nombre d’appels fluctue considérablement chaque jour et d’heure en heure. Lors de la planification, une organisation réussie prend en compte les périodes de pointe et les périodes creuses. Les niveaux et les compétences nécessaires pour le personnel du centre de services sont également à prendre en considération. Les temps convenus de résolution doivent être équilibrés par rapport à la complexité des systèmes supportés et à ce que le business est prêt à payer pour déterminer le niveau de compétences requis. La plupart du temps, l’approche optimale et la plus rentable est un support de premier niveau à travers le centre de services, qui enregistre les appels et escalade rapidement aux deuxième et troisième niveaux de groupes de support qui ont plus de compétence. D’ailleurs, le taux de résolution de premier niveau peut-être amélioré si on fournit du personnel avec une base de connaissances efficace, des scripts de diagnostic et des outils cohérents, ainsi qu’une prise de conscience et de la formation continue.

Métriques pour le centre de services Définir des métriques réalistes pour la revue des performances du centre de services à des points réguliers dans le temps. De cette façon la maturité, le rendement, l’efficacité et les opportunités peuvent être évalués, et les activités du centre de services améliorées. S’assurer que les métriques de performance du centre de services sont réalistes et choisies soigneusement. En plus des mesures dures des performances du centre de services, il est important aussi d’effectuer des mesures douces sous la forme d’enquêtes de satisfaction du client et de l’utilisateur. Est-ce que les utilisateurs pensent que les réponses à leurs appels sont correctes, est-ce que l’agent du centre de services a été courtois et professionnel ? L’utilisateur répondra plus volontiers à ce type de questions. .

Externalisation du centre de services La décision d’externaliser est un sujet stratégique pour les cadres dirigeants, et sera discutée en détail dans les domaines de la stratégie des services et la conception des services.

Gestion technique La gestion technique se réfère aux groupes, départements ou équipes qui offrent une expertise technique et une gestion générale de l’infrastructure informatique.

Le rôle de la gestion technique La gestion technique a un double rôle : • C’est le gardien de la connaissance et des compétences techniques relatives à la gestion de l’infrastructure informatique. Dans ce rôle, la gestion technique aide à garantir que les connaissances requises pour concevoir, tester, gérer et améliorer les services informatiques sont établies, développées et raffinées. • Elle prend soin des ressources réelles nécessaires à soutenir le cycle de vie de la gestion des services informatiques. Dans ce rôle, la gestion technique aide à garantir que les ressources sont formées et mises en œuvre efficacement, pour qu’elles puissent concevoir, construire,

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

130

Les fondamentaux de la gestion des services informatiques selon ITIL V3

transférer, traiter et améliorer la technologie requise qui est nécessaire pour fournir et soutenir les services informatiques. En assurant ces deux rôles, la gestion technique aide à garantir que l’organisation est capable d’accéder au type et au niveau des ressources humaines pour gérer la technologie, et par conséquent, satisfaire les buts du business. La gestion technique mène aussi les opérations informatiques tout en gérant les opérations technologiques et fournir une direction aux opérations informatiques.

Objectifs de la gestion technique La gestion technique assiste la planification, la mise en œuvre et la maintenance d’une structure technique stable pour soutenir les processus business de l’organisation. Ceci est effectué par : • Une configuration technique bien conçue et rentable. • L’utilisation des connaissances techniques pour maintenir l’infrastructure technique dans un état optimal. • L’utilisation effective des connaissances techniques, pour diagnostiquer et résoudre rapidement les défaillances.

Activités générales de la gestion technique La gestion technique est concernée par plusieurs activités générales, comme : • Démarrer les programmes de formation. • Concevoir et organiser des formations pour les utilisateurs, le centre de services et les autres groupes. • Rechercher et développer des solutions qui pourront aider à agrandir le portefeuille des services, ou être utilisées pour simplifier ou automatiser les opérations informatiques • Les mises en production qui sont souvent mises en œuvre avec l’assistance du personnel de la gestion technique.

Organisation de la gestion technique En général, la gestion technique n’est pas assurée par un département ou un groupe. Une ou plusieurs équipes de support technique sont nécessaires pour assurer la gestion technique et le support pour l’infrastructure informatique. La gestion des opérations informatiques consiste en un nombre de zones technologiques. Chaque zone exige une série de compétences spécifiques pour la gérer et l’exploiter. Certaines compétences sont liées entre elles, et peuvent être réalisées par des généralistes, tandis que d’autres s’appliquent spécialement à un composant, un système ou une plateforme.

Conception technique, maintenance technique et support La gestion technique est composée d’architectes techniques spécialisés, de concepteurs, de spécialistes de maintenance et de personnel de support.

Métrique pour la gestion technique Des métriques spécifiques pour la gestion technique dépendent largement de la technologie qui est en train d’être gérée. Quelques métriques générales comprennent :

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

131

• mesurer la sortie convenue • valeurs du processus • performance technologique • intervalle moyen entre les défaillances (MTBF) d’un équipement spécifique • mesure des activités de maintenance • développement de la formation et des compétences

Documentation de la gestion technique La documentation de la gestion technique consiste, entre autres, en : • documentation technique (manuels, manuels de gestion et d’administration, manuels utilisateur pour les CI) • calendriers de maintenance • inventaire des compétences

Gestion des opérations informatiques La gestion des opérations informatiques est la fonction responsable d’effectuer les activités opérationnelles quotidiennes. Elle garantit que le niveau convenu des services informatiques est réalisé pour le business. La gestion des opérations informatiques joue un double rôle : • Elle est responsable de la mise en œuvre des activités et des standards de performance qui ont été définies lors de la conception de services et ont été testées pendant la transition de service. Dans ce sens, le rôle de l’exploitation informatique se concentre sur le maintien du statu quo, au moyen duquel la stabilité de l’infrastructure informatique et la cohérence des services informatiques sont les tâches les plus importantes des opérations informatiques. • En même temps, la production informatique est une partie du processus qui crée de la valeur ajoutée au business et supporte la valeur en réseau (voir stratégie des services). Les opérations informatiques doivent être capables d’une adaptation continue aux exigences et demandes du business.

Objectifs de la gestion des opérations informatiques Les objectifs de la gestion de l’exploitation informatique sont : • Préserver la situation existante pour accomplir la stabilité dans les processus et activités de l’organisation. • Recherche et amélioration continues pour un meilleur service à moindre coût tout en maintenant la stabilité. • Application rapide des compétences opérationnelles pour analyser et résoudre les défaillances opérationnelles.

Organisation de la gestion des opérations informatiques La gestion de l’exploitation informatique est vue comme une fonction séparée, mais dans plusieurs cas, le personnel de la gestion technique et des applications contribue à cette fonction. L’affectation des activités dépend de la maturité de l’organisation.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

132

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Métriques de la gestion des opérations informatiques La gestion des opérations informatiques mesure la mise en œuvre réelle des activités et procédures définies, ainsi que l’exécution des activités des processus. Quelques exemples : • réalisation réussi des tâches planifiées • le nombre des exceptions aux activités et tâches planifiées • métrique des processus • métrique des activités de maintenance • métrique liée à la gestion des installations

Documentation de la gestion des opérations informatiques La gestion des opérations informatiques génère et utilise un certain nombre de documents, y compris : • Standard Operating Procedures (procédures standard d’exploitation – SOP) – une série de documents indiquant des instructions et des programmes d’activité détaillés pour chaque équipe, département ou groupe de gestion des opérations informatiques. • Journaux des opérations – chaque activité qui est effectuée comme faisant partie des opérations informatiques doit être enregistrée pour diverses raisons, afin de : − confirmer la réussite de tâches ou d’activités spécifiques − confirmer qu’un service informatique a été fourni comme convenu − fournir une base pour la gestion des problèmes pour rechercher la cause sous-jacente des incidents − fournir une base pour les rapports sur la performance des équipes et des départements des opérations informatiques. • Programmes et rapports des équipes – les documents qui illustrent les activités exactes qui doivent être effectuées dans un poste ; il y a aussi une liste indiquant toutes les dépendances et les séquences des activités ; il peut y avoir plus d’un programme opérationnel car chaque équipe dispose d’une version pour ses propres systèmes.

Gestion des applications La gestion des applications est responsable de la gestion des applications durant leurs cycles de vie. La fonction de la gestion des applications est exécutée par un département, un groupe ou une équipe qui est concernée par la gestion et le support des applications opérationnelles. La gestion des applications joue aussi un rôle dans la conception, le test et l’amélioration des applications qui font partie des services informatiques.

Rôle de la gestion des applications La gestion des applications est pour les applications ce que la gestion technique est pour l’infrastructure informatique. Elle joue un rôle dans toutes les applications, qu’elles soient acquises ou développées en interne. L’une des décisions les plus importantes auxquelles elle contribue est s’il y a lieu d’acheter une application ou plutôt, la développer en interne (discutée en détail dans la conception des services). Quand cette décision est prise, la gestion des applications joue un double rôle : • Elle est le gardien des connaissances et du savoir-faire pour la gestion des applications. • Elle fournit de réelles ressources pour le support du cycle de vie de la gestion des services informatiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

133

Deux autres rôles assurés par la gestion des applications sont : • Donner des conseils aux opérations informatiques sur la meilleure manière d’effectuer la gestion opérationnelle des applications. • Intégrer le cycle de vie de la gestion des applications avec le cycle de vie de la gestion des services informatiques.

Objectifs de la gestion des applications Les objectifs de la gestion des applications sont le support des processus business de l’organisation en déterminant les exigences fonctionnelles et managériales pour les applications. Un autre objectif est d’aider à la conception et à la mise en œuvre des applications, de les soutenir et de les améliorer.

Principes de la gestion des applications L’une des décisions les plus importantes dans la gestion des applications est s’il y a lieu de développer ou d’acheter une application qui comporte la fonctionnalité exigée. Le directeur technique (CTO), ou le groupe de pilotage, prend la décision finale, mais en agissant ainsi, tous les deux dépendent d’un nombre de sources d’information. Si le décideur veut qu’une une application soit développée, il/elle doit aussi décider s’il y a lieu de le faire développer par son personnel ou d’externaliser le développement. Ce point est détaillé dans le chapitre consacré à la conception des services.

Cycle de vie de la gestion des applications Le cycle de vie qui est suivi pour développer et gérer l’application passe par plusieurs étapes, comme le cycle de vie logiciel (SLC) et le cycle de vie de développement logiciel (SDLC). Ceux là sont surtout utilisés par les équipes de développement des applications et leurs gestionnaires de projets pour définir leur participation dans la conception, le développement, le test, la mise en œuvre et le support des applications. Des exemples de telles approches comprennent l’analyse des systèmes structurés, la méthodologie de conception (SSADM) et la méthode de développement des systèmes dynamiques (DSDM). Le développement et l’exploitation des applications font partie du même cycle de vie et doivent être prises en compte dans toutes les phases du cycle de vie des services, bien que le degré d’implication dépende de la phase du cycle de vie. Relation entre cycle de vie de la gestion des applications et cycle de vie de la gestion des services Le cycle de vie de la gestion des applications ne constitue pas une alternative pour le cycle de vie de la gestion des services. Les applications sont une partie des services et doivent être gérés comme telles. Néanmoins, les applications combinent de façon unique technologie et fonctionnalités. Ceci exige une attention particulière lors de chaque phase du cycle vie de la gestion des services. Pour chaque phase du cycle de vie de la gestion des applications sont attribués des objectifs propres et particuliers, des activités, des livrables et équipes. A chaque phase correspond également une responsabilité claire pour garantir que la production corresponde aux objectifs spécifiques du cycle de vie de la gestion des services. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

134

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Exigences

Optimiser

Concevoir

Exploiter

Construire

Déployer

Figure 6.5  Cycle de vie de la gestion des applications

Les phases de gestion des applications au sien d’exploitation des services sont : • exigences • conception • construction • déploiement • exploitation • optimisation Pendant la première phase, les exigences pour une nouvelle application sont collectées, qui reposent sur les besoins business de l’organisation. Il y a six types d’exigences pour une application, qu’elle soit développée en interne, externalisée ou achetée : • Exigences fonctionnelles – qu’est ce qui est nécessaire pour soutenir une certaine fonction business ? • Exigences de la gestion – se concentrent sur le besoin d’un service responsive, disponible et sécurisé, et concerne des questions comme le déploiement, la gestion des systèmes, et la sécurité. • Exigences d’utilisation – quels sont les besoins de l’utilisateur, et comment peut-on les satisfaire ? • Exigences d’architecture – surtout s’il exige un changement dans les standards d’architecture existants. • Exigences d’interface – où les dépendances se produisent entre les applications ou les outils existants et la nouvelle application. • Exigences du niveau de service – spécifier comment le service sera fourni, quelle doit être la qualité de la production et les autres aspects qualitatifs qui sont mesurés par l’utilisateur ou le client.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

135

La phase de conception traduira les exigences en spécifications. Conception de l’application et de l’environnement où le modèle opérationnel dans lequel l’application est exécutée aura lieu aussi durant la phase de conception. Des considérations architecturales pour la conception et l’exploitation sont les aspects les plus importants de cette phase, car elles pourront avoir un effet sur la structure et le contenu de l’application et du modèle opérationnel. La phase de construction prépare l’application et le modèle opérationnel pour le déploiement. Les composants de l’application sont codés et achetés, intégrés et testés. Le test n’est pas une phase séparée dans le cycle de vie bien qu’il s’agisse d’une activité séparée. Le test constitue une partie intégrale de la phase de développement et de lancement, comme validation de l’activité et production de ces phases. Ceci est connu comme support de début de vie (plus d’informations sur le sujet se trouve dans la transition des services). La phase de déploiement met en œuvre le modèle opérationnel et l’application. L’environnement informatique existant absorbe le modèle opérationnel et l’application est installée au dessus du modèle opérationnel. Ceci concerne les processus de mise en production et la gestion de déploiement qui sont décrits sous transition de services. Pendant la phase d’exploitation, l’organisation du service utilise l’application comme partie de fourniture des services demandés par le marché. La performance de l’application par rapport au service global est mesurée en continu en liaison aux niveaux de services et les facteurs d’influence les plus importants. La phase d’optimisation revoit et analyse les résultats de la métrique de performance du niveau de service. Les améliorations éventuelles sont discutées et les développements nécessaires sont initiés. Les deux stratégies principales comportent la maintenance et l’amélioration itérative des niveaux de service à des coûts plus bas. Ceci mène à un changement du cycle de vie d’une application ou à son retrait. Une bonne communication avec les utilisateurs est importante pendant cette phase.

Activités génériques de la gestion des applications Bien que la plupart des équipes et des départements de la gestion des applications soient consacrés à des applications spécifiques, ils partagent un certain nombre d’activités. Elles comprennent : • Identifier les connaissances nécessaires pour gérer les applications dans la phase d’exploitation des services. • Initialiser des programmes de formation pour développer les compétences pour de ressources appropriées de la gestion des applications et pour garder les rapports de formation pour ces resources. • Définir des standards pour la conception de nouvelles architectures et déterminer les architectures des applications pendant les processus de la stratégie des services. • Tester, concevoir et exécuter la fonctionnalité, les performances et le contrôle des services informatiques. • Définir les standards de la gestion des événements. • Définir, gérer et maintenir les attributs et les relations des CI d’application dans le système de gestion des configurations.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

136

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Organisation de la gestion des applications Bien que les départements, groupes et équipes de la gestion des applications accomplissent tous des fonctions similaires, chaque application a son ensemble d’exigences de gestion et opérationnelles. Les différences peuvent inclurent : • l’intention de l’application • la fonctionnalité de l’application • la plateforme sur laquelle l’application est exécutée • le type ou la marque de technologie qui est utilisée Les équipes et les départements de la gestion des applications sont principalement organisés sur la base des catégories des applications qu’ils supportent. Des exemples d’une organisation typique de la gestion des applications comprennent : • applications financières • applications RH • support de fabrication • support de ventes • centre d’appels et applications de marketing • applications spécifiques de business • applications informatiques • portails web Traditionnellement, le développement des applications et les équipes/départements de gestion ont fonctionné comme des unités autonomes. Chaque équipe gère son propre environnement à sa façon et ils ont tous une liaison privilégiée avec le business. Une attention récente sur des architectures orientées objet et orientées service, et la pression grandissante du marché qui demande une réponse plus rapide et une coopération améliorée, a rapproché ces deux mondes. Ceci exige une participation importante du personnel opérationnel du service dans la phase de conception des services.

Rôles et responsabilités de la gestion des applications • La gestion des applications a deux rôles : • Le gestionnaire des applications – assure la supervision et la responsabilité globale de la gestion et des décisions prises. • l’analyste/architecte des applications – est responsable des exigences pour que celles-ci correspondent aux spécifications de l’application.

Métriques de la gestion des applications Les métriques de la gestion des applications dépendent principalement de la façon dont les applications sont gérées, mais les métriques générales comprennent : • mesure des sorties convenues • métriques des processus • performance de l’application • mesure des activités de maintenance • Les équipes de la gestion des applications coopèrent étroitement avec les équipes de développement des applications et les métriques convenables sont utilisées pour mesurer ceci • développement de la formation et des compétences

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

137

Rôles et responsabilités de l’exploitation des services La clé d’une exploitation des services efficace est d’avoir une définition claire et nette des rôles et responsabilités.

Rôles du centre de services Les rôles suivants sont nécessaires pour le centre de services : • Gestionnaire du centre de services − Gère les activités du centre de services − Agit comme un point d’escalade pour les superviseurs − Prend en charge un service clientèle plus étendu − Signale aux gestionnaires supérieurs toute question pouvant avoir un impact considérable sur le business − Assiste aux réunions du comité consultatif (CAB) sur les changements − Est le responsable global du traitement des incidents et des demandes de service • Superviseur du centre de services − Garantit que l’effectif et les compétences sont maintenus ; − Est responsable d’élaborer des rapports de gestion ; − Est la personne centrale des appels difficiles ; • Analystes du centre de services − Fournissent le premier support en acceptant les appels et en traitant les incidents conséquents ou les demandes de service, utilisant les processus des incidents et d’exécution des demandes. • Super-utilisateurs − Utilisateurs du business qui agissent comme liens entre le business et l’informatique.

Rôles de la gestion technique Les rôles suivants sont nécessaires pour les domaines de la gestion technique : • Gestionnaires techniques/Leaders d’équipe − responsable du contrôle et de la prise de décision • Analystes techniques/Architectes − définir et maintenir les connaissances quant à la façon dont les systèmes sont reliés et s’assurer que les dépendances sont comprises • Opérateurs techniques − effectuer les tâches opérationnelles quotidiennes.

Rôles de la gestion des opérations informatiques Les rôles suivants sont nécessaires pour la gestion des opérations informatiques : • gestionnaire des opérations informatiques • leaders de poste • analystes des opérations informatiques • opérateurs informatiques

Rôles de la gestion des applications La gestion des applications exige des gestionnaires d’application et des leaders d’équipe. Ils ont la responsabilité globale du département des études.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

138

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les analystes et architectes d’application sont responsables de la combinaison entre les exigences du marché aux spécifications techniques.

Rôles de la gestion des événements Il n’est pas d’usage de nommer un gestionnaire des événements, mais il est pourtant important d’assurer que les procédures de gestion des événements soient coordonnées. En règle générale le centre de service n’est pas impliqué dans la gestion des événements mais dès qu’un événement est identifié comme un incident, le centre de services le transmettra au groupe de spécialistes appropriés. La gestion technique et la gestion des applications jouent un rôle important dans la gestion des événements. Par exemple, les équipes effectuent la gestion des événements des systèmes sous leur contrôle.

Rôles de la gestion des incidents Le gestionnaire des incidents est responsable de : • Conduire à l’efficacité et à l’efficience le processus de la gestion des incidents. • Produire des informations de gestion. • Gérer l’équipe de support d’incidents (premier niveau et deuxième niveau). • Surveiller l’efficacité de la gestion des incidents et faire des recommandations d’amélioration. • Gérer les incidents majeurs. • Développer et maintenir les systèmes de gestion des incidents. • Gérer les incidents efficacement en utilisant le support du premier, deuxième, et troisième niveau.

Rôles de l’exécution des requêtes Le traitement initial des requêtes est effectué par le personnel du centre de services et de gestion des incidents. L’exécution propre est affectée aux groupes opérationnels, départements concernés ou prestataires externes.

Rôles de la gestion des problèmes Une personne (ou, dans les organisations plus grandes, une équipe) doit être responsable pour la gestion des problèmes. Le gestionnaire des problèmes est responsable pour la coordination de toutes les activités de la gestion des problèmes et spécifiquement de : • Liaison avec tous les groupes de solutions des problèmes pour donner des solutions rapides aux problèmes dans le cadre des cibles SLA. • Propriété et protection de la base de données des erreurs connues. • Clôture formelle de tous les enregistrements de problèmes. • Liaison avec les fournisseurs et les autres parties pour s’assurer de la conformité aux obligations contractuelles. • Gérer, exécuter, documenter et planifier toutes (suivi) les activités liées aux revues des problèmes majeurs.

Rôle de la gestion des accès Puisque la gestion des accès est une exécution de la gestion de la sécurité et de la disponibilité, ces deux secteurs sont chargés de définir les rôles appropriés. Bien qu’aucun gestionnaire d’accès ne

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

139

soit généralement pas désigné par une organisation, il est important qu’il y ait un processus pour la gestion des prérogatives et des accès. Ce processus et la politique connexe sont généralement définis et préservés par la gestion de la sécurité d’information et exécutés par diverses fonctions de l’exploitation des services, comme le centre de services, la gestion technique et la gestion des applications.

Structures de l’organisation de l’exploitation des services Il y plusieurs façon d’organiser la fonction d’exploitation des services, et chaque organisation prendra ses propres décisions selon sa taille, sa position géographique, la culture et l’environnement du business.

Organisation par spécialisation technique Ce type d’organisation crée des départements selon la technologie, les compétences et les activités nécessaires pour gérer cette technologie. L’exploitation informatique suit la structure des départements de la gestion technique et de la gestion des applications. En conséquence, l’exploitation informatique est mise au point selon le programme opérationnel des départements de la gestion technique et de la gestion des applications, et tous les groupes doivent être définis pendant la phase de la conception de services.

Organisation par activité Ce type de structure organisationnelle se focalise sur le fait que des activités similaires sont effectuées sur toutes les technologies au sein d’une organisation. Ce qui signifie que les gens qui effectuent des activités similaires, indépendamment de la technologie, sont groupés ensemble, bien que des équipes peuvent exister au sein du département qui est concerné par une technologie spécifique, une application spécifique, etc.

Organiser pour gérer les processus Ce n’est pas une bonne idée de structurer l’ensemble de l’organisation selon les processus. Les processus sont utilisés pour éliminer l’effet silo des départements, et non pas pour créer des silos. Dans les organisations qui reposent sur les processus, les gens sont organisés en groupes ou départements qui effectuent ou gèrent un processus spécifique. Cependant, ce type de structure d’organisation ne doit être utilisé que si la gestion de l’exploitation informatique n’est pas uniquement responsable de l’exploitation informatique. Dans certaines organisations, l’exploitation informatique est également responsable pour la définition des SLA et la négociation des UC. Les départements qui reposent sur les processus ne sont efficaces que s’ils sont capables de coordonner l’exécution du processus à travers l’ensemble de l’organisation. Ce qui signifie que les départements qui reposent sur les processus ne sont considérés que si la gestion de l’exploitation informatique joue le rôle de propriétaire du processus pour des processus spécifiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

140

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Organiser une exploitation informatique par la géographie L’exploitation informatique peut être physiquement déployée, et dans certains cas chaque lieu doit être organisé selon son propre contexte. Cette structure est généralement utilisée dans les circonstances suivantes, quand : • Les centres informatiques (data centers) sont répartis géographiquement. • Diverses régions ou pays possèdent différentes technologies ou offrent différentes gammes de services. • Il y a différents modèles de business ou de structures d’organisation dans les diverses régions ; en d’autres termes, le business est décentralisée selon la situation géographique et chaque unité business est assez autonome. • La législation est différente pour chaque pays ou region. • Différents standards s’appliquent, en fonction du pays ou de la region. • Il y a des différences de cultures ou de langues parmi le personnel qui gère les services informatiques.

Structures d’organisation hybrides Il est peu probable que la gestion de l’exploitation informatique s’orientera vers une seule structure organisationnelle. La plupart des organisations utilisent une spécialisation technique combinée à des activités supplémentaires ou à des départements basés sur les processus : • Fonctions combinées – les départements de l’exploitation informatique, de la gestion technique et de la gestion des applications font partie de la même structure ; ceci arrive parfois quand tous les groupes sont installés dans le même centre informatique (data center), dans ces cas, le gestionnaire du centre informatique est responsable de la gestion technique, des applications et de la production informatique. • Structure combinée de gestion technique et des applications – certains business organisent leurs fonctions de la gestion technique et de la gestion des applications selon les systèmes ; ceci signifie que chaque département comporte des spécialistes d’applications et des spécialistes techniques d’infrastructure informatique qui gèrent les services en se basant sur une série de systèmes.

6.5 Méthodes, techniques et outils Les exigences les plus importantes pour l’exploitation des services sont : • une technologie intégrée de la gestion des services informatiques (ou jeux d’outils) • autosuffisance (exemple : FAQ sur une interface web) • flux des travaux ou gestion électronique de processus • un CMS intégré • technologie de détection, déploiement et licences • prise de main à distance • outils de diagnostic • capacités à rédiger des rapports • tableaux de bord • intégration à la gestion de services business

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

141

6.6 Mise en œuvre Guides de bonnes pratiques généraux de mise en œuvre pour l’exploitation des services :

Gérer les changements dans l’exploitation des services Le personnel de l’exploitation des services doit mettre en œuvre les changements sans impact négatif sur la stabilité des services informatiques offerts.

Déclencheurs des changements Plusieurs raisons peuvent déclencher un changement dans l’environnement de l’exploitation des services, y compris : • matériel ou logiciel nouveau ou mis à niveau • législation • composants obsolètes • amélioration des processus • changement dans les niveaux de service • nouveaux services

Évaluation des changements Faire participer l’exploitation des services à évaluer tous les changements aussitôt que possible. De cette façon, les problèmes opérationnels sont traités convenablement.

Déterminer et gérer les risques de l’exploitation des services Dans plusieurs cas, il est nécessaire que l’appréciation du risque soit menée rapidement, afin de prendre les mesures appropriées. Ceci est spécialement nécessaire pour les changements potentiels ou les erreurs connues, mais aussi en cas de défaillances, risques d’environnement, distributeurs, risques de sécurité et nouveaux clients qui ont besoin de support.

Personnel opérationnel dans la conception et la transition des services Le personnel d’exploitation des services doit participer activement dans les premières étapes de la conception et de la transition de services. Ceci garantira que les nouveaux services travaillent vraiment dans la pratique et qu’ils peuvent être supportés par le personnel de l’exploitation de service.

Planification et mise en œuvre des technologies de gestion de services Il y a plusieurs facteurs que les organisations doivent planifier avant et pendant la mise en œuvre des outils supports ITSM, comme : • licences • déploiement • vérification des capacités • synchronisation de la technologie/déploiement • le type d’introduction – le choix d’une introduction de type Big Bang ou une approche progressive Puis, nous discuterons de certains défis que l’exploitation des services doit surmonter.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

142

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Manque d’engagement parmi le personnel de développement et des projets Historiquement, une frontière existe entre le personnel d’exploitation des services et les développeurs de nouvelles applications, ou chargés de l’exécution des projets qui fournissent une nouvelle fonctionnalité dans un environnement opérationnel. Cette image est dommageable car les questions de l’exploitation des services sont mieux envisagées au début de nouveaux développements ou projets, quand il y a encore temps d’inclure ces facteurs dans les étapes de planification. La conception des services et la transition des services décrivent les étapes nécessaires à inclure tout au début dans les questions de la production informatique dans de nouveaux développements et projets.

Justifier la dépenses Il est souvent difficile de justifier les dépenses de l’exploitation des services car les fonds utilisés sont souvent considérés comme des coûts d’infrastructures. Or, dans la gestion de services informatiques, et plus particulièrement l’exploitation des services, plusieurs investissements génèrent des économies et montrent un ROI positif tout en améliorant la qualité de service.

Des défis pour les gestionnaires de l’exploitation des services Les gestionnaires de l’exploitation des services relèvent les défis suivants : • La conception des services a tendance à se concentrer sur un service pendant que l’exploitation des services vise à livrer et soutenir tous les services. • La conception de service sera exécutée en mode projet tandis que l’exploitation des services se focalise sur les processus de la gestion continue et les activités qui réapparaissent. • Les deux phases du cycle de vie possèdent différentes métriques qui encouragent la conception des services pour inclure le projet à temps, comme précisé et avec le budget prévu. Cependant, il est difficile de prédire à quoi ressemblera le service, et quels seront les coûts après le lancement, puis après un certain temps. Si le service ne fonctionne pas comme prévu, la gestion de l’exploitation informatique en sera responsable. • Une transition des services inefficace risque d’entraver la transition de la conception à la production. Les métriques constituent un autre ensemble de défis à relever. Chaque structure alternative introduira une combinaison différente d’articles qui sera facile ou bien difficile à mesurer. Une troisième série de défis concerne l’utilisation d’équipes virtuelles. Les structures de gestion traditionnelles hiérarchisées sont incapables de traiter la complexité et la diversité de la plupart des organisations. Les structures de la gestion des connaissances et de l’autorité d’élaboration deviennent de plus en plus importantes avec l’expansion des organisations et leur diversité. La stratégie des services va s’étendre davantage sur cela. L’un des plus importants défis des gestionnaires de l’exploitation des service est de trouver l’équilibre entre les nombreuses relations internes et externes. L’utilisation des réseaux, des

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’exploitation des services

143

partenariats et des modèles de services partagés est de plus en plus intense. Un gestionnaire d’exploitation des service doit investir dans les connaissances et les compétences de la gestion des relations afin de faire face à la complexité de ses défis.

Facteurs clé de succès Support de gestion Un support de la part du haut et du management intermédiaire est nécessaire pour toutes les activités et processus de la gestion des services informatiques, surtout dans l’exploitation des services. Il est crucial d’obtenir suffisamment de moyens financiers et des ressources. La hiérarchie doit aussi offrir un support visible lors du lancement de nouvelles initiatives d’exploitation des services. Le management intermédiaire doit aussi fournir le support et les actions nécessaires.

Support du business Il est aussi important que l’exploitation des services soit supportée par les unités du business. La réussite est au rendez-vous lorsque le personnel de l’exploitation des services fait participer le business dans toutes leurs activités, et montrent les succès et les échecs. Une consultation régulière du business est cruciale dans la construction d’une bonne relation et pour assurer un support ; l’exploitation des services est mieux placée pour accéder aux désirs et soucis du business. De plus, le business fournit un retour d’information sur les efforts de l’exploitation des services pour satisfaire les besoins du business.

Recrutement et rétention de personnel Un nombre suffisant de personnes avec les compétences adéquates, est crucial pour la réussite de l’exploitation des services. Considérer les défis suivants : • Les projets pour de nouveaux services précisent souvent les compétences requises, mais peuvent sous-estimer le nombre du personnel nécessaire et comment les compétences seront retenues. • Il peut y avoir un manque de personnel avec de solides connaissances de la gestion des services ; employer de bons techniciens est important, il doit y avoir aussi un certain nombre de gens qui ont des connaissances des problèmes technologiques et de services. • Un personnel avec à la fois une connaissance de la technologie et des services est relativement rare, il est souvent formé à cet effet ; il est important de les retenir en leur offrant un plan de carrière clair et une compensation solide. • On attribue souvent au personnel de nouvelles tâches assez rapidement, alors qu’ils sont extrêmement occupés par leur charge de travail courante. Les projets de gestion de services réussis nécessitent un investissement à court terme en des travailleurs temporaires.

Formation de la gestion de services Une bonne formation et une sensibilisation procurent de grands avantages. En plus d’améliorer le savoir-faire, elles peuvent générer de l’enthousiasme de la part des acteurs. Le personnel de l’exploitation des services doit être conscient des conséquences de leurs actions pour l’organisation. Une culture de la gestion de services doit être créée. La gestion de services ne réussira que si le personnel se focalise sur les objectifs généraux de la gestion de services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

144

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Outils appropriés De nombreux processus et activités de la gestion de services ne peuvent être exécutés de manière efficace sans des outils de support appropriés. La direction doit garantir que les moyens financiers pour ces outils font partie des budgets annuels, et doit soutenir leur acquisition, mise en œuvre et maintenance.

Validité des tests La qualité des services informatiques fournis par l’exploitation des services dépend de la qualité des systèmes et des composants qui sont livrés par l’environnement opérationnel. La qualité sera améliorée considérablement si un test solide et complet des nouveaux composants et des mises en production est effectué au moment opportun. En outre, la documentation doit être testée indépendamment pour garantir qu’elle soit complète et de qualité.

Mesure et rédaction des rapports Des accords clairs sont nécessaires concernant la manière dont les choses sont mesurées et rapportées ; des cibles claires seront affectées à tout le personnel , et les gestionnaires du business et de l’informatique seront capables d’évaluer rapidement et simplement si un progrès est accompli, et quel secteur mérite le plus d’attention.

Risques Considérer les risques suivants : • Perte de service – le plus grand risque encouru par l’exploitation des services est la perte de services informatiques essentiels avec un impact contreproductif sur le personnel, les clients et les finances. Dans les cas extrêmes, cette perte de service peut affecter la vie et la santé, notamment lorsque les services informatiques sont utilisés à des fins médicales et de sécurité. • Risques sur une exploitation des services réussie : – moyens financiers et ressources insuffisants – perte de dynamisme – perte de personnel important – pas de résistance aux changements – manque de support de gestion – si la conception échoue sur les exigences, une mise en œuvre réussie ne pourra obtenir les résultats requis ; ce qui implique une nouvelle conception – dans certaines organisations, la gestion de services est considérée comme suspecte par l’informatique et le business ; les avantages de la gestion de services doivent être clairs pour toutes les parties prenantes et les différentes attentes des clients ; ce problème peut être résolu par une gestion des niveaux de services claire et une communication soignée pendant la conception de services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 7

Phase de cycle de vie : l’amélioration continue des services 7.1 Introduction Les départements informatiques doivent continuellement aligner et réaligner leurs services sur les besoins business en identifiant et en réalisant des améliorations aux services TI, qui soutiennent le business. Pour la version 3 d’ITIL, cette approche est intégrée dans la phase d’amélioration continue des services du cycle de vie. En anglais on fait une différence entre ininterrompue et continue. • Ininterrompue (continuous) veut dire que l’organisation est impliquée dans une activité sans interruption ; les efforts sont constamment au même niveau ; par exemple, opération ininterrompue. • Continue (continual) signifie une succession d’activités proches l’une de l’autre ; de cette façon, on crée une séquence d’efforts visant à l’amélioration : amélioration continue. Un service informatique est créé par un certain nombre d’activités. La qualité de ces activités et le processus qui relie ces activités déterminent la qualité du service final. L’amélioration continue des services (Continual Service Improvement – CSI) se concentre sur les activités et les processus pour améliorer la qualité des services. Pour ce faire, elle utilise le cycle Plan-Do-CheckAct (Planifier-Faire-Vérifier-Agir) de Deming. Ce cycle recommande une phase de consolidation pour chaque amélioration, afin d’incorporer les nouvelles procédures au sein de l’organisation. Cela implique un schéma répétitif d’efforts d’amélioration à des niveaux différents d’intensité, au lieu d’un seul effort d’amélioration continu qui serait toujours au même niveau. C’est la raison pour laquelle le C de CSI, selon la version 3 d’ITIL, signifie continue (continual) et non pas ininterrompue (continuous). La mesure et l’analyse sont des opérations essentielles de CSI ; en mesurant, il est possible d’identifier les services qui sont rentables et les services qui peuvent être améliorés. Le processus d’amélioration CSI comporte un plan à sept étapes. Créer un plan d’amélioration des services (Service Improvement Plan – SIP) est une activité de Gestion de Niveaux des services (Service Level Management – SLM) qui s’inscrit dans le cadre du périmètre de CSI. La section “Processus et autres activités” couvre cette activité de façon plus approfondie. Ensuite, nous décrivons les

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

146

Les fondamentaux de la gestion des services informatiques selon ITIL V3

rôles qui exécutent les activités de base, suivies des méthodes, des techniques et des technologies qui les facilitent. Les interfaces entre la gestion des niveaux de services et le CSI sont abordés dans la dernière section concernant les interfaces avec les autres phases et les processus de gestion des services informatiques du cycle de vie ITIL. Tout d’abord, il convient d’éxaminer la justification du CSI et un certain nombre de concepts de base.

Buts et objectifs Le but de CSI est l’amélioration continue de l’efficacité et de l’efficience des services informatiques, leur permettant de mieux satisfaire les besoins du business. Cela implique à la fois d’atteindre et de dépasser les objectifs (efficacité) et d’obtenir ces objectifs au moindre coût possible (efficience). Pour augmenter l’efficacité, Il est possible, par exemple, de réduire le nombre d’erreurs dans un processus. Pour rendre un processus plus efficient, il est possible d’éliminer toute activité non nécessaire ou d’automatiser les opérations manuelles. En mesurant et en analysant les résultats du processus dans toutes les phases du cycle de vie des services, il est possible de déterminer les résultats qui sont structurellement pires que les autres. Ces derniers offrent la plus grande probabilité d’amélioration. CSI mesure et surveille principalement les aspects suivants : • Conformité du processus – l’application suit-elle les processus de gestion des services nouveaux ou modifiés et utilise-t-elle de nouveaux outils ? • Qualité – Les activités des différents processus satisfont-elles leurs objectifs ? • Performance – Quel est le degré d’efficacité du processus ? Quels sont les délais écoulés ? • Valeur business d’un processus – Le processus fait-il la différence ? Est-il efficace ? Comment le client juge-t-il le processus ? Les principaux objectifs de CSI sont : • Mesurer et analyser les réalisations de niveau de service en les comparant avec les besoins des accords sur les niveaux de service (SLA). • Recommander les améliorations dans toutes les phases du cycle de vie. • Introduire des activités qui augmentent la qualité, l’efficience, l’efficacité et la satisfaction du client des services et des processus de gestion des services informatiques. • Exploiter des services informatiques plus rentables sans renoncer à la satisfaction du client. • Utiliser des méthodes de gestion de la qualité appropriées à l’amélioration des activités.

Périmètre Le périmètre de CSI comporte quatre domaines importants : • la qualité générale de la gestion informatique • la mise au point continue des services informatiques selon les besoins actuels et futurs du business • la mise au point continue du portefeuille des services informatiques • la maturité des processus informatiques qui rendent possibles les services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

147

7.2 Concepts de base CSI et changement organisationnel Pour faire en sorte qu’une amélioration continue fasse partie intégrante de la culture organisationnelle, il faut souvent changer les mentalités. Ceci est un des aspects parmi les plus difficiles de CSI, et en réalité, de nombreux programmes de CSI échouent parce qu’ils ne réalisent pas (ou ne peuvent pas réaliser) les changements culturels. John P. Kotter, Professeur de Leadership à la Harvard Business School, a mené une étude sur plus de cent sociétés et a découvert huit étapes essentielles pour réussir des changements organisationnels : • Créer un sentiment d’urgence – par exemple, répondre à la question “Que ce passerait-il si on ne faisait rien ?” • Former une coalition dominante – un seul pionnier ne peut pas changer toute une organisation ; il faut une petite équipe clé, investie de l’autorité et des ressources nécessaires ; cette équipe peut grandir à mesure que le soutien croît. • Créer une vision – une bonne vision formule l’objectif et la raison d’être de CSI, fournit une direction, motive, coordonne et formule des objectifs pour la direction ; rend ces objectifs SMART (Spécifique, Mesurable, Approprié, Réaliste et à Temps) ; sans une vision, tout programme CSI deviendra vite un répertoire de projets sans bénéfices évidents pour l’organisation ; la vision doit être modélisée en fonction des besoins du client. • Communiquer la vision – chaque partie prenante doit connaître la vision, l’utilité que celle-ci représente pour elle et pourquoi CSI est nécessaire ; pour ce faire, il faut préparer un plan de communication et démontrer par l’exemple. • Autoriser les autres à intervenir sur la vision – éliminer les obstacles, donner une direction en définissant des objectifs clairs et en fournissant les ressources adaptées au personnel, comme des outils et de la formation ; créer la sécurité et la confiance en soi ; seulement alors, les personnes seront capables de devenir responsables de leur contribution au CSI : • Planifier et apporter des améliorations rapides gagnantes – évaluer ce qui peut être amélioré rapidement dans chaque service ou processus ; les planifier, les exécuter et les communiquer pour augmenter le soutien. • Consolider les améliorations et créer davantage de changements – des améliorations rapides et gagnantes convainquent et motivent ; des réussites à moyen terme créent de la confiance quant aux propres aptitudes d’amélioration de l’organisation et prévoient une série de procédures standard ; mais à long terme, une amélioration peut être considérée comme étant réussie uniquement si les personnes et les processus s’améliorent eux-mêmes continuellement. • Institutionnaliser les changements : – Engager du personnel ayant de l’expérience en termes de meilleures pratiques dans le domaine de la gestion informatique. – Donner des instructions de travail dès l’entrée en function. – Clarifier ce que sont les procedures. – Former le personnel pour la gestion informatique. – Faire coïncider les objectifs et les rapports aux demandes changeantes. – Définir les points d’action clairs dans les comptes-rendus. – Intégrer des nouvelles solutions informatiques et des projets de développement dans les processus existants.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

148

Combinées avec une gestion correcte des projets, ces étapes augmenteront remarquablement les chances de succès.

Le cycle PDCA De façon générale, une approche big bang ne débouche pas sur un programme d’améliorations réussi. C’est la raison pour laquelle, dans les années 1930, le statisticien américain Dr. W. Edward Deming a développé une approche progressive de l’amélioration : le cycle Plan-Do-Check-Act (Planifier-Faire-Vérifier-Agir – PDCA) : • Planifier- ce qu’Il faut faire, qui doit le faire et comment ? • Faire – exécuter les activités planifiées • Vérifier – vérifier si les activités génèrent les résultats escomptés • Agir – ajuster le plan en fonction des vérifications Ensuite, une phase de consolidation incorpore les changements au sein de l’organisation. Le cycle est également connu comme Roue de Deming (Figure 7.1). Direction de mouvement Qualité

Amélioration de qualité

Gestion de Qualité 1 Planifier 2 Faire 3 Vérifier 4 Agir

P

D

A

C

ITI ISO L /IE

C2

00

00

Assurance qualité

Temps

Figure 7.1  Le cycle PDCA

CSI utilise le cycle PDCA dans deux zones : • mise en œuvre du CSI • amélioration continue des services et des processus En premier lieu, nous discutons du cycle pour la mise en œuvre du CSI (Figure 7.2) : • Planifier le CSI : – déterminer le périmètre – déterminer les besoins que CSI doit satisfaire – établir les objectifs, par exemple, en utilisant une analyse des écarts

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

149

– définir les points d’action – déterminer les vérifications qu’il faut exécuter pendant la phase de vérification – déterminer les interfaces entre CSI et le reste du cycle de vie – déterminer les activités de processus qu’il faut introduire – fixer les rôles et les responsabilités (gestion) – établir les outils nécessaires pour soutenir et documenter les processus – sélectionner les méthodes et les techniques pour mesurer et documenter la qualité et l’efficacité des services et des processus • Mettre en œuvre de CSI (faire) : – déterminer le budget – documenter les rôles et les responsabilités – déterminer la politique, les plans et les procédures CSI, les maintenir, communiquer des informations les concernant, et former le personnel – fournir la surveillance, les analyses et les outils de rédaction de rapports – intégrer CSI dans la stratégie des services, la conception des services, la transition des services et l’exploitation des services • Surveiller, mesurer et évaluer CSI (vérifier) : – relater des accomplissements concernant les plans – évaluer la documentation – effectuer les évaluations du processus et les audits – formuler les propositions pour l’amélioration des processus • Mettre au point CSI (agir) : – introduire les améliorations – mettre au point la politique, les procédures, les rôles et les responsabilités

Exigences du métier

Amélioration continue de services (CSI) Responsabilités du management

Demande de nouveau service

Planifier CSI

Mesure de service et processus Exigences externes Exigences sécurité

Agir Modifier la CSI

Faire Mettre en place CSI Vérifier Surveiller, mesurer et réviser la CSI

Résultats métier Satisfaction client Processus plus efficaces et plus efficients Nouveaux services changés Amélioration de la Motivation des collaborateurs

Figure 7.2  Cycle PDCA pour l’amélioration des services, appliqué à l’introduction de CSI (conformément à ISO/IEC 20000).

Pendant la mise en œuvre de CSI, toutes les phases jouent un rôle important. La deuxième zone d’utilisation du cycle PDCA – l’amélioration continue des services et des processus – met

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

150

Les fondamentaux de la gestion des services informatiques selon ITIL V3

notamment l’accent sur les phases vérifier et agir. Toutefois, certaines activités des phases planifier et faire sont également concernées : • Planifier des initiatives d’améliorations : – fixer des objectifs et vérifier les méthodes – effectuer une analyse des écarts – déterminer les points d’action – Mettre en œuvre les initiatives d’amélioration : – éliminer toute éventuelle divergence – fournir une exécution sans heurt du processus • Surveiller, vérifier et évaluer les services et les processus : – comparer les vérifications après l’amélioration avec ceux d’avant l’amélioration et les objectifs définis dans la phase de planification – déterminer si les divergences doivent être éliminées – faire des recommandations pour l’amélioration telles que la mise au point du catalogue des services et les nouvelles vérifications SLA • Amélioration continue des services et des processus : – introduire les améliorations – déterminer les divergences qu’il faut aborder, cela constitue l’entrée de la phase de planification

Métrique, IPC et FCS Le gestionnaire des services informatiques a besoin de connaître si l’organisation dans son ensemble satisfait ses objectifs et les processus qui y contribuent. Une métrique mesure les résultats d’un processus ou d’une activité en déterminant si une certaine variable satisfait ses objectifs établis. Par exemple, une métrique mesure le nombre d’incidents résolus en une heure. Les métriques sont principalement interprétées à un niveau stratégique et tactique. Elles doivent décrire tous les processus dans une organisation. Trois types de métrique sont nécessaires pour la CSI : • Métrique de technologie – mesure la performance et la disponibilité des composants et des applications. • Métrique de processus – mesure la performance des processus de gestion des services ; ils sont issus des indicateurs clés de performance (Key Perfomance Indicator – KPI) qui, à leur tour, sont issus des facteurs clés de succès (Critical Succes Factor – CSF) ; voir également de la quatrième étape du processus de l’amélioration CSI : données du processus ; ces métriques contribuent à déterminer les opportunités d’amélioration pour chaque processus. • Métrique de service – les résultats du service final ; ils sont mesurés au moyen de la métrique des composants. Une métrique est issue de l’objectif établi par une organisation. Si le business considère la technologie de l’information comme un centre de coût, alors il voudra certainement abaisser les coûts. Si, par contre, il considère les TI comme un facilitateur de l’entreprise, l’objectif sera certainement de développer des services flexibles qui diminueront le temps de mise sur le marché. Le système de mesure ne devrait pas se concentrer uniquement sur un seul des trois aspects : argent, temps et qualité ; sinon, les deux autres aspects ne recevront pas assez d’attention.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

151

Les CSF sont définis pour la mission du business : ce sont des éléments essentiels pour accomplir la mission. Dans le sillage des CSF, les KPI déterminent la conformité de la qualité, de la performance, de la valeur et des processus. Ils peuvent être soit qualitatifs (comme la satisfaction des clients) ou quantitatifs (comme les coûts d’un incident d’imprimante). Au début du programme d’amélioration, deux ou trois KPI par CSF fournissent déjà beaucoup d’informations qui devront être traitées. Les KPI peuvent être étendus ou ajustés ultérieurement en fonction des nouveaux développements. Par exemple, si l’organisation a atteint ses objectifs ou quand de nouveaux processus de gestion de services sont introduits. Déterminer si le KPI est adapté en répondant à ces questions : • Atteignons-nous nos objectifs si nous accomplissons le KPI ? • Le KPI peut-il être interprété correctement ? Aide-t-il à déterminer l’action nécessaire ? • Qui a besoin de l’information ? Quand ? Avec quelle fréquence ? Avec quelle vitesse l’Information doit-elle être disponible ? • Le KPI est-il stable et précis ou est-il sujet aux influences externes non contrôlables ? • Avec quelle facilité peut-on ajuster le KPI aux nouveaux développements ? • Dans quelle mesure le KPI peut-il être mesuré maintenant ? Dans quelles circonstances ? • Qui collecte et analyse les mesures ? Qui est responsable des améliorations résultant de cette information ?

Données, Information, connaissance et sagesse (Data, Information, Knowledge, Wisdom – DIKW) La métrique fournit des données quantitatives, par exemple le centre de services enregistre 12 000 incidents par mois. CSI transforme ces données en informations qualitatives, un message reçu et compris qui est issu des données traitées et regroupées ; comme le fait que 18% des incidents signalés le sont par courrier électronique. En combinant les informations avec l’expérience, le contexte, l’interprétation et la réflexion, elles deviennent des connaissances, par exemple, puisque nous savons que l’organisation est un magasin en ligne, nous pouvons déterminer l’impact des incidents concernant l’utilisation du courrier électronique. Ce qui vient ensuite dans le CSI est la sagesse : être capable de faire les évaluations correctes et de prendre les décisions correctes en utilisant les données, les informations et les connaissances de la meilleure façon possible. Par exemple, puisque nous connaissons l’impact des incidents emails sur le client, nous pouvons décider de nous concentrer sur ce service car nous voulons améliorer notre service client. Le processus d’amélioration CSI focalise sur l’acquisition de la sagesse (voir la section “Processus et autres activités” et l’étape 6 du processus d’amélioration CSI concernant la rédaction de rapports sur les services).

Gouvernance La gouvernance guide les organisations et les contrôles. La corporate gouvernance fournit une gestion correcte, honnête, transparente et responsable d’une organisation. La gouvernance business aboutit à des performances correctes de l’entreprise. Ensemble ils sont connus sous la notion de gouvernance d’entreprise.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

152

Les fondamentaux de la gestion des services informatiques selon ITIL V3

La gouvernance informatique fait également partie de la gouvernance d’entreprise. Elle façonne les processus et la structure d’une organisation informatique et garantit qu’elle atteigne ses objectifs. La conformité aux nouvelles réglementations, telles que la loi américaine SarbanesOxley de 2002 (corporate gouvernance) et une, constante, meilleure performance à un moindre coût (gouvernance business) font également partie de la gouvernance informatique. Ces deux développements constituent les motivations principales pour le CSI : les fournisseurs des services informatiques doivent offrir leurs services selon une perspective stratégique plutôt que tactique. Les départements informatiques qui ne se focalisent que sur la technologie deviendront vite moins attrayants pour leur business. Un standard ITSM tel qu’ITIL aide à contrôler une organisation en la forgeant dans un système cohérent de rôles, de responsabilités, de processus, de politique et de contrôles.

Politiques et procédures CSI Les politiques CSI définissent des accords sur la mesure, la rédaction de rapports, les niveaux de service, les CSF, les KPI et les évaluations. Ceux-ci doivent être connus de toute l’organisation. La plupart des organisations évaluent chaque mois les résultats de processus. Il convient d’évaluer les nouveaux services plus souvent. Une organisation informatique devrait mettre en œuvre les politiques du CSI suivantes : • Toutes les initiatives d’amélioration doivent passer par le processus de gestion des changements. • Tous les groupes fonctionnels sont responsables des activités CSI. • Les rôles et les responsabilités CSI sont enregistrés et annoncés (voir la section “Organisation”).

7.3 Processus et autres activités Pour améliorer les services de l’organisation informatique, le CSI mesure le rendement de ces services. Les principales activités CSI sont : • Vérification : – vérifier les résultats des processus – examiner la satisfaction du client – évaluer la maturité du processus – vérifier si le personnel suit les guides de bonnes pratiques internes – analyser les données de mesure et les comparer avec les objectifs dans le SLA • Rédaction des rapports : – proposer des améliorations pour toutes les phases du cycle de vie – prendre en compte la pertinence des objectifs existants • Améliorer : – iIntroduire les activités qui augmentent la qualité, l’efficience, l’efficacité et la satisfaction du client des services – utiliser des méthodes de gestion de la qualité appropriées à l’amélioration des activités

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

153

Définir des directions à suivre L’effet de l’amélioration est fortement déterminé par la direction dans laquelle a lieu l’amélioration. “Vous pouvez me dire, s’il vous plait, la direction que je dois prendre en partant d’ici ?” “Cela dépend beaucoup de l’endroit où vous voulez aller,” répond le Chat. “Cela m’importe peu – ” dit Alice. “Alors la direction que vous prenez n’a pas d’importance non plus,” dit le Chat. “Pourvu que j’aille quelque part,” ajoute Alice en guise d’explication. “Oh, c’est chose sûre,” réplique le Chat, “si vous allez assez loin.” Source : Lewis Carroll, Alice au pays des merveilles, 1865 Sans une vision de la direction de l’amélioration, une amélioration n’a qu’une valeur limitée. C’est la raison pour laquelle, il faut déterminer une vision qui comprenne ses objectifs avant de commencer un processus d’amélioration. L’organisation doit continuellement évaluer sa voie d’amélioration actuelle (objectifs CSI) quant à la pertinence, l’achèvement et la faisabilité. Le modèle CSI en Figure 7.3 peut fournir un support.

Comment poursuivre cet élan?

Quelle est la vision?

Vision, mission, buts et objectifs du métier

Où sommes-nous actuellement?

Evaluation de base de référence

Où voulons-nous aller?

Objectifs mesurables

Comment y arriver?

Amélioration de services et processus

Y sommes-nous arrivés?

Mesures et métriques

Figure 7.3  Modèle CSI

Ce cycle continu consiste en six phases : 1. Déterminer la vision – Les TI ont un aperçu des objectifs de leur business, et avec le business, elle détermine une vision pour mettre au point la stratégie informatique selon la stratégie business ; ensemble elles formulent une mission, des buts et des objectifs.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

154

Les fondamentaux de la gestion des services informatiques selon ITIL V3

2. Enregistrer la situation actuelle – enregistrer le point de départ (la base de référence) du client, de l’organisation, des personnes, des processus et des technologies. 3. Déterminer les objectifs mesurables – fixer les priorités avec le client selon la vision : Que devons améliorer d’abord, quelle doit être l’ampleur de l’amélioration et quand doit-il finir ? 4. Planifier – rédiger un plan d’amélioration de service précis (SIP) y compris les actions pour obtenir la situation désirée 5. Vérifier – mesurer si les objectifs ont été atteints, et vérifier si les processus sont conformes 6. Garantir – incorporer les changements pour les maintenir. Annoncer ce plan à toute l’organisation pour créer une conscience, une compréhension, un enthousiasme et un support. Créer un dialogue avec l’organisation, communiquer régulièrement et rendre compte des accomplissements réels.

Mesure des services Pour déterminer la situation actuelle, la deuxième étape du modèle CSI doit mesurer une organisation. Cela veut dire que l’organisation doit être capable de déterminer la valeur de ses services par rapport aux niveaux de service convenus. Elle doit aussi être capable d’en rendre compte à ses clients. Cela implique que l’organisation sache quels composants, systèmes et applications sont responsables de telle ou telle partie d’un service. Mesurer une organisation met également en évidence la responsabilité du client lors d’une défaillance. Il en résulte que le client pourra accroître son niveau de connaissance par la formation. La section du processus d’amélioration CSI du chapitre 13 approfondit le sujet de la mesure des services.

Processus d’amélioration CSI Le processus d’amélioration CSI ou processus d’amélioration en 7 étapes décrit la manière de mesurer et de rendre compte de ces mesures. La phase de planification du CSI produit un plan d’amélioration de services (SIP). Si la gestion des niveaux de service découvre que quelque chose peut être amélioré, elle le passera au CSI. CSI peut alors formuler les activités qui porteront à l’amélioration. Pour l’exécution, CSI génère un SIP. Cela transforme “l’amélioration” en un processus TI avec des entrées, des activités, des sorties, des rôles et des rapports. CSI mesure et traite ces mesures dans un processus continu d’amélioration. Cela va de la mesure à l’amélioration en sept étapes : 1. Que doit-on mesurer ? 2. Que peut-on mesurer ? 3. Collecter les données (mesures) 4. Traiter les données 5. Analyser les données 6. Présenter et utiliser les informations 7. Mettre en œuvre des actions correctives

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

155

Le chapitre 13 contient une section élaborée sur le processus d’amélioration CSI.

Rapport des services Le rapport des services est le processus responsable de générer et fournir des rapports sur les résultats atteints et sur les développements en termes de niveaux de service. Une description complète du processus de rapport de service se trouve au chapitre 13.

7.4 Organisation Les activités de processus ne se limitent pas à une partie de l’organisation. C’est la raison pour laquelle le gestionnaire de processus doit croiser les rôles et les activités définis du processus avec le personnel existant. Pour cela, des définitions claires de la responsabilité et de l’obligation de rendre compte sont nécessaires, par exemple, en utilisant une matrice RACI (Responsable [Exécutant], Accountable [Responsable], Consulted [Consulté], Informed [Informé]).

Rôles et responsabilités CSI comprend les rôles permanents de la production, tels que le gestionnaire des services, le propriétaire des services et le propriétaire de processus, des analystes, et ainsi que les rôles temporaires de projets, tels que les gestionnaires de projet et les membres de l’équipe de projet. Le tableau 7.1 fournit une vue générale des activités et des rôles clés correspondants. Les rôles ne sont pas tous à temps plein. Faire un partage global et ajuster par la suite, si nécessaire. Activité clé Collecter des données en mesurant les résultats de services et processus de gestion de services et les comparer avec les bases de référence, buts, SLAs et benchmarks ; analyse des tendances Fixer des objectifs pour améliorations d’efficience et efficacité des coûts partout dans le cycle de vie des services Fixer des objectifs pour l’amélioration des services et utilisation des ressources Prendre en compte des exigences supplémentaires du business et de la sécurité Créer un SIP et mettre en place des améliorations Encourager les collaborateurs de proposer des améliorations Mesurer, faire du reporting, communiquer sur les initiatives d’amélioration Réviser les politiques, processus, procédures et plans selon besoin Assurer que toutes les actions privilégiées seront complétées et qu’elles ressortent les résultats prévus

Rôle clé Gestionnaire de Service, propriétaire de service, propriétaire de processus informatique

Gestionnaire de Service

Gestionnaire de Service, propriétaire de service, propriétaire de processus business Gestionnaire de Service, propriétaire de processus business Gestionnaire de Service, propriétaire de service, propriétaire de processus Gestionnaire de Service Gestionnaire de Service Gestionnaire de Service Gestionnaire de Service, propriétaire de service, propriétaire de processus informatique, propriétaire de processus business

Tableau 7.1  Activités clés et rôles à partager.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

156

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Le tableau 7.2 fournit une vue générale des rôles, des activités et des aptitudes nécessaires aux différentes étapes du processus d’amélioration CSI. étape 1. Définition de ce qu’il faut mesurer ?

Rôles Décideurs, tels le gestionnaire de service, propriétaire de service, gestionnaire des niveaux de service, gestionnaire d’amélioration continue (CSI), propriétaire de processus 2. Définition de Fournisseurs de service ce qu’on peut internes et externes qui mesurer ? connaissent les possibilités, comme le gestionnaire de service, propriétaire de service et le propriétaire de processus 3. Collecte Collaborateurs qui des données fournissent les services (mesurer) pendant les phases de Transition des Services et Exploitation des Services, comme le personnel du Centre de Services au quotidien 4. Process data Voir étape 3

types d’activité • Niveau élevé de management •  Variation élevée •  orienté action •  communicatif •  concentré sur l’avenir

•  intellectuel •  investigateur • variation moyenne à élevée •  orienté vers des buts • spécialisé en gestion du business •  standardisé •  routine (peu de variation) •  automatisé •  niveau administratif •  procédural

•  spécialisé •  structures •  automatisé •  variation moyenne •  procédural

5. Analyze data

Fournisseurs de service Voir étape 2 internes et externes qui connaissent les possibilités, comme le propriétaire de service et le propriétaire de processus et les analystes du métier et de l’IT. 6. présentation Fournisseurs de service Voir étape 1 et utilisation de internes et externes qui l’information connaissent les possibilités, (reporting) et les décideurs, comme le gestionnaire d’amélioration continue (CSI), gestionnaire de service, gestionnaire de niveaux de service, propriétaire de processus 7. mettre Voir étape 6 Voir étape 2 en œuvre des actions correctives

Compétences • compétences managériales •  communiquer • créer et utiliser des concepts • maîtriser des situations complexes et incertaines • éducation and expérience •  analyser •  modéliser •  attitude inventive •  éducation •  programme

•  exactitude •  précision •  formation appliquée •  expérience technique

• compétences numériques •  méthodique •  exactitude •  formation appliquée •  programmation • expérimenté avec outils informatiques Voir étape 2

Voir étape 1

Voir étape 2

Tableau 7.2  Rôles pour le processus d’amélioration CSI. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

157

Pour les examens “Fondamentaux” d’ITIL, il faut connaître les rôles imprimés en gras dans le tableau 7.2. Ces rôles seront abordés plus loin, sauf le rôle de gestionnaire des niveaux de service. La section sur “la conception des services” décrit ce rôle. La section “autres rôles” mentionne les autres rôles présents dans le CSI. La figure 7.4 montre la manière dont les différents rôles peuvent coopérer.

Gestionnaire de Services

Gestionnaire de Niveaux de Service

Client

Options d’amélioration

Options d’amélioration

improvement opportunities

Options d’amélioration

Propriétaire de Service

Options d’amélioration

Gestionnaire de l’Amélioration Continue des Services (CSI)

Reporting

Figure 7.4  Comment les différents rôles coopèrent de façon efficace.

Gestionnaire de service Le gestionnaire de service gère le développement, l’introduction et l’évaluation des produits ou services (nouveaux et existants). Il est responsable de : • l’atteinte de la stratégie et des objectifs de l’entreprise • benchmarking • gestion financière • gestion du client • gestion des fournisseurs • gestion de l’ensemble du cycle de vie • gestion des inventaires Le gestionnaire de service doit bien connaître les analyses du marché, être capable d’anticiper les nouveaux besoins du marché, formuler des programmes complexes, guider son personnel et vendre ses services.

Gestionnaire CSI Sans une responsabilité claire et équivoque, les améliorations n’ont pas lieu. Par conséquent, ce nouveau rôle est essentiel pour un programme d’amélioration réussi. Le gestionnaire CSI est responsable du CSI dans l’organisation. Il dirige les mesures, les analyses, les enquêtes et les rapports des tendances et initie les activités d’amélioration des services. De plus, il garantit aussi la disponibilité suffisante des ressources de support CSI. Il est responsable de : Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

158

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• développement du domaine CSI • conscience du CSI au sein de l’organisation • allouer les rôles CSI • identifier et présenter les opportunités d’amélioration à la direction et prioriser les améliorations avec le propriétaire du service • identifier les exigences surveillance avec le gestionnaire des niveaux de service • s’assurer que les bons outils de surveillance sont installés • créer les SIP avec le gestionnaire des niveaux de service • etablir des bases de référence afin de mesurer l’amélioration par rapport à une telle base • définir les CSF, les KPI et les métriques • utiliser les référentiels et les modèles de support • faire en sorte que la gestion des connaissances devienne une partie intégrante de la routine quotidienne • évaluer les données analysées Le gestionnaire de CSI doit être capable de conduire des projets au sein de toute l’organisation, de construire de bonnes relations avec le business et la direction informatique ; il doit avoir du flair pour les opportunités d’amélioration dans l’ensemble de l’entreprise et être capable de conseiller le personnel.

Propriétaire de service Il est crucial de nommer une personne responsable pour chaque service : il s’agit du propriétaire de service. Ce dernier est le point de contact central pour un service spécifique. Peu importe où se trouvent les composants, les processus ou les fonctions technologiques sous-jacents. Ses principales responsabilités sont : • posséder et représenter le service • comprendre les composants qui composent le service • mesurer la performance et la disponibilité • assister aux réunions du comité consultatif sur les changements (CAB) si ces changements concernent son service • se mettre avec le gestionnaire CSI pour identifier et prioriser les améliorations • participer aux évaluations internes et externes des services • maintenir la description de service dans le catalogue des services • participer à la négociation des SLA et des OLA

Propriétaire de processus Avoir un propriétaire est tout aussi crucial pour un processus que pour un service. Le propriétaire de processus garantit que l’organisation suit un processus. Il doit être un gestionnaire expérimenté ayant suffisamment de crédibilité, d’influence et d’autorité sur les départements de l’organisation qui font partie du processus. Le propriétaire de processus accomplit le rôle essentiel de Champion de Processus, est en charge de la conception, est l’avocat et le coach de son processus. Voir également la section “Conception des services”.

Autres rôles Les autres rôles qui sont importants pour la CSI : • Gestionnaire des connaissances de service – conçoit et maintient une stratégie de gestion des connaissances et la met en œuvre. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

159

• Analyste rapporteur – évalue et analyse les données, et identifie les tendances ; coopère souvent avec les rôles SLM (voir Conception des services) ; doit avoir de bonnes aptitudes à la communication car rédiger des rapports est un type de communication essentielle. • Responsable de communication – conçoit une stratégie de communication pour CSI.

7.5 Méthodes, techniques et outils Il existe plusieurs méthodes et techniques pour vérifier si les améliorations planifiées produisent réellement des améliorations mesurables. En général, une seule méthode ou technique ne suffit pas : vous devez trouver la meilleure combinaison pour votre organisation. Vérifier si les méthodes et les techniques choisies sont adaptées pour mesurer les résultats de vos processus, pour les documenter entièrement et pour instruire le personnel qui utilisera la méthode ou la technique.

Revue des mises en œuvre Pour déterminer si les améliorations produisent les effets désirés, il faut demander si la situation problématique d’origine a été réellement améliorée et comment l’organisation a planifié et mis en œuvre l’amélioration. Les questions suivantes aident dans ce contexte : Avons-nous évalué correctement la situation actuelle et avons-nous formulé correctement le problème ? • Avons-nous pris les bonnes décisions pour notre stratégie ? • Avons-nous adopté la stratégie de la bonne façon ? • Avons-nous formulé les bons objectifs CSI ? • Les objectifs ont-ils été atteints ? • Fournissons-nous les meilleurs services informatiques ? • Quelles leçons avons-nous appris et où en sommes-nous ?

Évaluations Une évaluation compare la performance d’un processus opérationnel par rapport à une performance standard. Cela peut être un accord dans un SLA, un standard de maturité ou une moyenne des entreprises (benchmark) dans la même industrie. Avec les évaluations, les organisations informatiques montrent leur engagement vers la maturité. Les évaluations sont très bien adaptées pour répondre à la question “Où en sommes-nous maintenant ?” et à déterminer l’étendue de l’écart avec “Où voulons-nous être ?”. Un référentiel d’évaluation de maturité bien mis au point aide à évaluer tous les aspects de l’environnement d’un processus, y compris les personnes, le processus et la technologie ainsi que les facteurs qui influencent l’efficacité d’un processus Ne pas oublier que le niveau désiré de performance ou de maturité d’un processus dépend de l’impact que le processus a sur les processus business du client. Il faut tout d’abord déterminer la relation entre les processus, les services informatiques, les systèmes et les composants informatiques. CSI peut évaluer les résultats d’efficacité et d’efficience séparément pour chaque composant. Cela aide à identifier les zones à améliorer.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

160

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Il est essentiel de définir clairement ce qui est évalué. Cela doit être basé sur les objectifs et l’utilisation attendue des rapports. Une évaluation peut avoir lieu sur trois niveaux : • Processus seul – évalue seulement les attributs d’un processus basé sur les principes généraux et les lignes de conduite du référentiel sur lequel est basé le processus en question • Personnes, processus et technologie – évalue également les aptitudes, rôles et talents des gestionnaires et du personnel qui participent au processus ; évalue également la technologie de support du processus. • Complète – évalue également la culture d’acceptation du processus, l’aptitude de l’organisation à établir une stratégie de processus, la définition d’une vision de l’environnement du processus, la structure et le fonctionnement de l’organisation processus, etc. Toutes ces évaluations seront comparées au modèle de maturité sélectionné. Les évaluations sont utiles dans : • La phase de planification – en tant que point de départ (base de référence) pour les performances du processus. • La phase de mise en œuvre (faire) – pour vérifier que les estimations sont correctes. • La phase de mesure (vérifier) – pour compléter l’équilibre et identifier d’éventuelles ultérieures améliorations. Avantages des évaluations : • Elles peuvent mesurer certaines parties d’un processus indépendamment du reste et déterminer l’impact de ce composant spécifique sur le reste du processus. • Elles peuvent être répétées. Inconvénients des évaluations : • Elles n’offrent qu’un instantané et ne donnent aucune indication quant à la dynamique culturelle d’une organisation. • Elles peuvent devenir un but en eux-mêmes au lieu d’un moyen. • Elles sont fortement consommatrices de main d’œuvre. • Les résultats sont encore dépendants des évaluateurs subjectifs et ne sont donc pas entièrement objectifs, même si les mesures le sont. Cela s’applique aussi bien aux évaluations internes et externes. Le tableau 7.3 donne une vue générale des avantages et des inconvénients sur ces deux axes.

Benchmark Un benchmark est un type spécifique d’évaluation : les organisations comparent leurs processus (parties des processus) avec la performance des mêmes types de processus qui sont habituellement reconnus comme meilleures pratiques. Cela peut se faire de quatre façons : • interne – avec un point de départ anticipé (base de référence) • interne – avec un autre système ou département • externe – avec les standards du secteur • externe – directement avec les organisations semblables ; toutefois, cela est seulement utile s’il y a suffisamment d’organisations semblables en termes d’environnement, de secteur et de localisation géographique.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

Évaluation Interne Avantages •  pas de consultants coûteux •  outils d’auto-évaluation disponibles gratuitement • promotion de la coopération et de la communication interne •  promotion du niveau de connaissance interne •  bon point de départ pour la CSI •  connaissance interne de l’environnement existant Évaluation Externe Avantages •  objectif, impartial •  expert avec connaissance d’ITIL • forte expérience avec plusieurs organisations informatiques •  compétences analytiques •  crédibilité •  impact minimal sur la fourniture des services

161

Désavantages •  moins impartial •  acceptation décevante des résultats •  possibilité de politique interne •  connaissance réduite des compétences •  intensive, demande beaucoup de travail

Désavantages •  coûts élevés •  risque au niveau de l’acceptation • connaissance réduite de l’environnement existant • une préparation insuffisante réduira l’efficacité

Table 7.3  Internal versus external assessment

La forme choisie dépend des objectifs du benchmark : • Mesures des coûts (prix) et de la performance des fournisseurs internes et externes. • Comparer les performances du processus avec les standards du secteur existants. • Comparer les performances financières de niveau général (high-level) avec les standards du secteur ou d’autres organisations. • Mesurer l’efficacité de l’obtention de la satisfaction client requise. Pour ce faire, il faut établir un profil organisationnel, qui s’appuie sur quatre composants clés : • Profil d’information de l’entreprise – informations de base telles que le périmètre et le type. • Actifs actuels – matériels tel que les postes de travail et les serveurs. • Meilleures pratiques actuelles – politique, procédures et outils ainsi que leur degré d’utilisation dans l’organisation. • Complexité – le nombre d’utilisateurs ainsi que la quantité et le type de technologie dans l’organisation. Dans tous les cas, un benchmark fournit les résultats suivants : • représente la performance • montre les écarts • montre le risque à ne pas combler ces écarts • aide à établir les priorités • aide à bien communiquer les informations De cette façon, les organisations découvrent si leurs processus sont rentables, s’ils satisfont aux besoins du client et leur degré d’efficacité par rapport à d’autres organisations. Elles prennent conscience du besoin d’amélioration et des façons de le faire, par exemple dans les domaines des économies d’échelle, efficience et efficacité. Le management peut alors agir sur cela. Idéalement, le benchmarking fait partie d’un cycle continu d’amélioration et se répète régulièrement.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

162

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Des études sur la performance de son organisation, comparée à d’autres départements ou organisations, prennent du temps. Établir une base de données des benchmarks et rendre visite aux organisations impliquent également des coûts. Le benchmark s’effectue en coopération avec : • le business • les utilisateurs ou les consommateurs • les fournisseurs de service internes • les fournisseurs de service externes • les utilisateurs du domaine public • les partenaires benchmark (autres organisations qui sont impliquées dans la comparaison). Il faut d’abord vérifier s’il n’y a pas de zones à problème. Utiliser les étapes du processus d’amélioration CSI, supportées par (certaines) des techniques suivantes : • discussions informelles avec le business, le personnel et les fournisseurs • groupes de focalisation • étude de marché • étude quantitative • enquêtes • analyses de reengineering • fichiers de processus • rapports de variation du contrôle qualité • analyse du ratio financier Voici deux formes spéciales de benchmarking : • Comparaison de la maturité du processus – à la différence d’une évaluation, il ne s’agit pas une comparaison avec un modèle de maturité, mais le niveau de maturité est comparé avec celui d’autres organisations, par exemple, CMMI peut servir comme modèle de maturité. • Coût total de possession (Total Cost of Ownership – TCOTM) – la somme de tous les coûts de la conception, de l’introduction, de l’exploitation et de l’amélioration des services (développé par Gartner) ; il est souvent utilisé pour comparer des services spécifiques au sein d’une organisation avec ceux d’une autre organisation.

Tableau de bord équilibré (Balanced Scorecard – BSC) Dans les années 1990, Kaplan et Norton ont développé le tableau de bord équilibré (BSC – Balanced Scorecard). Définissez un tableau de bord équilibré pour chaque domaine d’activité stratégique. Procédez attentivement : sélectionnez de deux à quatre objectifs. Il est ensuite possible de procéder en cascade pour les composants sous-jacents, tel que le centre de services. Après la mise en œuvre réussie, il faut continuer à mesurer régulièrement.

Analyse des écarts Cette analyse suit naturellement les évaluations et les benchmarks. Elle détermine où en est l’organisation en ce moment et mesure l’écart avec ce qui est attendu. De cette façon, il est possible de voir les nouvelles opportunités d’amélioration. Le modèle d’écart des services à la figure 7.5 montre les écarts ou les divergences possibles.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

163

Expériences vécues

Que voulons-nous?

Communications internes et externes, influences et facteurs d’influence

GAP 1 GAP 3

GAP 2 GAP 16

De quoi avons-nous besoin?

GAP 4

GAP 6

Qu'obtiendronsnous? Service prévu GAP 5

GAP 15 GAP 14

CLIENT FOURNISSEUR GAP 9

Exploitation des Services

Communications aux clients

ce que nous avons obtenu? Service perçu

GAP 13

Transition des Services GAP 12

GAP 8 Conception des Services

GAP 11

GAP 7 Stratégie des Services

GAP 10

Figure 7.5  Modèle d’écart des services (d’après SERVQUAL: Parasuraman, Zeithaml et Berry).

Les analyses d’écart peuvent être le résultat d’un benchmarking sur les enquêtes de maturité des services ou des processus. Elles peuvent être effectuées à un niveau stratégique, tactique ou opérationnel. Elle donne une vue générale de la quantité de ressources et d’argent qu’une organisation doit dépenser pour atteindre des objectifs spécifiques.

Analyse SWOT Une analyse SWOT s’intéresse aux Strengths (forces), Weaknesses (faiblesses), Opportunities (opportunités) et Threats (menaces) d’une organisation (composant) ou d’un projet. L’organisation répond alors aux questions suivantes : • Comment peut-on tirer profit des forces de l’organisation ? • Comment peut-on éliminer les points faibles ? • Comment peut-on utiliser les opportunités de façon optimale ? • Comment peut-on gérer et éliminer les menaces ? Établir l’objectif final avant d’effectuer une analyse SWOT. Observer les points forts qui contribuent à atteindre un objectif, les points faibles qui empêchent de l’atteindre, les conditions externes qui contribuent à promouvoir l’objectif et les conditions externes qui l’empêchent.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

164

Pour aboutir à un SWOT de toute l’organisation, il faut d’abord effectuer un SWOT pour chaque composant ou fonction de l’organisation, puis les intégrer dans un SWOT d’entreprise. Voit le tableau 7.4 pour des aspects de SWOT. Forces Potentielles •  compétences clés •  actifs financiers •  reconnu comme leader du marché •  management qui a fait ses preuves Opportunités Potentielles •  création de nouveaux groupes de clients • mise en place des compétences et connaissances pour des nouveaux produits

Faiblesses potentielles •  manque de direction stratégique claire •  locaux obsolètes •  faible gain économique •  faible visibilité sur la performance Menaces Potentiels •  concurrents avec prix plus bas •  croissance réduite de marché •  législation et règlementation couteuse

Tableau 7.4  Exemples d’aspects d’analyse SWOT.

Diagramme swimlane de Rummler-Brache Geary Rummler et Alan Brache ont introduit l’idée de représenter les relations entre les processus et les organisations ou départements au moyen de couloirs dans un diagramme swimlane (couloirs de natation) de Rummler-Brache. Ce diagramme représente les flux d’un processus : depuis le client jusqu’à la technologie en passant par le département (Figure 7.6). Les lignes horizontales divisent les organisations ou départements les uns des autres. Les activités et les décisions sont connectées par des flèches pour indiquer les flux.

Gestion des Changements

Intérieur

Lancer la RFC

Gestionnaire des Changements

Revoir la RFC

Comité Consultatif sur les Changements (CAB)

Examiner et Évaluer la RFC

Planifier des Mises à Jour

Coordonner le déploiement des changements

Autoriser la RFC

Figure 7.6  Diagramme swimlane de Rummler-Brache.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Passer en revue et clôturer l’enregistrement du changement

Phase de cycle de vie: l’amélioration continue des services

165

La ligne contenant ces composants indique chaque composant organisationnel responsable pour une activité ou décision. Cet instrument est très utile en tant qu’outil de communication avec la direction car il place tout le processus dans une structure reconnaissable des organisations.

Outils Le CSI nécessite différents types de logiciel pour soutenir, tester, surveiller et rendre compte des processus ITSM. Suivant l’évaluation de “où voulons-nous être ?” les exigences pour l’amélioration des outils sont prises en compte et documentées. Le besoin et le degré de sophistication des outils dépendent du besoin du business en services TI et d’une certaine façon de la taille de l’organisation. Dans tous les cas, les outils doivent surveiller et analyser les principaux composants d’un service, d’une façon qui soutienne le processus d’amélioration CSI. Ils peuvent aussi centraliser, automatiser et intégrer les processus clés. Cela produit ensuite de nouvelles données pour l’analyse des tendances. Les outils à utiliser pour CSI sont par exemple : • Suites de gestion des services informatiques – les outils et les suites qui sont compatibles avec le référentiel des processus ITIL fournissent des niveaux d’intégration importante entre les processus et les fichiers associés. Cette fonctionnalité crée une source riche de données et donc plein d’entrées pour CSI. Le système de gestion des configurations est à la base de l’intégration de toute fonctionnalité d’un outil de gestion des services TI et donc une source cruciale de données pour CSI. • Gestion des événements – les événements sont des messages de statut venant, par exemple, de serveurs et de systèmes ; les outils pour la gestion des événements évaluent ces rapports de statut pour l’impact et l’origine, et classent les rapports. • Gestion du système et du réseau – elle surveille les plates-formes technologiques ; les outils génèrent des messages d’erreur pour la gestion des événements, en fournissant des entrées pour la gestion de la performance. • Solution automatisée des incidents et des problèmes – écrans de détection proactifs, scripts préprogrammés qui réparent automatiquement la technologie ; ils enregistrent également les informations pour l’analyse d’éventuelles améliorations. • Gestion de la connaissance – bases de données avec description des incidents et des problèmes précédents avec leurs solutions ; mesure également l’utilisation de la base de données et l’efficacité de la solution. • Exécution des demandes de service (catalogue des services et diagramme de flux) – aide à définir un catalogue des services et automatise les demandes de service et leurs solutions. • Gestion de la performance – collecte les données concernant la disponibilité, la capacité et la performance pour développer des systèmes d’information de disponibilité et de capacité. • Surveillance de la performance des services et des applications – surveille le service de la technologie du point de vue utilisateur ; les outils mesurent les temps de disponibilité, de réaction et de transaction ainsi que l’efficacité des serveurs. • Outils d’analyse statistique – point de collecte central des données brutes des outils mentionnés ci-dessus ; les instruments d’analyse regroupent ces données de façon logique, en

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

166

Les fondamentaux de la gestion des services informatiques selon ITIL V3

créant des modèles pour les services actuels et en élaborant des modèles de prévision pour les services à venir. • Contrôle des versions de logiciel/gestion des configurations de logiciel – crée une vue générale de tous les logiciels pour l’environnement de développement, fournissant ainsi la bibliothèque des supports définitifs (DML). • Gestion des tests de logiciel – soutient les activités de test et de déploiement de la gestion des mise en production. • Gestion de la sécurité – protège contre les intrus et l’utilisation non autorisée ; tous les matériels et les logiciels placés sous la gestion de la sécurité doivent automatiquement signaler tout incident menaçant la sécurité. • Gestion des projets et du portefeuille – enregistre les nouvelles fonctionnalités ainsi que les services et les systèmes qu’elles soutiennent ; les outils contribuent à élaborer le portefeuille des services et à le mettre à jour ; ils peuvent également automatiser certains aspects organisationnels tels que les plans. • Gestion financière – surveille l’utilisation des ressources et des services pour le processus de facturation. • Décisionnel/rédaction de rapports – collecte des données venant des outils mentionnés cidessus, à partir desquelles il génère des informations importantes pour le business.

7.6 Mise en œuvre Avant de mettre en œuvre CSI, il faut s’assurer que : • Les rôles fondamentaux de gestionnaire CSI, propriétaire de service et analyste de reporting sont attributes. • Les surveillance et reporting sur les métriques technologiques sont en place. • Les réunions de revue internes sont programmes. • Une réunion de revue externe, qui suit les réunions internes, est programmée. La communication joue un rôle important dans n’importe quel projet d’amélioration de service. Un plan de communication est exigé qui doit prendre en compte les réponses et feedbacks de l’audience cible. Établir un plan de communication mentionnant toujours le messager, le message, le groupe destinataire, le moyen utilisé, la date et la fréquence de la communication, la méthode de communication et un mécanisme de feedback. CSI peut être mis en œuvre au moyen de différentes approches : • Approche du service – permet de définir les points concernant certains services ; et de créer un plan d’action avec le propriétaire du service : Comment allons-nous éliminer le point ? • Approche du cycle de vie – permet d’observer les résultats de plusieurs phases du cycle de vie et de chercher d’éventuelles améliorations. • Approche fonctionnelle – si de nombreux incidents se produisent au sein d’une fonction spécifique d’une organisation, par exemple dans le groupe serveur, il est possible d’éliminer autant de problèmes que possible dans ce groupe de fonctions au moyen d’un projet de test. Voir aussi “Concepts de base” : changement organisationnel et cycle PDCA.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

167

Dossier business Le dossier business doit clarifier l’utilité de procéder avec le CSI. Il doit indiquer ce qui changera réellement dans la situation future souhaitée par rapport à la situation de départ. A partir d’une base de référence établie, une organisation peut estimer ce que la situation présente fournit et coûte, et ce que l’amélioration de la situation fournira et coûtera. Formuler cela dans un langage que le business comprend. Dans tous les cas, il convient de répondre aux questions suivantes : • Où sommes-nous ? – déterminer les niveaux de service actuels. • Que voulons-nous ? – déterminer la vision, la mission, les buts et objectifs de la société. • De quoi avons-nous besoin ? – déterminer les services qui sont essentiels pour l’accomplissement de la mission et établir les priorités. • Que pouvons-nous dépenser ? – à l’aide de la gestion des niveaux de services (SLM) et de la gestion financière, établir le budget des services informatiques et voir les actions qui sont faisables. • Qu’obtiendrons-nous cela ? – déterminer les résultats requis en même temps que le business. • Qu’avons-nous obtenu ? – faire en sorte que l’exploitation de services surveille et rend compte des niveaux de service. • Est-ce que cela satisfait encore nos désirs/besoins ? – étudier avec le business les améliorations ultérieures possibles. Répondre à ces questions à l’aide de tests. La section “Processus et autres activités” aborde les tests en détail. Pour un dossier business, il est important d’avoir une vue générale des coûts et des bénéfices du CSI. De plus amples informations sur la mesure et l’estimation des coûts et des bénéfices du CSI sont disponibles dans la section “Processus et autres activités” et dans la section “Méthodes, techniques et outils”.

Coûts Quand une initiative d’amélioration est décidée, il faut toujours contrôler les coûts de construction, d’exploitation et de maintenance en cours. Notamment les coûts suivants : • main d’œuvre • formation • outils pour traiter les données des mesures • évaluations ou études benchmark • temps de la direction pour suivre les progrès • campagnes de communication pour développer la sensibilisation et changer la culture

Bénéfices Les résultats du plan d’amélioration d’un service peuvent être ventilés comme suit : • Améliorations – améliorations mesurables par rapport à la situation de départ ; • Bénéfices – profit résultant des améliorations (d’habitude exprimé en termes financiers) ; • Retour sur Investissement (ROI) – la différence entre les coûts et les bénéfices de l’amélioration ;

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

168

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Valeur sur investissement (VOI) – ROI, plus la valeur supplémentaire qui ne peut s’exprimer en argent ou qui ne devient claire qu’à long terme ; il est difficile de quantifier la valeur supplémentaire telle qu’une satisfaction client plus grande ; s’il y a suffisamment de chiffres réels, cela n’ajoute pas grand chose ; des notes explicatives en annexe de cette valeur qualitative sont plus utiles. Définir les bénéfices directs et indirects et prendre en compte chaque groupe de parties prenantes pour chaque niveau organisationnel. Définir les bénéfices qui sont mesurables. Mettre le business au premier rang. La valeur ajoutée pour le business peut vouloir dire : • délais plus courts sur le marché • intimité client • coûts de maintenance plus bas pour l’inventaire • part de marché plus grande CSI peut fournir les bénéfices suivants : • Au business : – Support plus fiable pour les processus business via la gestion des incidents, des problèmes et des changements. – Productivité accrue via l’augmentation de la qualité et de la disponibilité des services informatiques. – Le business sait ce qu’ils attendent du département informatique et ce que le département informatique attend d’eux. – Les procédures pour garantir la continuité du service informatique sont orientées vers les besoins du business. – Meilleure gestion des informations relatives aux processus business et aux services informatiques – Le département informatique dispose d’une connaissance accrue des processus business, pour faire en sorte de mieux répondre aux désirs du business. – Les projets qualité, les mises en production et les changements fonctionnent d’après le plan et fournissent la qualité convenue aux coûts convenus. – Le nombre des opportunités manquées est minimal. – Les relations entre le business et les TI sont meilleures. – La satisfaction du client est plus grande. • Financiers : – Services informatiques efficients. – Infrastructure et services informatiques rentables. – Réduction des coûts, par exemple en réduisant les coûts de mise en œuvre des changements et moins d’excès dans les processus et les équipements. – Les changements ont moins d’impact (financier) sur le business. – Les services satisfont les besoins mais ne les excèdent pas. – Meilleure ventilation des ressources, ainsi les dépenses pour la continuité des services informatiques sont proportionnelles à l’importance des processus business qu’elles soutiennent. – Structure des coûts ajustée pour correspondre aux besoins du business. – Coûts et risques minimum avec vérification que les réglementations sont appliquées.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

169

• Innovants : – Le développement de la technologie et des services est plus proactif via une meilleure information quant aux secteurs dans lesquels les changements apportent des profits. – Le département informatique réagit mieux aux changements de la demande du business ou du marché et aux nouvelles tendances. – Un business qui fait confiance à son fournisseur de services informatique ose penser grand. • Bénéfices internes pour l’organisation informatique – Plus le département Informatique est compétent, moins il y a de risques d’erreur. – Intégration des personnes et des processus. – Davantage de communication et de travail en équipe (avec le business aussi). – Un personnel plus productif et plus motive. – Des rôles et des responsabilités defines. – Des processus plus efficaces, une meilleure utilisation des resources. – Les TI reproduisent et augmentent les profits grâce à une maturité accrue des processus. – Une métrique et des rapports de gestion meilleurs via une approche structurée de mesure et de collecte de connaissances. – Une meilleure image et davantage de confiance dans les opportunités d’améliorations actuelles et futures. – Les services et les systèmes réalisent des objectifs faisables dans le cadre d’un calendrier réaliste. – Une meilleure direction des fournisseurs de services. – De meilleures relations avec le business. – Des coûts alignés sur les besoins du business.

Facteurs clés de succès Un facteur clé de succès est une condition nécessaire pour qu’un service ou un processus obtienne un bon résultat. Les facteurs clés de succès du CSI sont : • Nommer un gestionnaire CSI (voir également “Organisation”). • Adoption de CSI par toute l’organisation. • Participation constante et visible de la direction aux activités CSI, par exemple, en créant une vision et en la communiquant. • Critères clairs pour attribuer des priorités aux projets d’amélioration. • Adoption de l’approche du cycle de service. • Budgets adéquats. • Affectation des ressources. Ne pas ajouter l’effort d’amélioration comme une simple activité supplémentaire sur une liste des activités déjà chargée. • Technologie pour soutenir des activités d’amélioration. • Embrasser les processus de gestion des services et ne pas les adapter pour satisfaire les besoins et les intentions cachés.

Défis et risques L’introduction de CSI s’accompagne des défis et des risques suivants : • Manque d’engagement de la hiérarchie. • Mauvaises relations et communication entre les TI et le business. • Connaissance insuffisante de l’impact des TI sur le business et ses principaux processus. • Connaissance insuffisante des priorités du business.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

170

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Manque d’information, de surveillance et de mesure. • Ne pas utiliser les informations provenant des rapports. • Ressources, budget et délais insuffisants. • Immaturité des processus de gestion des services. • Gestion de la connaissance insuffisante ou manquante (voir également “Organisation”). • Vouloir tout changer tout de suite. • Résistance aux changements (culturels). • Objectifs, stratégies et politique business ou informatiques insuffisants. • Mauvaise gestion des fournisseurs. • Manque de test. • Outils trop complexes ou insuffisants. • Différence dans la technologie utilisée.

Interfaces CSI utilise beaucoup de données de l’ensemble du cycle de vie d’un service. Les informations résultant de ce processus, ainsi que les demandes du business, les spécifications techniques, les opportunités informatiques, le budget, les tendances et les réglementations, fournissent un aperçu des opportunités d’amélioration d’une organisation.

Gestion des niveaux de service (SLM) La gestion des niveaux de service est le processus le plus important pour CSI : elle discute avec le business des besoins de l’organisation informatique pour mesurer et pour définir les résultats. C’est la raison pour laquelle cette section commence par des informations concernant ce que SLM et CSI ont en commun. Pour de plus amples renseignements sur les processus de gestion des niveaux de service, consulter la section concernant la “Conception des services”. Après chaque phase du cycle de vie, il convient de tester si l’initiative d’amélioration a atteint ses buts. Cela peut se faire à l’aide de la Revue post-implémentation (Post Implementation Review – PIR) du processus de gestion des changements. Une vue générale des aspects communs entre CSI et les autres processus ITIL et les différentes phases du cycle de vie des services est fournie uniquement à partir de l’étape 3 car les étapes 1 et 2 du processus d’amélioration CSI traitent principalement de SLM et CSI. L’exploitation des services fournit également des informations sur ce qui peut être mesuré avant l’étape 2. À la lumière de CSI, l’objectif de SLM est de maintenir et d’améliorer la qualité des services informatiques. SLM remplit cet objectif en effectuant un cycle constant d’accords, de surveillance et de rédaction de rapports sur les niveaux de service informatique. Dans le processus d’amélioration CSI, SLM joue un rôle sur : • Ce que l’on devrait mesurer : – Consulter le business pour connaître leurs desires. • Ce que l’on peut mesurer : – Voir ce qui a déjà été mesuré. – Déterminer ce qui peut et devrait être mesuré (SLA, OLA et contrats de sous-traitance).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

171

• Collecter les données (mesures) : – Déterminer ce qui se passe avec les données : qui les reçoit, quelles analyses sont nécessaires ? • Traitement des données: – Évaluer les données traitées avec une perspective business. – Considérer la fréquence avec laquelle les données doivent être traitées et la fréquence des rapports dont elles font l’objet. • Analyse des données: – Comparer les réalisations de niveau de service (performance, résultats) avec les SLA. – Identifier et enregistrer les tendances pour faire apparaître des modèles. – Déterminer les besoins pour les SIP. – Le besoin d’ajuster les OLA existants ou les contrats de sous-traitance (UC). • Présenter les informations: – Rédiger des rapports et communiquer avec le business. – Organiser les évaluations de service internes et externs. – Aider à donner des priorités aux activités. • Mettre en œuvre des mesures correctives: – En collaboration avec la gestion des problèmes et de la disponibilité, établir un plan d’amélioration des services (SIP) et garantir que l’organisation applique ce plan. De cette façon, la gestion des niveaux de service (SLM) détermine ce que l’organisation mesure et surveille en collaboration avec le business ; elle rend compte de la performance et signale les nouvelles demandes du business. CSI utilise ces informations pour identifier et attribuer des priorités aux opportunités d’amélioration. Cela constitue les entrées les plus importantes pour le SIP (Figure 7.7). 7.7).

Accords sur les mesures et le reporting

Mesures et reporting sur les niveaux de services informatiques

Accords

Déterminer le budget

Activité

Données

Données, information

Identifier et prioriser des opportunités d’amélioration

Connaissance, sagesse

Budget

SIP (Programme d’amélioration de service)

Document

Figure 7.7  SLM et SIP

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

172

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Il est recommandé d’établir un budget annuel pour les SIP. SLM et CSI peuvent alors agir rapidement, ce qui mène à une attitude proactive. Si une organisation externalise les processus de fourniture des services, elle doit aussi négocier par rapport à CSI et l’inclure dans le SLA. Sinon, la partie responsable ne sera plus motivée à fournir davantage que ne le prévoit le contrat.

Surveiller et collecter les données (mesure, étape 3) Dans le cycle de vie des services, la stratégie des services surveille les effets des décisions prises concernant la stratégie, les standards, la politique et la conception. La conception des services surveille et collecte des informations concernant la conception et la modification des services ainsi que les processus de gestion des services. Cette phase teste également si les CSF et les KPI convenus avec le business sont mesurables et efficaces. Ils déterminent également ce qui devrait être mesuré et établissent des calendriers et des jalons pour ce faire. La transition des services surveille et mesure les données concernant l’utilisation réelle des services ainsi que les processus de gestion des services. Elle développe les procédures de surveillance et établit les critères de mesure pour l’après mise en œuvre. L’exploitation des services mesure la performance des services et des composants dans l’environnement de production. Une fois encore, cela constitue les entrées pour le processus d’amélioration CSI. Que pouvons-nous mesurer et que nous disent ces données ? Au delà de la gestion des niveaux de service (SLM), la gestion de la disponibilité joue également un rôle important dans l’étape 3. Ce processus: • Crée des métriques en consultation avec le business pour mesurer la disponibilité. • Détermine les outils qui sont nécessaires pour effectuer ces measures. • Surveille et mesure la performance de l’infrastructure et débloque suffisamment de ressources pour cela. • Fournit les données au CSI. • Met à jour les plans de disponibilité. La gestion de la capacité effectue également ces actions ; elle le fait afin de mesurer si l’organisation informatique peut fournir les services requis. Ce rôle peut se faire avec trois perspectives: • Gestion de la capacité business – répond aux questions “De quoi avons-nous besoin ?” et “Comment mesure-t-on cela ?” en collaboration avec le business. • Gestion de la capacité de service – répond à la question “De quoi avons-nous besoin ?” à partir de la perspective du client et fournit des informations au CSI. • Gestion de la capacité des composants – examine les composants d’un service et détermine ce qu’il faut mesurer pour surveiller le service dans son ensemble ; La gestion des Incidents définit les besoins de surveillance pour pister les événements et les incidents, de préférence, automatisés, avant qu’ils ne posent problème. Elle surveille également les temps de réaction, de réparation et de résolution ainsi que le nombre d’escalades. Par exemple,

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

173

le centre de services surveille le nombre de rapports, le temps moyen de réponse et le pourcentage d’appels provenant de personnes qui ont raccroché de façon prématurée. La gestion de la sécurité surveille et mesure la sécurité et enregistre les incidents et de problèmes liés à la sécurité. En dernier lieu, la gestion financière surveille et mesure les coûts et contrôle le budget. Elle contribue également à la rédaction de rapports concernant les initiatives d’amélioration des coûts et du ROI.

Traiter les données (étape 4) L’exploitation des services traite les données en groupes logiques. À l’Intérieur de ces groupes, la gestion de la disponibilité et la gestion de la capacité traitent les données au niveau des composants en ce qui concerne la disponibilité et la capacité. Elles travaillent ensemble avec SLM pour donner à ces données une perspective “bout en bout” et utilise le formulaire de rapport convenu pour ce faire. La gestion des Incidents et le centre de services vérifient et traitent les données concernant les incidents et les demandes de service ; les KPI en rendent compte. La gestion de la sécurité vérifie et traite les données concernant les incidents liés à la sécurité et en rend compte.

Analyser les données (étape 5) La stratégie des services analyse les tendances, observe si les stratégies, la politique et les standards introduits atteignent leur objectif et s’il y a des opportunités d’amélioration. La conception des services analyse les résultats des activités de conception et des projets ; elle recherche les tendances et les opportunités d’amélioration. Elle observe également si les CSF et les KPI établis dans l’étape 2 sont encore valables. L’exploitation des services analyse également les résultats, les tendances et les opportunités d’amélioration. Le processus d’exploitation des services le plus important pour CSI est la gestion des problèmes. Ce processus trouve les causes sous-jacentes des problèmes et ces dernières constituent des opportunités importantes d’amélioration. La gestion de la disponibilité analyse les performances et les tendances des composants et des données des services. Elle compare les données avec celles des mois, des trimestres et des années précédents. Elle observe également si les bonnes informations sont analysées et s’il faut des SIP. Elle utilise les techniques suivantes: • Analyse de l’impact de la défaillance d’un composant (Component Failure Impact Analysis – CFIA) – une matrice de disponibilité met à jour les composants qui sont stratégiquement importants pour chaque service et les rôles qu’ils jouent (Figure 7.8) ; pour cela, il faut une base de données de gestion des configurations (CMDB) bien organisée. • Analyse par arbre de pannes (Fault Tree Analysis – FTA)- détermine la chaîne d’événements pouvant conduire à la défaillance d’un service informatique (Figure 7.9). • Analyse des défaillances de service (Service Failure Analysis – SFA)- observe ce que les défaillances représentent pour le business (impact) et ce que le business attend et veut obtenir

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

174

avec l’amélioration de la disponibilité de bout-en-bout ; à partir de cela, CSI peut déterminer et attribuer des priorités aux améliorations. • Poste d’observation technique (Technical Observation Post – TOP) – une réunion du personnel informatique ayant différentes spécialisations pour discuter un aspect de la disponibilité ; • Cycle de vie détaillé d’un incident – calcule le Mean Time to Restore Service (temps moyen de restauration d’un service – MTRS) ; voir également la section sur la “Facilité de maintenance” dans la “Stratégie des services”. Elément de configuration PC, portable #1 PC, portable #2 Câble #1 Câble #2 Prise #1 Prise #2 Segment d’Ethernet Router Connexion WAN Router Segment NIC Serveur Logiciel système Application Base de données

Service A

Service B

B

B B B B X X X X X X X A B B B X

B X X X X X X A B B B X

X A B “”

= Défaillance, service indisponible = Configuration sans faille = Configuration sans faille avec redondance = Sans impact

Figure 7.8  Matrice CFIA

Service indisponible

En dehors des heures de service

Empêchement Service indisponible

OU

Réseau défaillant Ordinateur Application défaillant défaillante

ET

Connexion de base défaillante

Connexion de secours défaillante

Figure 7.9  Analyse par arbre de pannes

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Phase de cycle de vie: l’amélioration continue des services

175

La gestion de la capacité analyse quand et quels clients utilisent quels services, comment ils les utilisent et comment cela influence la performance d’un ou de plusieurs systèmes ou composants. Ceci fournit également des opportunités d’amélioration au CSI. Quand la gestion des problèmes est orientée vers la résolution de problèmes qui se sont déjà produits dans le passé, la gestion de la capacité essaie de prévenir les problèmes de façon proactive, par exemple, en augmentant la capacité de stockage à temps. Souvent cela se fait en reproduisant une situation dans un modèle et en posant ensuite un certain nombre de questions “Que se passerait-il si”. La gestion des incidents et le centre de services peuvent comparer les données collectées avec les résultats précédents et les niveaux de service convenus. Ils peuvent également proposer des SIP ou des actions correctives. La gestion de la sécurité utilise tous les autres processus pour trouver l’origine des incidents et des problèmes liés à la sécurité. Elle recherche les tendances et les améliorations possibles dans le domaine de la surveillance et vérifie si les stratégies produisent les résultats escomptés. Chaque initiative d’amélioration doit consulter la gestion de la continuité des services informatiques (ITSCM) pour s’assurer que les services informatiques ne sont pas mis à risque. La gestion des risques joue un rôle central en cela. Elle analyse les effets que peut avoir une amélioration, tandis qu’à son tour, CSI analyse les résultats des activités de la gestion des risques, pour découvrir des opportunités d’amélioration. Voir aussi la conception des services en ce qui concerne la gestion des risques.

Présentation et utilisation (étape 6) La stratégie des services présente les résultats, les tendances et les recommandations pour l’amélioration des stratégies, de la politique et des standards adoptés. La conception des services fait cela pour les améliorations de la conception et les activités des projets ; la transition des services et l’exploitation des services le fait pour le service et les processus de la gestion des services. La gestion de la disponibilité, la gestion de la capacité, la gestion des incidents, le centre de services, la gestion des problèmes et la gestion de la sécurité contribuent à créer des rapports et à attribuer des priorités aux actions correctives. La gestion des connaissances est très importante pour la présentation et l’utilisation des informations pour CSI. C’est la seule façon qu’a CSI d’obtenir une bonne vue générale de la connaissance de l’organisation et des opportunités d’amélioration. Ceci est également important pour garantir l’amélioration continue et assurer que toutes les connaissances et l’expérience collectées sont partagées et stockées. Pour de plus amples renseignements sur la gestion des connaissances, consulter également la section “Transition des services”.

Mettre en œuvre des actions correctives (étape 7) La gestion de la disponibilité, la gestion de la capacité, la gestion des incidents, le centre de services, la gestion des problèmes et la gestion de la sécurité effectuent des actions incrémentales ou correctives là où l’approbation du business n’est pas nécessaire.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

176

Les fondamentaux de la gestion des services informatiques selon ITIL V3

La gestion de la capacité peut également procéder en introduisant des mesures de la gestion de la demande pour influencer le comportement de son utilisateur final: • calcul des coûts • faire une politique pour l’utilisation correcte des services • communiquer les attentes • expliquer l’utilisation correcte • négocier les temps de maintenance • établir des restrictions d’utilisation, telles que limiter la quantité d’espace de stockage Comme pour tous les autres changements dans le cycle de vie, les changements CSI doivent passer par les processus de changement, de mise en production et de déploiement. CSI doit donc soumettre une demande de changement (RFC) avec la gestion des changements et mener une revue post-implémentation (PIR) après la mise en œuvre. Il convient également de prendre en compte la mise à jour de la CMDB au moyen de la gestion des configurations. Après cela, la gestion de la continuité des services informatiques (ITSCM) doit mettre à jour le plan de continuité.

Conclusion L’introduction du CSI n’est pas simple. Elle demande des efforts conscients tendant à l’amélioration continue dans le cadre de la culture et du comportement de l’organisation, ainsi qu’une attitude proactive. Dans un monde où les technologies changent très rapidement, une telle attitude proactive représente un grand défi ; après tout, nous sommes constamment contrôlés par les changements. Dans une situation d’externalisation croissante et de développement professionnel de la gestion des services informatiques, la qualité des services devient progressivement un facteur de distinction. Pour prendre le contrôle et pour atteindre le niveau de qualité désiré, il est préférable de travailler de façon proactive. CSI est ici essentiel. Comme pour nombre d’autres domaines, une approche progressive est requise. Ne pas commencer par une approche Big Bang, avec tous les processus en même temps, mais déterminer d’abord les zones à problèmes importants (par exemple à l’aide du SWOT) et choisir une approche correctement évaluée pour les améliorations. Reconnaître les facteurs critiques de succès est fondamental dans cette phase.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

PARTIE 2

FONCTIONS ET PROCESSUS

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 8

Introduction aux fonctions et aux processus 8.1 Introduction C’est au fournisseur de services informatiques de gérer, en interne, ses processus. Toutefois, une organisation qui essaie encore de contrôler ses processus se focalise sur elle-même. Une organisation qui se concentre sur la prise de contrôle de ses systèmes dans le but de fournir des services, se focalise encore sur elle-même. L’organisation n’est pas prête pour une focalisation externe, tant qu’elle ne contrôle pas ses services et qu’elle n’est pas capable de les modifier à la demande. Cette focalisation externe est nécessaire pour devenir une véritable organisation orientée client. Les niveaux de maturité varient en fonction des organisations. Par conséquent, les gestionnaires informatiques ont besoin d’orientations claires pour leurs domaines. La plupart des organisations travaillent actuellement à l’introduction d’une approche orientée processus ou orientée client, ou doivent s’y attacher. Le contrôle des processus constitue donc une étape essentielle vers une organisation orientée client mature. Depuis 10 ans, ITIL contribue fortement à la mise en place d’une organisation orientée processus. Ce développement a commencé dans l’Europe du nord-ouest. Il a également fait quelques émules sur la plupart des autres continents au cours des dernières années. Toutefois, à l’échelle globale, seul un petit nombre d’organisations ont réellement appliqué cette approche -, et un nombre encore plus petit a accompli de sérieux progrès. Alors que des projets de changement avaient été jugés nécessaires pour que les organisations évoluent vers une démarche orientée processus, ces efforts n’ont pas tous été couronnés de succès. Ces résultats nous mènent à la conclusion que la plupart des organisations doivent accéder à des informations correctes, et appliquer les meilleures pratiques des processus business des organisations informatiques. Heureusement, ces informations sont abondantes. Les livres d’ITIL version 2 fournissent une documentation très complète sur les processus les plus importants. La version 3 complète la précédente en proposant encore plus d’informations.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

180

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Le modèle par processus est au moins aussi important que les processus eux-mêmes. En effet, ceux-ci doivent être déployés en prenant en compte leurs relations de manière cohérente, pour obtenir l’effet souhaité. Il existe une grande variété de modèles de processus. Au cours de ces dernières années, l’expérience acquise avec ces processus et ces modèles de processus a généré une documentation très riche, que l’on retrouve dans de nombreux ouvrages, magazines et livres blancs, présentés à d’innombrables congrès.

8.2 Gestion des processus Le but de chaque organisation consiste à concrétiser sa vision, sa mission, sa stratégie, ses objectifs et sa politique, ce qui veut dire que des activités appropriées doivent être mises en œuvre. Par exemple, un restaurant achète des ingrédients frais, les chefs travaillent ensemble pour fournir des résultats cohérents, et il ne doit pas y avoir de grandes différences de style parmi le personnel de service. Un restaurant mérite trois étoiles uniquement s’il arrive à maintenir sur le long terme une même qualité élevée. Ce n’est pas toujours le cas : le personnel change, les clés du succès ne durent jamais, et souvent les chefs s’en vont pour ouvrir leur propre restaurant. Fournir une qualité élevée et cohérente signifie que diverses activités doivent être coordonnées : meilleurs sont le fonctionnement et l’efficience de la cuisine, meilleure sera la qualité de service fournie aux clients. Pour un restaurant, les activités appropriées incluent l’achat de légumes, la comptabilité, les commandes de matériel publicitaire, la réception des clients, le nettoyage des tables, l’épluchage des pommes de terre et la préparation le café. Une liste de ce genre ne suffit pas. Privée de structure, les acteurs de l’organisation oublieront vite les choses et la confusion règnera. Il vaut mieux, par conséquent, structurer les activités. De préférence, celles-ci seront organisées pour voir la contribution des divers groupes d’activités aux objectifs de l’entreprise, et leurs corrélations avec d’autres activités. De tels groupes d’activités sont appelés processus. Si la structure du processus d’une organisation est clairement décrite, elle mettra en évidence : • ce qui doit être fait • les entrées et les résultats attendus • comment mesurer si les processus donnent les résultats attendus • comment les résultats d’un processus affectent ceux d’un autre processus Les processus peuvent être définis de plusieurs façons. Selon les objectifs du propriétaire du processus, l’accent est mis sur certains aspects spécifiques. Par exemple, une description de processus très détaillée offre un niveau de contrôle élevé. Au contraire, une définition superficielle de processus montre en revanche que le propriétaire du processus ne s’est pas particulièrement inquiété de l’exécution des étapes. Une fois les processus définis, les rôles, les responsabilités et les personnes sont associées aux différents aspects, ce qui amène le processus au niveau d’une procédure.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction aux fonctions et aux processus

181

Processus Lorsque nous organisons les activités en processus, nous n’utilisons ni la répartition existante des tâches ni les divisions existantes en départements. Il s’agit d’un choix conscient. En optant pour une structure par processus, certaines activités de l’organisation ne sont pas coordonnées, d’autres sont en double, négligées ou deviennent inutiles. Un processus est un ensemble structuré d’activités conçu en vue d’atteindre un objectif spécifique. En revanche, l’accent est mis sur l’objectif du processus et les relations avec d’autres processus. Un processus est une série d’activités réalisées pour transformer une entrée en sortie, et fournir en dernier lieu un résultat. Les entrées traitent les ressources utilisées dans le processus. Les sorties décrivent les produits immédiats du processus, alors que le résultat indique les effets significatifs du processus sur le long terme. Les activités de contrôle permettent d’associer les entrées et les sorties de chacun des processus à des politiques et à des standards, pour fournir des informations sur les résultats devant être obtenus par le processus. Le contrôle régule les entrées et les traitements opérés par les processus lorsque les paramètres de traitement ou de sortie ne sont pas conformes aux standards et aux politiques. Il en résulte des chaînes de processus qui décrivent les entrées qui entrent dans l’organisation et pour quel résultat. Le contrôle surveille aussi des points dans ces chaînes afin de vérifier la qualité des produits et des services fournis par l’organisation. Les standards de sortie de chaque processus doivent être définis de manière à ce que la chaîne complète des processus, dans le modèle de processus, réponde aux objectifs de l’entreprise. Si la sortie d’un processus répond aux besoins définis, le processus est alors efficace et transforme correctement ses entrées en sorties. Pour être réellement efficace, on doit prendre en considération le résultat plutôt que la sortie seulement. Si les activités dans le processus sont également réalisées avec un effort et un coût minimaux, le processus est alors efficient. Il revient à la gestion du processus d’avoir recours à la planification et au contrôle pour garantir une exécution efficace et efficiente. Nous pouvons étudier chaque processus séparément afin d’optimiser sa qualité. Le propriétaire du processus est responsable des résultats du processus. Le gestionnaire du processus est responsable de la réalisation et de la structure du processus, qu’il communique au propriétaire de processus. Une combinaison logique d’activités permet de clarifier les différentes phases que vous pouvez contrôler. En reprenant l’exemple du restaurant, la responsabilité des achats se distingue de celle de la cuisine, de sorte que les chefs n’ont pas à acheter quoi que ce soit et peuvent se concentrer sur leurs activités de base. Le management de l’organisation fournit le contrôle sur la base de la qualité du processus, telles que le montrent les données des résultats de chaque processus. Dans de nombreux cas, les indicateurs de performance pertinents et les standards auront déjà fait l’objet d’un accord. Dans ce cas, le gestionnaire du processus peut contrôler au quotidien le processus. Le propriétaire du processus évalue les résultats par rapport aux indicateurs de performance et aux contrôles, pour vérifier que les résultats sont conformes au standard convenu. Sans indicateurs précis, il est

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

182

Les fondamentaux de la gestion des services informatiques selon ITIL V3

difficile pour un propriétaire de processus de déterminer si le processus est sous contrôle, et si les améliorations planifiées sont en cours de mise en œuvre. Les processus sont souvent décrits en utilisant des procédures et des instructions de travail. Une procédure est une manière spécifique de réaliser une activité ou un processus. Une procédure décrit le ´comment’, et peut aussi décrire le ´qui’ accomplit les activités. Une procédure peut inclure des étapes de processus différents. Une procédure peut varier en fonction de l’organisation. Un ensemble d’instructions de travail définit dans le détail la manière dont une ou plusieurs activités, appartenant à une procédure doivent être accomplies, à l’aide de la technologie ou d’autres ressources. Un processus est défini comme une série logique d’activités reliées entre elles, exécutées pour répondre à un objectif donné. Les processus sont composés de deux types d’activités : les activités destinées à la réalisation de l’objectif (activités opérationnelles ayant trait à la capacité de traitement) et les activités destinées à gérer ces dernières (activités de contrôle). Les activités de contrôle garantissent que les activités opérationnelles (workflow) sont accomplies à temps, dans le bon ordre, etc. (Par exemple, dans le traitement des changements, il est toujours garanti qu’un test est effectué avant la mise en production et non après.)

Processus et départements De nombreuses entreprises sont organisées de manière hiérarchique. Il existe des départements, responsables d’activités exécutées par un groupe d’employés. Plusieurs méthodes permettent de structurer des départements, par exemple, par client, par produit, par région ou par discipline. Les services informatiques dépendent généralement de plusieurs départements, clients ou disciplines. Par exemple, un service informatique, destiné à fournir à des utilisateurs un accès à un programme de comptabilité sur un ordinateur central, implique plusieurs disciplines. Ainsi, le centre de traitement de l’information permet l’accès au programme et à la base de données, le département des données et des télécommunications permet l’accès au centre de traitement de l’information, et une équipe de support bureautique fournit aux utilisateurs une interface d’accès à l’application. Les processus qui englobent plusieurs départements (ou équipes) peuvent vérifier la qualité d’un service en contrôlant des aspects particuliers de la qualité, tels que la disponibilité, la capacité, le coût et la stabilité. Un fournisseur de services cherchera à faire correspondre ces aspects de qualité avec les exigences du client. La structure de ce type de processus garantit que des informations correctes sont disponibles sur la fourniture de services, de sorte que la planification et le contrôle des services puissent être améliorés. La figure 8.1 montre un exemple simple de combinaisons d’activités dans un processus (indiqué par les lignes en tirets).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction aux fonctions et aux processus

183

Gestion informatique

Développement de logiciel

Entrées Opérations

Centre de Services Sorties

Organisation projet

Maintenance logicielle et Gestion des Applications

Bureautique et Télécommunications

Gestion du Réseau

Figure 8.1  Processus et départements

Gestion des services informatiques et processus La gestion des services informatiques est reconnue comme une approche orientée processus et services, appelée initialement gestion des technologies de l’information. Le passage de la gestion des infrastructures à celle des processus a tracé la voie pour l’expression Gestion des services informatiques, envisagée comme une discipline orientée processus et clients. Les processus devraient toujours afficher un objectif défini. L’objectif des processus de gestion des services informatiques est de contribuer à la qualité des services informatiques. La gestion de la qualité et le contrôle de processus font partie de l’organisation et de ses politiques. En utilisant une approche par processus, les meilleures pratiques pour la gestion des services informatiques décrivent la manière dont les services sont fournis, à l’aide de séries d’activités les plus efficaces et efficientes. Dans la version 3 d’ITIL, le cycle de vie des services repose sur ces descriptions de processus. La structure et l’attribution des tâches et des responsabilités, entre les fonctions et les départements, dépendent du type d’organisation. Ces structures varient beaucoup parmi les départements informatiques, et elles changent souvent. La description de la structure du processus fournit toutefois un point de référence commun qui change moins rapidement. Cela permet de maintenir la qualité des services informatiques pendant et après des réorganisations, ainsi que parmi les fournisseurs et les partenaires, lorsque ceux-ci changent. Cela rend les fournisseurs de services beaucoup moins sensibles aux changements d’organisation, et beaucoup plus souples : les fournisseurs de services peuvent continuellement adapter leur organisation aux conditions changeantes, sans modifier les bases de leurs processus. Ainsi, l’organisation peut rester ouverte pendant le travail de reconstruction. Néanmoins, la réalité peut poser certains problèmes pratiques, plus difficiles que ce que la théorie préconise. La mise en œuvre des meilleures définitions des processus d’un secteur économique permet aux fournisseurs de services informatiques de se concentrer sur leur business. Comme dans d’autres secteurs, les processus du monde informatique se ressemblent dans toutes les organisations de même nature. De nombreuses descriptions de processus, documentés dans ITIL, ont été reconnues comme étant les meilleures que l’industrie pouvait espérer adopter.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

184

Les fondamentaux de la gestion des services informatiques selon ITIL V3

8.3 Équipes, rôles et positions en ITSM (Gestion des Services Informatiques) La manière dont les organisations partagent les tâches, permettant d’accomplir des processus ou des activités, varie énormément. Les tâches peuvent être couvertes par des entités organisationnelles, tels que des groupes, des équipes, des départements ou des divisions. Ces entités organisationnelles sont ensuite gérées sous la forme d’organisations hiérarchiques par un gestionnaire de niveau, qui a un certain périmètre de contrôle et gère une ou plusieurs entités. Des organisations horizontales sont composées de relativement peu de couches au sein de cette hiérarchie. Les organisations peuvent aussi diviser les tâches dans un esprit d’égalité, comme c’est le cas notamment des organisations en réseau, dans lesquelles la coopération entre les diverses unités est dominante. À côté des organisations hiérarchiques, dont la gestion est effectuée par niveau, des organisations projets utilisent principalement des formes temporaires de coopération projet, alors que des organisations processus reposent essentiellement sur une méthode de travail convenue. Naturellement, ces types de gestion peuvent être combinés de nombreuses façons. Raison pour laquelle nous voyons un grand nombre de configurations organisationnelles uniques. Les organisations se distinguent les unes des autres, notamment en fonction de leur type d’organisation. Une organisation hiérarchique a du personnel principalement composé de gestionnaires seniors. Une organisation orientée processus a du personnel responsable de processus. En fonction du mode de management, par processus, par niveau ou projet, le personnel se composera d’une combinaison de gestionnaires responsables et pertinents. Lors de la mise en place d’une organisation, des fonctions et des rôles sont attribués, en plus des divers groupes (équipes, départements, divisions). Les rôles sont des ensembles de responsabilités, d’activités et d’autorités attribuées à une personne ou à une équipe. Une personne ou une équipe peuvent avoir des rôles multiples ; les rôles de gestionnaire des configurations et de gestionnaire des changements peuvent être remplis par une seule personne. Les fonctions (positions) sont traditionnellement considérées comme des tâches et des responsabilités attribuées à une personne spécifique. Une personne qui a une fonction particulière est chargée d’un ensemble de tâches et de responsabilités clairement définies, pouvant comporter divers rôles. Les fonctions peuvent aussi être définies de manière plus large, comme un concept logique s’appliquant à des personnes et à des mesures automatisées, et qui exécutent un processus clairement défini, une activité ou une combinaison de processus ou d’activités.

8.4 Outils utilisés en ITSM D’innombrables aides de support automatisées sont utilisés pour la performance des tâches : on les appelle outils. À l’aide de ces outils, les tâches de gestion peuvent être automatisées ; par exemple, les tâches de surveillance et les tâches de distribution de logiciel. D’autres outils contribuent à la performance des activités elles-mêmes ; par exemple, les outils des centres de service ou les outils de gestion des services. En fait, cette dernière catégorie supporte la gestion de plusieurs processus, ce qui fait qu’on parle souvent d’outils de workflow – bien qu’ils n’intègrent pas vraiment de moteurs de workflow.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction aux fonctions et aux processus

185

Le fait que le secteur informatique s’appuie essentiellement sur des installations automatisées (pour le traitement de l’information), une véritable profusion d’outils a vu le jour, ce qui a largement contribué aux capacités de performance des organisations informatiques.

8.5 Communication dans des organisations de service informatique Les personnes, les processus, les partenaires et la technologie fournissent les rouages principaux de chaque organisation, mais ces rouages ne fonctionnent bien que lorsqu’ils sont correctement huilés : la communication est un élément essentiel de toute organisation. Si les acteurs ne connaissent pas les processus ou utilisent des instructions ou des outils inappropriés, le résultat ne sera pas celui attendu. Les personnes représentent les actifs de base de l’organisation. Cela n’est pas uniquement dû au fait qu’elles sont en mesure de réaliser certaines activités ou de prendre des décisions, mais parce qu’elles ont acquis l’habitude de communiquer. Quand une organisation applique des instructions très détaillées pour toutes ses activités, cela se termine en bureaucratie. Parallèlement, une organisation sans aucune règle serait la proie du chaos. Quel que soit l’équilibre qu’une organisation essaie de trouver, elle tirera toujours un énorme bénéfice de la communication entre les acteurs de l’organisation. Des réunions régulières et formelles représentent une aide appréciable. Mais les organisations ne doivent pas sous-estimer le rôle important de la communication informelle : de nombreux projets ont été sauvés par une simple discussion autour de la machine à café ou sur un parking. Les structures formelles de communication comprennent : • rédaction de rapports – rédaction de rapports internes et externes, destinés à la direction ou au client, rapports d’avancement des projets, alertes • réunions – réunions formelles de projets, réunions régulières ayant des objectifs spécifiques • services en ligne – messagerie, chatrooms, pagers, groupwares, systèmes de partage de documents, messagerie instantanée, téléconférence et installations de réunion virtuelle • tableaux d’affichage – près de la machine à café, de la fontaine d’eau, à l’entrée du bâtiment, au restaurant d’entreprise. Les équipes et départements IT, tout comme les utilisateurs, les clients internes et les équipes de production de services, doivent communiquer entre eux. Les parties prenantes pour la communication se trouvent donc parmi tous les directeurs et les employés concernés par la gestion des services, dans toutes les couches de l’organisation, et avec tous les clients, les utilisateurs et les fournisseurs de services. Une bonne communication permet d’anticiper les problèmes. Toute communication doit avoir un but ou un résultat spécifique. Toutes les équipes et tous les processus et départements doivent s’appuyer sur une politique de communication claire. La gestion des services informatiques comprend plusieurs types de communication, tels que : • communications opérationnelles courantes • communications entre équipes • rapports de performance • communications pendant les projets • communications lorsque des changements ont lieu

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

186

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• communication en cas d’exceptions • communication en cas d’urgences • formation pour des processus nouveaux ou adaptés et pour les conceptions de service • communication avec les équipes de production de services concernant les stratégies et les conceptions de service

8.6 Culture Les organisations qui veulent changer, notamment pour améliorer la qualité de leurs services, sont tôt ou tard confrontées à la culture organisationnelle actuelle. Elle doivent alors gérer un changement de cette culture : ce changement est envisagé comme la conséquence d’un changement plus global. La culture organisationnelle, ou culture d’entreprise, se réfère à la façon dont les personnes interagissent au sein de l’organisation ; à la façon dont les décisions sont prises et mises en œuvre’ ; à l’attitude des employés par rapport à leur travail, aux clients, aux fournisseurs de services, à leurs supérieurs et à leurs collègues. La culture, qui dépend des normes et des valeurs des personnes appartenant à l’organisation, ne peut pas être contrôlée, mais elle peut être influencée. Influencer la culture d’une organisation nécessite un leadership sous la forme d’une politique claire et cohérente, ainsi qu’une politique de gestion du personnel. La culture d’entreprise peut avoir une influence majeure sur la fourniture des services informatiques. Les entreprises accordent de l’importance à l’innovation de différentes façons. Dans une organisation stable, où la culture accorde peu de valeur à l’innovation, il est difficile d’aligner les services informatiques sur les changements dans l’organisation du client. Si le département informatique est instable, une culture qui accorde de la valeur au changement peut constituer une sérieuse menace pour la qualité de ses services. Dans ce cas, une culture du style chacun pour soi peut se développer, dans laquelle un nombre important de changements non contrôlés entraîne un grand nombre de pannes.

8.7 Processus, projets, programmes et portefeuilles Les activités peuvent être gérées à partir d’une approche par processus, d’une perspective hiérarchique organisationnelle (par niveau) ou en mode projet, ou à partir d’une combinaison des trois. Les organisations qui n’appliquent que l’une de ces méthodes de gestion perdent souvent les bénéfices des autres. Le choix pratique dépend souvent de l’histoire, de la culture, des qualifications et des compétences, et des préférences personnelles. Le choix optimal peut être entièrement différent, mais les exigences d’application de ce choix sont difficiles à satisfaire et varient dans le temps. Il n’existe aucune loi stricte quant à la façon dont une organisation doit combiner processus, projets et programmes. Toutefois, chacun reconnaît l’apport des pratiques modernes de gestion des organisations informatiques. En effet, l’approche la plus reconnue de la gestion des services informatiques s’appuie sur la gestion de processus. Cela veut dire que chaque fois que l’organisation travaille avec des projets ou des programmes, elle doit avoir établi la manière dont ces approches fonctionnent ensemble.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Introduction aux fonctions et aux processus

187

La relation pratique entre projets et processus est déterminée par leur position relative en termes de principes directeurs pour la gestion de l’organisation : si les projets sont considérés comme étant moins importants que les processus, alors les décisions liées aux projets prennent le pas sur les décisions liées aux processus ; par conséquent, l’organisation ne sera pas en mesure de mettre en œuvre une série stable de processus. Dans un autre cas de figure, avec des projets capables de fonctionner uniquement selon un ensemble de contraintes imposées par les processus, la gestion de projets devra s’adapter à de nouvelles limites et définitions (sachant que les projets changent toujours quelque chose de A à B, ils seront probablement associés à la gestion des changements, des mises en production et des déploiements). La solution la plus adéquate dépend de la compréhension du rôle de la gestion des services informatiques au sein de l’organisation. Pour relever ce défi de management, il est recommandé d’établir une compréhension commune des processus, des projets, des programmes ainsi que des portefeuilles. Les définitions suivantes peuvent être utilisées : • Un processus – Un processus est un ensemble structuré d’activités conçu en vue d’atteindre un objectif spécifique. • Projet – un projet est une organisation temporaire, avec des personnes et d’autres actifs nécessaires pour atteindre un objectif. • Programme – un programme consiste en un certain nombre de projets et d’activités qui sont planifiés et gérés ensemble pour répondre à une série globale d’objectifs. • Portefeuille – un portefeuille est un ensemble de projets et/ou de programmes, n’étant pas nécessairement reliés, regroupés pour contrôler, coordonner et optimiser l’ensemble du portefeuille. N.B. Dans ITIL, un portefeuille de services est l’ensemble complet des services gérés par un fournisseur de services. Sachant que le regroupement projet/programme/portefeuille correspond à une série hiérarchique de ressources essentielles pour les projets, le problème peut être réduit à une simple relation entre un projet et un processus. La différence la plus élémentaire entre un processus et un projet est le caractère isolé du projet, par opposition au caractère continu du processus. Si un projet a atteint ses objectifs, ce projet est alors terminé. Des processus peuvent être activés plusieurs fois, de manière parallèle ou séquentielle. Le processus se caractérise par sa nature répétitive : les processus sont définis uniquement si chaîne répétitive d’activités est suffisamment importante pour permettre la standardisation et l’optimisation. Les projets visent à changer une situation A en une situation B. Cela peut impliquer une simple chaîne d’activités, mais aussi une série très complexe d’activités. L’argent, le temps, la qualité, l’organisation et l’information constituent également des éléments importants pour les projets. Un projet est en principe lancé si au moins un des éléments précités est d’une valeur considérable. En réalité, les projets ne sont que des manières d’organiser un changement spécifique en fonction d’une situation. Sous cet aspect, ils ressemblent aux processus. C’est souvent une question de prérogative : les processus mettent l’accent sur une séquence spécifique d’activités, sur les décisions prises à certains niveaux et sur la qualité des activités impliquées. Les processus sont continuellement initialisés et répétés, et utilisent à chaque fois la même approche. Les projets mettent plus l’accent sur les contraintes de temps et d’argent, sur les ressources utilisées, pour

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

188

Les fondamentaux de la gestion des services informatiques selon ITIL V3

que les projets évoluent et se terminent. En ce sens, les projets varient beaucoup plus que les processus. Voici une façon très pratique de combiner les bénéfices des deux systèmes de gestion : • Le processus définit la manière dont des séries spécifiques d’activités sont réalisées. • Les projets peuvent être utilisés pour transformer une situation A en une situation B, et se rapportent toujours à un changement. • Si les ressources (temps, argent ou autres) impliquées dans un processus spécifique nécessitent le niveau d’attention qui est normalement appliqué dans un projet, alors les activités du processus (ou une partie seulement) peuvent être réalisées comme un projet, mais toujours sous le contrôle du processus : si des changements sont réalisés, en utilisant des techniques de gestion de projets, les politiques de gestion des changements s’appliquent toujours. Cela permet aux organisations de maintenir une orientation client constante et d’appliquer une approche par processus pour optimiser cette orientation client, et en même temps de tirer profit d’un niveau élevé de contrôle des ressources qui peut être réalisé avec l’utilisation de techniques de gestion de projet.

8.8 Fonctions et processus dans les phases du cycle de vie Pour une améliorer la lisibilité et l’homogénéité, la structure suivante est la plus souvent utilisée pour toute description : 1. Introduction – décrit l’objectif et les buts du processus ou de la fonction, son périmètre, sa valeur pour l’entreprise, les guides de bonnes pratiques, les points de départ et les concepts de base. 2. Activités, méthodes et techniques – explique le processus ou la fonction de façon plus détaillée, en se basant sur le flux d’activités (si possible) ; 3. Interfaces – décrit comment le processus ou la fonction sont déclenchés, leurs entrées et sorties, et leurs liens avec d’autres fonctions ou processus. 4. Métrique – décrit la métrique des processus, notamment les indicateurs clés de performance (KPI). 5. Mise en œuvre – décrit les facteurs clés de succès (CSF), les défis, les risques et les pièges suite à l’introduction d’un processus ou d’une fonction.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 9

Fonctions et Processus dans la Stratégie des services 9.1 Gestion financière Introduction La gestion financière est un composant à part entière de la gestion des services. Elle fournit à la direction des informations essentielles pour assurer une fourniture de services efficiente et rentable. Une gestion financière efficiente permet à l’organisation de justifier les dépenses et de les allouer directement aux services. Les organisations informatiques sont de plus en plus conscientes qu’elles fonctionnent comme n’importe quelle entreprise s’adressant à un marché. Ainsi, elles doivent comprendre et maîtriser les facteurs qui influencent la demande. Une organisation informatique doit aussi tenter de réduire ses coûts tout en améliorant son offre. Correctement mise en œuvre, la gestion financière fournit des données significatives et essentielles pour évaluer la performance. Elle fournit également des réponses à des questions concernant l’organisation elle-même, comme : • Est-ce que notre stratégie de différentiation génère des profits et des revenus élevés. Contribuet-elle à réduire les coûts ou à étendre le périmètre ? • Quels services coûtent le plus cher et pourquoi ? • Quels sont nos points les moins efficients ? La gestion financière garantit que les coûts des services informatiques sont clairs (notamment grâce au catalogue des services) et que le marché les comprend. Les avantages sont : • prises de décision améliorées • gestion du portefeuille des services • conformité financière et contrôle • contrôle opérationnel • recherche et création de valeur

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

190

Estimation de la valeur du service Comment la gestion financière contribue-t-elle à identifier le processus de création de valeur ? L’évaluation d’un service permet au métier de comprendre exactement les services fournis par l’organisation informatique. L’estimation de la valeur d’un service consiste principalement à déterminer la valeur des services, à un niveau que le métier considère comme réaliste. Ceci permet au fournisseur de comprendre la manière de servir les intérêts du client. Parallèlement, l’estimation de la valeur améliore la gestion de la demande et le comportement du client. L’utilité et la garantie des services sont traduits en montants financiers pour calculer leur valeur. ITIL définit deux concepts centraux de la valeur, pour estimer la valeur d’un service : • Valeur de fourniture – les coûts réels sous-tendus des TI, associés à la fourniture d’un service, y compris tous les éléments de réalisation, à la fois corporels et incorporels. Ces coûts comprennent : – coûts de matériels et de licences logicielles – coûts annuels de maintenance pour les matériels et les logiciels – personnel pour fournir et maintenir le service – installations payées – impôts, capitaux ou intérêts d’emprunts – coûts de mise en conformité • Valeur potentielle du service – le composant de valeur ajoutée, qui repose sur la perception que le client a de la valeur du service ; ou bien de l’augmentation de l’utilité et de la garantie, attendue de la part du client, par rapport aux possibilités de ses propres actifs. Observez la valeur de chaque élément du service pour déterminer sa véritable valeur. Puis déterminez la valeur finale du service en additionnant ces composants, et en les comparant avec les coûts (coûts de fourniture). La figure 9.1 présente de manière détaillée les concepts associés à la valeur. Consultez la section sur la “Conception des Services” du chapitre 4, pour plus de détails sur l’identification de la valeur potentielle du service. Valeur potentielle du Service

Valeur de la Fourniture de Service

Performance Potentielle Actifs du client

+

Service level performance designed and delivered

+

Actifs du Service

Valeur débloqué Potentielle + Desired outcome

Réalisation de la valeur du service

Figure 9.1  Les actifs du client constituent la base pour la définition de la valeur

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Stratégie des services

191

Modélisation de la demande Une gestion inadéquate de la demande de services génère des coûts et des risques. La modélisation de la demande utilise des informations financières, orientées service, avec des facteurs d’offres et de demande, afin de modéliser l’utilisation prévue par le métier et les exigences associées de fourniture TI.

Gestion du portefeuille des services La gestion financière fournit des données cruciales pour la gestion du portefeuille des services. En appliquant des structures de coûts aux services, les entreprises peuvent comparer les coûts de leurs services à ceux des autres fournisseurs.

Optimisation de la fourniture de services La gestion financière fournit des données cruciales pour optimiser la fourniture des services (Optimisation de la fourniture de services ou Service Provisioning Optimisation – SPO). SPO examine les entrées financières et les limites des composants du service, pour déterminer la nécessité de chercher des alternatives, afin d’augmenter la compétitivité du service, en termes de coûts et de qualité. Cette analyse financière des composants du service, ainsi que ses contraintes et sa valeur, se situent au cœur de l’interaction entre la gestion financière et de SPO.

Planifier avec confiance L’objectif de la gestion financière consiste à garantir un financement approprié pour la fourniture et l’utilisation des services. Un planning qualifie la demande attendue en services informatiques et la traduit en termes financiers. Le planning se compose de trois branches. Chacune représente les résultats financiers nécessaires pour garantir une transparence continue et une estimation de la valeur du service : • Planning des dépenses de fonctionnement et d’investissement (actifs immobilisés fixes et généraux) – Les dépenses en services informatiques sont intégrées dans un système financier commun, et sont considérés comme une partie du cycle de la planification collective. • Planning de la demande – le besoin et l’utilisation des services informatiques. • Planning règlementaire et environnemental (conformité) – contrôlé à partir du métier. Un planning soigné permet d’avoir confiance dans les données financières et les modèles qui fournissent des informations précises sur le développement de la demande et de l’offre des services.

Analyse des investissements en service La gestion financière fournit des modèles analytiques et la connaissance pour déterminer la valeur attendue ou les bénéfices d’une initiative donnée, d’une solution, d’un programme ou d’un projet d’une manière standardisée. L’objectif de l’analyse des investissements en service consiste à indiquer la valeur de la totalité du cycle de vie d’un service. Celle-ci repose sur (a) la valeur reçue et (b) les coûts effectués pendant le cycle de vie d’un service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

192

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Comptabilité La gestion financière joue un rôle de transition entre les systèmes financiers de l’entreprise et la gestion des services. Lorsque la fonction comptable est orientée services, elle contribue à comprendre plus en détails la fourniture et la consommation des services. Elle contribue également à la production de données pour le processus de planification. Les propriétés de la comptabilité et les fonctions associées sont : • Les enregistrements du service – attribution d’un élément de coût au service concerné • Les catégories de coût – les dépenses de haut niveau, comme le matériel, les logiciels, la main d’œuvre, l’administration ; une fois que la base de l’administration des coûts est établie (par département, service et client par exemple), des catégories de coût sont déterminées pour les entrées de coût ; les catégories de coût varient en fonction de la taille de l’organisation ; les catégories de coût doivent être décrites de manière claire et reconnaissable, de sorte que les coûts soient facilement affectés ; les catégories de coût sont alors divisées en unités de coût ; les détails de chaque coût seront déterminés lors d’une étape ultérieure • Classification des coûts – afin de garantir un contrôle approprié des coûts, il est important de détailler les catégories de coût concernées ; les coûts peuvent être ventilés selon plusieurs critères. – Coûts d’investissement/charges : s Les coûts d’investissement concernent l’achat d’actifs qui durent généralement plusieurs années. La dépense est inscrite sur plusieurs années. Seul le montant inscrit est comptabilisé comme coût. s Les charges sont des coûts qui interviennent régulièrement et qui ne sont pas compensées par des actifs corporels de production (par exemple : un contrat de maintenance pour le matériel, les coûts de licence, les primes d’assurance). – Les coûts directs/indirects – Quels sont les coûts qui contribuent directement à un produit ou à un service et inversement : s Les coûts directs sont des coûts qui peuvent être identifiés spécifiquement et exclusivement pour un service informatique. Par exemple, les activités et les matériels directement et exclusivement associés à un service spécifique (une connexion à large bande passante, par exemple). s Les coûts indirects ne peuvent pas être identifiés directement pour un service informatique (exemple : les coûts d’installations, des services de support et administratifs). – Les coûts fixes/variables – Les coûts qui varient ou non avec le volume de la production : s Les coûts fixes sont des coûts qui ne varient pas en fonction du volume de la production, tels que les investissements en matériels, logiciels et bâtiments. Généralement, les écritures et les intérêts mensuels et annuels sont saisis comme des charges, et non comme des coûts d’acquisition. Les coûts fixes subsistent, même si le service est réduit ou terminé. s Les coûts variables sont des coûts qui varient en fonction du volume de la production, comme l’embauche de collaborateurs externes. – Les unités de coût – Les unités de consommation identifiées, qui représentent un service ou un actif de service spécifique.

Dynamique des coûts variables (Variable Cost Dynamics – VCD) La dynamique des coûts variables (VCD) se concentre sur l’analyse et la compréhension des nombreuses variables qui ont un impact sur les coûts du service. La VCD analyse les impacts

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Stratégie des services

193

prévus d’événements tels que des acquisitions, des changements dans le portefeuille des services ou des alternatives de fourniture de service. Voici quelques exemples de composants de coût variables du service : • nombre et catégories d’utilisateurs • nombre de licences de logiciel • nombre et catégories de ressources • coûts d’une licence utilisateur supplémentaire

Activités, méthodes et techniques Estimation de la valeur du service Lors de l’estimation de la valeur d’un service, les décisions suivantes sont prises : • Coûts directs vs coûts indirects – peut-on attribuer les coûts directement à un service spécifique ou sont-ils partagés par plusieurs services (coûts indirects) ? Une fois que les composants de coût sont identifiés d’une manière claire et précise, des règles ou une politique sont utiles pour renseigner sur la répartition des coûts entre plusieurs services. • Coûts de main d’œuvre – Pour le développement d’un système de calcul des coûts de main d’œuvre pour un service donné. • Coûts variables – Les dépenses variables, comme le nombre des utilisateurs ou le nombre des demandes en cours. Afin de prévoir les coûts variables, vous pouvez utiliser : – Les paliers – Identification d’économies d’échelle, pour encourager le client à acheter certains volumes. – Coûts maximaux – description des coûts des services basés sur une variation maximale. – Coûts moyens – Les coûts des services reposent sur une variance moyenne calculée sur une période écoulée. • Traduction des données comptables des coûts en valeur de service – ne peut être effectuée qu’à partir du moment où les coûts sont liés aux services. Après avoir établi les coûts fixes et variables pour chaque service, il faut considérer les composants de coût variables et le niveau de variation du service.

Alternatives de modèle de financement Cette section présente plusieurs modèles traditionnels de financement des services informatiques : • Financement par un plan glissant – un cycle de financement constant ; approprié pour un cycle de vie des services pour lequel une obligation de financement est contractée au début du cycle, et continue jusqu’à ce que des changements se produisent ou que le cycle de vie s’arrête • Plans basés sur des déclencheurs – des déclencheurs activent un événement spécifique ; le processus de gestion des changements, par exemple, agit comme élément déclencheur pour le processus de planification, pour tous les changements approuvés avec des conséquences financières • Financement à base zéro – ne concerne que les coûts actuels d’un service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

194

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Analyse d’impact sur le métier (Business Impact Analysis -BIA) L’analyse d’impact sur le métier (BIA) représente la base de la planification de la continuité du métier. BIA identifie l’impact opérationnel et financier liés à une interruption des opérations métier, ainsi que les conséquences sur les actifs et les clients. Cette information renseigne sur la performance opérationnelle et permet de la faire progresser. Ainsi, elle contribue à améliorer les décisions prises sur la priorité de traitement des incidents, à se focaliser sur la gestion des problèmes, la gestion des changements et des mises en production, l’exploitation, la priorité des projets, etc. BIA se présente comme un outil supplémentaire pour identifier les coûts liés à la défaillance d’un service et à sa valeur relative. Les coûts liés à la défaillance d’un service se traduisent par une baisse de la productivité et des revenus, pendant une période donnée.

Décisions clés pour la gestion financière Certains concepts de gestion financière influencent fortement le développement des stratégies des services. ITIL en souligne un certain nombre, permettant à chaque organisation de déterminer les meilleures alternatives pour ses stratégies de services. • Remboursement des coûts, centre de valeur ou centre de coûts ? – Le cycle financier des services informatiques commence par le financement des ressources qui produisent le résultat. Les clients associent ce résultat à de la valeur ajoutée, ce qui permet de réinitialiser le cycle de financement. Les services informatiques font typiquement référence à un centre de coûts, par un financement qui ne sert en fait qu’à réapprovisionner les coûts actuels de fourniture des services. • Facturation : facturer ou ne pas facturer ? – Un modèle de facturation permet de justifier et de rendre transparent un service informatique. La facturation rend conscient les clients sur le coût de fourniture d’un service. Il existe plusieurs modèles de facturation : – Facturation notionnelle – Une méthode de comptabilité qui fournit un aperçu des coûts imputés pour une méthode donnée. – Facturation à l’unité – implique une offre sur différents niveaux de garantie et/ou d’utilité pour un service ou un ensemble de services, à partir de tarifs et d’un modèle de facturation appropriés. – Usage mesuré – introduire les coûts sur la base d’unités de consommation établies soigneusement ; s’applique exclusivement pour les organisations pour lesquelles la gestion financière est mûre. – Direct plus – un modèle simplifié dans lequel les coûts peuvent être directement imputés à un service. Ceux-ci augmentent en fonction du pourcentage de coûts indirects et des services partagés. – Coût fixe ou utilisateur – le modèle de facturation le plus simple. Les coûts sont calculés selon une méthode convenue, à partir par exemple du nombre d’utilisateurs. Ce modèle ne permet pas vraiment d’influencer le comportement des consommateurs. • Liste de contrôle d’implémentation de la gestion financière – La mise en œuvre s’appuie par exemple sur les étapes suivantes : planifier, analyser, concevoir, mettre en œuvre et mesurer.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Stratégie des services

195

9.2 Gestion du Portefeuille des Services (SPM) Introduction Un portefeuille des services décrit les services d’un fournisseur en termes de valeur pour l’entreprise. Il articule les besoins du métier et la manière dont le fournisseur réagit par rapport à ces besoins. La valeur créée pour l’entreprise s’exprime par des termes issus du marketing : elle garantit ainsi que la compétitivité du fournisseur de services est mesurable par rapport aux concurrents. A l’aide de SPM, les managers estiment mieux les exigences de qualité et les coûts associés. Ils peuvent rechercher les éléments de réduction des coûts, tout en gardant la même qualité de service. La Gestion du Portefeuille des Services (Service Portfolio Management – SPM) est une méthode dynamique permettant de maîtriser les investissements dans la gestion des services pour toute l’organisation, dans un but de création de valeur. Les objectifs de la Gestion du Portefeuille des Services sont de réaliser et de créer une valeur maximale, tout en maîtrisant les risques et les coûts. SPM commence par la documentation des services standards de l’organisation et puis ceux du catalogue des services. Pour que les services soient viables sur le plan financier, le portefeuille combine les services du catalogue et ceux à l’étude. Le gestionnaire de produit joue un rôle important dans la Gestion du Portefeuille des Services. Il est responsable de la gestion des services, envisagé comme un produit, pendant tout son cycle de vie. Les gestionnaires de produit se focalisent sur l’organisation et la coordonnent. Ils sont propriétaires du Catalogue de Services. Ils travaillent en étroite collaboration avec le Gestionnaire des Relations Métier (BRM, Business Relation Manager), qui gère le Portefeuille Clients et le coordonne. SPM est avant tout une méthode de gouvernance.

Valeur pour l’entreprise Le Portefeuille des Services sert de base pour la prise de décision. Il aide à répondre aux questions stratégiques suivantes : • Pourquoi un client devrait-il acheter ces services ? • Pourquoi un client devrait-il acheter ces services chez nous ? • Quels sont les modèles de tarification et de facturation ? • Quels sont nos forces et nos faiblesses, nos priorités et nos risques ? • Comment doit-on distribuer nos ressources et nos capacités ? • Une stratégie de Portefeuille des Services permet à l’organisation d’anticiper les changements, en maintenant sa stratégie et sa planification.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

196

Stratégie de services

Définir

• Inventaires des • études métier

Analyser

• Propositions de valeur • Priorisation

Approuver

• Portefeuille de services • Autorisation

Préparer

• Communication • Allocation des Ressources

Figure 9.2  Processus du Portefeuille des Services

Activités, méthodes et SPM est un processus dynamique et continu qui comporte les méthodes de travail suivantes (voir aussi Figure 9.2) : • Définir – dresser un inventaire des services, des dossiers métier et approuver les données du portefeuille ; commencer par collecter les informations sur tous les services existants et proposés afin de déterminer les coûts du portefeuille existant ; la nature cyclique du procédé SPM indique que cette phase ne dresse pas seulement l’inventaire des services, mais approuve aussi les données maintes et maintes fois ; chaque service inclus dans le portefeuille doit s’appuyer sur un dossier métier. • Analyser – maximiser la valeur du portefeuille, mettre au point, donner un ordre de priorité et équilibrer l’offre et la demande ; dans cette phase, une forme concrète est donnée aux objectifs stratégiques. – Commencer par une série de questions top-down, telles que : – Quels sont les objectifs à long terme de l’organisation de services ? – Quels services sont requis pour réaliser ces objectifs ? – Quelles sont les capacités et les ressources nécessaires pour réaliser ces services ? En d’autres termes, quels sont les quatre P ? – Comment peut-on réaliser cela ? Les réponses à ces questions forment la base de l’analyse, mais déterminent aussi le résultat attendu de SPM. Les investissements en services doivent être divisés en trois catégories stratégiques : – Faire fonctionner le métier (RTB, Run The Business) – Les investissements RTB se concentrent sur la maintenance de l’exploitation du service. – Développer le métier (GTB, Grow The Business) – Les investissements GTB sont destinés à agrandir le périmètre des services. – Transformer le métier (TTB, Transform the Business) – Les investissements TTB forment un tremplin vers de nouveaux marchés. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Stratégie des services

197

• Approbation – terminer le portefeuille proposé, autoriser les services et les ressources et prendre les décisions pour l’avenir. Six différents résultats sont attendus : garder, remplacer, rationaliser, refaire, renouveler et éliminer. • Charte – communiquer des décisions, allouer les ressources et définir une charte des services ; commencer par une liste de décisions et d’éléments d’actions ; communiquer avec l’organisation sur ce sujet clairement et sans équivoque. Ces décisions doivent être en harmonie avec le budget et les plans financiers ; la valeur escomptée de chaque service sera intégrée dans les prévisions financières et la planification des ressources ; les nouveaux services sont transmis vers la phase de conception des services ; les services existants sont mis à jour dans le catalogue des services. La transition des services prépare le retrait des services retirés. Avec un portefeuille efficient ayant un ROI et des niveaux de risques optimaux, une organisation crée une valeur maximale tout en limitant l’utilisation des ressources et des capacités.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

198

Les fondamentaux de la gestion des services informatiques selon ITIL V3

9.3 Gestion de la demande Introduction Les défis de la gestion de la demande des services La Gestion de la Demande (Demand Management) est essentielle dans la gestion des services. Elle aligne l’offre sur la demande et anticipe la demande le plus précisément possible, voire la régule dans la mesure du possible. Une demande mal gérée représente un risque pour les fournisseurs de services. Une trop grande quantité de capacité, par exemple, génère des coûts qui ne créent pas de valeur. Cependant, une capacité inappropriée affecte la qualité du service et limite la croissance des services. Les accords sur les niveaux de service (SLA), les prévisions de la demande, la planification et une coordination rigoureuse avec le client peuvent minimiser l’incertitude de la demande, mais ils ne peuvent pas l’éliminer entièrement. La gestion des services doit tenir compte du problème supplémentaire de synchronisation entre la production et la consommation. L’exploitation de services est impossible sans l’existence d’une demande qui consomme le résultat. C’est un pull-system, dans lequel les cycles de consommation stimulent le cycle de production (voir Figure 9.3). Demande actuelle

Le Cycle de consommation crée des demandes

Actifs des clients

Actifs de service

Production cycle consumes demand

Fourniture de capacité

Figure 9.3  Une relation étroite entre la demande et la capacité

Contrairement aux produits, il est impossible de produire des services à l’avance et de le stocker en anticipation de la demande. La capacité de production des ressources disponibles pour un service est alors ajustée en fonction des prévisions de la demande.

Gestion de la demande axée sur l’activité Les processus métiers sont la source principale de la demande des services. Les Modèles d’Activité Métier (Patterns of Business Activity – PBA) influencent les modèles de la demande du point de vue des fournisseurs de services (voir Figure 9.4). Il est extrêmement important d’étudier le métier du client pour identifier, analyser et codifier les modèles, afin de fournir une base suffisante pour la gestion de la capacité.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Stratégie des services

199

Tendance des demandes

Tendance des activités métier

Processus métier

Processus service Chaîne de service

Plan de gestion de capacité

Schéma des prestations

Stimulation et pénalités pour influencer la consommation

Gestion de la demande

Figure 9.4  Les opérations métier ont un impact sur les modèles de la demande de services

Activités, méthodes et techniques Les services de base et les services de soutien Les services de base fournissent les résultats demandés par le client. Ils représentent la valeur que les clients cherchent et pour laquelle ils sont prêts à payer. Les services de base servent de repère pour les propositions de valeur faites au client, ils fournissent une base pour leur utilisation, et ils permettent une satisfaction durable. Les services de soutien permettent cette proposition de valeur.

Développement d’une offre différentiée La stratégie marketing s’appuie sur deux concepts de base : la construction d’un bouquet de services de base et le soutien de ces services. Les fournisseurs de services doivent analyser minutieusement les conditions actuelles de leur environnement métier, les besoins spécifiques des clients ou les segments sur lesquels ils sont positionnés, ainsi que les alternatives disponibles pour leurs clients. Ces décisions sont stratégiques, parce qu’elles cherchent à maintenir la valeur pour le client sur le long terme, même si les pratiques de l’industrie, les standards, les technologies et les règlementations évoluent. Les bouquets de services de soutien et de services de base impactent leur conception et leur exploitation. Les fournisseurs de services doivent se concentrer sur une fourniture efficace de la valeur à travers les services de base, tout en gardant un œil sur les services de soutien. Des recherches ont montré que les clients sont souvent mécontents des services de soutien. Certains services de soutien, comme le Centre de Services ou le support technique, font généralement partie d’un package mais peuvent également être fournis séparément. Cette considération est importante lors de la planification de la stratégie et lors de la revue des plans. Ces décisions stratégiques ont un fort impact la réussite du fournisseur de service au niveau du portefeuille. Elles sont essentielles pour les fournisseurs de services qui travaillent avec plusieurs organisations et domaines d’activité stratégiques (Business Units), étant en même temps poussés à réduire les coûts afin de préserver la compétitivité de leur portefeuille.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

200

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Packages de service ITIL définit les packages de service comme suit : Un package de service est une description détaillée d’un service informatique qui peut être fourni à un client. Un package de service inclut un package de niveau de service (Service Level Package – SLP) et un ou plusieurs services de base et services de soutien. La définition d’un package de niveau de service (SLP) est : Un package de niveau de service (Service Level Package- SLP) représente un niveau défini d’utilité et de garantie pour un package de service particulier. Chaque SLP est conçu pour répondre aux besoins d’un modèle d’activité Métier particulier. Les SLP sont associés à un ensemble de niveaux de services, une politique des prix, et un package de service de base (Core Service Package – CSP). ITIL définit un package de services de base comme suit : Un package de service de base est une description détaillée d’un service de base qui peut être partagé par deux ou plusieurs packages de niveau de service. Une ligne de service (Line Of Service – LOS) est définie comme suit : Une ligne de service est un service de base ou un service de soutien qui s’appuie sur plusieurs packages de niveau de service. Une ligne de service est gérée par un directeur de produit et chaque package de niveau de service est conçu pour soutenir un segment particulier du marché. Des combinaisons de CSP et SLP permettent de répondre aux besoins de clients sur des segments spécifiques, à la recherche de valeurs particulières. Les CSP et SLP forment un bouquet flexible pour permettre une optimiser et maintenir l’efficience du catalogue des services (Figure 9.5). L’avantage des CSP est qu’ils fournissent un contrôle rigoureux des services de base utilisés par tous les domaines d’activité stratégique (Business Units). Il contrôle la complexité et assure le résultat du métier. Chaque domaine d’activité stratégique (Business Unit – BU) peut développer des SLP sur la base des applications et des processus de leur propre marché.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Stratégie des services

201

Segment du client Z2 Segment du client X Segment du client Y

Segment du client Z

“OEM” Segmert

Package de Niveau de Service D Package de Package de Niveau de Niveau de Service A Service B

Package de Niveau de Service C

Package du Cœur de Service

Figure 9.5  Les SLP servent de méthode pour fournir des services spécifiques

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

202

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 10

Fonctions et processus dans la Conception des services 10.1 Gestion du catalogue des services Introduction Le but de la Gestion du Catalogue des Services (Service Catalog Management SCM) est de fournir une source d’information centralisée et cohérente pour tous les services connus (recensés) et d’assurer ainsi que cette information soit disponible pour les ayants droit (bénéficiaires). L’objectif de la gestion du catalogue des services est de développer et de maintenir un catalogue des services contenant l’ensemble des détails, des statuts, des interactions éventuelles et des interdépendances réciproques pour tous les services actuels et ceux qui sont sur le point d’être opérationnels.

Valeur pour l’entreprise Le catalogue des services est la ressource centrale qui contient toutes les informations sur les services informatiques offerts par le fournisseur de service. Ainsi, chacun obtient une image précise et cohérente des services IT, de leurs détails et de leurs statuts. Le catalogue renseigne sur les services actifs du point de vue client, la manière dont ils doivent être utilisés, les processus métier qu’ils soutiennent et le niveau de service qu’un client, interne et externe, peut en attendre.

Concepts de base Au fil des ans, les infrastructures informatiques des organisations évoluent à vive allure et il devient complexe d’obtenir une cartographie précise des services offerts par ces mêmes organisations, aussi bien à leurs clients internes qu’externes. Pour une meilleure visibilité des services offerts, le portefeuille des services est développé à partir d’un catalogue préalablement défini, et maintenu à jour. Le développement du portefeuille des services est un des éléments de la phase de stratégie des services fournis. Le portefeuille s’appuie également sur toutes les autres phases du cycle de vie des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

204

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Il est important de distinguer le portefeuille du catalogue des services : • Portefeuille des services Le portefeuille contient des informations sur chaque service et son statut. Le portefeuille décrit ainsi tout le processus, à commencer par les exigences du client pour le développement, la construction et l’exécution du service. Le portefeuille des services représente tous les services actifs et inactifs dans les diverses phases du cycle de vie. • Catalogue des services Le catalogue est un sous-ensemble du portefeuille des services et ne comprend que des services actifs et approuvés (au niveau des revendeurs) dans l’exploitation des services. Le catalogue divise les services en composants. Il contient les politiques, les guides de bonnes pratiques et les responsabilités ainsi que les prix, les accords sur les niveaux de service et les conditions de livraison. Le client peut revoir la majeure partie du catalogue des services. De nombreuses organisations intègrent leur portefeuille et leur catalogue dans le Système de Gestion des Configurations (CSM, Configuration Management System). En définissant chaque service, un élément de Configuration (CI) doit être défini et, lorsque cela est possible, intégré dans une hiérarchie. L’organisation peut associer les incidents et les demandes de changement aux services en question. C’est pour cette raison que les changements, à la fois dans le portefeuille et le catalogue, doivent faire partie du processus de gestion des changements. Le catalogue des services peut aussi être utilisé pour l’analyse d’impact métier (BIA, Business Impact Analysis), pour la gestion de la continuité des services informatiques (ITSCM), ou pour la gestion de la capacité afin de répartir au mieux la charge de travail. Ces avantages justifient l’investissement (en termes de temps et d’argent) nécessaire pour l’établissement d’un catalogue. Le catalogue des services revêt un aspect métier et technique : • Le catalogue des services métiers contient tous les détails des services qui sont fournis au client ainsi que les relations avec différents départements et processus métiers, qui dépendent du service IT. C’est le catalogue des services du point de vue client. Le catalogue des services métiers facilite le développement des processus de gestion des niveaux de service (SLM) proactifs et préventifs, ou même le développement pour la Gestion des Services Métiers(BSM). • Le catalogue des services techniques contient les détails des services IT fournis au client, ainsi que leurs relations avec des services de soutien et partagés, composants et éléments de configuration (CI). C’est la partie qui n’est pas visible du client. Le catalogue des services techniques détaille les aspects techniques (et les départements) qui sont nécessaires pour fournir le service. Une combinaison des deux catalogues fournit une vue d’ensemble rapide de l’impact des incidents et des changements sur le métier. C’est pourquoi de nombreuses organisations matures combinent les deux aspects dans un catalogue des services, en tant que partie d’un Portefeuille des Services.

Activités, méthodes et techniques Le catalogue des services est la seule ressource contenant des informations fiables sur tous les services du fournisseur de service. Le catalogue doit être accessible à toute personne autorisée. Les activités de ce processus sont les suivantes : • Définition et documentation des services avec toutes les parties prenantes. • Interfaçage avec la gestion de portefeuille des services afin de définir le contenu du portefeuille des services et du catalogue des services. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

205

• Production et mise à jour d’un catalogue des services précis, dont le contenu est cohérent avec le portefeuille des services. • Interfaçage, dépendance mutuelle, cohérence et surveillance du portefeuille des services. • Interfaçage avec les groupes de support, les fournisseurs de service et la gestion des configurations et dépendance mutuelle entre les services IT et les services de soutien, les composants de service et la surveillance du Système de Gestion de Configuration (CMS). • Interfaçage avec la Gestion de la Relation Métier et la Gestion des Niveaux de Service afin de s’assurer que l’information soit cohérente avec le métier et les processus métiers.

Interfaces Les entrées sont : • Informations venant du métier de l’organisation et de la stratégie IT, les plans informatiques et les plans financiers, etc. • Analyse d’impact sur le métier • Système de Gestion de Configuration (CMS) • Retour d’information d’autres processus Les sorties sont • Documentation et accord sur la définition de service • Mise à jour du Portefeuille des Services • Mise à jour du Catalogue des Services

Métriques Les indicateurs clés de performance (KPI) sont • Le nombre de services enregistrés et mis à jour dans le catalogue des services et le pourcentage de services fournis qui passent dans l’environnement de production. • Le nombre d’écarts entre les informations provenant du catalogue des services et la réalité. • Le pourcentage de croissance de couverture du catalogue des services métiers, par rapport aux services opérationnels. • Le pourcentage de croissance de couverture du catalogue des services techniques, par rapport aux composants informatiques de soutien des services. • Accès du Centre de Services aux informations de soutien des services, exprimé par le pourcentage d’incidents sans information.

Mise en œuvre Le défi le plus important à relever pour le processus de gestion du catalogue des services est de maintenir un catalogue précis (contenant à la fois les aspects métiers et techniques), intégré au portefeuille des services. Pour ce faire, des tableurs ou des bases de données doivent être développés avant d’intégrer le catalogue des services ou le portefeuille des services dans le Système de Gestion des Configurations (CSM) et dans le Système de Gestion des Connaissances de Services (SKMS). De plus, il est important que toutes les parties concernées reconnaissent que les deux catalogues sont des sources essentielles d’informations et doivent être utilisés et maintenus par tous au sein de l’organisation des services informatiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

206

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les facteurs clés de succès sont : • La mise en place d’un catalogue des services précis. • Une prise de conscience, par les utilisateurs du métier, des services fournis. • La prise de conscience par le personnel IT de la technologie supportant le service. Les risques comprennent : • Des informations inexactes dans le catalogue et le fait qu’il ne soit pas contrôlé par la gestion des changements. • Faible utilisation du catalogue des services et de son utilisation dans les processus opérationnels. • Absence de précision des informations fournies par le métier, l’organisation informatique et le portefeuille des services. • Les outils et les ressources nécessaires pour maintenir les informations à jour. • Le contournement de l’utilisation du portefeuille des services et du catalogue des services. • Des informations trop détaillés difficiles à maintenir ou d’un niveau trop général pour être utile.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

207

10.2 Gestion des niveaux de service Introduction L’objectif du processus de gestion des niveaux de service (SLM) est d’assurer qu’un niveau convenu de service informatique soit fourni pour les services actuels et que les services futurs soient fournis selon des objectifs réalistes et préalablement définis. Les objectifs se définissent ainsi : • Définir, documenter, accepter, surveiller, mesurer, rédiger des rapports et effectuer une revue du niveau de service. • Instaurer et améliorer les relations et les communications avec le métier et les clients. • Surveiller et améliorer la satisfaction client au niveau de la qualité des services fournis. • S’assurer que les IT et les clients ont une attente claire et non-ambiguë des niveaux de service à fournir. • S’assurer que des actions proactives pour améliorer les niveaux de service fournis soient mises en œuvre, si la justification des coûts le permet.

Périmètre La gestion des niveaux de service représente le fournisseur de services informatiques pour le métier. Un contact régulier et bidirectionnel permet d’établir les services présents et futurs. La gestion des niveaux de service doit gérer les attentes des deux parties (interne et externe). De plus, la gestion des niveaux de service assure que les services fournis répondent aux attentes. Le processus de la gestion des niveaux de service doit inclure les éléments suivants : • Développement de liens avec le métier. • Développement et gestion des accords sur les niveaux opérationnels (OLA). • Révision des contrats avec les fournisseurs sous-traitants. • Prévention proactive des défaillances de service, réduction des risques de service et amélioration de la qualité de service. • Rédaction de rapports, gestion de tous les services et revue de tous les manquements et faiblesses des SLA.

Valeur pour le business La gestion des niveaux de service (SLM) assure la communication et les relations entre les différentes parties prenantes (internes et externes). Elle s’accorde sur les objectifs de niveaux de service et fournit les informations de gestion nécessaires pour les atteindre. Lorsque les objectifs ne sont pas atteints, SLM doit informer le métier sur la (les) cause(s) en lui transmettant les mesures mises en œuvre pour empêcher de nouvelles défaillances. Le processus de gestion des niveaux de service implique la planification, la coordination, la rédaction d’une première version, l’acceptation, la surveillance et la rédaction de rapports portant sur les accords de niveaux de service (SLA), y compris la revue du service fourni, ainsi qu’une revue de l’accomplissement afin de s’assurer que le niveau de qualité exigé et justifiable soit continuellement maintenu. Un accord sur les niveaux de service (SLA) est un accord écrit entre le fournisseur de services et son client. Il définit des cibles et les responsabilités entre les deux parties.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

208

D’un autre côté, un accord sur les niveaux opérationnels (Operational Level Agreement OLA) est un accord entre un fournisseur de services IT et un autre département d’une même organisation concernant l’assistance dans la fourniture de service. Unité métier A

Unité métier B Le métier

Processus métier

2

3

5

Processus métier

1

6

4 SLM

SLR(s)

SLA(s)

Définir, documenter & accorder les exigences des nouveaux services & créer SLAs

Développer des contacts & des relations, enregistrer & gérer des réclamations et remerciements

Service A

Surveiller la performance de service par rapport au SLA & faire des reportings de service

G D F

standards de documentation & modèles

SLA(s)

Effectuer des revues de service & proposer des améliorations avec des SIP

Fournir une assistance au Catalogue de Services & maintenir des modèles documentaires

Assembler, mesurer et améliorer la satisfaction client

Catalogue de Services Reportings de service

Passer en revue et réviser les SLAs, le périmètre des services et les contrats de soustraitance

OLAs

Équipes Support

B C

Gestion des Fournisseurs

Contrats

Fournisseurs

Figure 10.1  Processus de gestion des niveaux de service

Activités, méthodes et techniques Les activités de la gestion des niveaux de service (Figure 10.1) sont : • Concevoir les référentiels de la gestion des niveaux de service (SLM) – Le SLM conçoit et structure son offre de prestations, de sorte que les services soient fournis de manière appropriée pour répondre aux besoins organisationnels des clients. Les options suivantes sont envisageables : – SLA orienté service un SLA couvre un seul service pour tous les clients de ce service ; un SLA peut être conçu pour des services de messagerie ou pour fournir, par exemple, certaines installations téléphoniques. Ce référentiel peut rencontrer des difficultés si les besoins spécifiques varient d’un client à un autre ; – SLA orienté client un seul accord avec un client pour tous les services qu’il utilise ; le client préfère souvent ce type d’accord car toutes ses exigences sont ainsi saisies dans un seul document.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

209

– SLA multi-niveaux une combinaison s’appuyant, par exemple, sur la structure suivante : s niveau entreprise, couvrant toutes les questions génériques du SLM  s niveau client, couvrant toutes les questions du SLM qui concernent un groupe de clients ou de domaines d’activités spécifiques s niveau de service, couvrant tous les sujets qui concernent un service spécifique relatif à un client spécifique Le SLA multi-niveaux conserve les SLA à une taille gérable et réduit la fréquence des mises à jour. • Déterminer, documenter, négocier les exigences pour les nouveaux services et produire des exigences de niveaux de service (SLR) – une fois le catalogue des services réalisé et la structure du SLA déterminée, le premier SLR a besoin d’être validé par un test (simulation) ; à ce stade, le client et les autres départements doivent être impliqués (mise en situation réelle) afin de valider la conformité d’accords et de protocoles jugés réalistes. • Surveiller les performances au regard du SLA et rédiger des rapports concernant le résultat – Tout ce qui est incorporé dans le SLA doit être mesurable afin d’éviter les litiges ; par exemple, le fournisseur de services peut mesurer le temps de réponse à un incident. Il est conseillé de produire des rapports périodiques concernant les résultats et de les utiliser pour échanger avec le client. Il est également recommandé d’enregistrer toutes les réclamations et les compliments, et de partager les contraintes et les bénéfices avec les parties concernées. • Améliorer la satisfaction du client – Outre les critères précités, la satisfaction du client doit être prise en compte. Cela peut se faire, notamment, à l’aide de questionnaires. • Revoir et réviser les accords de sous-traitance – Le fournisseur de services informatiques dépend en quelque sorte aussi de ses propres services techniques internes (ou de ses fournisseurs et partenaires de coopération externes) ; afin de satisfaire les cibles du SLA, des accords de sous-traitance avec les départements internes (Operational Level Agreement OLA) doivent soutenir le SLA, de la même manière que les accords de sous-traitance avec les parties externes (Underpinning Contracts UC) ; les accords doivent toujours être à jour et incorporés aux processus de gestion des changements et de gestion des configurations. • Rédiger des comptes-rendus sur les services – La communication est une activité de base en gestion des services et cela demande un reporting adéquat. Les mécanismes de reporting doivent être spécifiés et convenus. Des comptes-rendus doivent être fournis à intervalles réguliers. Les comptes-rendus de service constituent une base de discussion lors des réunions de revue des prestations. Le compte-rendu doit présenter des informations précises pour tous les champs et processus intégrant des notions de performance d’un service, mesurées en fonction des cibles métier précédemment identifiées. • Revoir et améliorer les services – Se concerter régulièrement avec le client afin d’évaluer les services et identifier les éventuelles améliorations dans la fourniture des prestations ; se concentrer sur les éléments d’amélioration qui produisent les plus grands bénéfices pour le métier et les utilisateurs ; dresser régulièrement des rapports sur les progrès des améliorations et les incorporer dans le plan d’amélioration des services (SIP). • Revoir et améliorer les SLA – Tous les accords sont soumis à la gestion des changements et des configurations et ils sont revus périodiquement pour assurer que des changements sur l’infrastructure n’ont pas invalidé les SLA. • Développer des contacts et des relations – Le SLM doit inspirer confiance au métier  de l’organisation en s’appuyant sur le catalogue des services, le SLM peut commencer à travailler de façon proactive ; le catalogue fournit des informations grâce auxquelles les relations entre

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

210

Les fondamentaux de la gestion des services informatiques selon ITIL V3

les services, les unités et les processus métier, qui dépendent de ces services, peuvent être mieux compris ; afin que cela se fasse de manière exhaustive, le SLM peut exécuter, entres autres, les activités suivantes : • Consulter et informer les parties prenantes, les clients et les gestionnaires concernés : – Maintenir des informations précises dans le portefeuille et catalogue des services. – Adopter une attitude flexible et responsable par rapport aux besoins des clients. – Développer une connaissance complète du métier et des clients. – Mettre en œuvre des études de satisfaction clients. En ce qui concerne la gestion de l’information : • Elle fournit des informations critiques au SLM sur les services opérationnels, les buts définis et les infractions. • Elle soutient la gestion du catalogue des services du SLM au moyen du catalogue des services. • Elle fournit des informations et des tendances au SLM sur la satisfaction client.

Interfaces Les entrées sont : • les informations métier provenant de la stratégie métier, les plans financiers, etc. • les exigences métier • le portefeuille des services et le catalogue des services • les informations sur les changements • le système de gestion des configurations (CMS) Les sorties sont : • les rapports de service • le programme d’amélioration des services (SIP) • le plan de qualité des services (SQP) • les modèles de documents standards • les SLA, SLR et OLA • les comptes-rendus des réunions de revue de service

Métriques • Les indicateurs clés de performance (KPI) incluent : • le pourcentage décroissant d’objectifs de SLA non atteints • le pourcentage de croissance de satisfaction client • le pourcentage de réduction des infractions au SLA

Mise en œuvre • Les possibles déclencheurs pour l’activité du SLM sont : • les changements dans le portefeuille des services • les accords nouveaux ou modifiés • la modification dans la stratégie ou la politique • la satisfaction et l’insatisfaction des services et prestations • les réunions de revue et les actions

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

211

10.3 Gestion de la capacité Introduction L’objectif de la gestion de la capacité est d’assurer qu’une capacité IT à coûts justifiables existe en permanence et que celle-ci est alignée sur les besoins actuels et futurs du métier. La gestion de la capacité est d’abord soutenue par la Stratégie des Services où les décisions, l’analyse des besoins métier et les résultats client influencent le développement des modèles d’activité business (Patterns of Business Activity PBA), des lignes de service (Lines Of Service LOS) et des Packages de Niveau de Service (Service Level Packages SLP). Cela fournit les indicateurs pour les besoins courants et prévisibles afin d’aligner la capacité à la demande. Les objectifs de la gestion de la capacité sont : • La création et la mise à jour d’un plan de capacité reflétant les besoins actuels et futurs du client. • Les conseils internes et externes sur les services en termes de capacité et de performance. • La garantie que les services fournis répondent aux objectifs définis en gérant la performance et la capacité des services. • La contribution au diagnostic de problèmes et d’incidents liés à la performance et à la capacité. • La réalisation d’enquêtes sur l’impact de tous les changements apportés au plan de capacité. • La prise de mesures proactives en vue d’améliorer les performances.

Périmètre Le processus de la gestion de la capacité devrait être le point central d’information de toutes les questions de performance et de capacité informatiques. Le support du réseau et des serveurs occupent la majorité des tâches opérationnelles quotidiennes. Il fournit une information importante sur la performance au processus de gestion de la capacité. De plus, la gestion de la capacité se concentre sur l’espace disponible et sur l’environnement métier. Elle peut aussi jouer un rôle dans certains aspects de gestion des RH. En effet, pour assurer une qualité de service convenue, le personnel doit être suffisamment expérimenté et qualifié. Toutefois, c’est une des principales responsabilités de la direction de l’organisation. Les facteurs déclencheurs sont les exigences des clients telles qu’elles sont établies dans les SLA. Étant donné que la gestion de la capacité comprend la totalité de l’environnement informatique et client, elle est en mesure de répondre aux exigences de capacité et de performance actuelles et futures de manière rentable. Gérer de grandes infrastructures informatiques est une tâche difficile et exigeante, en particulier lorsque la capacité informatique et les investissements financiers nécessaires augmentent. La planification est vitale pour réaliser des économies d’échelle, par exemple, lors de l’achat de composants. La gestion de la capacité devrait livrer des informations au portefeuille des services et au processus de gestion des fournisseurs pour assurer que les meilleurs contrats soient négociés avec ces mêmes fournisseurs de services. La gestion de la capacité fournit des informations sur l’utilisation actuelle

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

212

Les fondamentaux de la gestion des services informatiques selon ITIL V3

et future des ressources des composants individuels pour permettre à l’organisation de décider en toute confiance : • quels composants mettre à niveau • quand effectuer une telle mise à niveau • quel serait le coût d’une telle mise à niveau La gestion de la capacité et la stratégie des services ont une relation réciproque et étroite dans la mesure où la stratégie des services repose sur les plans de l’organisation, qui à leur tour proviennent de la stratégie. En d’autres termes, pour fonctionner correctement, elle doit comprendre les plans de l’organisation à court, moyen et long terme. D’autres processus sont moins efficaces s’ils ne reçoivent pas d’entrées (input) de la part de la gestion de la capacité. Par exemple, quel est l’effet d’un changement (gestion des changements) sur la capacité disponible ou quelles seraient les exigences de niveau de service dans la mise en œuvre d’une nouvelle prestation (SLM) ? Une gestion de la capacité approfondie est en mesure de prévenir les événements (et leur impact) avant qu’ils ne se produisent.

Valeur pour le métier La gestion de la capacité est responsable de la planification et de la programmation des ressources informatiques afin de fournir un niveau de service cohérent correspondant aux exigences actuelles et futures du client. La gestion de la capacité fournit un plan de capacité en concertation avec le client. Le plan spécifie les ressources informatiques et financières nécessaires pour soutenir le business, y compris une justification des dépenses. Le processus de la gestion de la capacité implique d’équilibrer à la fois les coûts aux ressources nécessaires et la fourniture à la demande. La planification et les processus de la gestion de la capacité doivent être impliqués dans chaque phase du cycle de vie des services ; de la stratégie à la conception et à la transition, et de l’exploitation jusqu’à l’amélioration continue des services.

Activités, méthodes et techniques Le processus de gestion de la capacité (Figure 5.2.8) est composé de : • Activités réactives, telles que : – la surveillance – la mesure • Activités proactives, telles que : – prévoir les exigences futures – anticiper des tendances En général, plus le processus de la gestion de la capacité est proactif, moins les activités réactives sont nécessaires.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

Passer en revue la capacité et la performance actuelle

213

Système d’Information de Gestion de la Capacité

Augmenter la capacité actuelle des services et des composants

Reportings & données sur la Capacité et la Performance

Évaluer, s’accorder & documenter les nouvelles exigences et les capacités

Prévisions

Planifier une nouvelle capacité

Plan de Capacité

Figure 10.2  Le processus de la gestion de la capacité

La gestion de la capacité est un processus extrêmement technique, complexe et exigeant, qui comprend trois sous-processus (Figure 10.2) : • Gestion de la capacité business (Business Capacity Management BCM) qui transforme les exigences du client en spécifications pour les services et l’infrastructure informatiques ; elle se concentre sur les exigences actuelles et à venir ; elle implique la gestion de la capacité métier dans : – Support quand des exigences de niveau de service (SLR) sont établies, la gestion de la capacité doit soutenir le SLM dans la compréhension des exigences définies par le client pour la capacité et la performance. – Conception et changement des configurations des services la gestion de la capacité doit être impliquée dans le développement et la modification de services nouveaux et faire des recommandations pour l’achat de matériels et de logiciels lorsque des facteurs de performance et de capacité jouent un rôle. – Vérification du SLA la gestion de la capacité conseille le SLM sur les objectifs réalisables qui sont mesurables. – Approbation du SLA fournir un support au SLM si de nouvelles négociations sont nécessaires, en identifiant les solutions possibles et les coûts correspondants. – Contrôle et mise en œuvre tous les changements en capacité de service et capacité de ressource doivent suivre l’ensemble des processus IT comme la gestion des changements, configurations et projets pour assurer que les mesures de contrôle et de coordination pour ces changements soient en place ainsi que tous les composants nouveaux ou à modifier, enregistrés et suivis pendant tout leur cycle de vie. • Gestion de la capacité des services (Service Capacity Management SCM) l’objet principal de ce sous-processus est d’identifier et de comprendre les services informatiques (y compris les ressources, les modèles, les charges minimum/maximum, etc.) et d’assurer qu’ils soient conformes aux cibles définies dans le SLA ; la gestion de la capacité des services surveille tous

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

214

les services, mesure leur performance, enregistre et analyse les données, et rédige des rapports sur ces informations ; ce sous-processus se concentre sur la gestion, le contrôle et l’anticipation des performances et des capacités des services informatiques opérationnels (existants). • Component Capacity Management (Gestion de la capacité des composants CCM) ce sous-processus se concentre principalement sur la gestion, le contrôle et l’anticipation des performances, sur l’utilisation et les capacités des composants informatiques individuels, tel que les processeurs, le réseau et la bande passante ; l’accent est mis sur l’infrastructure informatique qui soutient les services ; c’est surtout une activité exécutée lors de la phase d’exploitation du service (voir aussi Chapitre 12).

Portefeuille de Services

Exigences du métier Reportings sur la Capacité & la Performance Gestion de Capacité métier

SLA/SLR

Conception de services informatiques

Gestion de la Capacité des Services

Gestion de la Capacité des Composants

Passer en revue la Capacité & la performance actuelle Améliorer la capacité actuelle de service & des composants Système d’Information de Gestion de la Capacité (CMIS)

Évaluer, s’accorder & documenter les nouvelles exigences et les capacités

Prévisions

Planifier la nouvelle capacité Plan de Capacité Outils de Gestion de la Capacité

Figure 10.3  Sous-processus de gestion de la capacité

Activités de support de la gestion de la capacité Certaines activités doivent être exécutées de manière répétée (de façon proactive ou réactive) (Figure 10.3). Elles fournissent des informations de base et des déclencheurs pour d’autres activités et processus dans la gestion de la capacité. Ces activités incluent : • le réglage et l’optimisation • la surveillance de l’utilisation • l’analyse

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

215

• la mise en œuvre • l’exploitation de nouvelles technologies • la conception de la résilience (reprise d’activité initiale) La gestion de la capacité comprend également : • la gestion et le contrôle des seuils • la gestion de la demande • l’anticipation du comportement des services informatiques à l’aide de méthodes de modélisation telles que : – le modèle de référence – l’analyse des tendances – le modèle analytique – le modèle de simulation • le dimensionnement des applications, l’estimation des exigences pour les ressources destinées au support des changements proposés

Gestion de l’information et système d’information de gestion de la capacité L’objectif du système d’information de gestion de la capacité (Capacity Management Information System CMIS) est la fourniture d’informations pertinentes sur la capacité et la performance des services et de l’infrastructure afin de soutenir le processus de gestion de la capacité. Ce système d’information est un des éléments principaux dans le processus de gestion de la capacité. Tous les sous-processus de gestion de la capacité analysent les informations stockées. Par exemple, celui-ci contient des informations du métier sur les besoins actuels et futurs du client. Il contient aussi des données sur les services, tels que les temps de réponse, des informations sur l’utilisation des composants (par ex. trafic d’un serveur) et des données financières (par ex. les coûts relatifs aux mises à jour).

Interfaces Les activités de gestion de la capacité peuvent être déclenchées, entre autres, suite à des perturbations dans les services, des avertissements portant sur la capacité et la performance, des services nouveaux et modifiés, des changements de plans d’activité, IT et stratégiques, ainsi que lors de la revue et la révision des SLA, OLA, contrats et autres accords.

Entrées • l’information métier en provenance des plans de l’organisation (stratégiques, financiers, etc.), ainsi que l’information sur les besoins actuels et futurs • les informations sur les services et les IT en provenance des plans et de la stratégie IT • les informations de performance et de capacité des composants • les questions sur la performance des services provenant de la gestion des incidents et des problèmes • l’information financière • les informations sur les changements et les performances • le CMIS • l’information sur la charge de travail provenant de l’équipe d’exploitation

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

216

Paramétrage, ajustement de précision

Analyse

Déploiement

Surveillance, monitoring

Seuil de ressource

Seuil de Service

Système d’Information de Gestion de la Capacité

Reporting d’exception sur le service

Reporting d’exception sur l’utilisation des ressources

Figure 10.4  Activités itératives dans la gestion de la capacité

Sorties • le système d’information et de gestion de la capacité (CMIS) • le plan de capacité avec des informations sur l’utilisation actuelle des services ainsi que les plans de satisfaction des services en cours et ceux à venir • l’information sur la performance des services et l’activité de reporting • l’analyse de la charge de travail et son activité de reporting • le reporting en termes d’anticipation de la charge d’activité prévisionnelle • les seuils, les alertes et les événements à venir

Métrique Afin d’évaluer l’efficience et l’efficacité, les activités doivent inclure : • le pourcentage de précision de l’anticipation des tendances métier • la production ponctuelle des prévisions de charge de travail • l’amélioration de la surveillance de la performance et du débit des services et des composants • la justification et l’implémentation opportune de nouvelles technologies • la réduction de l’utilisation d’anciennes technologies • la réduction des incidents et des problèmes liés à une capacité inadéquate

Mise en œuvre L’un des principaux défis à relever est de convaincre le client de fournir davantage d’informations stratégiques. Cela permet au fournisseur de services d’assurer une gestion efficace de la continuité métier. Cela est particulièrement important dans l’externalisation de services. Un autre défi à relever est d’intégrer des informations pour la gestion de la capacité des composants (CCM) afin que celles-ci soient analysées de manière cohérente. Ainsi, la gestion de la capacité est en mesure de fournir des informations détaillées sur l’utilisation des composants.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

217

Les facteurs clés de succès comprennent : • la capacité d’anticipation de l’activité et de la charge • la capacité de mettre en avant l’efficience de cette gestion en termes de coûts • la possibilité de planifier et de mettre en œuvre la capacité appropriée pour satisfaire les besoins métier de l’organisation Les risques comprennent : • le manque d’engagement de la part de l’entreprise • le manque d’information et de vision sur la stratégie et les enjeux de l’organisation • la mise en œuvre de processus bureaucratiques lourds ou coûteux en main-d’œuvre

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

218

Les fondamentaux de la gestion des services informatiques selon ITIL V3

10.4 Gestion de la disponibilité Introduction L’objectif du processus de gestion de la disponibilité est d’assurer que le niveau de disponibilité des services fournis à l’ensemble des activités de l’organisation est conforme ou dépasse les besoins initiaux et futurs, dans une logique de rentabilité. Ses objectifs sont : • créer et maintenir un plan de disponibilité à jour, qui reflète les besoins actuels et futurs du client • donner des conseils en cas de problèmes liés à la disponibilité • guider le client et le fournisseur de services informatiques • garantir que les résultats de la disponibilité soient conformes ou dépassent les besoins définis • fournir une assistance lors de la réalisation d’un diagnostic dans la résolution de problèmes et d’incidents liés à la disponibilité • évaluer l’impact des changements sur le plan de disponibilité, sur la performance et la capacité des services et des ressources • prendre des mesures proactives afin d’améliorer la disponibilité

Périmètre Le processus de gestion de la disponibilité comprend la conception, la mise en œuvre, la mesure, la gestion et l’amélioration de la disponibilité des services informatiques et des composants utilisés pour fournir ces derniers. Il doit comprendre les exigences de la disponibilité des services et des composants du point de vue métier, en termes de : • processus métier actuels (leur exécution et leurs exigences) • plans et exigences d’activité future • objectifs des services, exploitation et fourniture des services actuels • infrastructure informatique, données, applications et environnement (y compris les performances) • impacts et priorités des activités par rapport aux services et à leur utilisation. Une fois ces problèmes assimilés, la gestion de la disponibilité est capable d’assurer que tous les services et composants sont conçus et fournis afin d’être conformes à leurs objectifs en termes de besoin d’activité préalablement convenus. La gestion de la disponibilité doit être intégrée dans tous les services opérationnels, nouveaux, modifiés ainsi que dans les services de support. Elle couvre tous les aspects de service ayant un impact sur la disponibilité, tels que la formation, les compétences, les procédures et les outils.

Valeur pour le business La disponibilité et la fiabilité des services informatiques ont un impact direct sur la satisfaction du client et sur la réputation de l’entreprise. En tant que tel, la gestion de la disponibilité est vitale. Elle devrait donc être incluse (tout comme la gestion de la capacité) dans toutes les phases du cycle de vie des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

219

Activités, méthodes et techniques Les principales activités de la gestion de la disponibilité sont (Figure 10.5) : • déterminer les exigences de disponibilité du métier • déterminer les fonctions métiers vitales (VBF) • déterminer l’impact des composants défaillants • définir les objectifs pour la disponibilité, la fiabilité et la facilité de maintenance des composants informatiques • surveiller et analyser les composants informatiques • mettre au point des métriques et de reporting dans la disponibilité, la fiabilité et la facilité de maintenance qui font l’objet de rapports d’un point de vue utilisateur métier et organisation du support informatique • investiguer les causes sous-jacentes des niveaux d’indisponibilité des services • créer et maintenir un plan de disponibilité (continuité des services)

Activités réactives Surveiller, mesurer, analyser, faire du reporting & passer en revue la disponibilité de service & composants Analyser tous les services & les composants indisponibles & proposer les actions de réparation

Système d’Information de Gestion de la Disponibilité (AMIS)

Reportings de gestion de la disponibilité

Activités proactives Plan de disponibilité Évaluation & gestion de risque

Planifier & concevoir des

Mettre en place des contre-mesures justifiées

Passer en revue tous les services nouveaux et modifiés et tester tous les mécanismes de disponibilité & de résilience

Critères de conception de disponibilité Schéma de test de disponibilité

Figure 10.5  Le processus de gestion de la disponibilité

La gestion de la disponibilité surveille, mesure, analyse les aspects suivants  et fournit les informations associées : • Disponibilité la capacité du service, du composant ou du CI à fonctionner comme prévu avec le client au moment souhaité. • Fiabilité la durée de fonctionnement d’un service, d’un composant ou d’un CI sans interruption conformément aux accords passés.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

220

• Facilité de maintenance la rapidité de retour à un fonctionnement normal après une défaillance et l’efficacité de recouvrement d’un service, un composant ou un CI. • Engagement de services la capacité d’un fournisseur de services IT externe à respecter les termes de leur contrat. La notion de mesure est extrêmement importante. Cela peut s’effectuer selon trois perspectives : • Perspective métier examine la disponibilité informatique du point de vue de sa contribution ou de son impact sur les fonctions métiers vitales (VBF) qui soutiennent tout ou partie de l’activité de l’organisation. • Perspective utilisateur considère la disponibilité des services informatiques comme une combinaison de trois facteurs : fréquence, durée et périmètre de l’impact (combien d’utilisateurs ou de parties de l’organisation sont affectés), et aussi mesure des temps de réponse. • Perspective du fournisseur de services informatiques considère la disponibilité de services et de composants en fonction de la disponibilité, de la fiabilité et de la facilité de maintenance.

Métier Clients

Clients

Clients

Accord sir les niveaux de service Disponibilité (% de disponibilité de service)

IT

Service A

Service C

Service B

Systèmes informatiques Accords sur les niveaux opérationnels Fiabilité & Facilité de Maintenance (MTBF & MTRS) Équipes de Support Internes

Contrats et accords Facilité de Service (disponibilité, MTBF & MTRS) Fournisseurs

Figure 10.6  Conditions de disponibilité et mesures

La gestion de la disponibilité doit constamment garantir que tous les services répondent aux objectifs préalablement définis. En cas de services nouveaux ou modifiés, ceux-ci doivent aussi être conçus de manière à répondre à ces objectifs. Pour cela, la gestion de la disponibilité exécute des activités réactives et proactives : • Activités réactives elles sont exécutées dans la phase opérationnelle du cycle de vie. – surveillance, mesure, analyse et rédaction de rapports quant à la disponibilité des services et des composants

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

221

– analyse de l’indisponibilité – cycle de vie étendu de l’incident – analyse des défaillances de service (SFA) • Activités proactives doivent être exécutées dans la phase de conception du cycle de vie : – identification des fonctions métier vitales (VBF) – conception pour une disponibilité – analyse d’impact de la défaillance d’un composant (CFIA) – analyse du point de défaillance unique (SPoF) – analyse par arbre de pannes (FTA) – modélisation – analyse et gestion des risques – calendrier de tests de disponibilité – maintenance planifiée et préventive – production du document de disponibilité prévue du service (PSA) – revue et amélioration continues

Principes directeurs Une gestion de la disponibilité efficace comprend à la fois à des activités réactives et proactives. Ne pas perdre de vue les éléments suivants : • La disponibilité de services est l’un des aspects les plus importants pour la satisfaction des clients. • En cas de défaillances, l’efficacité d’une réponse se traduit par une grande satisfaction du client. • Améliorer la disponibilité n’est possible qu’en comprenant comment les prestations supportent les opérations du client. • La disponibilité ne peut être gérée qu’en tant que maillon le plus sensible de la chaîne. • Ce n’est pas seulement un processus réactif, mais aussi et surtout un processus proactif. • Il est plus sage et plus rentable d’incorporer le bon niveau de disponibilité dès le début, c’està-dire dans la conception de nouveaux services.

Point de départ pour la gestion de la disponibilité La Figure 10.7 illustre un certain nombre de points de départ pour la gestion de la disponibilité. L’indisponibilité d’une prestation (service) peut-être réduite par l’identification de chacune des phases connues dans le cycle de vie détaillé d’un incident. Les services doivent être restaurés rapidement lorsqu’ils ne sont pas disponibles pour les utilisateurs. Le temps moyen de restauration du service (Mean Time to Restore Service MTRS) est le temps nécessaire pour la reprise opérationnelle d’une fonction (service, système ou composant) après une défaillance. Le MTRS dépend d’un certain nombre de facteurs, tels que : • configuration des actifs de service • MTRS des composants individuels • compétences du personnel de support • ressources disponibles • plans de la politique • procédures • redondance

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

222

Détecté

Enregistré

Diagnostiqué

Réparé

Résolu

Restauré

Incident

Incident

Délai de Délai Délai de Délai de détection d’enregistrement diagnostique réparation

Délai de résolution

Délai de restauration

Temps d’indisponibilité, Temps de restauration

Disponibilité, temps entre les défaillances

Facteur de facilité de maintenance

Facteur de fiabilité

Temps entre les incidents du système

Figure 10.7  Le cycle de vie détaillé d’un incident (à noter la combinaison des schémas de Stratégie des Services et d’Amélioration Continue des Services)

L’analyse du MTRS en fonction de chaque facteur est utile pour améliorer les performances des services et leur conception. Le MTRS peut être diminué par la gestion de chacun de ses composants (Figure 10.7). Réduire la durée des facteurs suivants limite le temps d’indisponibilité d’un service : • Détection/enregistrement de l’incident le temps entre l’occurrence d’un incident et sa reconnaissance. • Diagnostic de l’incident la phase jusqu’à ce qu’un diagnostic ait été effectué. • Réparation de l’incident la phase suivante nécessaire pour effectuer les réparations physiques. • Reprise de l’incident le temps nécessaire pour la reprise du système. • Restauration de l’incident le temps qui est ensuite nécessaire pour restaurer totalement le service et le mettre à disposition du client. D’autres métriques pour mesurer la disponibilité incluent : • Temps moyen des pannes (Mean Time Between Failure MTBF) ; le temps moyen qu’un CI ou un service peut fonctionner sans défaillance. • Temps moyen entre les incidents systèmes (Mean Time Between System Incidents MTBSI) : le temps moyen entre le début d’une première défaillance d’un CI ou d’un service (prestation) et le début d’une autre défaillance. • Temps moyen de Réparation (Mean Time To Repair MTTR) : le temps moyen pour réparer un CI ou un service après une défaillance. Le MTTR est mesuré du début de la défaillance jusqu’à la réparation. Le MTTR n’inclut pas le temps de récupération ou restauration du service ou CI.

Redondance La redondance est une façon d’augmenter la fiabilité et la durabilité des systèmes. ITIL définit les types de redondance suivants : • Redondance active ce type sert à soutenir des services essentiels ne pouvant pas souffrir d’interruption. La capacité productive des actifs redondants est toujours disponible. Avec la

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

223

redondance active, toutes les unités redondantes opèrent en même temps. Par exemple des disques miroirs dans un ordinateur serveur. • Redondance passive l’utilisation d’actifs redondants qui restent inutilisés jusqu’à ce qu’une défaillance (réactive) ne survienne. Par exemple des serveurs de secours ou des systèmes groupés. ITIL utilise aussi la différenciation suivante pour expliquer les types de redondance : • Redondance diverse (redondance hétérogène) redondance moyennant divers types d’actif de service partageant les mêmes aptitudes (répartition du risque). Cette méthode est utilisée lorsque la cause de la défaillance est difficile à anticiper, comme des supports de stockage, de langages de programmation ou des équipes de développement différentes. • Redondance homogène désigne l’utilisation d’une plus grande capacité du même type d’actifs de service. Avec ce type, une grande certitude demeure sur les causes de défaillance, comme l’utilisation de deux processeurs identiques. Les redondances active et passive peuvent être utilisés séparément ou en combinaison avec les types homogène et hétérogène. Par exemple : la redondance qui est à la fois active et homogène a une faible tolérance aux défaillances et une grande certitude sur les causes de défaillance. Les approches suivantes améliorent l’accessibilité des services : • Canaux divers la demande passe par différents types de canaux d’accès ; cela signifie qu’elle résiste en cas de défaillance d’un canal donné (redondance diverse active). • Réseau fermé des portes d’accès multiples augmentent la capacité du réseau (redondance homogène). • Couplage lâche les interfaces reposent sur une infrastructure publique, des technologies open source et des options d’accès omniprésentes, tels que les téléphones mobiles et les navigateurs ; il offre aux utilisateurs un accès au service via de multiples canaux et depuis de multiples sites ; les développements de sécurité rendent cette méthode de plus en plus accessible.

La gestion de l’information et le système d’information de la gestion de la disponibilité La gestion de la disponibilité doit permettre de maintenir un système d’information. Le système d’information de la gestion de la disponibilité (Availability Management Information System AMIS) contient toutes les mesures et les informations nécessaires pour mesurer le processus de gestion de la disponibilité. Il procure aussi à l’entreprise les informations justes sur le niveau de service à fournir en termes de composants et de services de support. Le système d’information constitue la base pour le plan de disponibilité. Le plan de disponibilité est différent d’un plan de mise en œuvre de la gestion de la disponibilité, bien qu’il puisse être initialement développé conjointement avec le plan de mise en œuvre. La gestion de la disponibilité change constamment, raison pour laquelle le plan de disponibilité doit contenir les éléments suivants : • Les niveaux actuels de disponibilité comparés aux niveaux attendus (selon la perspective client). • Les actions menées pour résoudre des défauts dans la disponibilité. • Les détails des conditions de disponibilité modifiées pour des services existants et futurs.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

224

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Un calendrier prévisionnel pour les attributions de l’analyse des défaillances de service (Service Failure Analysis SFA). • Une revue périodique des attributions de SFA. • Les bénéfices et les opportunités des mises à jour planifiées. Le plan doit compléter le plan de capacité et le plan financier et doit couvrir une période de deux ans. Les six premiers mois doivent être couverts plus en détail. Le plan doit être mis à jour (avec des petits modifications) chaque trimestre et avec des modifications à plus grande échelle tous les six mois.

Interfaces Les activités dans le secteur de la gestion de la disponibilité sont déclenchées, entre autres, par : • des besoins du client nouveaux ou en cours de modification • de nouveaux objectifs dans les accords par ex. les SLA, OLA ou contrats • des défaillances du service • des événements et alertes de disponibilité Les relations avec d’autres fonctions et processus sont : • La gestion de la disponibilité qui soutient la gestion des incidents et des problèmes afin de résoudre les problèmes et incidents portant sur la disponibilité. • La gestion de la disponibilité qui fournit à la gestion de la capacité la notion de résilience et de capacité de rechange. • La gestion de la disponibilité fournit à la gestion de la continuité des services informatiques (ITSCM) une évaluation sur l’impact et les risques pour le métier et les mécanismes de restauration. • La gestion de la disponibilité aide le SLM à déterminer les études et les objectifs de la disponibilité, et fait des propositions d’amélioration en cas de défaillance des services ou des composants. Les entrées de la gestion de la disponibilité sont : • Les informations métier, telles que les stratégies d’organisation, les plans financiers et les informations sur les exigences actuelles et futures des services informatiques. • Les analyses des risques, les analyses d’impact sur l’activité et les études des fonctions métier vitales. • Les informations sur les services provenant du portefeuille des services et du catalogue des services ainsi que du processus du SLM. • Les calendriers des changements et la planification des mises en production provenant de la gestion des changements et de la gestion des mises en production. • Les objectifs de service. • Les informations de défaillance et d’indisponibilité. Les sorties de la gestion de la disponibilité sont : • le système d’information de la gestion de la disponibilité • le plan de disponibilité • les critères de conception de la disponibilité et de la reprise (recouvrement des fonctions, de • l’activité, etc.)

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

225

• les rapports sur la disponibilité, la fiabilité et la facilité de maintenance des services • un enregistrement des risques à jour • surveillance, gestion et reporting • calendrier des tests de disponibilité • calendrier de l’entretien préventif et planifié • interruption prévue du service (Projected Service Outage – PSO)

Métriques Les organisations peuvent recourir à plusieurs indicateurs clés de performance (KPI) pour mesurer l’efficacité et l’efficience de la gestion de la disponibilité, telles que : • le pourcentage de réduction de l’indisponibilité des services et des composants • le pourcentage d’augmentation de la fiabilité des services et des composants • le pourcentage d’amélioration générale de disponibilité de bout en bout des services • le pourcentage de réduction des coûts d’indisponibilité • le pourcentage d’amélioration de la satisfaction du client

Mise en œuvre La gestion de la disponibilité comporte les défis suivants : • Atteindre les attentes des clients, de l’entreprise et de la direction. • Intégrer toutes les informations sur la disponibilité dans un système d’information de la gestion de la disponibilité. • Convaincre la direction de la nécessité d’investir dans des actions proactives de maintien de la disponibilité. Les facteurs clé de succès pour la gestion de la disponibilité sont : • Gérer la disponibilité et la fiabilité des services informatiques. • Disponibilité des infrastructures informatiques (comme convenu dans le SLA) et fourniture à des coûts optimaux. • Satisfaire les exigences métier d’accès aux services IT. Les risques pour la gestion de la disponibilité sont : • Le manque d’engagement de l’entreprise envers le processus de gestion de la disponibilité. • Le manque d’informations adéquates sur les plans et les stratégies à venir. • Le manque de ressources et de fonds. • L’utilisation croissante de rapports (mesure, reporting, etc.) trop élaborés.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

226

Les fondamentaux de la gestion des services informatiques selon ITIL V3

10.5 Gestion de la continuité des services informatiques Introduction L’objectif de la gestion de la continuité des services informatiques (ITSCM) est de soutenir le processus de la continuité de l’activité en général, en garantissant que les services et les installations informatiques nécessaires (y compris les systèmes informatiques, réseaux, applications, bases de données, environnement, support technique et centre de services, etc.) peuvent reprendre, selon les délais exigés et attendus par le métier. Les objectifs incluent : • Maintenir un ensemble de plans de continuité et de reprise. • Réaliser régulièrement des analyses d’impact sur le business (Business Impact Analysis BIA). • Effectuer régulièrement des estimations de risque. • Fournir conseil et orientation à toutes les autres unités métier et IT sur l’ensemble des questions liées à la continuité et à la reprise de l’activité. • Garantir que les mécanismes appropriés à la continuité et à la reprise d’activité sont mis en place afin de satisfaire ou dépasser les objectifs de continuité attendus. • Évaluer l’impact de tous les changements sur la continuité et la reprise d’activité. • Mettre en œuvre des mesures proactives afin d’améliorer la disponibilité des services (si les coûts sont justifiés). • Négocier des accords avec les fournisseurs de services IT en ce qui concerne la capacité de reprise d’activité dans une perspective de plan de continuité.

Périmètre L’ITSCM se concentre sur les événements que l’organisation considérerait comme des sinistres graves. Le processus de gestion des incidents gère des événements moins significatifs. L’ITSCM se concentre principalement sur les actifs et les configurations informatiques qui supportent les processus métier. Dans le cas d’un repli sur un site de secours, suite à un sinistre par exemple, le processus prendra par exemple en compte les bureaux, l’hébergement du personnel, les services téléphoniques. En règle générale, l’ITSCM ne s’occupe pas directement des risques à long terme liés notamment aux changements stratégiques d’une organisation. Bien que ceux-ci puissent avoir un impact énorme, il y a généralement assez de temps pour les identifier et prendre des mesures. Les problèmes techniques mineurs, tels que des défaillances de disques non critiques, ne sont pas couverts par ce processus ils sont traités par la gestion des incidents. L’ITSCM couvre : • les accords sur le périmètre de l’ITSCM • l’analyse d’impact sur l’activité pour quantifier l’impact des sinistres • l’identification des risques, l’analyse des risques et l’évaluation des risques pour identifier les menaces sur la continuité et la probabilité qu’elles surviennent • la création d’une stratégie globale de l’ITSCM qui est d’office intégrée dans la stratégie de continuité de l’activité • la création de plans de continuité • les tests faits sur les plans • l’exploitation et la maintenance continue des plans

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

227

Valeur pour le business L’ITSCM joue un rôle précieux dans le support du processus de la planification de la continuité du business. Les organisations l’utilisent souvent pour sensibiliser aux exigences de continuité et de reprise et justifier leur décision de mise en œuvre du processus de planification de la continuité de l’activité (y compris les plans/scenarios).

Activités, méthodes et techniques L’ITSCM est un processus cyclique. Il maintient les plans de continuité des services développés et les plans de reprise alignés sur les plans de continuité d’activité lorsque ceux-ci sont mis à jour.

Gestion de la Continuité du métier

Stratégie de Continuité du métier

Plans de Continuité du métier

IInvocation

Cycle de Vie

Activités clés, fonctions vitales

Planification

Création de politique Périmètre Lancer un projet

Exigences et stratégie

Analyse d’impact sur le métier Evaluation de risque Stratégie de Continuité des Services Informatiques

Mise en place

Développer des plans de Continuité des Services Informatiques Développer des plans informatiques, plans de résolution et procédures Planning organisationnel Stratégie de test

Opération continue

Education, sensibilisation et formation Passer en revue & auditer Tester Gestion des Changements

Figure 10.8  Cycle de vie de continuité des services informatiques

Le processus comprend quatre phases (Figure 10.8) : 1. Initialisation – Cette phase couvre toute l’organisation et comporte les activités suivantes : – la définition de la politique – la spécification des termes de référence et du périmètre – l’affectation des ressources (personnes, ressources et fonds) – la définition de l’organisation du projet et de la structure de contrôle – accord du projet et des plans qualité 2. Exigences et stratégie – Déterminer les exigences métier pour l’ITSCM est vital lorsqu’on étudie la manière dont une organisation peut survivre à un sinistre. Cette phase comprend des exigences et une stratégie. Les exigences demandent l’exécution d’une analyse d’impact métier et une analyse des risques : – Exigence 1 : Analyse d’impact métier (Business Impact Analysis BIA) Son objectif est de quantifier l’impact provoqué par la perte des services. Si l’impact peut être déterminé en détail, il est appelé impact fort par exemple pertes financières. L’´impact faible est moins

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

228

Les fondamentaux de la gestion des services informatiques selon ITIL V3

facile à déterminer, comme l’impact sur les relations publiques, le moral, la santé, etc. Le BIA identifie les services les plus importants pour l’organisation et, en tant que tel, fournit un input important pour la stratégie. Entre autres, l’analyse identifie :  le type de dommage ou de perte (par ex. revenu ou réputation) s la manière d’escalader les problèmes s les compétences, les installations et les services requis pour continuer les activités (services, prestations) importantes s les délais de reprise des processus les plus vitaux, partielle et complète s la détermination des périodes de reprise pour chaque service D’une manière générale, davantage de mesures préventives doivent être prises en ce qui concerne les processus et services qui seront plus rapidement et fortement affectés. Les efforts doivent être portés sur les mesures de continuité et de recouvrement d’activité là ou l’impact est le plus important. – Exigence 2 : Estimation des risques De nombreuses méthodes d’analyse et de gestion des risques existent. Une analyse des risques est une évaluation des risques pouvant causer des interruptions de service, voire des infractions de sécurité. La gestion des risques identifie les réponses et les contre-mesures rentables. La méthode standard, telle que la gestion du risque (Management of Risk MoR), sert à étudier et à gérer les risques. Cette méthode se compose de cinq parties : s principes M_o_R s approche M_o_R (approche organisation) s processus M_o_R (identification, évaluation, planification, mise en œuvre) s incorporation et revue M_o_R s communication (fourniture d’informations à jour et adéquates) – Stratégie 1 : Mesures de réponse des risques Des mesures visant à réduire les risques doivent être mises en œuvre en association avec la gestion de la disponibilité, car la réduction des défaillances affecte la disponibilité du service. Ces mesures peuvent comprendre : systèmes tolérants aux pannes, contrôles corrects de la sécurité informatique et stockage hors site. – Stratégie 2 : Mesure de récupération ITSCM La stratégie de continuité est un équilibre entre le coût des mesures de réduction de risque et les choix de mesures de récupération destinées à restaurer les processus d’activité critiques dans les délais attendus. Un certain nombre d’options de reprise sont possibles : s Solutions de contournement manuelles : solution manuelle temporaire pour une période limitée. s Ententes de réciprocité : accords de support entre des parties ayant des infrastructures similaires (peu utilisé de nos jours). s Reprise graduelle (ou cold standby) : méthode qui permet de disposer de services de base, tels que de l’hébergement et des locaux équipés, disponibles à des coûts réduits et dans un délai déterminé (quatre jours ou plus). s Reprise intermédiaire (warm standby) : reprise dans un délai de deux ou trois jours, généralement basée sur une installation préparée, et souvent partagée avec d’autres organisations. s Reprise rapide (hot standby) : reprise dans les 24 heures qui se focalise sur les services principaux, comprenant par exemple des sites dédiés pouvant être opérationnels très rapidement et avec une très faible perte de données.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

229

s Reprise immédiate (aussi appelée hot standby) : option pour la reprise immédiate des principaux services vitaux, qui utilise des techniques de type mirroring, des sites dédoublés et d’autres solutions redondantes. 3. Mise en œuvre Les plans de l’ITSCM peuvent être créés une fois la stratégie approuvée. Il ne faut toutefois pas oublier que la structure de l’organisation (leadership et processus décisionnels) change en cas de processus de reprise après un sinistre. De préférence, cette mise en place nécessite la nomination d’un manager senior généralement en charge, avec un coordinateur et des équipes de reprise, de tester les plans de reprise d’activité dans leur ensemble, par exemple en utilisant les méthodes de tests suivantes : – tests d’utilisation – tests complets – tests partiels (par ex. uniquement un service ou serveur) – tests de scénario (test pour des réponses/scénarios spécifiques) 4. Opération permanente Cette phase comprend : – la formation et la sensibilisation du personnel – revue et audit – tests – gestion des changements (garantit que tous les changements ont été revus du point de vue de leur impact potentiel) – tests ultimes (invocation).

Gestion de l’information Notez toutes les informations nécessaires pour maintenir les plans de l’ITSCM. Alignez le plan sur les informations de la BCM (Gestion de la Continuité du Business). Celui-ci devrait contenir au minimum des informations sur : • la version la plus récente de la stratégie BCM et de l’analyse d’impact sur le business • les risques, les registres de risques, les évaluations des risques et les réponses possibles • tests effectués et planifiés • détails de l’ITSCM et des plans correspondants • installations de reprise, fournisseurs, partenaires et accords existants • détails sur les processus de sauvegarde et de restauration

Interfaces L’ ITSCM peut être déclenché par divers événements : notamment de nouveaux besoins nouveaux ou une modification de ceux-ci pour le métier • objectifs nouveaux ou modifiés dans les accords par ex. les SLA, OLA ou contrats • occurrence d’un incident majeur qui nécessite d’être évalué pour éventuellement déclencher les plans ITSCM ou BCM • activités périodiques, telles que l’analyse d’impact sur le métier ou l’analyse des risques L’ITSCM s’interface notamment avec : • La gestion des incidents et des problèmes Les incidents et les problèmes peuvent facilement évoluer en incidents majeurs et en sinistres. • La gestion de la disponibilité – l’exécution de l’analyse des risques et la mise en œuvre de réponses aux risques doivent être étroitement coordonnées avec le processus de la gestion de la disponibilité.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

230

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• La gestion des niveaux de service Les exigences de reprise sont convenues et documentées dans les SLA. Les entrées de l’ITSCM incluent : • les informations métier (stratégies d’organisation, plans) • les informations IT • les informations financières • plans et stratégie BCM • les informations sur les changements (provenant de la gestion des changements) • CMS • calendriers de test. Les sorties de l’ITSCM incluent : • politique et stratégie ITSCM revues • pratiques et reporting d’analyse d’impact métier • revues et reporting d’analyses et gestion des risques • les plans de continuité • scénarios de tests • revues et reporting de tests

Métriques • La réussite de l’ITSCM peut être mesurée à l’aide des KPI suivants : • Le résultat d’audits périodiques des plans ITSCM • L’étendue des cibles de reprise des services qui sont convenues et documentées dans le SLA • Les résultats des tests des plans ITSCM • La revue périodique des plans ITSCM.

Mise en œuvre Les défis suivants se posent à l’ITSCM : • Fournir des plans de continuité quand il n’y a aucun processus BCM. • En cas de processus BCM, le défi est d’y intégrer le plan ITSCM et de le conserver ainsi. La réussite de l’ITSCM est fortement influencée par le fait de savoir si : • Les services peuvent être fournis et restaurés conformément aux objectifs des clients. • Toute l’organisation est informée des plans BCM et ITSCM. Ses risques comprennent : • Manque d’engagement de la part de l’entreprise et du management. • Manque de ressources et de budget. • Concentration excessive sur la technologie et non pas sur les services et les besoins des clients. • Étude et gestion des risques effectuées de manière trop isolée, et non pas en collaboration avec la gestion de la disponibilité et la gestion de la sécurité.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

231

10.6 Gestion de la sécurité informatique Introduction L’objectif de la gestion de la sécurité informatique est d’aligner la sécurité informatique et celle du métier ; garantir que la sécurité informatique soit gérée de manière efficace dans tous les services, toutes les activités de gestion des services et les prestations diverses. Ses buts sont : • Que les informations soient disponibles et utilisables, selon le besoin (disponibilité). • Que les informations soient disponibles exclusivement aux personnes autorisées (confidentialité). • Que les informations soient complètes, précises et protégées contre tout changement non autorisé (intégrité). • Que l’on peut avoir confiance dans les transactions et les échanges d’information entre les entreprises et les partenaires (authenticité et acceptation).

Périmètre La gestion de la sécurité informatique doit avoir un aperçu de l’ensemble du périmètre de la sécurité informatique et de la sécurité du business. Cela signifie, entre autres : • politique et plans de sécurité de l’entreprise actuels et futurs • exigences de sécurité • exigences légales • obligations et responsabilités • risques métier et risques informatiques (ainsi que leur gestion) Cela permet à la gestion de la sécurité informatique de gérer les aspects de sécurité actuels et futurs du business de manière rentable. Ce processus doit comporter les éléments suivants : • Production, maintenance, distribution et imposition d’une politique de sécurité informatique. • Compréhension des exigences actuelles et futures de sécurité du métier ; • Mise en œuvre (et documentation) de contrôles supportant la politique de sécurité informatique et gérant les risques. • Gestion des fournisseurs de services et des contrats concernant l’accès aux systèmes et aux services. • Gestion des infractions et des incidents de sécurité. • Amélioration proactive des systèmes de contrôle de sécurité.

Valeur pour le business La gestion de la sécurité informatique garantit que la politique de sécurité informatique satisfasse l‘ensemble de la politique de sécurité métier et aux exigences de la gouvernance d’entreprise. Il s’agit d’un processus de sensibilisation interne aux besoins de sécurité dans tous les services et actifs. La direction est responsable des informations d’entreprise et est censé réagir aux éléments qui ont un impact sur leur protection. On attend de la direction qu’elle considère la sécurité des informations comme faisant partie intégrante de la gouvernance d’entreprise. Donc, chaque fournisseur de services informatiques doit s’assurer d’une politique de gestion de la sécurité des informations afin de surveiller et d’imposer cette politique.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

232

Concepts de base • Le processus et le référentiel de gestion de la sécurité informatique comprennent : • la politique de sécurité informatique • le Systèmes de gestion de la sécurité informatique (ISMS) • une stratégie de sécurité exhaustive (liée à la stratégie et aux objectifs business) • une structure organisationnelle de sécurité efficace • un ensemble de contrôles de sécurité pour soutenir la politique • la gestion des risques • les processus de surveillance • une stratégie de communication • une stratégie d’éducation et de formation

Activités, méthodes et techniques Système de gestion de la sécurité informatique Le système de gestion de la sécurité informatique IT Security Management System ISMS) fournit la base pour le développement rentable d’un programme de sécurité informatique supportant les objectifs métier. Utiliser les quatre P de Personnel, Processus, Produits (y compris la technologie) et Partenaires (y compris les fournisseurs de service) afin de garantir que des niveaux élevés de sécurité soient mis en place. ISO 27001 est la norme formelle par laquelle des organisations peuvent faire certifier leur ISMS. La Figure 10.9 repose sur diverses recommandations, y compris la norme ISO 27001, et fournit un aperçu des cinq étapes et de leurs objectifs. Client – Exigences – Besoins du Business MAINTENIR Apprendre Améliorer Planifier Mettre en place

PLANIFIER Accords sur les niveaux de service Contrat de sous-traitance Accords sur les niveaux opérationnels Politiques

CONTRÔLE Organiser Créer un modèle, structure Distribuer des responsabilités EVALUER Audits internes Audits externes Auto-évaluation Incidents de sécurité

METTRE EN PLACE Sensibiliser Classification et enregistrement Sécurité du personnel Sécurité physique Réseau, applications, ordinateurs Gestion des Accès Procédures des incidents de sécurité

Figure 10.9  Référentiel pour la gestion de la sécurité informatique

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

233

Gouvernance de la sécurité La gouvernance de la sécurité informatique aboutit à six résultats : • L’alignement stratégique : – les exigences de sécurité doivent être actionnées par les exigences de l’organisation – les solutions de sécurité doivent correspondre aux processus de l’entreprise • La fourniture de valeur : – ensemble standard de pratiques de sécurité – une bonne gestion des priorités pour les efforts à répartir dans les secteurs, avec le plus grand impact et le plus grand bénéfice pour le business. • La gestion des risques : – profils des risques – sensibilisation aux priorités de gestion des risques • La gestion des performances : – métriques définies, attendues et significatives – processus de mesure d’aide à l’identification de défauts • La gestion des ressources : – disponibilité et enregistrement des connaissances – documentation des processus de sécurité • L’assurance des processus métier Le gestionnaire de la sécurité informatique doit comprendre que la sécurité n’est pas uniquement une étape dans le cycle de vie et qu’elle ne peut pas être résolue uniquement par de la technologie. La sécurité informatique doit être intégrée dans tous les services (et systèmes). C’est un processus continu qui implique une gestion permanente. La Figure 10.10 décrit les contrôles utiles de ce processus.

Menace Prévention/ réduction

Évaluation/ reporting Incident

Détection/ Réduction

Évaluation/ reporting Dommages

Correction/ Restauration

Évaluation/ reporting Contrôle

Figure 10.10  Contrôles de sécurité pour les menaces et les incidents.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

234

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Cette figure montre qu’un risque peut conduire à une menace, qui à son tour provoque un incident, dont la conséquence est un dommage. Des mesures adaptées sont adoptées entre ces phases : • Mesures préventives elles préviennent les effets (par ex. gestion des accès). • Mesures de réduction elles limitent les effets (par ex. copies de sauvegarde et tests). • Mesures de détection elles détectent les effets (par ex. surveillance). • Mesures répressives elles suppriment les effets (par ex. blocage). • Mesures correctives elles réparent les effets (par ex. annulation).

Gestion de l’information Toutes les informations nécessaires à la gestion de la sécurité informatique doivent être stockées dans un système de gestion de la sécurité informatique. Ce système comprend tous les contrôles de sécurité, des risques, des défaillances, des processus et des rapports. Il faut soutenir et maintenir la politique de sécurité informatique et le système de gestion de la sécurité informatique. Les informations doivent couvrir tous les services informatiques et être incorporées dans d’autres systèmes de gestion de l’informatique, notamment le portefeuille des services et le système de gestion des configurations (CMS).

Interfaces La gestion de la sécurité peut être déclenchée par : • une politique d’entreprise nouvelle ou modifiée • une politique de sécurité nouvelle ou changée du business • les processus de gestion des risques de l’entreprise nouveaux ou modifiés • les exigences ou les besoins du business, nouveaux ou modifiés dans les accords par ex. les SLA, OLA ou contrats La gestion de la sécurité a des interfaces avec, entre autres : • La gestion des incidents et des problèmes La gestion de la sécurité informatique fournit un support dans le processus décisionnel et la correction des incidents et des problèmes relatifs à la sécurité. • ITSCM La gestion de la sécurité informatique est liée à l’évaluation de l’impact et des risques pour l’entreprise, ainsi que de la fourniture des mécanismes de reprise. L’ISO 27001 exige un plan ITSCM opérationnel. • SLM Il fournit le support pour l’établissement d’exigences et de responsabilités relatives à la sécurité et leur incorporation dans le SLR et le SLA. • La gestion des changements La gestion de la sécurité informatique supporte la gestion des changements dans l’analyse des impacts éventuels de changements sur la sécurité. Les entrées du processus de gestion de la sécurité informatique sont : • les informations métier (stratégies, plans) • les informations IT • la gouvernance d’entreprise, les directives et les politiques de la sécurité métier • les informations de service provenant du processus SLM • processus d’analyse de risque et le reporting

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

235

• les détails des événements et infractions de la sécurité • les informations de changement provenant du processus de gestion des changements • CMS • Les détails d’accès des partenaires et fournisseurs de services Les sorties du processus de gestion de la sécurité informatique sont : • la politique générale de gestion de la sécurité informatique • ISMS • les processus d’évaluation de risque, de sécurité et de reporting • les contrôles de sécurité, les audits et les rapports • le calendrier des tests de sécurité

Métriques Les indicateurs clés de performance (KPI) comprennent : • le pourcentage de diminution des infractions de sécurité • le pourcentage de diminution de l’impact des infractions et des incidents de sécurité • l’augmentation de la sensibilisation sur les procédures de la sécurité dans l’organisation

Mise en œuvre Le principal défi dans ce processus est de garantir un support adéquat de l’entreprise, de la sécurité du business et de la direction. S’il vient à manquer, il est impossible d’établir un processus de sécurité efficace. Si un support interne est disponible, le défi consiste à intégrer les scenarios dans les plans de sécurité de l’entreprise. Une gestion des changements et une gestion des configurations rigoureuses sont nécessaires pour maintenir cette intégration. S’il y a bien un support de la DSI, mais une absence de support côté métier, les contrôles de sécurité IT et les évaluations des risques seront très limités dans leurs possibilités d’atteinte des objectifs. S’il existe une politique de sécurité métier, le défi consiste à y intégrer le processus de gestion de la sécurité. Une gestion des changements et une gestion des configurations rigoureuses sont exigées pour réussir une telle intégration. La réussite de la gestion de la sécurité informatique est fortement influencée par : • la protection du métier contre les violations de sécurité • l’élaboration d’une politique claire intégrant les besoins de l’activité • les procédures de sécurité qui sont justifiées et supportées par la direction • un marketing efficace et une formation sur les exigences de sécurité • un mécanisme d’amélioration Les risques dans la gestion de la sécurité informatique comprennent : • Un danger accru de mauvaise utilisation du système d’information en termes de confidentialité et d’éthique. • Les hackers.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

236

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Un manque d’engagement de la part de l’entreprise, de la direction, manque d’informations adéquates. • Focalisation excessive sur des aspects techniques et non sur les services et les besoins des clients. Trop souvent, l’analyse et la gestion des risques sont effectuées de manière isolée, plutôt qu’en coordination avec la gestion de la disponibilité et l’ITSCM.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

237

10.7 Gestion des fournisseurs Introduction L’objectif du processus de la gestion des fournisseurs est de gérer les fournisseurs et leurs services, afin de maintenir une qualité homogène de services IT pour les métiers, en assurant que les prestations sont à la hauteur de l’investissement financier engagé. Les buts sont les suivants : • Valoriser la prestation des fournisseurs et le suivi des contrats. • Assurer que les accords et les contrats de sous-traitance avec les fournisseurs de services sont en cohérence avec les besoins de l’activité de l’organisation. • Gérer les relations avec les fournisseurs et leurs performances. • Négocier et convenir des contrats avec les fournisseurs. • Maintenir une politique de fournisseurs et une base de données des fournisseurs et des contrats (Supplier and Contract Database SCD).

Périmètre Le processus de gestion des fournisseurs comprend la gestion de tous les fournisseurs et de tous les contrats, à titre de support de la fourniture de services TI au business. Plus la contribution d’un fournisseur sera importante, plus il fera un effort dans sa propre gestion (son développement interne), et plus il devra être impliqué dans le développement et la mise en œuvre de la stratégie. A contrario, plus sa contribution sera modeste plus elle sera maintenue principalement à un niveau opérationnel. Le processus doit comprendre les aspects suivants : • Mise en œuvre d’une politique de fournisseurs. • Maintenance d’une base de données des fournisseurs et des contrats (SCD). • Classement des fournisseurs et des contrats et évaluation des risques. • Évaluation des contrats et des fournisseurs. • Développement, négociation et accord des contrats. • Révision, renouvellement et résiliation des contrats.

Valeur pour le business Un des buts les plus importants dans la gestion des fournisseurs est d’obtenir la juste valeur pour son investissement financier de la part des fournisseurs et contrats et d’assurer que toutes les cibles dans les accords et contrats de sous-traitance sont alignés aux besoins du business et les cibles convenues dans le SLA. Cela assure la fourniture de services de qualité, homogènes de bout à bout, en en ligne avec les attentes du business. Les processus de gestion des fournisseurs doivent s’aligner avec l’ensemble des exigences de l’entreprise et celle des autres processus de gestion des services informatiques, notamment ceux liés aux exigences de la gestion de la sécurité informatique et de l’ITSCM.

Concepts de base Toutes les activités dans ce processus doivent être dirigées par la stratégie des fournisseurs et celle des services. Il est nécessaire de créer une base de données des fournisseurs et des contrats (SCD) afin d’obtenir une mise en œuvre cohérente et efficace de cette politique de services. Dans l’idéal, cette base de données doit être un élément intégré du CMS ou du SKMS. La base de données doit contenir tous les détails concernant les fournisseurs et les contrats, ainsi que ceux

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

238

sur les types de service, de produit et toute information en relation avec l’ensemble des éléments de leur configuration. Les données qui y sont stockées fournissent d’importantes informations pour les activités et les procédures, telles que : • Le classement des fournisseurs. • La maintenance de la base de données des fournisseurs et des contrats. • L’évaluation et l’installation de nouveaux fournisseurs et de nouveaux contrats. • L’établissement de nouveaux fournisseurs. • La gestion de fournisseurs de contrat (prestations) et performance. • Le renouvellement de contrats et leur résiliation.

Activités, méthodes et techniques Lorsqu’il s’agit de fournisseurs externes, il est recommandé de rédiger un contrat formel dans lequel les responsabilités et les objectifs sont clairement définis, convenus et documentés. Gérez ce contrat pendant tout son cycle de vie (Figure 10.11).

Identifier les exigences Évaluer les fournisseurs Catégoriser Régulariser

Base des données des fournisseurs et des contrats (SCD)

Gérer Renouveler/terminer

Figure 10.11  Cycle de vie du contrat

Les différentes phases sont : • Identification des exigences du métier et préparation d’un dossier métier : – produire un relevé des besoins (Statement of Requirement – SOR) et/ou un appel d’offre (Invitation To Tender – ITT) – assurer la conformité à la stratégie et à la politique de l’organisation – développer un dossier business initial • Évaluer et obtenir de nouveaux fournisseurs (contrats) – identifier les méthodes d’achat ou d’acquisition – établir les critères d’évaluation – sélectionner – négocier – se mettre d’accord sur le contrat – établir une liste de nouveaux fournisseurs et contrats – enregistrer les prestations du fournisseur et le contrat associé dans la SCD

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans la Conception des services

239

– transition de service – établir les contacts et les relations • Classer les fournisseurs et les contrats : – évaluation ou réévaluation du fournisseur et du contrat – assurer que les changements se font par la transition des services – catégorisation du fournisseur – mettre à jour la SCD – entretenir la SCD • Gérer la performance du fournisseur et du contrat – gestion et contrôle de l’exploitation et de la fourniture des services – surveillance et reporting – revue et amélioration – gestion du fournisseur et de la relation – revue au moins une fois par an du périmètre des services par rapport aux besoins du métier, des cibles et des accords – prévoir la résiliation des prestations (services) • Fin de période – revue – renégociation et/ou renouvellement, voire résiliation

Interfaces Le processus de gestion des fournisseurs peut être déclenché par : • Les modifications ou les nouvelles directives de la gouvernance de l’entreprise. • Des stratégies informatiques ou des activités nouvelles et/ou modifiées. • Des exigences d’activités nouvelles et/ou modifiées voire des prestations revues. Les entrées pour la gestion des fournisseurs sont : • les informations métier (stratégies, plans) • les stratégies des fournisseurs et des contrats • les détails des plans de l’entreprise • les stratégies des fournisseurs • les contrats des fournisseurs • les informations sur les performances Les sorties de la gestion des fournisseurs sont : • la base de données des fournisseurs et des contrats • les informations sur les performances • les plans d’amélioration des fournisseurs (plans d’amélioration des services des fournisseurs, SIP) • les rapports de recherche Les relations avec d’autres processus sont : • SLM aide à déterminer les buts, les exigences et les responsabilités. • Gestion de la sécurité informatique gérer les fournisseurs et leur accès aux services. • Gestion du portefeuille des services garantir que le portefeuille des services (prestations) représente de manière précise tous les systèmes de soutien et les détails.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

240

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Métriques Les performances de gestion des fournisseurs peuvent être mesurées selon : • l’augmentation du nombre de fournisseurs satisfaisant aux accords des contrats • l’augmentation du nombre d’objectifs contractuels alignés avec le SLA et le SLR Toutes les informations requises par la gestion des fournisseurs doivent être stockées dans la base de données des fournisseurs et des contrats. Celle-ci doit aussi contenir des informations sur les fournisseurs et les contrats et sur l’exécution des services de support. Intégrez cela dans le portefeuille des services.

Mise en œuvre La gestion des fournisseurs doit relever les défis suivants : • le changement constant des exigences métier et informatiques • l’existence de contrats imparfaits • une expérience insuffisante au sein de l’organisation • l’assujettissement à des contrats sur le long terme Afin de relever à ces défis, il convient de faire attention aux éléments suivants : • processus de gestion de services bien définis et décrits des deux côtés • relations mutuelles avantageuses • rôles clairs • bonne communication Le succès de la gestion des fournisseurs sera en partie déterminée par : • La protection contre une mauvaise performance du fournisseur. • Des services (et des objectifs) adaptés aux exigences du métier. • La clarté des fournisseurs et des contrats. La gestion des fournisseurs comporte les risques suivants : • Manque d’engagement de la part de l’entreprise et de la direction. • Manque d’information sur la politique et les objectifs futurs du métier. • Manque de ressources ou de budget. • Accords contractuels impossibles à atteindre.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 11

Fonctions et Processus dans la Transition des Services 11.1 Planification et support de la transition Introduction Les objectifs de la planification et du support de la transition des services incluent : • Planification et coordination des ressources afin d’assurer la réalisation des spécifications de la conception des services. • Commencer par la phase de transition, identifier, gérer et limiter les risques pouvant interrompre le service. Les buts de la planification et du support de la transition comprennent : • Planifier et coordonner des moyens humains et matériels au sein du cadre de travail. • S’assurer que chacun applique les mêmes cadres et standards. • Signaler les problèmes sur les services. • Élaborer des plans clairs et complets. • Soutenir les équipes de transition et les autres concernées. • Planifier des changements contrôlés. • Signaler les problèmes, les risques et les autres écarts.

Périmètre Les activités suivantes sont comprises dans le périmètre de la planification de la transition : • Inclure les spécifications de conception et les exigences du produit dans les plans de transition . • Gérer les : – plans – activités de support – progrès de la transition – changements – problèmes – risques – écarts

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

242

Les fondamentaux de la gestion des services informatiques selon ITIL V3

– processus – systèmes supports et outils • Suivre les réalisations de la transition des services. • Communiquer avec les clients, les utilisateurs et les parties prenantes.

Valeur pour le métier Une approche intégrée de la planification facilite l’adéquation entre des plans de transition et les changements du client, du fournisseur et du métier.

Concepts de base Le Package de conception de service (Service Design Package – SDP) contient les informations requises par l’équipe de transition des services : • packages de service applicables (par ex. package de service de base, package de niveau de service) • spécifications du service • modèles de service • conception architecturale requise pour la fourniture de services nouveaux ou modifiés, y compris des contraintes • définition et conception de chaque package de mise en production • conception détaillée de l’assemblage et intégration des composants en un package de mise en production • plans de mise en production et de déploiement • critères d’acceptation de services Les guides de bonnes pratiques et la politique de mise en production traitent les sujets suivants : • Attribution de conventions de nommage. Distinguez les types de mise en production, comme : mise en production majeure, mineure et d’urgence. • Rôles et responsabilités ; plusieurs personnes de différentes organisations peuvent être concernées par une mise en production. Pour cette raison, il est utile de fixer une matrice des responsabilités (RACI). • Fréquence des mises en production, la fréquence attendue de chaque type de mise en production. • Approche pour l’acceptation et le regroupement de changements dans les mises en production. • Comment la configuration de référence (baseline) est comparée avec la situation actuelle, lors de la mise en production (matériels, logiciels, documentation et connaissances). • Critères d’entrée, de sortie et d’autorité de recette de la mise en production pour chaque phase de transition des services et dans les environnements de test, de formation, et de retour à l’état initial suite à une mise en production qui s’est mal déroulée. • Critères d’autorisation pour abandonner le support de début de vie (Early Life support – ELS) et transmettre le support à l’Exploitation des Services.

Activités, méthodes et techniques Les activités pour la planification et le support consistent à : 1. établir la stratégie de transition 2. préparer la transition des services

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

243

3. planifier et coordonner la transition des services 4. support

1. Établir une stratégie de transition La stratégie de transition définit l’approche générale pour organiser la transition des services et l’affectation des ressources. Les aspects examinés sont : • objet, buts et objectifs • contexte et périmètre • normes applicables, accords, accords réglementaires, contractuels et légaux • organisations et parties prenantes impliquées dans la transition de services • cadre pour la transition des services • critères de réussite et d’échec • personnes, rôles et responsabilités • approche incluant le modèle de transition, les plans de gestion des changements, actifs, configurations et connaissances ; estimation de transition ; préparation ; évaluation ; gestion des erreurs ; KPI • les produits (livrables) qui sont le résultat des activités de la transition, comme les plans de transition, planification des jalons, exigences financières Le SDP définit les diverses phases de la transition de services. Celles-ci consistent en l’acquisition et le test des composants, le test des services mis en production, l’exploitation de services prêts, le premier déploiement, le support de début de vie (ELS), l’évaluation et la finalisation de la transition des services.

2. Préparer la transition des services Les activités de préparation consistent en : • Analyse et acceptation des entrées des autres phases du Cycle de Vie des Services et des autres entrées. • Vérification des livrables d’entrée, comme le SDP, les critères d’acceptation des services (Service Acceptance Criteria – SAC) et le reporting de revue. • Identification, création et planification des demandes de changement (RFC). • Surveillance de l’enregistrement des bases de référence dans la base de données de la gestion des configurations avant le début de la transition des services • Surveillance d’une transition jusqu’à ce qu’elle soit prête.

3. Planifier et coordonner la transition des services Un plan de transition des services décrit les tâches et les activités exigées pour la mise en production et le déploiement d’une mise en production dans les environnements de tests et d’exploitation. Ce plan inclut : • environnement de travail et infrastructure • planification des jalons • activités et tâches à exécuter • personnel, exigences de ressources, budgets et perspectives pour chaque phase • délais et contingence

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

244

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Lorsque la mise en production se déroule dans des environnements et des sites distribués, une planification intégrée est essentielle. Ainsi, collectez et regroupez les plans de transition. Reliez-les aux mises en production, aux plans de test et de construction des versions, aux diagrammes de changements et aux plans de déploiements et de mises en production. Les bonnes pratiques suggèrent de regrouper différentes mises en production au sein d’un seul programme, et de considérer chaque mise en production comme un projet. Mettez en œuvre des revues de qualité pour l’ensemble de la transition des services, de mise en production et des plans de déploiement. Les questions qui peuvent apparaître sont : • Les plans de transition des services et de mise en production sont-ils à jour et autorisés ? Les dates de mise en production sont-elles connues ? • Les risques liés à l’impact sur les coûts, l’organisation et la technologie ont-ils été pris en compte ? • Les nouveaux éléments de configuration (CI) sont-ils compatibles entre eux et avec ceux de l’environnement dans lesquels ils seront déployés ? • Les personnes qui devront travailler avec ces CI sont-elles suffisamment formées ? • Les changements potentiels dans l’environnement de l’entreprise ont-ils été pris en compte ?

4. Support du processus de transition La transition des services conseille et soutient toutes les parties prenantes. L’équipe de planification et de support donnera un aperçu aux parties prenantes concernant les processus de transition des services, les systèmes de supports et les outils. De plus, l’équipe administrera les changements, les ordres de travail, les problèmes, les risques, la communication et le déploiement. L’équipe tiendra aussi au courant les parties prenantes concernant la planification et le processus. Finalement, les activités de transition de services sont surveillées : la mise en œuvre des activités est comparée à la manière dont celles-ci ont été prévues (telles que formulées sur le plan et le modèle de transition).

Interfaces Le déclencheur pour la planification de la transition des services est une RFC approuvée. Entrées possibles pour la planification de la transition : • RFC autorisés • package de conception de service (SDP) • définition du package de mise en production et spécifications de la conception • critères d’acceptation (SAC) pour le service Sorties possibles pour la planification de la transition : • stratégie de transition • collection intégrale des plans de transition des services

Métriques Les indicateurs clés de performance (KPI) les plus importants pour la planification de la transition et le support sont :

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

245

• Le nombre de mises en production déployées qui correspondent aux exigences convenues avec le client. • Réduction du nombre d’écarts par rapport au périmètre prévu, la qualité, les coûts et les ressources. • Une satisfaction accrue du client et de l’utilisateur final concernant les plans et la communication. • Réduction du nombre de questions, des risques et des retards en raison d’une planification améliorée.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

246

Les fondamentaux de la gestion des services informatiques selon ITIL V3

11.2 Gestion des changements Introduction La proactivité et la réactivité sont à l’origine des changements. La réduction des coûts ou l’amélioration des services constituent de bons exemples de raisons proactives. Les solutions aux perturbations de service ou l’adaptation des services à un environnement qui change constituent des exemples de changement réactif. Les changements doivent être contrôlés convenablement, pour que : • l’exposition aux risques soit minimisée • la gravité de l’impact et l’interruption du service soient également minimisés • le changement soit déployé avec succès à la première tentative Les buts de la gestion des changements sont : • répondre au changement de l’activité métier du client • répondre aux demandes de changement RFC du métier et de l’informatique L’objectif du processus de gestion des changements est de garantir que les changements soient enregistrés, évalués, autorisés, priorisés, planifiés, testés, mis en œuvre, documentés et revues de manière contrôlée. Le processus de gestion des changements doit : • utiliser des méthodes et des procédures standardisées • enregistrer tous les changements dans la base de données de gestion des configurations (Configuration Management DataBase – CMDB) • tenir compte des risques pour le métier

Périmètre ITIL définit un changement comme suit : Un changement est l’ajout, la modification ou la suppression d’un service autorisé, planifié ou supporté (composant de service), ainsi que sa documentation associé. Le périmètre de la gestion des services comprend les changements de la configuration de référence (baseline) des actifs de services et des CI dans le cycle de vie des services en général. La section Gestion des Actifs des services et de la configuration détaillera ces questions ultérieurement dans ce chapitre. Chaque organisation doit elle-même définir les changements couverts par son processus de gestion des changements et ceux ne le sont pas. Par exemple, le remplacement d’un disque dur d’un PC ne fait peut-être pas partie du processus de gestion des changements. La Figure 11.1 montre le périmètre du processus de gestion des changements, ainsi que les interfaces du processus avec le métier, aux niveaux stratégique, tactique et opérationnel.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

247

Métier

Fournisseur de Service

Fournisseur

Changement stratégique

Gérer le métier

Gérer les services informatiques

Gérer le métier du fournisseur

Changement tactique

Gérer les processus métier

Portefeuille des services

Gérer les services externes

Exploitation des Services

Opérations externes

Service change

Changement opérationnel

Gérer les opérations métier

Figure 11.1  Périmètre de la gestion des changements

Valeur pour le métier Les interruptions de service associées aux changements peuvent avoir un impact négatif sur l’activité de l’organisation. Mais cette gestion des changements permet aussi au fournisseur de services d’ajouter de la valeur. Par exemple : • Les changements relatifs aux règlements financiers, comme SOX (Sarbanes-Oxley Act), ou d’autres règles de bonne gouvernance. • Une mise en œuvre des changements correctement planifiée de sorte que les délais du métier soient respectés. • Réduire le nombre de changements ayant échoué, et de ce fait réduire le nombre des interruptions de service. • Prioriser les changements et répondre convenablement aux exigences des changements du client. • Réduire le temps moyen de rétablissement des services (MTRS). A cause d’une dépendance accrue aux services informatiques, et parce que les technologies de l’information sont devenues si complexes, des changements et des mises en production bien structurés et planifiés contribuent à augmenter l’efficacité. Voici quelques indicateurs d’une gestion des changements inappropriée : • changements non autorisés • arrêt non prévu du service • changements déployés avec peu de succès • nombre élevé de changements d’urgence • mise en œuvre retardée des projets

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

248

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Politiques Les politiques pour le support de la gestion des changements sont : • Créer une culture de la tolérance zéro concernant les changements non autorisés. • Aligner le processus de la gestion des changements avec d’autres processus de changements dans l’organisation. • Une gestion des priorités efficace, à répartir par exemple parmi des changements innovateurs, correctifs, préventifs et réactifs. • Définir la responsabilité et la prise en charge pour les changements dans tout le cycle de vie. • Assurer l’intégration avec les autres processus de gestion des services. • Mettre en place une fenêtre des changements, une évaluation de la performance et des risques, ainsi que des mesures de performance.

Conception et planification Le processus de gestion des changements est planifié en association avec la gestion des mises en production et des configurations. Ceci permet d’estimer l’impact des changements sur les services et les mises en production Les exigences du processus de gestion des changements et sa conception incluent : • des exigences relatives aux lois et aux règlements en vigueur • une approche pour éliminer les changements non autorisés • identification et classification • organisation, rôles, responsabilités • parties prenantes • groupement et création de liens entre les changements • procédures • interfaces avec d’autres processus de gestion des changements

Concepts de base Une demande de changement (RFC) est une demande officielle pour changer un ou plusieurs CI. Un changement standard est un changement de service ou de composant d’infrastructure que la gestion des changements doit enregistrer, mais ayant un faible risque et étant pré-autorisé. Ce sont des changements de routine, tels que les extensions de PC. Un changement urgent est destiné à résoudre une panne (le plus tôt possible) dans un service informatique dont l’impact négatif est élevé pour le métier. Si ce changement exige la permission du comité consultatif sur les changements (Change Advisory Board – CAB), et que le CAB ne peut pas se réunir, il est nécessaire de définir une organisation plus restreinte pour prendre des décisions urgentes : le CAB d’urgence (ECAB). Un changement d’urgence, aussi, doit être testé et documenté le mieux possible. Le comité consultatif sur les changements (CAB) se réunit à des intervalles réguliers pour apprécier et prioriser les changements. Il se compose de représentants de toutes les parties prenantes et des départements, y compris :

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

249

• clients • utilisateurs finaux • développeurs d’applications • administrateurs système • experts • représentants du centre des services • production • représentants du fournisseur de services. Le CAB doit établir un ordre du jour standard, comprenant par exemple : • changements non autorisés • changements autorisés non traités par le CAB • RFC qui doivent être examinées par les membres du CAB • changements clôturés ou en cours • appréciation des changements déployés Aucun changement ne sera approuvé sans avoir la réponse à la question suivante : que fera-t-on si le changement n’a pas réussi ? Il faut toujours s’assurer qu’une situation de retour-arrière est disponible.

Activités, méthodes et techniques Généralement, les activités de la gestion des changements incluent : • planification des changements et contrôle • prévision dans le temps des changements et des mises en production • communication • décision et autorisation des changements • s’assurer de la présence des plans de retour-arrière • mesures et contrôle • rédaction de rapports managériaux • analyse de l’impact • amélioration continue Les activités spécifiques pour gérer les changements individuels sont abordées de la manière suivante (voir Figure 11.2) : 1. Créer et enregistrer la RFC 2. Réviser la RFC et proposer le changement 3. Déterminer et évaluer le changement 4. Autoriser le changement 5. Planifier les mises à jour 6. Coordonner l’implémentation du changement 7. Évaluer et clôturer le changement

1. Créer et enregistrer Un changement est soumis par un individu ou un département qui a besoin du changement. Pensez par exemple à un département métier qui a besoin de ressources fonctionnelles supplémentaires,

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

250

ou bien le gestionnaire des problèmes qui veut résoudre un problème par le biais de la gestion des changements. Toutes les RFC sont enregistrées et celles-ci sont identifiables par un numéro de référence unique. Le périmètre et l’impact du changement déterminent la quantité d’information exigée pour son évaluation.

Etablir un RFC Proposition de changement (optionnel) Enregistrer un RFC requested Passer en revue un RFC Gestion des changements

ready for evaluation Examiner et évaluer un RFC ready for decision

Autoriser la proposition du changement

Ordre de travail

Autoriser un RFC Responsable de changement

authorized

Planifier des mises à jour

Reporting d’évaluation

Gestion scheduled des changements Coordonner l’implémentation du changement* Gestion implemented des changements Passer en revue et clôturer l’enregistrement du changement closed

Ordre de travail

Mettre à jour l’information du changement et de la configuration au CMS

Déclencheur

* Includes build and test the change

Figure 11.2  Exemple de flux du processus pour un changement ordinaire

2. Revoir le RFC Après l’enregistrement, les parties prenantes vérifient si la RFC est illogique, inapplicable ou incomplète, ou bien si une RFC a déjà été demandée pour le même changement. Le cas échéant, de telles demandes sont refusées en précisant la raison du rejet. La partie soumettant la RFC a toujours la possibilité de défendre sa demande.

3. Déterminer et évaluer les changements L’étape commence par la catégorisation du changement. Le risque associé au changement doit être considéré avant même son autorisation. Une fois que la RFC a été approuvée, le risque du changement pour le métier est évalué. La probabilité que le risque se produise et son impact éventuel déterminent la catégorie du risque du changement. En pratique, une matrice de catégorisation du risque est généralement utilisée à cette fin (Figure 11.3). Une fois que le changement à été catégorisé, il est évalué. Basé sur l’impact, l’appréciation du risque, les avantages potentiels et les coûts du changement, l’autorité du changement (exemple, le gestionnaire des changements et/ou CAB) détermine s’il y a lieu d’approuver le changement ou non. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Impact du changement

Fonctions et Processus dans la Transition des Services

251

Impact élevé

Impact élevé

Probabilité bas

Probabilité élevé

Catégorie de risque: 2

Catégorie de risque: 1

Impact bas

Impact bas

Probabilité bas

Probabilité élevé

Catégorie de risque: 4

Catégorie de risque: 3

Probabilité

Figure 11.3  Exemple de matrice de catégorisation du risque.

Les questions suivantes doivent êtres posées pour chaque changement. Sans ces informations, l’évaluation du changement ne peut aboutir et l’équilibre entre le risque et le bénéfice pour les services opérationnels ne peut pas être compris. Les sept R de la gestion des changements représentent un bon point de départ pour l’analyse de l’impact : 1. Qui a soumis le changement ? (Raised : émetteur du changement) 2. Quelle est la raison du changement ? (Raison) 3. Quel est le résultat requis pour ce changement ? (Retour) 4. Quels sont les risques du changement ? (Risque) 5. Quelles ressources exige-t-il ? (Ressources) 6. Qui sont responsables pour la construction, le test et la mise en œuvre ? (Responsable) 7. Quelles relations existent-elles entre celui-ci et les autres changements ? (Relation) Déterminez la priorité des changements pour établir l’ordre dans lequel les changements doivent être mis en œuvre. L’impact et l’urgence convenus servent de base. L’impact repose sur les bénéfices liés au changement sur l’activité ou sur l’étendue des dommages si le changement tourne mal. L’urgence indique le temps de mise en œuvre. Quelques exemples de codes de priorité : • Priorité faible – un changement est souhaité mais peut attendre qu’une occasion se présente. • Priorité moyenne – il n’y a pas de grande urgence ou d’impact élevé, mais le changement ne doit pas être reporté à plus tard ; le comité consultatif sur les changements (CAB) affecte une priorité moyenne au changement lors de l’allocation des ressources. • Haute priorité – ce changement présente un risque sérieux pour un certain nombre d’utilisateurs ou un risque gênant pour un groupe important d’utilisateurs, ou il est lié à d’autres problèmes urgents ; le comité consultatif sur les changements (CAB) affecte à ce changement une priorité élevée lors de la prochaine réunion. • Priorité immédiate – provoque une importante perte de revenu ; une action immédiate est requise.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

252

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Planifier le calendrier des changements La gestion des changements doit programmer les changements dans le Calendrier des changements (Schedule of Changes – SC). Le SC comporte les détails de tous les changements approuvés et leur planification, comme la date de mise en œuvre. Les changements peuvent être regroupés en une seule mise en production. Après avoir consulté les départements informatiques concernés, le CAB peut fixer les délais de mise en œuvre des changements et les moments où les changements perturbent le moins les services. Un plan de retour-arrière doit être prêt pour le cas où la mise en œuvre du changement ne réussit pas.

4. Autoriser le changement Une instance officielle qui a autorité sur les changements doit donner son accord pour chaque changement. Celle-ci peut être une fonction, une personne ou un groupe de personnes. Le niveau auquel l’approbation est requise dépend du type de changement. Un exemple est montré sur la Figure 11.4.

Communications, décisions et actions

Communications, escalades pour les RFCs, risques, points à traiter

Responsable de changements

Exemples des niveaux de configuration impactés

Niveau 1

Comité de direction

Les changement à risque/coût élevé s’appuient sur des décisions de la part de la hiérarchie

Niveau 2

Direction informatique

Changement qui a un impact sur plusieurs services ou des départements de l’organisation

Niveau 3

CAB ou ECAB

Changement qui a un impact local ou sur un groupe de service

Niveau 4

Autorisation locale

Changement standard

Figure 11.4  Exemple d’un modèle d’autorisation

5. Coordonner la mise en œuvre Les changements approuvés doivent être transmis aux équipes techniques concernées pour la mise en œuvre des changements La construction et la création d’une mise en production sont des questions abordées dans la section sur Mise en production et gestion du déploiement. Il faut tester minutieusement les changements, les solutions aux incidents et la méthode de mise en œuvre pour les changements. La section Validation de services et tests détaille la phase de test.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

253

6. Évaluer et clôturer Les changements mis en œuvre – à l’exception des changements standards – sont évalués après un certain temps. Le CAB détermine si un suivi supplémentaire est nécessaire. Le CAB porte une certaine attention aux questions suivantes : • Est-ce que le changement a atteint le but souhaité ? • Est-ce que toutes les parties prenantes sont satisfaites du résultat ? • Y a-t-il eu des effets secondaires ? • A quel niveau y-a-t-il eu dépassement des coûts et des efforts ? Si le changement réussit, il peut être clôturé. Le résultat doit être inclus dans le revu postimplémentation (PIR) : l’évaluation du changement. Si le changement n’a pas réussi, la gestion du changement ou le CAB décide de ce qu’il faut faire. Une nouvelle RFC sera émise ou bien la RFC originale sera modifiée.

Interfaces Exemples de types de changement qui déclenchent le processus de gestion des changements : • changements stratégiques • changements dans un ou plusieurs services • changements opérationnels • changements pour l’amélioration continue (Voir aussi CSI au chapitre 13) Parmi les entrées de la gestion des changements, on trouve : • les politiques et stratégies de changement et mise en production • les RFC • proposition de changement • plans des changements, de transition, de mise en production et de déploiement, de test, d’évaluation, de réparation, etc. • calendrier des interruptions planifiées du service (PSO) • actifs et CI • résultats de test, reporting de test et évaluation Parmi les sorties de la gestion des changements, on trouve : • les RFC rejetés et approuvés • services nouveaux ou changés, les CI, les actifs • PSO ajustés • mise à jour du calendrier des changements • décisions des changements, actions, documents, enregistrements et rapports La gestion des changements s’interface avec les évolutions du métier, les programmes et les projets, ainsi qu’avec les sous-traitants et les partenaires. Interfaces avec d’autres processus de gestion des changements : • Gestion des Actifs et des configurations – le système de gestion des configurations (CMS) fournit des informations qui aident à déterminer l’impact des changements proposés et à les tracer ; elle montre aussi quels CI (ceux non inclus dans la RFC) ont été le plus affectés par le changement ; la figure 11.5 montre comment le changement et la gestion des configurations collaborent ensemble.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

254

• Gestion des problèmes – la gestion des problèmes est l’un des processus qui soumet le plus fréquemment des RFC et qui contribue énormément aux discussions du CAB. • Gestion de la continuité des services informatiques – ce processus a plusieurs procédures et plans qui sont mis à jour par le processus de gestion des changements. • Gestion de la sécurité informatique – tous les changements liés aux questions de la sécurité sont traités par le processus de gestion des changements. • Gestion des capacités et de la demande – une mauvaise gestion de la demande débouche sur plusieurs risques majeurs ; la gestion de la capacité joue une part importante dans l’évaluation des changements.

Gestion des changements Établir & enregistrer la demande de changement

Examiner un changement

Approuver / rejeter un changement

Coordonner l’implémentation d’un changement*

Passer le changement en revue

Clôturer le changement

Elément d’audit

Vérifier les enregistrements mis à jour

Mettre en production et distribuer des CIs nouveaux / modifiés

Gestion des configurations

Reporting & audits

Identifier des éléments affectés

Mettre à jour les enregistrements

Établir des bases de référence pour la mise en production et l’environnement

Système de Gestion des configurations (CMS) *Includes build and test where applicable

Figure 11.5  Flux de la gestion des changements et de la gestion des configurations

Métriques Parmi les KPI du processus de gestion des changements, on trouve : • Le nombre de changements mise en œuvre qui correspondent aux spécifications du client. • Les avantages du changement comparés aux coûts. • La réduction du nombre d’interruptions de service. • La réduction du nombre de changements non autorisés. • La réduction du nombre de retours-arrière. • Taux de succès des changements après évaluation, comparé au nombre de RFC approuvés. • La réduction du nombre de changements non planifiés. Exemples de métriques pour le processus de gestion des changements : • Métriques sortantes : – nombres de défaillances, incidents et problèmes dus aux changements – nombre de spécifications inexactes pour un changement

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

255

– nombre d’analyses incomplètes des impacts – charges de restauration du service en raison de spécifications erronées du changement • Métriques des charges de travail : – fréquence des changements – nombre de changements • Métriques des processus : – Satisfaction des utilisateurs en fonction de la rapidité, de la clarté et de la facilité d’utilisation. – Nombre de changements qui suivent la procédure officielle de gestion des changements. – Ratio des RFC planifiées par rapport aux RFC non planifiées. – Ratio de RFC acceptées par rapport aux RFC rejetées. – Utilisation du personnel. – Coûts par rapport au budget.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

256

Les fondamentaux de la gestion des services informatiques selon ITIL V3

11.3 Gestion des actifs de service et des configurations Introduction La gestion des actifs de service et des configurations (Service Asset and Configuration Management – SACM) fournit un modèle logique de l’infrastructure informatique. Dans ce modèle, les services informatiques sont liés à différents composants informatiques nécessaires pour fournir ces services. L’objectif est  de définir les services et les composants d’infrastructure, et de maintenir des enregistrements précis de la configuration. Dans ce contexte il est important que : • L’intégrité des actifs de service et les éléments de configuration (CI) soient protégés. • Tous les actifs et les CI se trouvent dans le système de la gestion de la configuration. • Les processus opérationnels et de gestion des services sont supportés de façon efficace.

Périmètre Tous les actifs qui sont utilisés pendant le cycle de vie des services tombe dans le périmètre de la gestion des actifs. Le processus offre une vue d’ensemble complète des actifs, et montre qui est responsable du contrôle et de la maintenance de ces actifs. La gestion des configurations assure que tous les composants (éléments de configuration, CI), qui forment une partie du service ou du produit, sont identifiés, intégrés dans une configuration de référence (baseline) et maintenus. Elle gère tous les changements relatifs à ces composants et approuve les nouvelles versions. Le processus fournit aussi un modèle logique de tous les services, actifs, infrastructure physique et relations réciproques. SACM a aussi un lien aux actifs et CI non informatiques, comme les documents qui supportent le développement des services et les éléments de configuration, ainsi que ceux qui soutiennent des services mais qui ne sont pas considérés des actifs. Le périmètre du processus comprend également les actifs et les CI des autres fournisseurs (actifs partagés), du moment qu’ils sont associés au service.

Valeur pour l’entreprise SACM augmente la visibilité et la performance du service, de la mise en production ou de l’environnement. Ceci aboutit notamment sur : • une meilleure prévision et planification des changements • des changements et des mises en production qu’il est possible d’évaluer, planifier et réaliser correctement • des incidents et problèmes à résoudre selon les accords du SLA • un meilleur respect des normes, obligations légales et réglementaires (réduction des nonconformités) • facilité d’identification des coûts associés au service

Politiques La première étape consiste à développer et maintenir les politiques de SACM qui définissent les objectifs, le périmètre, les principes et les facteurs clés de succès pour atteindre les objectifs du processus. L’implémentation de SACM demande des budgets et des ressources considérables.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

257

Des décisions et des priorités sont à prendre au niveau stratégique. Beaucoup de fournisseurs de services informatiques tendent initialement à se focaliser sur les actifs IT de base (matériel et logiciels) et les services qui sont de première importance pour l’entreprise, ou qui sont nécessaires pour se conformer aux lois et réglementations, comme SOX ou les licences de logiciels.

Points de départ La politique décrit le point de départ pour développer et contrôler les actifs et les CI. Celle-ci s’appuie sur : • Les coûts de SACM en fonction des risques potentiels sur le service en l’absence de sa mise en œuvre. • Le besoin de fournir des spécifications pour la gouvernance d’entreprise. • Le besoin de garantir les accords dans les SLA et les autres contrats. • Les spécifications pour des services disponibles, sûrs et rentables. • Les spécifications pour les critères de performance. • La transition depuis la maintenance réactive au contrôle proactif. • L’exigence de garder à jour des informations pertinentes sur les actifs et les configurations pour les parties prenantes.

Client

Package des niveaux de service (SLP)

Contrat

Portefeuille de services

Cœur de métier, banque

Service fourni par

Service de support pour le e-banking

Disponibilité

Soutenu par

Perception de l’utilisateur

Application

Logique métier

Domicilié

Messagerie

Service d’hébergement des applications

Service de données

Uses

Service Web

Topologie du réseau

Figure 11.6  Un exemple de modèle de configuration logique

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Service d’infrastructure technique

Identification

Service réseau

258

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Concepts de base En maintenant des relations entre les CI, un modèle logique des services, des actifs et de l’infrastructure (Figure 11.6) est créé. Celui-ci fournit aux autres processus des informations précieuses, pour notamment : • analyser les impacts pour les changements proposés • examiner les causes des incidents et des problèmes • planifier et concevoir des changements, mettre à jour des logiciels et rafraîchir la technologie • planifier des packages de mise en production et de déploiement • optimiser l’utilisation des actifs et des coûts ITIL définit un élément de configuration comme suit : Un élément de configuration est un actif, un composant de service ou un autre élément qui est (ou sera) maîtrisé par la gestion des configurations.

Il existe plusieurs types de CI, tels que : • CI de cycle de vie des service – CI pour le support des activités du cycle de vie des services, tel que le dossier business, la mise en production et les plans de changement. • Les CI de service, comme la capacité des services, les actifs de ressource des services, les modèles de service, les packages de mise à jour et les critères d’acceptation de service (SAC). • Les CI organisationnels, comme la documentation relative à la stratégie de l’organisation. • Les CI internes, comme ceux associés à des projets individuels. • Les CI externes, comme les spécifications des clients externes et les accords. • Les CI d’interface nécessaires pour la fourniture d’un service de bout en bout à travers une interface de fournisseur de services (Service Provider Interface – SPI) ? Afin de gérer des services informatiques importants et complexes et des infrastructures, SACM a besoin d’utiliser un système de soutien : un système de gestion des configurations. Dans le domaine des services informatiques, l’acronyme CMS est utilisé aussi pour Content Management System (système de gestion de contenu). Dans le contexte de ce livre, nous utiliserons l’acronyme CMS pour désigner le Configuration Management System (système de gestion des configurations). Un CMS se compose généralement de quatre couches : • une couche de présentation avec différentes vues pour différents objectifs. • une couche de traitement de la connaissance pour, par exemple, produire les rapports et des requêtes d’information. • une couche d’intégration de l’information qui collecte et structure les données. • une couche de données avec des données et des informations de différentes sources, comme les bases de données de gestion des configurations (CMDB), des outils de découverte et d’inventaire, des informations sur les projets, etc. Au niveau des données, le CMS peut récupérer ses données de différentes CMDB qui, ensemble, forment un CMDB fédérée. En pratique, il arrive souvent que certains éléments d’un service soient externalisés, tandis que d’autres sont fournis en interne. Par exemple, le réseau est sous

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

Presentation Layer

Portal

Vue pour la Gestion des Changements et les Mises en Production Schémas/plans Statut de la demande de changement Agenda et compte-rendu du CAB

259

Vue pour le cycle de vie des configurations Configurations de projet Stratégie de services Conception, Transition Opérations, Bases de référence de configuration et changements

Vue pour Gestion des Actifs Gestion des Actifs financiers Reporting des statuts des Actifs Comptes et factures, Gestion des licences Performance des Actifs

Vue pour Configuration Technique Applications de service Environnement applicatif Infrastructure d’environnement de test

Vue pour la Gestion de la Qualité Gestion des Actifs de Services et des Configurations (SACM), Politiques, Procédures, formulaires, modèles, check lists

Vue pour le Centre de Services Actifs de l’utilisateur Configuration de l’utilisateur, Changements, Mises en Production Actifs et Eléments de configuration et incidents liés, problème, contournements, changements

Rechercher, stocker, collecter, mettre à jour, publier, abonner, collaborer

Couche de traitement de la connaissance

Requête et analyse

Gestion de la performance Prévision, planning, budgétisation

Reporting

Modélisation

Surveillance Listes de scores, tableaux de bord, alertes

Business/client/fournisseur/utilisateur Service – Application – plan d’infrastructure Couche d’intégration d’information

Portefeuille de services Catalogue de services

Processus normal, données et modèle d’information

Modèle de service

Plan de schémas

CMDB intégrée

Gestion des métadonnées

Réconciliation de données

Mise en production de service

Synchronisation de données

Changement de services

Extraire, Transformer, Charger

Extraction

Data Integration

Données et Sources d’information et Outils

Bibliothèque des documents projet

Structuré

Logiciel projet

Bibliothèque de supports définitifs Bibliothèque des documents définitifs

CMDBs physiques

CMDB1 CMDB2

Bibliothèque des multimédia définitifs 1 CMDB3

Plateforme Outils de configuration p.e. base de stockage middleware réseau mainframe PC distribué Portable

Configuration de logiciels Gestion

Inventaire, Gestion des Actifs et outils d’audit

Applications d’entreprise Gestion des Accès Ressources Humaines Gestion Logistique Gestion de relation client (CRM)

Bibliothèque de supports définitifs 2

Figure 11.7  Exemple d’un CMS

traité au fournisseur de services A et la gestion du serveur est confiée au fournisseur de service B, tandis que la gestion de l’application est effectuée par l’entreprise elle-même. Dans ce cas, le CMS a besoin de données de trois différentes CMDB, chacune contrôlée par trois unités différentes. Dans la mesure du possible, utilisez des outils automatiques (comme les outils de découverte, d’inventaire et d’audit) pour alimenter et maintenir la CMDB. Cela réduit les risques d’erreurs et les coûts. ITIL définit diverses bibliothèques : • Une bibliothèque sécurisée est une collection de logiciels et de CI électroniques (documents) ou d’un type ou d’un statut connus. • Un magasin sécurisé est un endroit sécurisé où les actifs informatiques sont conservés. • La bibliothèque des supports définitifs (DML) est un lieu sécurisé dans lequel les versions définitives autorisées (approuvées) de tous les CI sont conservées et surveillées. • Les Pièces de rechange définitives et approuvées sont stockées de façon sécurisée. Toutes les bibliothèques de supports physiques et électroniques doivent pouvoir être identifiées individuellement et documentées dans le CMS. Une base de référence des configurations (configuration baseline) est une configuration d’un service, d’un produit ou d’une infrastructure qui a été officiellement revue et approuvée après. Elle constitue alors la base pour des activités futures. Elle ne peut être modifiée que conformément à des procédures officielles de changement. Une base de référence est utilisée entre autres pour :

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

260

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Constituer un point de repère dans le développement d’un service (base de référence de la conception de service). • Construire un composant de service à partir d’un nombre d’entrées définies. • Changer ou reconstruire des versions spécifiques lors d’une étape ultérieure. • Rassembler les composants importants prêts à être mis en production ou modifiés. • Servir de retour-arrière dans le cas d’un problème avec de nouvelles configurations (suite à des changements). Les configurations de référence sont intégrées dans le CMS. Un instantané (snapshot) représente le statut le plus récent d’un CI ou d’un environnement (par exemple, lors de son inventaire par un outil de collecte d’information). Un instantané est conservé dans le CMS comme un enregistrement historique, dont seule la lecture est possible. Il ne peut donc pas être modifié. Un instantané : • permet à la gestion des problèmes d’analyser la situation au moment où l’incident s’est produit • facilite la récupération des systèmes pour soutenir des logiciels d’exploration de sécurité

Activités, méthodes et techniques Les activités de base du processus SACM comprennent : 1. gestion et planification 2. identification des configurations 3. contrôle des configurations 4. comptabilisation des statuts et rédaction des rapports 5. vérification et audit

1. Gestion et planification Le management et l’équipe de la gestion des configurations décident du niveau de gestion des configurations nécessaire et comment ce niveau sera réalisé. Cela est documenté dans un plan de gestion des configurations. Le contenu d’un plan de gestion des configurations, inclut : • contexte et objectif • périmètre • exigences • politiques et standards applicables • organisation de la gestion des configurations, y compris les rôles et responsabilités • systèmes et outils SACM • sélection et application des processus et procédures pour implémenter les activités de SACM, y compris identification des configurations, gestion des versions, gestion de construction, etc. • plan d’implémentation de référence • gestion des relations et maîtrise d’interface, par exemple avec la gestion financière des actifs, les projets, les développements, les clients etc. • gestion des relations et maîtrise des fournisseurs de service et sous-traitants

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

261

2. Identification des configurations L’identification des configurations détermine et maintient l’attribution du nom et le numérotage des actifs et des CI, les relations réciproques et les attributs appropriés. Les activités les plus importantes de l’identification des configurations sont : • définition et documentation des critères pour le choix des CI et leurs composants • choisir les CI sur la base de critères prédéfinis • attribuer aux CI des nombres uniques pour faciliter leur identification • spécifier les attributs pour chaque CI • indiquer lorsque chaque CI sera placé sous le contrôle de la gestion des configurations • identifier le propriétaire de chaque CI Créer une structure des configurations pour chaque service informatique. Cette structure montre les relations et la hiérarchie entre les CI pour un certain service. Cette structure des configurations s’appuie sur une approche descendante. Le niveau le plus élevé est le service en question. Le niveau le plus bas de CI est déterminé par : • l’information disponible • le niveau nécessaire de contrôle • les ressources nécessaires pour la maintenance à ce niveau du CI Un CI est intégré uniquement s’il soutient les autres processus de gestion des services. Documentez les conventions d’attribution de nom et les appliquer dans l’identification des CI, les documents et les changements, mais aussi, par exemple, dans les configurations de base, les mises en production et les compilations. Chaque CI doit être identifié de manière unique au moyen d’un numéro de version, puisqu’il peut y avoir plusieurs versions pour le même CI ; par exemple différentes versions d’un logiciel. Lors de la planification des conventions d’attribution de nom, prévoyez un développement futur. Les noms doivent aussi être courts et significatifs, et correspondre le plus possible avec les conventions existantes Fournir tous les CI physiques, comme le matériel, avec des étiquettes, de sorte à faciliter leur identification. Les étiquettes doivent être facilement lisibles et accessibles, de sorte que l’utilisateur puisse communiquer au service d’assistance l’information figurant sur l’étiquette. Les étiquettes avec des codes-barres sont très efficaces lors d’audits physiques des CI. Lors de ces audits, il est vérifié si les CI dans l’organisation correspondent à ceux intégrés dans le CMS. Avec l’aide des attributs, l’information concernant le CI en question est stockée. Lors de la structuration de la CMDB, les attributs suivants peuvent être utilisés : • numéro/étiquette du CI ou numéro du code-barres – identification unique • type de CI • nom/description du modèle • version • emplacement • date de livraison • détails de licence, par exemple, durée limitée

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

262

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• propriétaire • statut • source/fournisseur • documents relatifs • logiciels relatifs • chemin des données/audit historique • type de relation • SLA associée • date d’acquisition • date d’acceptation • statut actuel • statut planifié • valeur d’acquisition • valeur résiduelle après dépréciation • observations Les caractéristiques d’un CI sont souvent enregistrées dans une documentation de la configuration. Le Tableau 11.1 est une matrice RACI (exécutant, responsable, consulté, informé) qui montre différents types de documentation des CI de service indiquant qui prend la responsabilité des documents dans les différentes phases du cycle de vie d’un service. Etape du cycle de vie des services Stratégie de Services

Conception des Services

Transition des Services

Exemple des actifs de cycle de vie des services impactés et CIs impactés Portefeuilles – contrat de service Client – Stratégie des Services Exigences Modèle de Cycle de vie des Services Package de Service (inclus les SLA) Package de Conception des Services, p.e. Modèle de Services, Contrat, Plan de gestion du fournisseur, définition d’interface du processus, plan d’engagement du client, politique de mise en production, définition de package de mise en production Modèle de Transition de Services Plan de test Environnements contrôlés Plan de construction / installation Spécifications de construction Plan de mise en production Plan de déploiement CMS SKMS Package de mise en production Base de référence de mise en production Documentation de mise en production Reporting d’évaluation Fiches de tests

Stratégie de Services A

Conception des Services C

Transition des Services C

Exploitation CSI des Services R C

I

A

C

R

C

I

C

A

R

C

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

Etape du cycle de vie des services Exploitation des Services

Amélioration Continue des Services

Exemple des actifs de cycle de vie des services impactés et CIs impactés Modèle d’Exploitation des Services Modèle de support des services Centre de Services Actifs de l’utilisateur Documentation de l’utilisateur Documentation de l’exploitation Documentation de support CSI model Service improvement plan Service reporting process

263

Stratégie de Services I

Conception des Services C

Transition des Services C

Exploitation CSI des Services A/R R

A

CA

CA

CR

A

Tableau 11.1  Tableau RACI pour documenter les configurations dans le cycle de vie

Le lien décrit comment les CI travaillent ensemble pour fournir un service. La CMDB maintient ces relations pour montrer, par exemple, les interdépendances entre les CI : • Un CI est une partie d’un autre CI – un module d’un logiciel est une partie d’une application (relation père/fils). • Un CI est connecté à – un PC est connecté à un réseau local LAN. • Un CI utilise un autre CI – un service de l’entreprise utilise un serveur. • Un CI est installé sur un autre CI – Word de MS est installé sur un PC. Les relations servent à relier d’autres RFC, incidents, problèmes, erreurs connues et mises en production aux CI. Les relations peuvent être de type 1-à-1, 1-à-n et n-à-1. Les CI sont classés en service, matériel, documentation de logiciel, personnel. Une unité de mise en production est une partie d’un service ou de l’infrastructure qui est mise en production globalement, suivant la politique des mises en production de l’entreprise. Les mises en production sont documentées dans le CMS pour leur support et leur déploiement. Les mises en production peuvent être classées selon les catégories suivantes : • Mises en production majeures – un déploiement important d’un nouveau matériel et logiciel avec, dans la plupart des cas, un accroissement considérable des fonctionnalités (V1.0, 2.0, etc.). • Mises en production mineures – elles contiennent généralement un nombre restreint d’améliorations ; certaines de ces améliorations ont été mises en œuvre précédemment comme des solutions rapides mais sont désormais intégrées dans la nouvelle version (V1.1, V1.2, etc.). • Mises en production urgente – généralement mises en œuvre comme solution temporaire pour un problème ou une erreur connue (V1.1.1, V1.1.2, etc.).

3. Contrôle des configurations Le contrôle des configurations garantit que les CI sont gérés convenablement. Aucun CI ne peut être ajouté, modifié, remplacé ou supprimé sans suivre la procédure convenue. Appliquez les bonnes pratiques et les procédures pour, entre autre : • gestion des licences • gestion des changements Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

264

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• gestion des versions • gestion des accès • contrôle des constructions • promotion • déploiement • installation • configurations de référence (baseline)

4. Comptabilisation des statuts et rédaction de rapports Le cycle de vie d’un composant est classé en différentes étapes vécues par les CI. Celles-ci doivent être documentées convenablement. Par exemple, une mise en production passe à travers les étapes suivantes : enregistrée, acceptée, installée, retirée. Les rapports sur les statuts donnent un aperçu sur les données actuelles et historiques de chaque CI, ainsi que les changements de statut qui se sont produits. Différents types d’actif de service et de rapports des configurations sont nécessaires pour la gestion des configurations. Les rapports peuvent concerner des CI individuels, mais aussi à un service complet. De tels rapports comprennent : • une liste des CI et leur base de référence ; • des détails sur le statut actuel et historique des changements ; • une liste des CI non autorisés détectés ; • rapports sur l’utilisation non autorisée de matériel et de logiciel.

5. Vérification et audit SACM conduit des audits pour s’assurer que : • Il n’y a pas de contradiction entre les bases de référence documentées et l’environnement de travail. • Les CI existent physiquement dans l’organisation ou dans la DML, les caractéristiques fonctionnelles et opérationnelles peuvent être vérifiées  ; les enregistrements dans la CMDB sont conformes à l’infrastructure physique. • La documentation des mises en production et des configurations est présente avant que la mise en production ne soit déployée. Documentez et signalez toutes les exceptions qui résultent des audits. Les actions correctives (les CI qui nécessitent d’être ajoutés, changés ou effacés) sont traitées à travers le processus de gestion des changements. Les audits sont menés aux moments suivants : • directement après des changements du CMS • avant et après des changements importants de services ou de l’infrastructure • à des intervalles aléatoires ou planifiés • avant une mise à jour pour s’assurer que l’environnement est conforme aux attentes • en réponse à la détection des CI non autorisés • après une restauration de service suite à un sinistre

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

265

Les outils d’audit effectuent des vérifications à intervalles réguliers (par exemple chaque semaine). Considérez, par exemple, un outil d’audit pour les ordinateurs de bureau qui compare la configuration des ordinateurs personnels par rapport à une configuration de référence.

Gestion de l’information Lancez les sauvegardes du CMS de manière régulière et conservez-les en un endroit sécurisé dans un autre lieu, pour une restauration suite à un incendie par exemple. Le CMS conserve l’information sur les sauvegardes des CI, l’historique des CI, leurs différentes versions et celles qui sont retirées.

Interfaces Les mises à jour des actifs et des CI sont déclenchées par des demandes de service, des RFC et des nouveaux actifs et CI. SACM s’interface avec tous les autres processus de gestion des services, notamment : Gestion des changements – pour les analyses d’impacts. • Gestion financière – pour un aperçu des coûts, des amortissements, de la maintenance et des réparations. • Gestion de la continuité des services informatiques – afin de rendre l’organisation consciente des actifs dont l’entreprise dépend, et pour le contrôle et la sauvegarde des composants et des logiciels. • Gestion des problèmes et des incidents – pour le diagnostic des problèmes et des incidents. • Gestion de la disponibilité – pour la détection des points de rupture. SACM interagit également avec la mise en production et la gestion de déploiement. Ces processus tirent beaucoup d’avantages d’une approche intégrée avec SACM.

Métriques Les mesures suivantes sont utilisées pour évaluer la performance du processus SACM : • une qualité et une précision accrues de l’information sur les actifs et les CI • moins d’erreurs à cause d’une information obsolète • audits plus courts parce que l’information est plus accessible • temps de diagnostic et de résolution plus courts pour les problèmes et les incidents • peu de contradictions entre la situation réelle et celle enregistrée dans le CMS

Mise en œuvre Le processus SACM doit entre autre relever les défis suivants : • convaincre le personnel qu’ils ne peuvent contourner le processus SACM • trouver des ressources financières et les justifier pour SACM • collecter trop de données parce qu’elles sont simplement disponibles • manque d’engagement du management et de support Les facteurs critiques de succès du processus SACM sont : • déterminer le niveau adéquat de détail et de profondeur • mettre en œuvre une approche hiérarchisée pour la structure des configurations

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

266

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• déterminer le niveau de détail adéquat • utiliser la technologie pour automatiser le CMS et appliquer les bonnes pratiques Les risques suivants sont connus : • trop de focalisation sur la technique et non sur l’opérationnel et le service • le CMS devient incohérent car, par exemple, du personnel non autorisé déplace les éléments matériels

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

267

11.4 Gestion des mises en production et des déploiements Introduction ITIL définit la gestion des mises en production et des déploiements comme : La gestion des mises en production et des déploiements a pour objectif de construire, tester et fournir un ensemble de prestations dédiées à la conception des services, permettant de répondre à un ensemble d’exigences attendues par l’ensemble des parties prenantes. Le but de la gestion des mises en production et des déploiements est de déployer les mises en production, et d’assurer que le client utilise les services de façon efficace. L’objectif de la gestion des mises en production et des déploiements est de garantir que : • les plans de mises en production et de déploiements sont en place • les mises en production groupées (compilation) sont déployées avec succès • le transfert des connaissances aux clients a lieu • il y a un minimum de perturbations aux services

Périmètre Les processus, les systèmes et les fonctions pour le packaging, la construction, le test et le déploiement d’une mise en production et l’établissement du service spécifié dans le package de service avant la livraison finale à l’exploitation des services.

Valeur pour l’entreprise Une gestion efficace des mises en production et des déploiements contribue au métier de la façon suivante : • les changements sont réalisés plus rapidement, moins chers et avec moins de risques, et les objectifs opérationnels sont mieux supportés • l’approche de la mise en œuvre est plus cohérente et les exigences de traçabilité (par ex. les audits, la législation etc.) sont mieux respectées

Concepts de base Une mise en production est un ensemble de CI nouveaux ou modifiés qui sont testés en vue d’une mise en production commune. Une unité de mise en production est une partie du service ou de l’infrastructure qui est intégrée dans la mise en production, conformément aux bonnes pratiques de mise en production de l’organisation. Il est important de déterminer le niveau approprié de la mise en production. Dans le cas d’une application critique (sensible) pour une entreprise, il serait plus sensé de s’appuyer sur une mise en production complète. Celle-ci n’est pas exigée pour la modification d’une simple page web HTML.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

268

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Lors de la conception des mises en production, différentes considérations s’appliquent sur la manière dont la production est déployée. Les options les plus fréquentes lors d’un premier déploiement sont : • Big Bang contre progressif – Une mise en production Big Bang déploie un nouveau service ou un service modifié pour tous les utilisateurs au même moment. Un déploiement progressif déploie la mise en production pour une partie des utilisateurs à un même moment. • Push ou Pull – Avec une approche Push, le composant du service est déployé à partir d’un lieu central à un endroit cible. Avec une approche Pull, la nouvelle mise en production est rendue disponible aux utilisateurs à un endroit central, et l’utilisateur le télécharge sur son poste quand cela lui convient. • Automatisé ou manuel – Les mises en production peuvent généralement être automatisées, en s’appuyant par exemple sur un logiciel d’installation. Les équipes de mise en production et de déploiement doivent s’entendre sur l’architecture informatique concernée, au sein du processus des mises en production et des déploiements. Cette compréhension est essentielle pour déterminer la séquence des activités pour tracer toutes les interdépendances. Un package de mise en production est une unité unique de mise en production ou un ensemble structuré d’unités de mises en production. Dans le cas d’un nouveau service ou d’un service modifié, tous les éléments dont le service est composé – l’infrastructure, le matériel, le logiciel, les applications, la documentation, la connaissance, etc. – doivent être pris en compte. Voir Figure 11.8. Pour différents types de package, voir 11.3 (SACM). Package de Mise en Production A9 V1.9

Documentation utilisateur

Unité de Mise en production applicative

Client Web

Changement sur la base de données

Client service A

Logiciel du serveur central

Documentation de mise en production

Supporting Service A

Supporting Service B

SSAU1

SSAU2

SSAU3

SSAU4

Figure 11.8  Exemple de package de mise en production

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

269

Activités, méthodes et techniques Les activités du processus de base de la gestion des mises en production et des déploiements comprennent : 1. planification 2. préparation pour construction, test et déploiement 3. construction et un test 4. test des services et pilotes 5. planification et préparation du déploiement 6. transfert, déploiement et retrait 7. vérification du déploiement 8. support de début de cycle de vie (ELS) 9. revue et clôture

1. Planification Avant de procéder à une mise en production, différents plans sont élaborés. Leur type et leur nombre dépend de la taille et de la complexité de l’environnement et du service à apporter ou à modifier. Les plans de mise production et de déploiement forment une partie du plan d’ensemble de transition des services. La gestion des changements approuvera ou rejettera les plans. Les plans, dans tous les cas, comportent : • un périmètre, contenu, risques, responsabilités et les parties prenantes de la mise en production • une équipe responsable pour la mise en production • une méthode de collaboration avec les parties prenantes Les (sous) plans suivants concernent la mise en production et le déploiement : • Critère de succès / échec – la transition des services est responsable de la planification des situations de succès / échec pour chaque phase de mise en production et de déploiement. • Plans de construction et de test – les plans de construction et de test sont nécessaire pour décrire l’approche de la construction, du test et de la maintenance de l’environnement de préproduction ; différents environnements sont nécessaires pour chaque type de test : pour le test d’une unité, le test d’une mise en production de service et le test d’intégration. Le modèle en V permet de tracer les différents niveaux de configuration auxquels la construction et le test doivent avoir lieu. Le côté gauche du V commence par les spécifications du service et se termine par la conception détaillée du service. Le côté droit du V reflète les activités de test, et les moyens avec lesquels les spécifications du côté gauche doivent être approuvées. Au milieu se trouvent les critères de test et d’approbation (Figure 11.9). • Planification des pilotes – pour tester le service nouveau ou modifié avec une partie des utilisateurs d’abord, un pilote est nommé ; ne pas oublier d’inclure dans les plans la manière de recueillir et de traiter les remarques des utilisateurs, et de concevoir un scénario de déploiement. • Planification d’un package (compilation) de mise en production et de construction – Elaborez des plans et des procédures pour : – critères de réussite/échec – la gestion des changements et la communication avec les parties prenantes – formation des collaborateurs, transfert de connaissance et détermination du degré de préparation des utilisateurs finaux Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

270

– l’utilisation des ressources (de la gestion des services) – le transfert des systèmes et des utilisateurs à un nouveau service • Planification du déploiement – concernant le déploiement, inclure les considérations suivantes dans le plan : – qu’est-ce qui a été déployé ? – qui sont les utilisateurs ? – quelle est la situation locale ? – où sont les utilisateurs ? – qui d’autre a besoin d’être notifié ? – pourquoi il y a eu un déploiement ? – quels sont les facteurs critiques de succès ? • Planification de la logistique et de la fourniture – une fois que l’approche du déploiement a été décidée, des plans de logistique et de fourniture sont élaborés avec une attention particulière sur les points suivants : – quand et comment seront livrés les composants du service ? – que fera-t-on s’il y a des retards ? – comment gérer les formalités des douanes et les autres conséquences dans le cas de distributions internationales ? • Planification financière et commerciale – les aspects financiers et commerciaux doivent être vérifiés avant de lancer le déploiement.

Niveau 1

Définir exigences Client/Métier

Valider les packages de Services, les offres et contrats

Critères/plans de revue de service

1a Niveau 2

1b Définir exigences de service

Test d’acceptation d’un service

Critères/plans d’acceptation de service

2a

2b Critères/plans d’exploitation des services

Concevoir une solution de service

Niveau 3

3a Concevoir une mise en production de service

Niveau 4

3b Service Release Package Test

Critères/plan de mise en production de service

4a

4b

Développer une solution de service

Niveau 5

5a Niveaux de Configuration et de Tests BL

Test préparatoire d’exploitation

Test de composants et assemblage

Construction et Test des composants de service

5b Fournitures de fournisseurs internes et externes

Base de référence Fournisseurs internes et externes

Figure 11.9  Le modèle service en V reflète la configuration et les niveaux de test

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

271

2. Préparation pour construction (compilation), test et déploiement Avant que l’approbation ne soit donnée pour la phase de construction et de test, la conception du service et de la mise en production est comparée aux spécifications du service nouveau ou modifié (validation). Cette comparaison fait ressortir les risques et les problèmes relatifs au service, aux actifs et aux CI. Les problèmes et les risques sont alors priorisés et des actions sont entreprises pour les résoudre au bon moment. Le rapport d’évaluation des services documente les résultats de la validation.

3. Construction et test La phase de construction et de test de la mise en production s’appuie sur les activités suivantes : • Gestion d’infrastructure générale (commune) et des services – gérer soigneusement les services et les infrastructures communes, car ils peuvent être d’une importance énorme pour la construction et le test. • Utilisation de la documentation de mise en production et de construction – la documentation disponible (procédures, modèles, manuels) est utilisée tout le temps ; cette documentation supporte l’équipe de mise en production dans l’acquisition et l’achat des actifs, les CI, les services et les produits pour la construction d’un package de mise en production intégrée ; dans ce contexte il faut considérer aussi l’authenticité de la licence (il faut avoir la possibilité de produire les licences nécessaires) des divers composants. • Acquisition, achat et test des CI et composants pour la mise en production – les CI et les composants proviennent des projets, des fournisseurs et des partenaires ; les activités d’achat comprennent : – l’enregistrement et la mise à jour des CI dans le CMS – s’assurer que les licences peuvent être produites quand c’est nécessaire ; vérifier aussi pour les CI et les composants la qualité, la légalité et les exigences d’étiquetage et d’attribution d’un nom • Compilation de la mise en production (packaging de la mise en production) – Les activités clés pour la construction et la compilation d’un package de mise en production sont : – assemblage et intégration des composants – préparation de la documentation de compilation et de mise en production – installation et vérification du package de mise en production – création d’une base de référence dans la composition du package – formulation d’un message de service (que le package de mise en production est prêt à utiliser) • Structuration et contrôle des environnements de test – les environnements de test doivent être stables et à même d’être contrôlés.

4. Test des services et pilotes La gestion des tests est responsable de la coordination des activités de test, de la planification et du contrôle de la mise en œuvre. La section 11.5 Validation et Tests de Services décrit en détail la gestion des tests. Dans ce paragraphe nous nous limitons aux tests qui sont menés pendant le processus des mises en production et des déploiements : • Tests des mises en production de service – la mise en production est compilée, installée et testée dans l’environnement cible.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

272

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Test de l’état de préparation de l’exploitation des services – Ce test garantit que le service, les applications sous-jacentes et l’infrastructure technique peuvent être transférés à l’environnement opérationnel de manière contrôlée. • Pilotes – un pilote doit tester s’il y a des éléments du service qui ne remplissent pas les spécifications, ou qui expose l’entreprise à des risques.

5. Planification et préparation du déploiement Ces activités préparent l’équipe de déploiement pour le déploiement. Les notions suivantes doivent êtres prises en compte : • Sont-ils prêts pour la mise en œuvre du package de mise en production ? • Ont-ils préparé le plan d’activité ? • Les risques potentiels ont-ils été prévus ? • Est-ce que chacun est suffisamment formé ? • Y a t-il eu des changements de dernière minute dans les spécifications ? De plus, d’autres aspects que l’équipe devra affronter sont estimés, comme les aspects financiers, le degré de préparation de l’organisation, l’infrastructure et autres facilités et les ressources de gestion des services disponibles. Lors de la planification d’un déploiement spécifique, les plans comprennent : la limitation des risques, les transferts, les mises à jour, les questions de logistique, le transfert de connaissance et la communication. Finalement, ces plans doivent être évalués et une RFC doit être créée et soumise à la gestion des changements pour approbation. C’est à l’issu de cette phase que le service est prêt pour le déploiement.

6. Transfert, déploiement et retrait Les activités suivantes sont importantes durant le déploiement : • Le transfert des actifs financiers – il peut s’agir, par exemple, du transfert des coûts de support et de maintenance, des frais de licence et de réserve pour les imprévus (reprise suite à un sinistre) à une tierce partie. • Transfert et transition du métier et de l’organisation – quand un service ou une unité de service est transféré, l’organisation elle-même doit s’adapter ; prendre en compte par exemple les nouvelles tâches, les autorités et les responsabilités. • Publication de la documentation – distribuez toute la documentation (guides de bonnes pratiques, processus, procédures, manuels) dont les utilisateurs auront besoin pour l’utilisation du nouveau service. • Transfert des aptitudes de la gestion des services – transférez l’information du nouveau processus ou modifié, systèmes et outils à l’équipe qui est responsable des activités de gestion des services. • Transfert du service – les activités concernant ce processus sont : – analyse des performances du service, problèmes et risques – audits des configurations des actifs de service – mise à jour du catalogue des services – distribution de la notification de service • Déploiement du service – toutes les activités nécessaires pour distribuer et installer le service. • Annulation de services – annuler les services redondants. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

273

• Élimination des actifs redondants – éliminer les actifs qui sont redondants suite au service nouveau ou modifié.

7. Vérifier le déploiement Quand toutes les activités de déploiement auront été complétées, il est important de vérifier que tous les utilisateurs, l’équipe d’exploitation des services, les autres collaborateurs et parties prenantes sont capables d’utiliser le service comme prévu. C’est aussi le moment propice au recueil des éléments rétroactifs post déploiement. Il est important d’utiliser ces informations pour l’amélioration des déploiements futurs.

8. Support de début de vie Le support de début de vie (Early Life Support – ELS) offre un support supplémentaire après le déploiement d’un service nouveau ou changé. ELS fournit les moyens pour résoudre les problèmes opérationnels et de support le plus vite possible, ce qui signifie que les utilisateurs n’auront pas à être confrontés à des interruptions de service. Celles-ci peuvent déboucher sur des problèmes ou des améliorations pouvant aider à stabiliser le service. L’équipe de déploiement met à jour aussi la documentation pendant la phase d’ELS et met à jour la base des connaissances avec des informations de diagnostic, des erreurs connues, des solutions de rechange et des FAQ. La transition des services assurera le suivi des performances du service nouveau ou modifié durant la phase d’ELS jusqu’à ce que tous les critères de sortie soient satisfaits, y compris : • Tous les utilisateurs sont capables d’utiliser le service de manière rentable et efficace. • Les propriétaires de services et de processus sont capables de gérer le service. • Le service convenu et les niveaux de performance sont réalisés.

9. Revue et clôture Dans la revue d’un déploiement, vérifier si : • Le transfert des connaissances et la formation ont été adéquats. • Toutes les expériences des utilisateurs ont été documentées. • Toutes les réparations et les changements sont terminés et tous les problèmes, les erreurs connues et les solutions de contournement ont été documentées. • Les critères de qualité ont été respectés. • Le service est prêt pour la transition d’ELS à la production. Vérifier aussi les questions qui doivent être transmises au CSI. Le déploiement est terminé quand le support est transféré à l’exploitation. C’est à l’issu de ces opérations que la gestion des changements effectuera une revue post implémentation (PIR). Pour finaliser la transition des services dans son ensemble, une évaluation officielle doit être effectuée. Celle-ci est ajustée à l’échelle et au périmètre du changement.

Gestion de l’information Quand des CI ont été déployés avec succès, le CMS est mis à jour avec des informations comme : • CI nouveaux ou changés • liens entre exigences et tests Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

274

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• plans d’installation et de construction • plans de logistique et de fourniture • plans de validation et de test • emplacements et utilisateurs nouveaux ou changés • statut mise de à jour • changements de propriétaires (des actifs et des CI) • licences Parallèlement, l’information documentée pour le système de gestion des connaissances des services, comme l’information sur le déploiement, la formation et les erreurs connues, sont éventuellement nécessaires.

Interfaces Le processus de mise en production est déclenché par une RFC approuvée. Les entrées pour le processus des mises en production et des déploiements sont : • RFC approuvées, package d’un service, SLP, SDP, SAC, plans de continuité. • Politiques de mise en production, conception et modèle, modèle de construction et plan. • Technologie, achat, gestion des services et standards des opérations et plans. • Critères de sortie et d’entrée pour chaque phase de la mise en production et du déploiement. Les sorties du processus des mises en production et des déploiements sont : • Plans de mise en production et de déploiement, RFC complétée, notifications de service, catalogue des services mis à jour et modèle de service. • Documentation d’une gestion de service nouveau ou changé et rapports de service. • Nouvelles aptitudes et environnements de service testés • SLA, OLA et contrats. • Rapport de transition des services et plan des capacités de service. • Liste de CI complète et précise avec trace d’audit des CI dans le package de mise en production, et les configurations de service nouveau ou changé et d’infrastructure.

Métriques Exemples de KPI liés aux clients : • L’amélioration de la performance du service. • La diminution du nombre d’incidents. • L’amélioration de la satisfaction du client et de l’utilisateur. Exemples de KPI liés aux fournisseurs : • Coûts moins élevés pour le diagnostic des incidents et problèmes. • Diminution du nombre d’incohérences entre les audits de configuration et la situation réelle.

Mise en œuvre Les défis dans le processus des mises en production et des déploiements sont : • Le développement de mesures de performance et de méthodes standards pour les projets et les fournisseurs. • Dépendance des projets et des fournisseurs.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

275

• Compréhension de tous les risques pouvant affecter la transition des services. • Comprendre les perspectives et les points de départ des différentes parties prenantes. Les facteurs critiques de succès dans le processus des mises en production et des déploiements sont : • Tout service nouveau ou modifié fonctionne dans l’environnement cible et est confronté à la conception de services. • Tout service nouveau ou modifié est éprouvé par un pilote. • Les modèles de tests sont réutilisables pour les tests de régression lors des mises en production futures. Les risques dans le processus des mises en production et des déploiements sont : • Manque de clarté dans les attentes et objectifs des différentes parties prenantes  ; des rôles, tâches et responsabilités mal définis. • Gestion incompétente, ressources financières insuffisantes, manque de contrôle, gestion des changements faible. • Relations médiocres avec les partenaires et les fournisseurs de services, support (engagement) insuffisant de la part des parties prenantes. • Risques liés à l’infrastructure technique et aux applications.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

276

Les fondamentaux de la gestion des services informatiques selon ITIL V3

11.5 Validation et tests des services Introduction Le test des services fournit une contribution importante à la qualité de la fourniture des services informatiques. Le test garantit que les services nouveaux ou modifiés sont adaptés aux objectifs et adaptés à l’usage (fit for purpose et fit for use). Adapté aux objectifs signifie que le service fait ce qui est attendu par le client, de sorte que le service supporte l’entreprise. Adapté aux objectifs concerne les aspects comme la disponibilité, la continuité, la capacité et la sécurité du service. Une attention insuffisante sur le test peut aboutir à : une augmentation du nombre des incidents, problèmes et erreurs, des appels téléphoniques supplémentaires au service desk à propos du fonctionnement du service, des coûts élevés et un service utilisé incorrectement. Le but de la validation et des tests des services est de fournir au client une prestation à haute valeur ajoutée. L’objectif de la validation et des tests des services est d’assurer que : • la mise en production fournit la valeur et les résultats attendus par le client dans le cadre des coûts, de la capacité et des contraintes prévus • les services sont adaptés à l’objectif et à l’usage • les spécifications (exigences) du client et des autres parties prenantes sont satisfaites

Périmètre La validation et les tests des services sont appliqués durant tout le cycle de vie de la prestation. Ils visent à tester la qualité du service, pour vérifier si les capacités et les ressources du fournisseur de services sont suffisantes pour fournir avec succès une prestation complète et/ou une mise en production. Le test apporte aussi un soutien important au processus de gestion des mises en production et des déploiements. De plus, le processus d’évaluation utilisera les résultats des tests.

Valeur pour l’entreprise Les interruptions de service peuvent être préjudiciables au métier du fournisseur de services, et aux clients qui y recourent. Elles pourraient porter préjudice à la réputation, entraîner des pertes financières et même des accidents (fatals). Par exemple, le rôle des services informatiques dans les hôpitaux, l’industrie automobile et l’aéronautique peut mener à de graves blessures, voire être cause de décès si la fourniture des services faillit.

Concepts de base Le modèle de service décrit la structure et la dynamique d’un service fourni par l’exploitation des services. La structure consiste en des services de base et des services supports et des actifs de service nécessaires. Quand un service nouveau ou modifié est conçu, développé et construit, ces actifs de service sont testés par rapport aux spécifications et aux exigences de la conception. Les activités, les ressources de flux, la coordination et les interactions décrivent la dynamique (voir Figure 11.10).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

277

(Structure) Modèle de service

Configuration d’actifs de service (Conception de Service)

Activités, événements et interactions (Conception de Service)

Exploitation des Services

(Dynamique)

Figure 11.10  Le modèle de service détermine la structure et la dynamique d’un service

Les politiques pour la validation et les tests des services sont : • politiques de la qualité des services • politiques des risques • politiques de réutilisation • politiques de transition des services • politiques des mises en production • test intégral obligatoire • tester toutes les parties prenantes • politiques de gestion des changements La stratégie de test définit l’ensemble de l’approche des tests et l’allocation des ressources nécessaires. La stratégie peut être appliquée à l’ensemble de l’organisation, à un ensemble de services ou à un seul service. Toutes les stratégies des tests sont développées en collaboration avec les parties prenantes. L’attention est prêtée aux objectifs, périmètre, standards, processus de test, mesures de test, approche de test, besoins en ressources humaines, moyens et livrables. Un modèle de test consiste à définir un plan de test, l’objet à tester et les scripts de test qui indiquent la méthode par laquelle chaque élément doit être testé. Afin de s’assurer que le processus peut être répété, les modèles de test doivent être structurés de façon à ce que : • Les critères de spécifications et de conception testés soient tracés. • Les activités de test, l’évaluation et les rapports peuvent être audités. • Les éléments de test peuvent être maintenus et modifiés. Que le test soit efficace ou pas, il sera en partie déterminé par le degré auquel le service satisfait aux exigences. Ces exigences, à leur tour, sont basées sur les perspectives de ceux qui utilisent, fournissent, déploient ou gèrent le service. Le package de conception de service définit alors les critères d’entrée et de sortie pour toutes les perspectives de test. En utilisant des modèles de test, comme un modèle en V (Figure 11.9), le processus Validation et Tests intègre très tôt le cycle de vie de ces services. Le modèle en V fournit un cadre important

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

278

Les fondamentaux de la gestion des services informatiques selon ITIL V3

pour organiser les niveaux auxquels les CI doivent être gérés. Cela aide aussi à déterminer les activités de test à mener. Les tests peuvent avoir lieu à différents niveaux. D’innombrables techniques et approches de test existent. La technique et l’approche dépend du type de service, du profil du risque, du but et du niveau du test. Ces exemples comprennent : revue du document, modélisation, simulation, test par scénario, jeu de rôle et test en laboratoire, pilote en situation réelle. Les considérations de conception qui sont importantes pour les tests concernent les finances (le budget est-il suffisamment élevé ?), la documentation (est-ce que tout est disponible, et dans le format convenable ?), la composition (construction), la testabilité (penser aux ressources, au temps et aux installations), la traçabilité (par rapport aux spécifications), quand et où le test sera effectué, et la restauration (y a-t-il un plan de sauvegarde ?). Il faut également prendre en compte lors de la conception, les données de gestion et de maintenance du test. Cela concerne la séparation des données de test et des données opérationnelles, les règles de sécurité des données, la sauvegarde des données du test, etc. En plus de tous les de types de test fonctionnels et non fonctionnels, une distribution des rôles est également possible, basée sur les perspectives suivantes : • Test des exigences de service adapté aux objectifs (fournisseur de services, utilisateurs et client) – est-ce que le service satisfait les spécifications prévues ? • Test du niveau de service (les gestionnaires du niveau de service, les gestionnaires opérationnels et les clients) – cela teste si le nouveau service satisfait les niveaux de service prévus. • Test d’assurance du service, adapté à l’usage (client) – pour vérifier la disponibilité, la capacité, la continuité et la sécurité. • Test d’utilisation (utilisateurs et mainteneurs) – pour vérifier la convivialité et l’utilisation pour des groupes spécifiques comme des utilisateurs malvoyants. • Test des règlements et des contrats (fournisseurs de services) – cela s’applique aux fournisseurs de services qui doivent (contractuellement) satisfaire à la norme ISO/IEC 20000 et aux industries qui doivent se conformer à des règlements spécifiques comme le Ministère de la Défense ou l’industrie pharmaceutique. • Test de gestion des services (fournisseur de services) – ISO/IEC 20000 peut être utilisé dans cette perspective ; ISO/IEC 20000 indique les exigences minimales que les processus doivent satisfaire. • Test opérationnel (système, service) – il peut s’agir de test de stress, de sécurité et de facilité de rétablissement. • Test de régression – aptitude à reproduire les tests (réussis) précédents afin de comparer les nouveaux résultats avec les précédents (mesure des écarts).

Activités, méthodes et techniques La figure 11.11 présente un schéma du processus de tests. Les activités ne sont pas nécessairement effectuées en ordre, elles peuvent également avoir lieu en parallèle. Les activités suivantes peuvent être distinguées : 1. gestion de la validation et des tests 2. planification et conception

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

279

3. vérification du plan et de la conception des tests 4. préparer l’environnement de test 5. test 6. évaluer les critères de sortie et reporting 7. nettoyage et clôture

RFC autorisé (avec analyse d’impact et ressources) Conception évaluée (SDP, SAC)

Évaluation de service (E2, En)

1. Gestion de Tests

2. Planifier et concevoir les tests

3. Vérifier le plan et la conception des tests

4. préparer environnement de tests

5. effectuer les tests (voir table suivant)

6. évaluer les critères d’abandon et le reporting

7. nettoyage de l’environnement de tests et clôture

Revise tests to deliver required results

Figure 11.11  Schéma du processus de test

1. Gestion de la validation et des tests La gestion de tests consiste en la planification et la gestion (contrôle), la préparation de rapports sur les activités ayant lieu pendant toutes les phases de test de la transition des services. Ceci contient les activités suivantes : • Planification des ressources, de ce qui a été testé et à quel moment. • Gestion des incidents, problèmes, erreurs, écarts, questions, risques (y compris lors de la découverte dans la phase de transition). • Collecte des mesures de test ; analyse, rapports et gestion.

2. Planification et conception Les activités de planification de test et de conception ont lieu tôt dans le cycle de vie des services et sont liées à : • ressources comme le matériel, réseau, nombre des collaborateurs, capacité, aptitude et finances • ressources métier requises • services de support • planification des jalons, de la fourniture et de la recette

3. Vérification du plan et de la conception des tests Les plans et la conception des tests sont vérifiés pour être sûr que tout (y compris les scripts) soit complet, et que les modèles de test prennent suffisamment en compte les risques du service en question et toutes les interfaces éventuelles.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

280

Les fondamentaux de la gestion des services informatiques selon ITIL V3

4. Préparation de l’environnement de test Préparez l’environnement de test et établissez une configuration de référence de l’environnement.

5. Test Les tests sont exécutés en utilisant des techniques et des procédures, manuels ou automatiques, de test. Les testeurs enregistrent tous les résultats. Si un test échoue, la raison en est documentée. Procédez au test minutieusement selon les plans et les scripts du test. Documentez la cause de l’échec.

6. Évaluez les critères de sortie et reporting Les résultats réels sont comparés aux résultats projetés (critères de sorties). Les résultats du test peuvent être interprétés en termes de succès/échec (approbation ou non). Tout risque sur l’objet testé peut impacter le fournisseur de services ou le client, ou se traduire par une augmentation des coûts pour atteindre les objectifs fixés. Collectez les résultats du test et compilez le rapport. Voici des exemples de critères de sortie : • Le service testé est conforme aux exigences de qualité. • L’infrastructure du service informatique et le support permettront à l’utilisateur d’effectuer toutes les fonctions comme prévu initialement. • Les configurations de référence sont saisies dans le CMS.

7. Nettoyage et clôture Assurez-vous que l’environnement de test est nettoyé. Évaluez l’approche du test et identifiez les améliorations.

Gestion de l’information La réutilisation est très avantageuse pour les tests, et pour cette raison il est conseillé de créer une bibliothèque des tests utiles et de s’assurer de sa mise à jour. Notez aussi la façon dont ces tests doivent être effectués et mis en œuvre. Quelle que soit sa qualité de conception, un test sans de bonnes données de test est inutile. Prenez donc soin des données de test. Pour cette raison, il est important que : • Les données de test et les données opérationnelles soient séparées. • Les règles de protection des données soient pris en compte. • Les procédures de sauvegarde et de récupération soient respectées.

Interfaces Le test est déclenché par l’activité de test planifiée dans un plan de mise en production, plan de test ou plan d’assurance qualité. Les entrées du processus de test et de validation sont : • les prestations de service et le package des niveaux de service (SLP) • les définitions d’interface par le fournisseur de services • un package de conception de service

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

281

• les plans de mise en production et de déploiement • les critères d’acceptation et RFC Les sorties du processus de test et de validation sont : • la configuration de référence de l’environnement de test • les tests effectués • les résultats des tests • analyse des résultats • rapport des incidents de test, problèmes de test et erreurs de test • suggestions d’amélioration (pour CSI) • données mises à jour • information et connaissances pour le système de gestion de connaissances Les tests supportent toutes les étapes de mise en production et de déploiement dans le processus de transition des services. De plus, un test est lié à la conception des services, CSI, exploitation des services et stratégie des services.

Métriques L’efficacité d’un test selon une perspective du client (externe) peut être mesurée par : • Réduction de l’impact des incidents et des erreurs dans la production qui peuvent être attribués aux services récemment installé. • Utilisation plus efficace des ressources, et implication du client (par ex. les tests de recette utilisateur). • Une meilleure compréhension par toutes les parties prenantes des rôles et des responsabilités liés au service nouveau ou modifié. Liés au fournisseur (interne) : Le processus de test doit être exécuté de manière aussi rentable et efficace possible. Les mesures potentielles à prendre sont : • Réduction des efforts et des coûts lors de la mise en place de l’environnement de test. • Réduction d’effort nécessaire pour découvrir les erreurs et réduction en nombre des erreurs répétées. • Réutilisation des données de test. • Réduction du pourcentage des incidents liés aux erreurs découvertes durant le test. • Nombre d’erreurs connues documentées pendant les phases précédentes de test.

Mise en œuvre Le grand défi à relever est la prise en compte sérieuse des tests par les organisations. Ce qui se traduit couramment par une absence de budget dédié. Les facteurs clés de succès sont : • Les problèmes sont identifiés très tôt dans le cycle de vie. • La qualité est intégrée à chaque phase du cycle de vie, par exemple en utilisant le modèle en V. • Des modèles de test réutilisables sont conçus, et les tests offrent la preuve que toutes les configurations ont été construites et mises en œuvre conformément aux exigences du client.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

282

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les risques sont : • Attentes et objectifs peu clairs, manque d’appréciation qu’un test est un processus clé lié à la qualité de fourniture des services. • Manque de ressources.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

283

11.6 Évaluation Introduction ITIL définit le processus d’évaluation comme : L’évaluation est un processus global qui vérifie l’adéquation entre les investissements financiers qui pourraient être engagés au regard des performances attendues. L’objectif du processus d’évaluation ITIL est de déterminer les performances d’un changement de service. Ces performances sont évaluées sur la base des performances prévues.

Périmètre Dans cette section, le périmètre est limité à l’évaluation des services nouveaux ou modifiés.

Valeur pour le métier L’évaluation fournit une entrée importante pour le CSI, pour l’amélioration future du développement de service et la gestion des changements.

Politique, points de départ et concepts de base Les politiques suivantes sont appliquées : • La conception des services et les changements de service sont évalués avant la transition réelle. • Tous les écarts entre les performances prévues et réelles sont gérés par le client (agent), exemple : recette ou refus. • Le client est impliqué dans l’évaluation. Les points de départ suivants sont importants dans l’exécution du processus : • Les effets imprévus d’un changement (et ses conséquences) doivent être identifiés. • Un changement de service est évalué équitablement, de manière cohérente, ouvertement et objectivement.

Activités, méthodes et techniques Le processus d’évaluation consiste à mettre en œuvre les activités suivantes : 1. planification de l’évaluation 2. évaluation de la performance prévue 3. évaluation de la performance réelle

1. Planification de l’évaluation Quand une évaluation est planifiée, les effets voulus et non voulus sont analysés. Les effets voulus doivent satisfaire les critères de recette ; ceux non voulus sont souvent longtemps invisibles et difficiles à prédire.

2. Évaluation des performances prévues Effectuez une appréciation du risque basée sur les exigences du client (y compris les critères de recette), les performances prévues et le modèle de performance. Envoyez un rapport d’évaluation provisoire à la gestion des changements si l’évaluation montre que les performances prévues

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

284

Gestion des changements

Conception des Services

Tests

Demande de Changement (RFC)

Package de Conception de Services

Plan de Tests et Résultat

Planifier l’évaluation

Evaluer la performance prévue

Performance prévue OK?

Non

Reporting intermédiaire d’évaluation

Gestion des changements

Oui Evaluate Actual Performance

Actual Performance OK? Oui

Non

Reporting intermédiaire d’évaluation

Gestion des changements

Reporting d’évaluation

Gestion des changements

Figure 11.12  Processus d’évaluation

représentent un risque inacceptable au changement ou dévie des critères de recette. Arrêtez les activités d’évaluation en attendant une décision de la gestion des changements.

3. Évaluation des performances réelles Après la mise en œuvre d’un changement de service, l’exploitation des services mesure les performances réelles. Effectuez une deuxième appréciation du risque, basée encore sur les exigences du client (y compris les critères de recette), les performances prévues et le modèle de performance. Envoyez un nouveau rapport d’évaluation provisoire à la gestion des changements si l’évaluation montre que les performances réelles représentent un risque inacceptable, et arrêtez les activités d’évaluation en attendant une décision de la part de la gestion des changements.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

285

Envoyez un rapport d’évaluation à la gestion des changements si l’évaluation est approuvée Un tel rapport contient un profil de risque, une déclaration de qualification et de validation (si nécessaire), et une recommandation (accepter ou refuser le changement).

Interfaces Les déclencheurs pour le processus d’évaluation sont : • une demande d’évaluation du gestionnaire de transition des services ou de la gestion des changements • une activité d’évaluation dans le plan du projet Entrée pour le processus d’évaluation : • le package de conception de service (SDP) • critères de recette de service (SAC) • rapports de test • résultats Le rapport d’évaluation représente la sortie.

Métriques Les KPI liés au client pour l’évaluation sont : différences dans les performances de service (minimale et diminuant) et le nombre d’incidents (faible et diminuant). Les KPI internes pour évaluation sont : le nombre de conceptions échouées (zéro) et temps d’évaluation (faible et diminuant).

Mise en œuvre Les défis comprennent : Retards sur le calendrier d’évaluation en raison des retards sur les projets et les fournisseurs. • Le développement de méthodes de mesure des performances standards et la création d’une culture de gestion des risques. • Considérez les risques depuis diverses perspectives et construisez une perception de l’impact des risques sur la transition des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

286

11.7 Gestion des connaissances Introduction L’objet de la gestion des connaissances est d’améliorer la qualité du processus (de gestion) de prise de décision en garantissant qu’une information fiable et sécurisée soit disponible durant le cycle de vie des services. Les objectifs de la gestion des connaissances, entre autres, sont : • Soutenir le fournisseur de services afin d’améliorer l’efficacité et la qualité des services. • Garantir que l’encadrement du fournisseur de services dispose d’une information adéquate.

Périmètre La gestion des connaissances est utilisée à travers la totalité du cycle de vie. Dans la version 3 d’ITIL, le livre sur la transition des services explique les principes de base de ce processus.

Valeur pour le métier La gestion des connaissances est particulièrement utile pendant la transition des services, parce que les connaissances associées et appropriées constituent des éléments de service clés pendant la transition. Les exemples spécifiques de l’application de la gestion des connaissances pendant la transition des services sont : • formation et transfert des connaissances, propriété intellectuelle, information de conformité et standards • la documentation des erreurs, les solutions de rechange et l’information sur les tests

Concepts de base La gestion des connaissances est souvent visualisée en utilisant la structure DIKW : DataInformation-Knowledge-Wisdom, voir Figure 11.13.

Context

Sagesse Pourquoi? Connaissance Comment? Information Qui, quoi, quand, où ? Données Understanding

Figure 11.13  Modèle DIKW

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

287

La base du système de gestion des connaissances des services (SKMS) est constituée par une quantité considérable de données recensées dans une base centrale comme le système de gestion des configurations (CMS) et la CMDB : la CMDB alimente le CMS et le CMS fournit une entrée pour le SKMS, et il supporte ainsi le processus de prise de décision. Cependant, le périmètre du SKMS est plus large : l’information qui y est stockée reste liée aux questions relevant de : • L’expérience et les compétences des collaborateurs. • L’information sur les questions périphériques comme le comportement des utilisateurs et les performances de l’organisation. • Les exigences et attentes des fournisseurs de services et partenaires.

Couche de présentation

Portail

Gouvernance IT Service Portfolio Reportings Amélioration continue Risques et points à traiter

Vue pour la Gestion de la Qualité Politiques, Processus, Procédures, Formulaires, modèles, checklists

Vue pour l’éducation et la formation

Vue pour les Services Tableau de bord Catalogue de Services Utilité et Garantie du Service Groupements? Package Reportings de Service

Vue pour la Gestion Vue pour le Centre de des Actifs et des Services et de Support Configurations Catalogue de Services Actif financier Clients, utilisateurs CMS information Parties prenantes, Reportings sur le statut Actifs, incidents, Données de la CMDB problèmes, Changements, Sources définitives Mises en production, Configurations, Performance

Vue pour l’auto assistance Catalogue de Services et de Produits Contacts, FAQ's My assets Procurement, Install, Move, Add, Change processing and monitoring

Rechercher, stocker, collecter, mettre à jour, publier, abonner, collaborer

Couche de traitement de connaissance

Requête et analyse

Gestion de la performance Prévision, planning, budgétisation

Reporting

Couche d’intégration d’information

Modélisation

Surveillance Listes de scores, tableaux de bord, alertes

Système de Gestion des Connaissances sur les Services (SKMS)

Processus normal, Données et modèle d’information

Gestion des métadonnées

Cartographie

Réconciliation des données

Synchronisation des données

Extraire, Transformer, Charger

Extraction

Data Integration CMDB Document Store Données et Sources d’information et Outils

CMDB1 DB

File Store

Structuré

Application Système et Infrastructure Gestion

CMDB2 Bibliothèque des supports définitifs Logiciel Documentation Multimédia

Gestion des Événements et des Alertes

Systèmes existants

Applications d’entreprise Gestion des Accès Ressources Humaines Gestion Logistique Gestion de la relation client (CRM)

Non Structuré

Figure 11.14  SKMS

Activités, méthodes et techniques La gestion des connaissances consiste en l’agrégation des activités, méthodes et techniques suivantes : 1. stratégie de la gestion des connaissances 2. transfert des connaissances 3. gestion des données et de l’information 4. utilisation de SKMS

1. Stratégie de la gestion des connaissances Une organisation a besoin d’une stratégie de gestion des connaissances globale. Si cette stratégie est déjà en place, la stratégie des connaissances de la gestion des services peut lui être liée. Qu’une

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

288

Les fondamentaux de la gestion des services informatiques selon ITIL V3

stratégie existe déjà ou non, la stratégie doit en tout cas couvrir les éléments suivants : • politiques, procédures et méthodes pour la gestion des connaissances • modèle de gouvernance, les changements organisationnels à venir, la définition des rôles et les responsabilités, et la finance • technologie requise et autres ressources • mesures de performance • attribution de rôles et responsabilités et financement continu La stratégie de gestion des connaissances se focalise aussi spécifiquement sur la documentation utile des connaissances, et sur les données et l’information qui supportent ces connaissances.

2. Transfert des connaissances Le transfert des connaissances constitue un défi, exigeant, en premier lieu, une analyse pour déterminer quel est le décalage des connaissances entre le département et la personne en possession des connaissances, et ceux qui la demandent ou ont besoin de ces connaissances. En fonction du résultat de cette analyse, un plan de communication est élaboré pour faciliter le transfert des connaissances. Il existe un certain nombre de techniques de transfert des connaissances, comme : • Style d’apprentissage – chacun a son propre style d’apprentissage ; la méthode doit donc être adaptée au groupe cible en question. • Visualisation des connaissances – cette technique utilise des supports visuels comme les photos, schémas, images et story-boards pour le transfert des connaissances. • Comportement incitatif – considérez, par exemple, les scripts du service d’assistance et les champs obligatoires dans les applications de logiciel. • Séminaires, webinaires, annonces – il est très efficace d’organiser un événement spécial pour le lancement d’un nouveau service. • Bulletins, journaux – des canaux de communication comme les bulletins ou des e-alertes se prêtent très bien au transfert des connaissances en petites étapes (incrémental au lieu de Big Bang).

3. Gestion de l’information La gestion des données et de l’information consiste en l’agrégation des activités suivantes : • Établissement des exigences pour les données et l’information – données et information sont souvent collectées sans une idée claire quant à la façon de les utiliser ; ceci peut se révéler très coûteux, il est donc bénéfique de déterminer d’abord les exigences. • Définition de l’architecture de l’information – afin d’utiliser les données efficacement, une architecture est créée, qui correspond aux exigences et à l’organisation ; un exemple d’une telle architecture est illustré à la Figure 11.14. • Établissement des procédures de gestion des données et de l’information – une fois les exigences et l’architecture connues, les procédures pour le contrôle et le support de la gestion des connaissances peuvent être formulées. • Évaluation et amélioration – comme dans tous processus, l’évaluation est nécessaire pour une amélioration continue.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans la Transition des Services

289

4. Utilisation du SKMS La fourniture des services aux clients à des fuseaux horaires et régions variés et avec différents horaires de fonctionnement impose des exigences très élevées pour le partage des connaissances. Pour cette raison, le fournisseur de services doit développer et maintenir un système SKMS qui est disponible pour toutes les parties prenantes et qui correspond à l’ensemble des exigences d’information. Un exemple d’un tel système est montré sur la Figure 11.14. En plus de la qualité de ses données pour la formation et l’accumulation de connaissances, il est utilisé pour : • Incorporer (service informatique et entreprise) la listes des terminologies et leur traduction dans le système. • Documenter les processus opérationnels et leurs interfaces avec le service d’information. • Inclure les SLA et autres contacts qui peuvent changer en raison d’une transition des services. • Inclure les erreurs connues, les solutions de contournement et les diagrammes du processus.

Interfaces Les erreurs décelées par le personnel de transition des services sont documentées et analysées. La transition des services rend l’information accessible à l’exploitation des services, sur les conséquences d’erreurs et toutes autres solutions de contournement. Le personnel de la transition des services collecte aussi de l’information et des données qui sont retournées à la conception des services via le CSI et alimentent en information la conception des services en cas de changement dans l’approche. Le personnel d’exploitation, comme le personnel de la gestion des incidents et le personnel de support de niveau 1 et 2, forment le point de collecte et de recensement central de l’information sur la gestion quotidienne des services. Il est essentiel que ces informations et ces connaissances soient documentées et transférées. Le personnel travaillant à la gestion des problèmes recourent énormément à cette base de connaissances.

Métriques Des indicateurs types pour la contribution d’un fournisseur de services informatiques sont : • déploiement de services nouveaux ou changés avec succès avec peu d’erreurs liées aux connaissances • connaissances accrues parmi le groupe cible • un plus grand nombre de questions résolues (résolution des problèmes, anomalies, etc.) • moins de dépendance sur le personnel pour la connaissance (transfert des connaissances) • identification/localisation plus rapide de l’information de diagnostic sur les incidents et les problèmes La valeur de la gestion des connaissances pour l’organisation est à déterminer aussi, quelle que soit la difficulté. Les indicateurs se rapportant au client : • support de début de vie (ELS) plus court • temps de résolution des problèmes plus court

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

290

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• expérience de l’utilisateur améliorée • moins de rapports d’erreurs inutiles en raison d’un transfert des connaissances plus ciblé Les métriques se rapportant au fournisseur de services : • L’utilisation de la base des connaissances, degré de réutilisation de la documentation. • Les erreurs rapportées par le personnel ou à travers un audit. • Implication du personnel dans les forums de discussion de type question/réponse. Mesure de réutilisation de matériel dans la documentation ; Satisfaction avec des formations, bulletins et des informations web

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 12

Fonctions et Processus dans l’exploitation des services 12.1 Gestion des événements Introduction ITIL définit un événement ainsi : Un événement est aléatoire, mesurable ou observable. Il est significatif pour gérer l’infrastructure ou fournir un service informatique, ainsi que pour évaluer l’impact qu’une déviation pourrait avoir sur les services. Les événements sont généralement détectés par les outils de surveillance. Pour assurer une exploitation des services efficace, une organisation doit avoir conscience du statut de son infrastructure et être capable de déceler toute déviation opérationnelle, qu’elle soit régulière ou prévue. Il est donc primordial de pouvoir s’appuyer sur de bons systèmes de surveillance et de contrôle. L’objectif de la gestion des événements est de déceler les événements, de les analyser et de déterminer actions pertinentes à engager. Cela constitue le point d’entrée pour l’exécution de nombreux processus et activités d’exploitation des services.

Périmètre La gestion des événements s’applique à n’importe quels aspects de la gestion de services nécessitant d’être contrôlés. Elle peut être automatisée, par exemple au niveau des éléments de configuration, de la surveillance des licences des logiciels, des facteurs de sécurité et de l’environnement (i.e. détection d’un feu ou de la fumée).

Valeur métier • La gestion des événements a généralement une valeur indirecte. Voici quelques exemples de valeur ajoutée pour le métier : • La gestion des événements fournit des mécanismes pour la détection précoce des incidents. • La gestion des événements facilite certaines activités automatisées nécessitant d’être surveillées de manière exceptionnelle. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

292

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Si la gestion des événements est intégrée dans les autres processus de gestion des services, elle peut également détecter des changements ou des exceptions ; cela permet à la bonne personne ou à l’équipe de répondre plus rapidement, et donc, d’améliorer la performance du processus. • La gestion des événements fournit une base pour les opérations automatisées ; ceci améliore l’efficacité et libère des ressources humaines coûteuses qui peuvent se consacrer à un travail plus innovant.

Concepts de base Différents types d’événement existent, tels que : • Des événements qui indiquent une opération normale, par exemple, un utilisateur qui se connecte pour utiliser une application. • Des événements qui indiquent une exception, par exemple, un utilisateur qui essaie de se connecter à une application en saisissant un mot de passe incorrect ou un scan de l’ordinateur qui révèle l’installation d’un logiciel non autorisé. • Des événements qui signalent une opération inhabituelle mais pas exceptionnelle, pouvant indiquer que la situation demande une surveillance accrue. Par exemple, la mémoire d’un serveur qui est utilisée à 95% de sa capacité prévue.

Activités, méthodes et techniques Le diagramme de la Figure 12.1 reflète le flux d’activités de la gestion des événements. C’est une présentation générique des grandes lignes. Il devrait être utilisé comme point de référence, plutôt que comme représentation réelle du flux de la gestion des événements. Les principales activités du processus de gestion des événements sont : • Un événement se vérifie – des événements se vérifient tout le temps, mais ils ne sont pas tous détectés ou enregistrés ; il est donc important pour les personnes qui développent, conçoivent, gèrent et soutiennent les services informatiques et l’infrastructure informatique de comprendre quels types d’événement doivent être détectés. • Rapport concernant les événements – la plupart des éléments de configuration (CI) sont conçus pour faire en sorte qu’ils communiquent des informations spécifiques les concernant, de l’une des façons suivantes : – Un outil de gestion sonde un dispositif et collecte des données spécifiques ; cela s’appelle également le polling. – Le CI génère un rapport si certaines conditions sont remplies. • Détection des événements – un outil ou un acteur détecte un rapport d’événement, le lit et l’interprète. • Filtrage des événements – cette étape permet de décider si un événement est communiqué à un outil de gestion ; sinon, le dispositif enregistre l’événement dans un journal et n’effectue aucune action ultérieure. • La signification des événements (classification des événements) – une organisation utilise souvent sa propre classification pour établir l’importance d’un événement, mais il est utile de les classer selon au moins trois grandes catégories : – Informative – un événement qui ne demande aucune action et qui n’est pas une exception, par ex. un utilisateur se connectant à une application ; ce type d’événement est généralement stocké dans le journal du système ou du service et il est sauvegardé pendant un certain temps.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

293

Événement

Création d’une notification d’événement

Evénement détecté

Evénement filtré

Informatif

Signification ?

Exception

Avertissement

Corrélation des événements

Déclencheur

Evénement enregistré

Réponse automatique

Incident/ Problème/ Changement ?

Alerte

Changement

Incident Problème

Gestion des Incidents

Intervention humaine

Gestion des Problèmes

Actions de révision

Non

Efficace ? Oui

Clôturer l’événement

Fin

Figure 12.1  Le processus de gestion des événements.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Gestion des Changements

294

Les fondamentaux de la gestion des services informatiques selon ITIL V3

– Alerte – cette étape vérifie si un service ou un dispositif a atteint un certain seuil  ; elle avertit la personne concernée ou le processus et/ou l’outil, pour leur permettre de contrôler la situation et d’effectuer ainsi les actions requises pour prévenir une exception. Par exemple, une alerte est générée lorsque l’utilisation de la capacité de la mémoire d’un serveur dépasse 65% et augmente ; s’il atteint 75%, les temps de réponse sont trop longs et les accords sur les niveaux opérationnels (OLA) ne sont pas tenus. – Exception – signifie qu’un service ou qu’un dispositif se comporte anormalement et ne respecte pas un OLA ou un SLA ; exemples d’exception : s un serveur est tombé (down) s le temps de réponse d’une transaction standard sur un réseau dépasse 15 secondes s une partie du réseau ne répond pas aux demandes de routine • Corrélation des événements – elle détermine le sens d’un événement et les actions à entreprendre. • Déclencheur – si un événement est reconnu, une réponse est requise  ; le mécanisme qui indique cette réponse s’appelle un déclencheur  ; il existe différents types de déclencheur, y compris : – Les déclencheurs d’incident génèrent un enregistrement dans le système de gestion des incidents, et lancent le démarrage du processus de gestion des incidents. – Les scripts exécutent des actions spécifiques, comme le redémarrage d’un dispositif. – Les déclencheurs de base de données refusent l’accès d’un utilisateur à des enregistrements ou à des champs spécifiques. Ils créent et effacent des saisies dans une base de données. • Options de réponse – le processus fournit un certain nombre d’options de réponse, pouvant être combinées : – journalisation des événements – réponses automatiques – alerte et intervention humaine – soumission d’une demande de changement (RFC) – ouverture d’un enregistrement d’incident – ouverture d’un enregistrement de problème ou liaison à un ticket existant • Actions d’évaluation – des milliers d’événements sont générés chaque jour, ce qui rend impossible une évaluation individuelle formelle ; toutefois, il faudrait vérifier tous les événements ou les exceptions importantes pour déterminer s’ils ont été traités correctement, ou si des types d’événement sont comptés ; dans nombre de cas, cela peut se faire automatiquement. • Clôturer l’événement – certains événements restent ouverts jusqu’à ce que des actions spécifiques soient entreprises, par ex. un événement lié à un incident ouvert. D’ailleurs la plupart des éléments sont ni ouvert, ni fermé.

Interfaces N’importe quel type d’événement est capable de déclencher la gestion des événements. Il convient de déterminer les événements qui sont importants et qui demandent une action. Entre autres, les déclencheurs incluent : • Des exceptions à n’importe quel niveau de performance d’un CI défini dans la conception. • Des spécifications, des accords sur les niveaux opérationnels ou des procédures de traitement standards. • Une exception dans un processus business qui est surveillée par la gestion des événements. • Un changement de statut dans un dispositif ou dans un enregistrement de base de données.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

295

• Finalisation d’une tâche automatisée (job). • Accès à une application ou une base de données par un utilisateur. La gestion des événements peut s’interfacer avec n’importe quel processus demandant une surveillance et un contrôle. L’interface la plus importante est la gestion des incidents, des problèmes et des changements. De plus, la gestion des configurations peut utiliser des événements pour déterminer le statut actuel d’un élément de configuration (CI) dans une infrastructure. Les événements représentent une source d’informations très riche pour les systèmes de gestion des connaissances.

Métriques Des métriques sont requises pour chaque période de mesure, afin de vérifier l’efficacité et l’efficience de tout processus de gestion des événements, par exemple : • Nombre d’événements par catégorie. • Nombre d’événements par signification. • Nombre et pourcentage d’événements demandant une intervention humaine, et nombre de cas dans lesquels cela s’est produit. • Nombre et pourcentage d’événements aboutissant à des incidents et des changements. • Nombre et pourcentage de chaque type d’événement par plate-forme et par application.

Mise en œuvre Les principaux risques sont : • incapacité à réunir des fonds suffisants • établissement du bon niveau de filtrage • incapacité à faire évoluer les agents de surveillance lors du déploiement

Conception pour la gestion des événements La gestion des événements sert de base pour la surveillance de la performance et de la disponibilité d’un service. C’est la raison pour laquelle la gestion de la disponibilité et de la capacité doivent spécifier et négocier les cibles et les mécanismes précis de surveillance. Pour cela, plusieurs instruments sont disponibles : • Instrumentation – définit la meilleure façon de surveiller et de gérer l’infrastructure informatique et les services informatiques, et de créer une conception appropriée. Il est nécessaire de déterminer : – ce qui nécessite une surveillance – le type de surveillance requise (active ou passive, de la performance ou de la production) – quand la surveillance devrait générer un événement ? – quel type d’information doit être communiqué ? – quel en est le public concerné ? Les mécanismes qu’il faut concevoir incluent : – comment les événements seront générés – est-ce que le CI peut déjà générer des événements – la sélection les données et leur utilisation pour les enregistrements d’événement – est-ce que les événements seront générés automatiquement ou faut-il sonder le CI ? – journaliser et sauvegarder les événements • Messages d’erreur – Important pour tous les composants (matériel, logiciel, réseaux, etc.) ;

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

296

Les fondamentaux de la gestion des services informatiques selon ITIL V3

concevoir les applications logicielles pour faire en sorte qu’elles puissent soutenir la gestion des événements, par exemple au moyen de messages ou de codes d’erreur significatifs indiquant clairement ce qui ne va pas, voire où sont localisées les causes probables. • Détection d’erreur et mécanismes d’alerte – pour une bonne conception, les éléments suivants sont nécessaires : – Une connaissance détaillée des exigences de niveau de service soutenus par chaque CI. – Des informations sur les personnes qui apporteront le support nécessaire aux CI. – Une connaissance des conditions normales et anormales d’utilisation des CI. – Des informations pouvant aider à déterminer les problèmes liés aux CI.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

297

12.2 Gestion des incidents Introduction Le processus de gestion des incidents traite tous les incidents. Il peut s’agir de défaillances, de questions ou de demandes qui proviennent des utilisateurs, en général, par un appel téléphonique au centre de services, ou par le personnel technique, ou bien qui sont automatiquement détectées et remontés par les outils de surveillance des événements. ITIL définit un incident comme étant : Un incident est une interruption non planifiée ou une baisse de qualité d’un service informatique. La défaillance d’un élément de configuration qui n’a pas encore affecté le service est également considérée comme un incident. L’objectif principal du processus de gestion des incidents est de restaurer les conditions normales de service aussi rapidement que possible et de minimiser l’impact sur les processus métier de l’entreprise.

Périmètre La gestion des incidents couvre tout événement qui perturbe ou pourrait perturber un service. Cela signifie qu’elle comprend les événements remontés directement par les utilisateurs, soit par le centre de services, soit par l’intermédiaire d’outils divers. Les incidents peuvent également être remontés ou journalisés par le personnel technique, ce qui n’implique pas nécessairement que tout événement devienne un incident. Les incidents et les demandes de services sont signalés au centre de services. Ils ne demandent pas pour autant la même attention ni la même méthode de résolution. Les demandes de service ne sont pas des perturbations de service mais des demandes de support, de fourniture, d’informations, de conseils ou de documentation provenant des utilisateurs.

Valeur métier La valeur de la gestion des incidents comprend : • La possibilité de pister et de résoudre les incidents qui débouchent sur une réduction des temps d’indisponibilité pour le métier ; par conséquent, le service est disponible plus longtemps. • La possibilité d’aligner les opérations informatiques et les priorités du métier ; la raison en est une bonne gestion des incidents capable de définir des priorités et de répartir les ressources de façon dynamique. • La possibilité d’établir des améliorations potentielles pour les services. La gestion des Incidents est clairement identifiable pour le métier, c’est-à-dire, que sa valeur est plus facile à démontrer que pour d’autres domaines de l’exploitation des services. C’est pourquoi, il est l’un des premiers processus à être mis en œuvre lors des projets de gestion des services.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

298

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Concepts de base Les éléments suivants devraient être pris en compte dans la gestion des incidents : • Limites de temps – s’accorder sur les limites de temps pour toutes les phases et les utiliser comme cibles dans les accords sur les niveaux de service (OLA) et les contrats de sous-traitance (UC) ; • Modèles d’incident – un modèle d’incident est une façon de déterminer les étapes nécessaires à la bonne exécution des processus (dans ce cas, le traitement de certains types d’incident) ; cela veut dire que les incidents standards seront traités correctement et dans les délais convenus. • Incidents majeurs – une procédure séparée est requise pour les incidents majeurs, ayant des délais plus courts et une urgence plus grande ; s’accorder sur la définition d’un incident majeur et élaborer tout un système de priorisation des incidents. Les personnes confondent parfois un incident majeur et un problème. Toutefois, un incident reste toujours un incident. Son impact ou son degré de priorité peut augmenter sans jamais devenir un problème. Un problème est la cause sous-jacente d’un ou de plusieurs incidents et fait l’objet d’un traitement séparé.

Activités, méthodes et techniques Le processus de gestion des incidents est constitué des étapes suivantes (Figure 12.2) : 1. identification 2. enregistrement 3. classification 4. priorisation 5. diagnostic 6. escalade 7. enquête et diagnostic 8. résolution et restauration 9. clôture. Un incident n’est pas traité tant que son existence n’est pas connue. Cela s’appelle l’identification des incidents. Pour le métier, il est généralement inacceptable d’attendre qu’un utilisateur subisse un incident et le signale au centre de services. L’organisation doit essayer de surveiller tous les composants importants, afin de détecter le plus tôt possible les défaillances existantes ou potentielles et d’initier ainsi le processus de gestion des incidents. Dans une situation parfaite, les incidents sont résolus avant d’avoir un impact sur les utilisateurs. Tous les incidents doivent être enregistrés de façon exhaustive, y compris la date et l’heure : enregistrement des incidents. Cela s’applique aux incidents reçus par le centre de services comme à ceux qui sont détectés automatiquement par un système d’avertissement des événements. Enregistrez toutes les informations pertinentes conce rnant la nature de l’incident pour garantir un enregistrement historique complet. Si l’incident est transféré à d’autres groupes de support, ceux-ci doivent disposer de toutes les informations pertinentes. Il est nécessaire d’enregistrer au moins : • un unique numéro de référence • la catégorie de l’incident • l’urgence de l’incident

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

299

• la priorité de l’incident • le nom/ID de la personne ou du groupe qui enregistre l’incident • la description des symptômes • les activités entreprises pour résoudre l’incident

Entrée de la Gestion des Événements

Entrée depuis une Interface Web

E-mail des équipes techniques

Appel utilisateur

Détection de l’incident Enregistrement de l’incident Catégorisation de l’incident

Demande de Service?

Oui

Non

Vers gestion des requêtes

Priorisation de l’incident Procédure pour les Incidents majeurs

Oui

Incident majeur? Non Diagnostique initial

Oui Escalade vers le management

Oui

Escalade hiérarchique nécessaire? Non

Escalade fonctionnelle nécessaire?

Oui

Escalade fonctionnelle vers les niveaux 2/3

Non Investigation & Diagnostique Résolution & Restauration

Clôture de l’incident

Fin

Figure 12.2  Diagramme de la gestion des incidents

Utilisez une classification des incidents appropriée, avec codage d’enregistrement pour enregistrer le type correct d’appel téléphonique. Ceci est important pour la suite, quand les types et la fréquence des incidents sont analysés afin d’établir des tendances pouvant être utilisées pour la gestion des problèmes, la gestion des fournisseurs et les autres activités de gestion des services informatiques. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

300

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Lors de l’enregistrement d’un incident, il se peut que les données à disposition soient incomplètes, trompeuses ou incorrectes. Il est donc important de vérifier la classification des incidents et de la mettre à jour lors de la conclusion d’un appel. Exemple d’incident classé : logiciel, application, suite financière et système des commandes d’achat. Un autre aspect important de l’enregistrement de tout incident est de lui affecter un code de priorité juste. Les agents et les outils de support utilisent ce code pour déterminer la manière dont l’incident sera traité. La priorité d’un incident peut généralement être déterminée en établissant son degré d’urgence (rapidité avec laquelle le métier a besoin d’une solution) et son impact. Le nombre d’utilisateurs concernés par un incident est souvent une indication de son impact. Quand un utilisateur remonte un incident au centre de services, l’agent doit essayer d’enregistrer le plus grand nombre possible de symptômes de cet incident pour effectuer le premier diagnostic. Il essaie également d’établir ce qui s’est mal passé et comment cela peut être corrigé. Des scripts de diagnostic et des informations sur les erreurs connues peuvent se révéler très utiles dans ce contexte. Si possible, l’agent du centre de services résout l’incident immédiatement et clôture l’incident. Si cela n’est pas possible, il escalade l’incident. Cela peut se faire de deux façons : • Escalade fonctionnelle – s’il est clair que le centre de services ne peut pas résoudre l’incident (suffisamment vite), ce dernier doit être escaladé immédiatement à un niveau de support supérieur ; si l’organisation dispose d’un groupe de support de deuxième niveau et que le centre de services pense qu’il peut résoudre l’incident, alors il le leur transmet ; s’il est clair qu’une connaissance technique majeure est requise et que le support de deuxième niveau n’est pas en mesure de résoudre l’incident dans les délais convenus, alors ce dernier doit être escaladé vers le groupe de support de troisième niveau. • Escalade hiérarchique – il s’agit d’avertir les gestionnaires informatiques concernés de l’éventualité d’incidents plus graves (par exemple, des incidents avec une priorité 1) ; l’escalade hiérarchique est également utilisée en cas de ressources insuffisantes pour résoudre l’incident ; l’escalade hiérarchique signifie que l’organisation contacte les gestionnaires placés plus haut dans la chaîne ; le management est informé de l’incident et peut effectuer les actions requises, telles que l’attribution de ressources supplémentaires ou contacter les fournisseurs. Lors du traitement d’un incident, chaque groupe de support mène son enquête pour savoir ce qui s’est mal passé. Chacun fait son diagnostic et pense à documenter toutes ces activités lors de l’enregistrement de l’incident pour garantir que des informations générales sur toutes ces activités seront disponibles. Lorsque l’utilisateur désire simplement des informations, le centre de services doit être en mesure de fournir la réponse rapidement et de résoudre la demande de service. Si une solution possible a été trouvée, elle doit être mise en œuvre et testée : il s’agit de l’étape de Solution et Restauration. Les actions suivantes peuvent alors être entreprises : • Demander à l’utilisateur d’effectuer des opérations sur son ordinateur ;

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

301

• Le centre de services peut exécuter la solution depuis un point central ou utiliser un logiciel de contrôle à distance pour prendre le contrôle de l’ordinateur de l’utilisateur et mettre en œuvre la solution ; • Demander à un fournisseur de résoudre l’erreur. Le groupe de support renvoie l’incident au centre de services, qui clôture l’incident. Toutefois, il vérifie d’abord que l’incident est résolu et que les utilisateurs sont satisfaits de la solution. Il doit également confirmer la classification, vérifier que l’utilisateur est satisfait, mettre à jour la documentation des incidents, déterminer si l’incident pourrait se répéter, et décider des actions à entreprendre afin d’en éviter la récurrence. L’incident peut alors être formellement clôturé.

Gestion des informations La plupart des informations utilisées par la gestion des incidents est fournie par les outils de gestion des incidents et par les enregistrements des incidents. La gestion des incidents a également accès au système de gestion des configurations (CMS). Cela permet d’identifier les CI concernés par l’incident. Il est également possible d’évaluer l’impact de l’incident.

Interfaces Les incidents peuvent être déclenchés de diverses façons. La voie la plus courante est lorsqu’un utilisateur appelle le centre de services ou quand il remplit un formulaire d’incident par internet. Toutefois, de plus en plus d’incidents sont enregistrés par les outils de gestion des incidents. Les processus suivants s’interfacent avec la gestion des incidents : • Gestion des problèmes – les incidents sont souvent causés par des problèmes sous-jacents qui doivent être résolus pour empêcher la récurrence de l’incident ; la gestion des incidents offre un espace pour enregistrer ces problèmes. • Gestion des configurations – elle fournit les données utilisées pour identifier et suivre les incidents ; le système de gestion des configurations (CMS) sert, entre autre, à identifier les composants défectueux et à déterminer l’impact d’un incident ; CMS sert également à identifier les utilisateurs qui subissent un impact suite à des problèmes possibles ; • Gestion des changements – si un changement est nécessaire pour mettre en œuvre une solution de contournement ou une solution, il est enregistré comme une demande de changement (RFC) et est exécuté par la gestion des changements ; la gestion des incidents est à même de suivre et de résoudre les incidents causés par des changements inappropriés ; • Gestion de la capacité – elle déclenche la surveillance de la performance si des problèmes apparaissent concernant la performance  ; la gestion de la capacité offre des solutions de contournement pour les incidents ; • Gestion de la disponibilité – elle utilise des données de la gestion des incidents pour déterminer la disponibilité des services informatiques et établit quelle partie du cycle de vie de l’incident peut être améliorée. • Gestion des niveaux de service (SLM) –SLM surveille les accords avec les clients concernant le support à fournir. La gestion des incidents informe SLM. Ce processus, par exemple, peut évaluer les SLA de façon objective et régulière. SLM établit les niveaux de service acceptables dans lesquels la gestion des incidents doit travailler.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

302

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Métriques • Les métriques permettent d’évaluer l’efficacité, l’efficience et le fonctionnement du processus de gestion des incidents. Exemples de métrique : • le nombre total d’incidents • le nombre et le pourcentage d’incidents majeurs • le coût moyen par incident • le nombre et le pourcentage d’incidents transmis de façon incorrecte • le pourcentage d’incidents traités dans les délais convenus

Mise en œuvre La gestion des incidents doit relever les défis suivants : • Détecter les incidents aussi rapidement que possible. • Convaincre tout le personnel (équipes techniques et utilisateurs) que tous les incidents doivent être enregistrés et les encourager à utiliser les options basées sur Internet pour résoudre euxmêmes les incidents (Self Help). • La disponibilité des informations concernant les problèmes et les erreurs connues, permettant au personnel de la gestion des incidents d’apprendre des incidents précédents et de suivre le statut des solutions. • Intégration avec le système de gestion des configurations pour déterminer la relation entre les éléments de configuration (CI) et se référer à l’historique des CI lors de la fourniture de support de premier niveau. • Intégration avec le processus de gestion des niveaux de service ; cela aide la gestion des incidents à déterminer correctement l’impact et la priorité des incidents ainsi qu’à définir et à exécuter les procédures d’escalade. Les facteurs clés de succès (CSF) suivants sont fondamentaux pour réussir une bonne gestion des incidents : • un bon centre de services • des cibles SLA clairement définies • un personnel de support adéquat, orienté client, techniquement qualifié et possédant les justes compétences à tous les niveaux du processus • des outils de support intégrés pour contrôler et gérer le processus • des OLA et des UC pour influencer et gérer le comportement de tout le personnel de support Les risques pour la gestion des incidents sont les suivants : • Être submergé par des incidents ne pouvant pas être gérés dans des délais acceptables en raison d’un manque de ressources bien formées. • Des incidents qui ne progressent pas à cause d’outils de support inadéquats qui manquent d’avertir ou d’informer quant aux éventuels progrès. • Manque de sources d’information adéquates à cause d’outils inappropriés ou d’un manque d’intégration. • Objectifs ou actions qui ne coïncident pas en raison d’OLA ou d’UC non alignés ou inexistants.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

303

12.3 Gestion des demandes Introduction ITIL utilise le terme demande de service pour décrire de façon générale les différentes demandes que les utilisateurs soumettent au département informatique. Une demande de service est une demande de la part d’un utilisateur pour une information, un conseil, un changement standard ou l’accès à un service. Par exemple, une demande de service peut être une demande de changement de mot de passe ou d’installation supplémentaire d’une application logicielle sur un poste de travail donné. Puisque ces demandes sont périodiques et impliquent peu de risques, il est préférable de les gérer dans le cadre d’un processus séparé. L’exécution des demandes (mise en œuvre des demandes) gère les demandes de services provenant des utilisateurs. Les objectifs du processus d’exécution des demandes sont : • Offrir aux utilisateurs un canal au travers duquel ils peuvent demander et recevoir des services ; pour ce faire, les approbations doivent être qualifiées et convenues au préalable. • Fournir des informations aux utilisateurs et aux clients quant à la disponibilité des services et à la procédure à suivre pour les obtenir. • Fournir les composants des services standards (par exemple, les licences et les logiciels). • Aider avec des informations générales, réclamations et commentaires.

Périmètre Le processus de traitement de ces demandes dépend de la nature de la demande. Dans la plupart des cas, il est possible de diviser le processus en une série d’activités devant être réalisées. Certaines organisations gèrent les demandes de service comme un type spécial d’incident. Toutefois, il existe une différence importante entre un incident et une demande de service. Un incident est généralement un événement non planifié, alors qu’une demande de service tend à être quelque chose qui peut et doit être planifiée.

Valeur pour le métier La valeur de la gestion des demandes repose sur la capacité d’offrir un accès rapide et efficace aux services standards que le métier peut utiliser pour améliorer la productivité ou la qualité des services et des produits métiers. L’exécution des demandes minimise les aspects bureaucratiques normalement nécessaires pour demander et obtenir l’accès à des services, nouveaux ou existants. Cela réduit le coût de la fourniture de ces services.

Concepts de base De nombreuses demandes de service sont périodiques. C’est pourquoi il est possible de planifier à l’avance le processus, en stipulant les phases nécessaires pour gérer les demandes, les individus ou les groupes de support concernés, les limites de temps et les escalades. En général, la demande de service est gérée comme un changement standard.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

304

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Activités, méthodes de travail et techniques La gestion des demandes se compose des activités, méthodes et techniques suivantes : • Sélection du menu – L’exécution des demandes permet aux utilisateurs de soumettre leurs propres demandes de service au moyen d’un lien avec les outils de gestion des services ; dans une situation idéale, l’utilisateur se verra offrir un menu depuis interface web, lui permettant de sélectionner et de saisir les informations de la demande de service. • Approbation financière – La plupart des demandes de service comportent des implications financières ; il faut d’abord déterminer les coûts de gestion d’une demande ; il est possible de s’accorder sur des prix fixes pour les demandes standards puis leur donner une autorisation immédiate ; dans les autres cas, le coût doit d’abord être estimé, après quoi, l’utilisateur doit donner sa permission. • Exécution – L’activité réelle de gestion dépend de la nature de la demande de service  ; le centre de services peut gérer de simples demandes, tandis que les autres demandes doivent être envoyées à des groupes de spécialistes et/ou aux fournisseurs. • Clôture – Une fois la demande de service remplie, le centre de services la clôture.

Interfaces La plupart des demandes sont déclenchées par les utilisateurs qui appellent le centre de services, ou bien lorsqu’ils complètent un formulaire de demande en ligne. De nombreuses demandes de service arrivent par le centre de service et peuvent être gérées au moyen du processus de gestion des incidents. Certaines organisations choisissent de gérer toutes les demandes de cette manière, d’autres préfèrent un processus séparé. Il existe également un lien très fort entre la gestion des demandes, la gestion de la mise en production, la gestion des actifs et la gestion des configurations, car certaines demandes traitent du déploiement de composants, nouveaux ou améliorés, qui peuvent être mis en œuvre automatiquement. L’exécution des demandes dépend des informations provenant des sources suivantes : • demandes de service • demandes de changement • portefeuille des services • politique de sécurité

Métriques Les métriques requises pour évaluer l’efficience et l’efficacité de l’exécution des demandes sont : • Le nombre total des demandes de service. • La ventilation des demandes de service par phase. • La quantité de travail nécessaire pour traiter des demandes de service en suspens ; • Le temps moyen pour gérer chaque type de demande de service. • Le nombre et le pourcentage des demandes de service qui sont gérées dans les délais convenus. • Le coût moyen par type de demande de service. • Le niveau de satisfaction client par rapport à la gestion des demandes de service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

305

Mise en œuvre L’exécution des demandes doit relever les défis suivants : • Définir clairement et documenter les types de demande gérés par le processus de gestion des demandes, pour permettre aux parties prenantes de connaître le périmètre. • Établir des interfaces d’accès au processus de gestion des demandes, pour permettre aux utilisateurs de générer eux-mêmes et directement leurs demandes. La gestion des demandes dépend des facteurs clés de succès suivants : • S’accorder sur les services standards et les personnes qui sont autorisées à les demander ; il faut également s’accorder sur le coût de ces services. • Proposer ces services aux utilisateurs, par l’intermédiaire du catalogue des services. • Définir une procédure standard d’exécution des demandes pour chaque service demandé. • Définir un seul contact pour demander le service ; c’est souvent réalisé via le centre de services ou une demande internet, mais aussi via une demande automatique effectuée directement dans le système de gestion des achats. • Des outils en libre service sont nécessaires pour offrir une interface web aux utilisateurs (Self Help) ; il est important que cette interface puisse communiquer avec les outils d’exécution. L’exécution des demandes comporte les risques suivants : • Si le périmètre est mal défini, personne ne saura exactement ce que le processus est censé gérer. • Des interfaces utilisateur mal conçues ou mal mises en œuvre rendent difficiles la soumission de demandes de la part des utilisateurs. • Des processus d’exécution mal conçus ou mal réalisés entraînent une incapacité du système à gérer le nombre ou le type de demandes soumises. • Une capacité de surveillance insuffisante génère des métriques imprécises.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

306

Les fondamentaux de la gestion des services informatiques selon ITIL V3

12.4 Gestion des problèmes Introduction ITIL définit un problème comme suit : Un problème est la cause inconnue d’un ou plusieurs incidents. La gestion des problèmes est responsable du contrôle du cycle de vie de tous les problèmes. L’objectif primaire de la gestion des problèmes est de prévenir les problèmes et les incidents, d’éliminer les répétitions d’incidents et de minimiser l’impact des incidents qui n’ont pas pu être évités.

Périmètre La gestion des problèmes comprend toutes les activités nécessaires pour diagnostiquer la cause sous-jacente des incidents et pour trouver une solution à ces problèmes. Elle doit aussi garantir que la solution est mise en œuvre au moyen des procédures correctes de contrôle, par l’intermédiaire de la gestion des changements et des mises en production.

Valeur pour le métier La gestion des problèmes collabore avec la gestion des incidents et des changements pour garantir des améliorations de la disponibilité et de qualité de la fourniture de services informatiques. Quand les incidents sont résolus, la solution est enregistrée. À un moment donné, ces informations servent à accélérer la gestion de l’incident et à identifier des solutions permanentes. Cela réduit le nombre d’incidents et les temps de traitement, entraînant ainsi une réduction des temps de perturbation et du nombre même de ces perturbations pour les systèmes critiques métier.

Concepts de base De nombreux problèmes sont uniques et nécessitent une gestion séparée. Toutefois, il est possible que certains incidents se présentent à nouveau en raison de problèmes sous-jacents. ITIL définit une erreur connue comme suit : Une erreur connue est un problème dont la cause première est documentée et pour lequel une solution de contournement existe. ITIL définit une solution de contournement comme suit : Solution de contournement : réduit ou élimine l’impact d’un incident ou d’un problème pour lesquels une solution définitive n’est pas encore disponible. En plus de créer une base de données des erreurs connues (Known Error Database – KEDB) permettant des diagnostics plus rapides, il peut se révéler utile de créer un modèle de problèmes pour gérer les problèmes futurs. Grâce aux étapes qu’il comporte, un modèle standard aide le personnel de la gestion des problèmes à respecter les délais de restauration.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

307

Activités, méthodes et techniques La gestion des problèmes se compose de deux processus importants : • Gestion réactive des problèmes – effectuée par l’exploitation des services. • Gestion proactive des problèmes – instaurée par l’exploitation de services, mais habituellement gérée par l’amélioration continue des services (CSI) (voir chapitre 13). La gestion réactive des problèmes se compose des activités suivantes (Figure 12.3) : • identification • enregistrement • classification • priorisation • enquête et diagnostic • décisions quant aux solutions de contournement • identification des erreurs connues • résolution • conclusion • révision • correction des erreurs détectées L’identification des problèmes recourt aux méthodes suivantes : • Le centre de services suspecte ou identifie la cause inconnue d’un ou de plusieurs incidents. Il en résulte un enregistrement du problème. Un incident peut clairement avoir été causé par un problème majeur. Dans ce cas, il faut enregistrer immédiatement le problème. • L’analyse d’un incident par le groupe de support technique révèle la présence d’un problème sous-jacent. • Une erreur d’infrastructure ou d’application est automatiquement déclarée, les outils d’alerte créent automatiquement un enregistrement de l’incident, qui souligne ainsi la nécessité d’enregistrer le problème. • Le fournisseur déclare un problème qui nécessite une solution. • L’analyse des incidents a lieu dans le cadre de la gestion corrective des problèmes. Il conduit à un enregistrement du problème pour permettre une enquête éventuelle plus approfondie de la cause sous-jacente de ce problème. Il convient d’analyser périodiquement les données d’un incident ou d’un problème pour identifier des tendances. Pour ce faire, une classification efficiente et détaillée des incidents et des problèmes est indispensable, ainsi que des comptes-rendus périodiques des zones à problèmes. Indépendamment de la méthode d’identification, tous les détails concernant le problème doivent être enregistrés (enregistrement des problèmes) pour permettre la création d’un rapport historique exhaustif. Les informations enregistrées doivent comprendre la date et l’heure afin de permettre un contrôle correct et une escalade éventuelle. Les problèmes doivent être classés de la même façon que les incidents, afin de permettre rapidement et facilement l’identification de la vraie nature du problème. La classification des problèmes fournit des informations utiles au management.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

308

Centre de Services

Gestion des événements

Gestion des Incidents

Gestion proactive des Problèmes

Fournisseur ou sous-traitant

Détection du problème

Enregistrement du problème

Catégorisation

Priorisation

CMDB

Investigation & Diagnostique

Contournement

Enregistrement d’une Erreur Connue Gestion des Changements Oui

Base de données des Erreurs Connues

Changement nécessaire? Non Résolution

Clôture

Problème majeur?

Révision des Problèmes majeurs

Non Fin

Figure 12.3  Diagramme de la gestion des problèmes

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

309

À l’instar des incidents, il faut également attribuer une priorité aux problèmes, et ce, de la même façon et pour les mêmes raisons que la gestion des incidents. Dans ce contexte, il faut également prendre en compte la fréquence et l’impact des incidents associés et la gravité des problèmes. Voici des exemples de considérations : • Le système peut-il être réparé ou faut-il le remplacer ? • Quels en sont les coûts ? • Combien de personnes, quels experts faut-il pour résoudre le problème ? • Combien de temps faut-il pour résoudre le problème ? • Quelle est la gravité du problème ? Afin de trouver la cause sous-jacente du problème et faire un diagnostic, il faut mener une enquête. La rapidité et la nature de cette enquête dépend de l’impact, de la gravité et de l’urgence du problème. Il convient d’utiliser le juste niveau de ressources et d’expertise pour trouver une solution. Il est souvent utile de reproduire le problème, afin de mieux comprendre ce qui n’a pas fonctionné. Ensuite, il est possible d’utiliser diverses méthodes pour trouver la meilleure solution possible. Pour ce, le mieux est d’utiliser un système de test qui reflète l’environnement de production. De nombreuses techniques d’analyse, de diagnostic et de résolution sont disponibles, y compris : • analyse chronologique • analyse de la valeur de dérangement • Kepner-Tregoe • Remue-méninges • diagrammes d’Ishikawa • analyse de Pareto Dans certains cas, une solution temporaire ou une solution de contournement sont applicables aux incidents causés par un problème. Toutefois, il est important que les comptes-rendus des problèmes restent ouverts et que les détails concernant la solution de contournement soient inclus dans le compte-rendu de chaque problème. Dès que le diagnostic a été fait, et surtout si une solution de contournement a été trouvée, les erreurs connues identifiées doivent être listées dans un rapport d’erreurs connues et stockées dans la base de données des erreurs connues (KEDB). Si d’autres incidents et problèmes sont déclarés, ils peuvent être identifiés et le service peut reprendre plus rapidement. Dès qu’une solution a été trouvée, idéalement, elle devrait être appliquée pour résoudre le problème. En réalité, il y a des mesures préventives pour garantir que la solution ne cause pas d’autres problèmes. Si un changement de fonctionnalité est nécessaire, il faut une demande de changement qui suive les étapes du processus de gestion des changements. Si le changement a été complété et évalué avec succès, et si la solution a été appliquée, alors le rapport du problème peut formellement être clôturé, ainsi que les rapports des incidents associés

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

310

Les fondamentaux de la gestion des services informatiques selon ITIL V3

qui sont encore en suspens. Ne pas oublier de vérifier que le rapport contienne une description complète de tous les événements. Après tout problème majeur, une revue doit être effectuée pour en tirer des leçons ultérieures. Notamment la revue doit évaluer : • ce qui s’est bien passé • ce qui s’est mal passé • ce qui peut être fait dans le futur • comment peut-on empêcher que le même problème ne se répète ? • si une tierce partie est responsable et si des actions de suivi sont nécessaires Il est très rare que de nouvelles applications, de nouveaux systèmes ou de nouvelles mises en production de logiciel ne contiennent pas d’erreurs. Dans la plupart des cas, un système de priorité est utilisé pendant les tests pour éliminer les erreurs les plus graves ; mais il est possible que des erreurs mineures ne soient pas corrigées.

Gestion de l’information Le système de gestion des configurations (CSM) contient les détails concernant tous les composants de l’infrastructure informatique et leurs relations. Cela représente une source précieuse pour diagnostiquer les problèmes et évaluer leur impact. Le but d’une base de données des erreurs connues (KEDB) est de stocker des connaissances concernant les incidents, les problèmes et les solutions adoptées  ; cela permet de faire des diagnostics plus rapides et de trouver des solutions au cas où d’autres incidents ou problèmes surviendraient. L’enregistrement des erreurs connues doit contenir les détails exacts concernant l’erreur et les symptômes, ainsi que les détails exacts d’une solution de contournement ou d’une solution pouvant être mise en œuvre pour redémarrer le service ou résoudre le problème. Il est possible qu’aucun Business Case n’existe pour une solution permanente à certains problèmes. Par exemple, si le problème ne cause aucune perturbation grave, qu’une solution de contournement existe déjà et que les coûts de résolution du problème dépassent les avantages offerts par une solution permanente, la gestion des problèmes peut décider de tolérer le problème. Tout comme le système de gestion des configurations (CMS), la KEDB fait partie d’un système plus large de gestion des connaissances des services (SKMS) (Figure 12.4). La section concernant la Transition des services (chapitre 10) fournit davantage d’information sur le SKMS.

Interfaces La plupart des enregistrements de problèmes sont déclenchés en réponse à un ou à plusieurs incidents, notamment par le personnel du centre de services. D’autres enregistrements de problèmes et d’erreurs connues associées sont déclenchés pendant les tests, notamment pendant les tests appelés tests de recette client, qui autorisent une mise en production malgré les erreurs connues.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

Couche de présentation

Portail

Gouvernance IT Service Portfolio Reportings Amélioration continue Risques et points à traiter

Vue pour la Gestion de la Qualité Politiques, Processus, Procédures, Formulaires, modèles, checklists

Vue pour l’éducation et la formation

311

Vue pour les Services Tableau de bord Catalogue de Services Utilité et Garantie du Service Groupements? Package Reportings de Service

Vue pour la Gestion des Actifs et des Configurations Actif financier CMS information Reportings sur le statut Données de la CMDB Sources définitives

Vue pour le Centre de Services et de Support Catalogue de Services Clients, utilisateurs Parties prenantes, Actifs, incidents, problèmes, Changements, Mises en production, Configurations, Performance

Vue pour l’auto assistance Catalogue de Services et de Produits Contacts, FAQ's My assets Procurement, Install, Move, Add, Change processing and monitoring

Rechercher, stocker, collecter, mettre à jour, publier, abonner, collaborer

Couche de traitement de connaissance

Requête et analyse

Gestion de la performance Prévision, planning, budgétisation

Reporting

Couche d’intégration de l’information

Modélisation

Surveillance Listes de scores, tableaux de bord, alertes

Système de Gestion des Connaissances des Service (SKMS)

Processus normal, Données et modèle d’information

Plan de schémas

Gestion des métadonnées

Réconciliation des données

Synchronisation des données

Extraire, Transformer, Charger

Extraction

Data Integration CMDB Document Store Données et Sources d’information et Outils

CMDB1 DB

File Store

Structuré Non Structuré

Application, Système et Infrastructure Gestion

CMDB2 Bibliothèque des supports définitifs Logiciel Documentation Multimédia

Gestion des Événements et des Alertes

Systèmes existants

Applications de l’entreprise Gestion des Accès Ressources Humaines Gestion Logistique Gestion de la relation client (CRM)

Figure 12.4  Le système de gestion des connaissances des services

Les processus suivants s’interfacent avec la gestion des problèmes : • Transition des services : – Gestion des changements – la gestion des problèmes garantit que toutes les solutions et contournements, pour lesquelles un changement est nécessaire, sont mises en œuvre dans un CI via un RFC ; la gestion des changements surveille la progression de ces changements et en informe constamment la gestion des problèmes. – Gestion des configurations – la gestion des problèmes utilise le CMS pour identifier les CI incorrects et pour déterminer l’impact des problèmes et des solutions. – Gestion des mises en production et des déploiements – elle est responsable du déploiement des solutions d’un problème dans l’environnement de production. • Conception des services : – Gestion de la disponibilité – elle contribue à minimiser les temps de perturbation et à augmenter les temps de production (uptime) ; de nombreuses informations de gestion concernant la gestion des problèmes sont transmises à la gestion de la disponibilité. – Gestion de la capacité – elle garantit l’utilisation optimale des ressources et fournit d’importantes informations à la gestion des problèmes, telles que les enregistrements de la capacité et les questions de performance  ; la gestion de la capacité soutient également l’application des mesures correctives. – Gestion de la continuité des services informatiques (ITSCM) – la gestion des problèmes sert de base pour l’ITSCM ; un problème n’est pas résolu s’il n’a pas un impact important sur le métier.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

312

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Amélioration continue des services : – Gestion des niveaux de service – les incidents et les problèmes influencent la qualité des services informatiques fournis par SLM ; la gestion des problèmes contribue à l’amélioration des niveaux de service et les informations de gestion qu’elle fournit ; elle sert de base lors de la revue des SLA. • Stratégie de services : – Gestion financière – la gestion des problèmes fournit des informations de gestion concernant les coûts de résolution et de prévention des problèmes  ; de cette façon, les informations peuvent servir d’entrées au budget et à la comptabilité ainsi que pour les calculs des coûts de possession (TCO – Total Cost of Ownership).

Métriques Les métriques suivantes servent à évaluer l’efficience, l’efficacité et la mise en œuvre du processus de gestion des problèmes : • Le nombre total de problèmes enregistrés pendant la période. • Le pourcentage de problèmes résolus dans les cibles SLA (et le pourcentage de problèmes non résolus). • Le nombre et le pourcentage de problèmes qui ont demandé davantage de temps pour être résolus. • La quantité de problèmes en suspens et la tendance (statique, décroissante, croissante). • Les coûts moyens de gestion d’un problème. • Le nombre de problèmes majeurs (en suspens, clôturés). • Le pourcentage de revues réussies de problèmes majeurs. • Le nombre d’erreurs connues ajoutées à la base de données KEDB. • Le pourcentage d’exactitude de la KEDB (après vérifications de la base de données).

Mise en œuvre La gestion des problèmes dépend fortement de la formulation d’un processus d’incident efficace et de l’utilisation d’outils corrects. Ceux-ci contribuent à identifier les problèmes aussi vite que possible.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

313

12.5 Gestion des accès Introduction La gestion des accès donne le droit aux utilisateurs d’utiliser un service, mais refuse l’accès aux utilisateurs non autorisés. Certaines organisations l’appellent également gestion des droits ou gestion des identités.

Périmètre La gestion des accès garantit que les utilisateurs ont accès à un service, mais elle ne garantit pas que l’accès soit toujours disponible aux temps convenus. Cela est géré par la gestion de la disponibilité. La gestion des accès peut être gérée par le centre de services, au moyen d’une demande de service.

Valeur métier La gestion des accès apporte la valeur suivante : • Un accès contrôlé aux services permet à l’organisation de maintenir la confidentialité de ses informations de manière plus efficace. • Le personnel dispose d’un niveau d’accès pertinent pour travailler correctement. • Le risque d’erreurs pendant la saisie des données ou l’utilisation d’un service vital de la part d’un utilisateur non qualifié sont réduits. • Au besoin, il est possible de refuser les droits d’accès plus facilement ; par exemple, l’accès peut être nécessaire pour la conformité (SOX, HIPAA, CobiT).

Concepts de base La gestion des accès s’appuie sur les concepts de base suivants : • Accès – le terme se réfère au niveau et au périmètre de fonctionnalité d’un service ou des données que l’utilisateur est autorisé à utiliser. • Identité – ce terme se réfère aux informations concernant les personnes distinguées par l’organisation comme des individus ; elle établit leur statut dans l’organisation. • Droits (aussi appelés privilèges) – ce terme se réfère aux paramétrages des utilisateurs ; aux (groupes de) services qu’ils sont autorisés à utiliser ; les droits classiques comprennent la lecture, l’écriture, l’exécution, l’édition et la suppression. • Services ou groupes de services – la plupart des utilisateurs ont accès à de multiples services ; il est donc plus efficace de donner à chaque utilisateur ou groupe d’utilisateurs, l’accès à tout un ensemble de services qu’ils pourront utiliser simultanément. • Services d’annuaire – ce terme se réfère à un type spécifique d’outil servant à gérer les accès et les droits.

Activités, méthodes et techniques L’accès (ou la limitation d’un accès) peut être demandé au moyen d’un certain nombre de mécanismes, tels que : • Une demande standard générée par le département des ressources humaines ; en général, cela se produit quand une personne est engagée ou promue ou quand elle quitte l’organisation. • Une demande de changement (RFC).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

314

Les fondamentaux de la gestion des services informatiques selon ITIL V3

• Une RFC soumise via le processus d’exécution des demandes. • L’exécution d’un script ou d’une option autorisés. La gestion des accès se compose des activités suivantes : • Vérification – la gestion des accès peut vérifier chaque demande d’accès pour un service informatique selon deux perspectives : – l’utilisateur demandant l’accès est bien la personne qu’il dit être ? – l’utilisateur a une raison légitime d’utiliser ce service ? • Accorder des droits – la gestion des accès ne décide pas qui a le droit d’accéder à tel ou tel service ; elle ne fait qu’exécuter la politique et les règlementations de la stratégie des services et de la conception des services. Plus il y a de groupes et de rôles, plus il y a de chances que des conflits entre les rôles surviennent. Dans ce contexte, les conflits de rôle se réfèrent à une situation dans laquelle deux rôles ou deux groupes spécifiques alloués à un utilisateur peuvent entraîner des problèmes liés à un conflit d’intérêt. Par exemple, un rôle nécessite un accès tandis que l’autre rôle l’interdit. • Surveiller les statuts d’identité – les rôles varient dans le temps et ont un impact sur les besoins de service. Voici des exemples de ce qui peut changer un rôle : changements de métier, promotion, licenciement, départ en retraite ou décès. • Enregistrer et surveiller les accès – la gestion des accès ne répond pas seulement aux demandes, elle doit aussi garantir que les droits qu’elle a accordés sont utilisés correctement ; c’est la raison pour laquelle la surveillance et le contrôle des accès doivent être compris dans les activités de toutes les fonctions techniques et de gestion des applications ainsi que dans les processus d’exploitation des services. • Révoquer ou limiter les droits – outre l’accord de droits d’utilisation d’un service, la gestion des accès est également responsable du retrait de ces droits ; mais elle ne peut pas en prendre la décision.

Gestion de l’information L’identité d’un utilisateur est l’information que le différentie en tant qu’individu et qui vérifie son statut dans l’organisation. Les données suivantes peuvent servir, par exemple : • nom • coordonnées telles que numéro de téléphone et mail • documentation physique, comme permis de conduire et passeport • numéros de référence d’un document ou faisant partie d’une base de données, comme le numéro de sécurité sociale ou de permis de conduire • des informations biométriques, telles que les empreintes digitales, l’ADN, la reconnaissance vocale, etc. Puisque chaque utilisateur dispose d’une identité distincte et que chaque service informatique peut être considéré comme une identité individuelle, il est souvent logique de les regrouper pour mieux les gérer. Parfois, on utilise les termes : profil utilisateur, template utilisateur ou rôle utilisateur pour décrire ce type de regroupement. La plupart des organisations disposent d’un ensemble standard de services pour tous les utilisateurs individuels, indépendamment de leur position ou de leur métier. Cependant, certains utilisateurs ont un rôle spécial. Par exemple, en plus des services standards, il est possible qu’un utilisateur

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

315

remplisse un rôle de gestion du marketing, ce dernier lui offrant accès à plusieurs outils spéciaux de modélisation marketing et financiers ainsi qu’à des données spécifiques.

Interfaces La gestion des accès est déclenchée par la demande d’un utilisateur d’accès à un service (ou groupe de services). Une telle demande peut avoir son origine dans : • une RFC • une demande de service • une demande du département des ressources humaines (RH) • une demande d’un gestionnaire ou d’un département ayant un rôle de RH ou ayant décidé d’utiliser un service pour la première fois La gestion des accès entretient des relations avec différents processus. Puisque toute demande d’accès à un service représente un changement, la gestion des changements joue un rôle important dans le contrôle des demandes d’accès. La gestion des niveaux de service surveille les accords concernant l’accès à chaque service. Cela comprend les critères des personnes ayant accès à un service, les coûts et le niveau d’accès accordé à différents types d’utilisateur. La gestion des accès entretient également une relation étroite avec la gestion des configurations. Le CMS peut servir à stocker les données et peut être consulté pour déterminer les accès courants.

Métriques Les métriques utilisées pour mesurer l’efficacité et l’efficience de la gestion des accès sont les suivantes : • le nombre de demandes d’accès (demandes de service et RFC) • le nombre de fois qu’un accès a été accordé par un service, un utilisateur ou un département • le nombre d’incidents requis pour rétablir des droits d’accès • le nombre d’incidents causés par des réglages d’accès incorrects

Mise en œuvre Les conditions de succès de la gestion des accès comprennent : • la possibilité de vérifier l’identité d’un utilisateur • la possibilité de vérifier l’identité de la personne ou de l’entité accordant l’autorisation • la possibilité d’accorder plusieurs droits d’accès à un utilisateur individuel • une base de données de tous les utilisateurs et des droits qui leur ont été accordés

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

316

Les fondamentaux de la gestion des services informatiques selon ITIL V3

12.6 Surveillance et contrôle Introduction La mesure et le contrôle des services se basent sur un cycle continu d’activités de surveillance, de compte-rendu et d’initiation. Ce cycle est détaillé dans cette section car il est essentiel à la fourniture, au support et à l’amélioration des services.

Concepts de base Trois termes guident la surveillance et le contrôle : • surveillance • rédaction de rapports • contrôle La surveillance se réfère à l’observation d’une situation pour découvrir des changements qui se produisent dans le temps. La rédaction de rapports se réfère à l’analyse, à la production et à la distribution du produit de l’activité qui est sous surveillance. Le contrôle se réfère à la gestion du caractère d’utilité ou au comportement d’un dispositif, d’un système ou d’un service. Trois conditions existent pour le contrôle : 1. L’action doit garantir que le comportement est conforme à un standard ou à une norme bien définis. 2. Les conditions menant à l’action doivent être définies, comprises et confirmées. 3. L’action doit être définie, approuvée et adaptée à ces conditions.

Activités, méthodes et techniques Le cycle surveillance/contrôle Le modèle le plus connu pour décrire le contrôle est le cycle de surveillance/contrôle. Bien qu’il s’agisse d’un modèle simple, il a de nombreuses applications complexes dans la gestion des services informatiques. Cette section décrit les concepts de base de ce modèle. Ensuite, nous verrons l’importance de ces concepts pour le cycle de vie de la gestion des services. La Figure 12.5 présente les principes de base du contrôle. Ce cycle mesure une activité et ses avantages au moyen d’une norme ou d’un standard prédéfinis pour déterminer si les résultats se trouvent dans les limites des valeurs cibles, en termes de performance ou de qualité. Dans le cas contraire, des actions doivent être entreprises pour améliorer la situation ou rétablir les performances normales. Il existe deux types de cycle de surveillance/contrôle : • Systèmes de cycle ouvert – ils sont conçus pour une activité spécifique, indépendamment des conditions de l’environnement ; par exemple, il est possible de faire une copie de sauvetage (backup) à un moment donné et de la compléter indépendamment des autres conditions. • Systèmes de cycle fermé – surveiller un environnement et répondre aux changements de cet environnement ; si, dans un réseau, des transactions de réseau dépassent un certain nombre,

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

317

le système de contrôle redirigera le trafic vers un circuit de sauvegarde, afin de réguler les transactions de réseau.

Norme

Contrôler

Comparer

Surveiller

Entrée

Activité

Sortie

Figure 12.5  Le cycle surveillance/contrôle

La Figure 12.6 illustre un cycle complexe de surveillance/contrôle : ce processus consiste en trois activités importantes. Chaque activité a une entrée et une sortie et, à son tour, cette sortie est une entrée pour l’activité suivante. Chaque activité est contrôlée par son propre cycle de surveillance/contrôle avec l’aide d’un ensemble de normes pour cette activité spécifique. Un cycle coordonné de surveillance/contrôle surveille tout le processus et garantit que toutes les normes sont adaptées et appliquées. Le concept de cycle de surveillance/contrôle peut servir à gérer : • La performance des activités dans un processus ou dans une procédure ; en théorie, chaque activité et chaque sortie respective peuvent être mesurées pour garantir que les problèmes dans le processus sont identifiés avant que le processus ne soit complété. • L’efficacité du processus ou de la procédure dans leur ensemble. • Les performances d’un dispositif ou d’une série de dispositifs. Il faut répondre à ces questions pour déterminer comment le concept de cycles de surveillance/ contrôle peut servir à la gestion des services : • Comment allons-nous définir ce que nous avons besoin de surveiller ? • Comment allons-nous le surveiller (manuellement ou de façon automatisée) ? • Qu’est-ce qu’un processus normal ? • De quoi dépendons-nous pour un processus normal ? • Que se passe-t-il avant que nous recevions les entrées ? • A quelle fréquence avons-nous besoin de mesurer ?

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

318

Norme

Comparer

Contrôler

Surveiller

Norme

Contrôler

Norme

Comparer

Contrôler

Surveiller

Entrée

Activité

Norme

Comparer

Contrôler

Surveiller

Entrée

Sortie

Activité

Comparer

Surveiller

Activité

Entrée

Sortie

Sortie

Entrée

Figure 12.6  Le cycle complexe de surveillance/contrôle

La Figure 12.7 illustre un cycle de surveillance/contrôle de la gestion des services informatiques et comment le contrôle d’un processus ou de ses composants peut servir à fournir un service. Responsables Métieur et Gestionnaires des Départements Métier (BU)

Amélioration Continue des Services

1

Stratégie des Services

2

Portfolios, Standards & Policies

Conception des Services Transition des Services Technical Archtectures and Performance Standards

Utilisateurs

Gestion informatique et Gestion des Fournisseurs

3

Norme

Contrôler

Comparer

Contrôler

Surveiller

Entrée

Activité

Sortie

Norme

Norme

Contrôler

Comparer

Surveiller

Surveiller

Entrée

Activité

Sortie

Comparer

Entrée

Activité

Equipe technique interne et externe, experts

Figure 12.7  Le cycle de surveillance/contrôle ITSM

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Sortie

Fonctions et Processus dans l’exploitation des services

319

Il existe deux niveaux de surveillance : • La surveillance et le contrôle internes – ils se concentrent sur les activités et les éléments qui se passent à l’intérieur d’une équipe ou d’un département, par exemple, un gestionnaire de centre de services qui surveille le nombre d’appels pour déterminer le nombre de personnes nécessaires pour répondre au téléphone (appels). • La surveillance et le contrôle externes – l’équipe de gestion des serveurs surveille (pour le compte d’autres groupes) les performances de la CPU sur des serveurs critiques, et elle garde le volume de travail sous contrôle ; ceci permet aux applications essentielles de fonctionner dans les limites des valeurs cibles établies par la gestion des applications. Cette distinction est importante. Si l’exploitation des services s’occupe uniquement de la surveillance interne, alors l’infrastructure est bien organisée, mais le métier n’aura aucune idée de la qualité de service ni comment l’améliorer. Si l’organisation s’occupe uniquement de la surveillance externe, la qualité de service sera mauvaise, sans en connaître les causes et ni les solutions. En pratique, la plupart des organisations combinent les surveillances interne et externe, mais dans de nombreux cas, elles ne sont pas connectées. Une surveillance sans contrôle est ni pertinente ni efficace. La surveillance doit toujours viser à atteindre les objectifs services et opérationnels. Par conséquent, s’il n’y a aucune raison claire de surveiller un système ou un service, il ne devrait pas y avoir de surveillance. Pour qu’une organisation puisse déterminer ce qu’elle veut surveiller, il faut d’abord définir les résultats attendus. Objectifs de la surveillance et du contrôle. Idéalement, ce processus devrait commencer par la définition des exigences de niveaux de service. Celles-ci spécifieront comment les clients et les utilisateurs mesurent la qualité du service. De plus, ces exigences de niveaux de service fournissent les entrées pour les processus de conception des services. Par exemple, la gestion de la disponibilité déterminera comment configurer l’infrastructure pour obtenir le minimum de perturbations. Lors de la détermination de ce que l’exploitation des services surveillera et de la façon dont elle contrôlera les processus, il est important d’identifier les parties prenantes de chaque service. Une partie prenante peut être définie comme toute personne ayant un intérêt à bien fournir ou recevoir des services informatiques. Chaque partie prenante considèrera, à partir de sa propre perspective, ce qu’il faut pour fournir et recevoir un service informatique. L’exploitation des services doit connaître ces perspectives afin de déterminer ce qu’il faut surveiller et comment exploiter les résultats.

Outils Il existe différents types d’outils de surveillance ; le contexte détermine le type de surveillance à utiliser : • Surveillance active vs surveillance passive : – La surveillance active se réfère à l’interrogation continue d’un dispositif ou d’un système afin d’en déterminer le statut.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

320

Les fondamentaux de la gestion des services informatiques selon ITIL V3

– La surveillance passive est plus répandue et se réfère à la création et au passage d’événements à un dispositif ou au personnel de surveillance. • Surveillance réactive vs surveillance proactive : – La surveillance réactive est conçue pour exiger une action après un certain type d’événement ou de perturbation. – La surveillance proactive sert à suivre des schémas d’événement qui indiquent qu’un système ou un dispositif peut tomber en panne. La surveillance proactive sert généralement dans des environnements plus matures, dans lesquels il est possible de détecter ces schémas plus tôt. • Mesures continues vs mesures basées sur les exceptions : – Les mesures continues visent à surveiller un système en temps réel pour garantir sa conformité à une norme de performance donnée. Par exemple, un serveur d’applications est disponible 99% du temps d’accès convenu. – Les mesures basées sur les exceptions ne mesurent pas les performances actuelles d’un service ou d’un système, mais cherchent et signalent les exceptions. Par exemple, un événement est créé si une transaction n’est pas terminée. Cela sert aux systèmes moins critiques ou aux systèmes dont les coûts sont importants. • Performance vs rendement – Il faut distinguer les rapports sur les performances des composants, des équipes ou d’un département (performance) et les rapports montrant que les objectifs de qualité des services ont été atteints (rendement). L’exploitation des services effectue ces deux types de surveillance, mais ITIL se focalise principalement sur la surveillance des performances.

Métriques Il est important que les organisations disposent de techniques solides et de valeurs de mesure, qui soutiennent leurs objectifs. Dans ce contexte, les concepts suivants sont pertinents : • Mesures – Elles se réfèrent à toutes les techniques qui évaluent le périmètre, la dimension ou la capacité d’un élément en fonction d’un standard ou d’une unité. Les mesures sont uniquement utiles s’il est possible de mesurer le rendement réel d’un système, d’une fonction ou d’un processus par rapport à un standard ou à un niveau désiré. Par exemple, un serveur doit être capable de traiter un minimum de 100 transactions standards à la minute. • Métriques – Elles concernent l’évaluation quantitative et périodique d’un processus, d’un système ou d’une fonction ainsi que les procédures et les outils qui sont utilisés pour cette évaluation, et les procédures servant à les interpréter. Cette définition est importante car, non seulement, elle spécifie ce qui doit être mesuré, mais aussi la manière dont les mesures doivent être effectuées, les limites inférieures et supérieures des performances et les actions nécessaires en cas de performance anormale ou exceptionnelle. • Indicateurs clés de performance (KPI) – Ils se réfèrent à un niveau spécifique convenu de performance pour mesurer l’efficacité d’une organisation ou d’un processus. Les KPI sont spécifiques à chaque organisation et sont connectés à une entrée, une sortie et à des activités spécifiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

321

12.7 Opérations informatiques Introduction Pour fournir des services selon les accords avec le client, le fournisseur de services doit d’abord gérer l’infrastructure technique servant à fournir les services. Quand bien même aucun nouveau client n’est ajouté, qu’aucun nouveau service n’est introduit, qu’aucun incident ne survienne dans les services existants, et qu’aucun changement ne doit être apporté dans ces mêmes services, l’organisation informatique aura toujours énormément à faire avec une gamme d’opérations de services. Ces activités doivent se concentrer sur la fourniture des services convenus, selon les accords.

Salle de contrôle La salle de contrôle est un point central de coordination qui gère divers événements et activités opérationnelles de routine ; elle émet des rapports sur le statut ou les performances des composants technologiques. Une salle de contrôle rassemble tous les points d’observation essentiels de l’infrastructure informatique afin qu’ils puissent être surveillés et gérés avec le minimum d’efforts dans un lieu central. La salle de contrôle combine un grand nombre d’activités, telles que la gestion de la console, le traitement des événements, la gestion du réseau de premier niveau et le support hors des heures d’ouverture de bureau. Dans certaines organisations, le centre de services fait partie de la salle de contrôle.

Activités, méthodes et techniques Calendrier des métiers Les opérations informatiques exécutent des routines, des requêtes ou des rapports standards que les équipes de gestion des applications ont transmis en tant que partie du service ou des tâches de maintenance quotidiennes de routine.

Sauvegarde et restauration La sauvegarde et la restauration font partie intégrante de la planification d’une bonne continuité. La conception des services doit donc garantir l’existence de stratégies de sauvegarde fiables pour chaque service. La transition des services doit garantir qu’elles sont testées de façon correcte. De plus, certaines organisations – telles que les fournisseurs de services financiers et les compagnies cotées en bourse – doivent formellement mettre en œuvre et surveiller une stratégie de sauvegarde et de restauration comme cela est prescrit par la loi et les règlementations. Les exigences exactes varient selon le pays et le secteur d’activité. Une organisation doit protéger ses données, y compris le stockage et la sauvegarde des données, dans des emplacements réservés où elles seront protégées, et au besoin, accessibles.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

322

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Une stratégie de sauvegarde complète doit être négociée avec le métier, et doit couvrir les éléments suivants : • Quelles données devrait-on inclure dans les sauvegardes et à quelle fréquence doit-on faire les sauvegardes ? • Combien de générations de données doit-on garder ? • Le type de plan de secours et les points de contrôle à utiliser. • Les emplacements utilisés pour la sauvegarde et le calendrier des rotations. • Les méthodes de transport. • Les tests requis. • Le point de reprise planifiée ; le point où les données doivent être reprises après le redémarrage d’un service informatique. • Temps de reprise planifié ; le maximum de temps permis pour redémarrer un service informatique après une interruption. • Comment vérifier que les sauvegardes fonctionneront lors de leur restauration ? Dans tous les cas, le personnel chargé des opérations informatiques doit être qualifié en matière de procédures de sauvegarde et de restauration. Ces procédures doivent être documentées correctement dans le manuel des procédures des opérations informatiques. Si nécessaire, il faut inclure des exigences ou des objectifs spécifiques dans les OLA ou les UC, et spécifier les obligations et les activités des utilisateurs ou des clients dans les SLA correspondantes. Une restauration peut être instaurée à partir de plusieurs sources, allant d’un événement indiquant la corruption de données à une demande de service émanant d’un utilisateur ou d’un client. Une restauration peut être nécessaire dans les cas suivants : • des données corrompues • des données perdues • un plan de crise / une situation de continuité des services informatiques • des données historiques requises lors d’enquêtes légales

Imprimer et produire Les informations de nombreux services sont produites sur des supports papier ou électroniques (production). Le fournisseur de services doit garantir que les informations finissent au bon endroit, de façon correcte et sous une forme appropriée. La sécurité des informations joue souvent un rôle important. Le client devrait communiquer à temps au fournisseur tout besoin ponctuel d’imprimer et de produire des informations. Des lois et des règlementations peuvent jouer un rôle important dans l’impression et la production de documents. L’archivage des données importantes ou sensibles joue un rôle important. Les fournisseurs de services sont généralement responsables de la maintenance de l’infrastructure afin de mettre les fonctions d’impression et de production à la disposition des clients (imprimantes, stockage). Dans ce cas, il faut définir et inclure cette tâche dans le SLA.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

323

12.8 Centre de services Un centre de services est une unité fonctionnelle, comprenant des associés impliqués dans différents événements de service. Ces événements de service proviennent d’appels téléphoniques, du web, ou de l’infrastructure ; ces derniers événements sont reportés automatiquement. Le centre de services est un élément très important du département informatique d’une organisation. Il doit constituer le point de contact unique (SPOC) pour les utilisateurs informatiques et il gère tous les incidents et demandes de service. Le personnel du centre de services utilise souvent des outils logiciels pour enregistrer et gérer tous les événements.

Justification et rôle du centre de services De nombreuses organisations considèrent le centre de services comme le meilleur moyen d’offrir un support de premier niveau pour des défaillances informatiques. Un centre de services offre les avantages suivants : • Service client amélioré, meilleure perception du service de la part du client et satisfaction accrue du client. • Accès élargi par le biais d’un seul point de contact, de communication et d’information. • Meilleure résolution des demandes client et utilisateur. • Coopération et communication améliorées. • Réduction de l’impact négatif sur le métier. • Infrastructure mieux gérée et contrôlée. • Meilleure utilisation des ressources grâce au support informatique et à la productivité accrue du personnel de l’entreprise. • Informations de gestion plus significatives permettant de meilleures décisions pour le support.

Objectifs du centre de services La raison d’être principale du centre de services est de rétablir un service standard à l’utilisateur aussi rapidement que possible. Cela peut signifier résoudre une erreur technique, mais aussi remplir une demande de service ou répondre à une question.

Structure organisationnelle d’un centre de services Il existe de nombreuses façons pour organiser un centre de services. La solution sera différente pour chaque organisation. Les options principales sont les suivantes : • centre de services local • centre de services centralisé • centre de services virtuel • service 24 heures/24 • groupes de centres de services spécialisés Ces options sont détaillées plus loin. En pratique, une organisation met en œuvre une structure qui combine ces options afin de satisfaire les besoins du métier. Le centre de services local est situé chez, ou à proximité, des utilisateurs auxquels il offre son support. Dans ce cas, la communication passe souvent mieux et la présence visible plaît à certains utilisateurs. Toutefois, un centre de services local est coûteux et peut ne pas être efficient si

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

324

Les fondamentaux de la gestion des services informatiques selon ITIL V3

la quantité des événements liés aux services ne justifie pas vraiment l’existence du centre de services. Voici quelques bonnes raisons pour maintenir un centre de services local : • différences linguistiques, culturelles et politiques • différences de fuseaux horaires • groupes spécialisés d’utilisateurs • existence de services ajustés ou spécifiques nécessitant des connaissances spécialisées • statut des utilisateurs Le nombre de centres de services peut être réduit en les installant dans un seul endroit (ou en réduisant le nombre de centres de service locaux). Dans ce cas, le personnel est réparti dans une ou plusieurs structures de centres de service centralisés. Ceci peut se révéler moins coûteux et plus efficient, car moins de personnel s’occupe des événements de service (appels), alors que le niveau de connaissance du centre de services augmentera de manière certaine. En utilisant la technologie, notamment Internet, et en utilisant des outils de support, il est possible de créer l’impression d’un centre de services centralisé, alors que le personnel est en fait réparti plusieurs lieux géographiques ou structurels. Cela s’appelle le centre de services virtuel. Certaines organisations internationales combinent deux ou plusieurs centres de services répartis géographiquement afin d’offrir un service 24 heures/24 et 7 jours /7. De cette façon, un centre de services en Asie, par exemple, peut s’occuper des appels entrants pendant ses heures de bureau, tandis qu’à la fin de cette période, un centre de services en Europe gère les événements en suspens. Ce centre traite ces événements de service en même temps que ses propres événements. A la fin de la journée, la responsabilité est transférée à un centre de services en Amérique, qui transmet alors la responsabilité au centre de services en Asie, complétant ainsi le cycle. Certaines organisations jugent bon de créer des groupes de centres de services pour permettre aux incidents liés à un service informatique spécifique d’être canalisés et envoyés immédiatement vers le groupe spécialisé. De cette façon, les incidents peuvent être résolus plus rapidement. L’environnement du centre de services doit être soigneusement sélectionné, de préférence, à un endroit où les postes de travail ont suffisamment d’espace et de lumière naturelle. Un environnement silencieux avec une bonne acoustique est également important, car le personnel ne devrait pas se déranger mutuellement lors de conversations au téléphone. Un mobilier de bureau ergonomique est également important.

Personnel du centre de services Le nombre de personnes doit être soigneusement établi, il doit être suffisant et disponible pour permettre au centre de services de satisfaire la demande métier à tout moment. Les nombres d’événements de service peuvent, bien sûr, fluctuer fortement de jour en jour, voire d’heure en heure. L’organisation doit tenir compte des heures d’affluence et des périodes creuses. Une décision doit être prise concernant les niveaux de qualification nécessaires pour le personnel du centre de services. Pour déterminer le niveau de qualification requis, il faut comparer les

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

325

temps de résolution convenus avec la complexité des systèmes supportés, et les dépenses que le métier est prêt à engager. L’approche la meilleure et la plus efficiente s’appuie généralement sur un support de premier niveau offert par le centre de services, qui enregistre les événements de service, puis les escalade rapidement à des groupes d’experts de deuxième et de troisième niveaux. Si des niveaux de qualification ont été établis, le centre de services doit être dirigé de façon à ce que le personnel reçoive et maintienne les qualifications nécessaires. Une bonne combinaison de personnes qualifiées doit être disponible à tout moment. Il est essentiel que tout le personnel des centres de services reçoive une formation suffisante. Tous les nouveaux collaborateurs doivent suivre un programme formel d’insertion. Le contenu exact de ce programme variera pour chacun, selon son expertise et son expérience. Pour tenir informé le personnel du centre de services, un programme est nécessaire afin qu’ils soient tenus au courant des nouveaux développements, services et techniques. Il est essentiel de bien planifier ces activités pour ne pas perturber les tâches normales. De nombreux centres de services organisent de brèves séances de formation pendant les périodes creuses quand le personnel a moins d’événements de service à gérer. Il est très important que tous les partenaires informatiques comprennent l’importance du centre lui-même et des personnes y travaillant. Des frictions entre les collaborateurs du centre conduiraient à un service perturbé et incohérent. Les managers doivent donc faire des efforts pour retenir les collaborateurs. De nombreuses organisations trouvent logique de désigner des super utilisateurs au sein de la communauté des utilisateurs. Ceux-ci fonctionnent comme des contacts avec l’organisation informatique en général et avec le centre de services en particulier. Les organisations peuvent fournir une formation supplémentaire aux super utilisateurs et les utiliser comme canal de communication. Il est possible de leur demander de filtrer les demandes et certains problèmes pour le compte de la communauté des utilisateurs. Si un service ou un composant important est tombé, entraînant une perturbation pour nombre d’utilisateurs, cela pourrait conduire à un volume énorme d’appels au centre de services. Les super utilisateurs ne fournissent pas de support pour tous les services informatiques. Dans nombre de cas, le super utilisateur offre uniquement un support pour une application, un module ou une unité métier spécifique. En tant qu’utilisateur métier, le super utilisateur connaît bien souvent les processus de la société et sait quels services fonctionnent dans la pratique. Il est très utile de partager ses connaissances avec le centre de services afin qu’il puisse offrir à l’avenir des services de meilleure qualité.

Métriques Pour évaluer les performances du centre de services à intervalles réguliers, des métriques doivent être établies. De cette façon, la maturité, l’efficience, l’efficacité et les potentiels peuvent être établis et les actions du centre de services améliorées.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

326

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Les métriques de performance d’un centre de services doivent être sélectionnées avec soin et de façon réaliste. Il est fréquent de sélectionner des métriques qui sont déjà disponibles et qui déterminent un indicateur possible de la performance. Toutefois, cela pourrait être une erreur. Le nombre total d’événements de service que reçoit un centre de services, par exemple, n’est pas un indicateur en soi de bonne ou de mauvaise performance, et peut, en réalité, être causé par des événements n’ayant pas d’impact sur le centre de services. Pour déterminer cela, des analyses plus approfondies et des métriques plus détaillées sont nécessaires. Celles-ci feront l’objet de recherches sur une période de temps donnée. À part les statistiques mentionnées précédemment, à propos de la gestion des événements de service, les métriques se composent, entre autre, de : • Temps de traitement au premier niveau  ; pourcentage des événements de service, qui sont résolus par le premier niveau de service, sans devoir être escaladés aux autres groupes de support. • Temps moyen pour résoudre un incident (ou tout autre type d’appel de service) s’il est résolu par le premier niveau). • Temps moyen d’escalade d’un incident (si une solution n’est pas possible au premier niveau). • Coûts moyens de traitement d’un incident. • Pourcentage de mises à jour des clients et des utilisateurs qui sont exécutées dans les limites des valeurs cibles, selon les objectifs du SLA. • Temps moyen pour évaluer et clôturer un incident résolu. En plus de suivre des métriques dures (hard) pour les performances du centre de services, il est également important d’effectuer des métriques douces (soft) : Les enquêtes de satisfaction client et utilisateur (par exemple : est-ce que les clients et les utilisateurs trouvent que l’on répond à leurs appels téléphoniques de façon satisfaisante ? Est-ce que le collaborateur du centre de services a été courtois et professionnel ?). Les utilisateurs et les clients peuvent remplir au mieux ce type de métrique, mais il faut également poser des questions spécifiques concernant le centre de services lui-même.

Externalisation du centre de services La décision d’externaliser est une question qui concerne la direction et est abordée en détail au chapitre 4 (Stratégie des services et Conception des services). Indépendamment des raisons de l’externalisation ou de la portée du contrat d’externalisation, il est important que l’organisation garde la responsabilité des activités et des services rendus par le centre de services. En dernier ressort, l’organisation est responsable du résultat de la décision et doit donc décider quels sont les services à offrir. Si le centre de services est externalisé, les outils doivent être cohérents avec les outils utilisés par l’organisation du client. L’externalisation est souvent perçue comme une opportunité de remplacer des outils obsolètes ou inadéquats : toutefois, de graves problèmes d’intégration surviennent souvent entre les outils et processus, existants et nouveaux.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et Processus dans l’exploitation des services

327

Idéalement, le centre de services externalisé doit utiliser les mêmes outils et processus pour permettre aux processus de passer sans heurts du centre de services aux deuxième et troisième niveaux. Les cibles du SLA pour la gestion des incidents et pour les délais de traitement doivent être négociés avec les clients et entre toutes les équipes et départements ; les objectifs des OLA et des contrats de sous-traitance (UC) doivent être coordonnés et mis au point avec les différents groupes de support afin qu’ils soutiennent les objectifs du SLA.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

328

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Chapitre 13

Fonctions et processus dans l’amélioration continue des services 13.1 Processus d’amélioration CSI Introduction Le processus d’amélioration CSI ou processus d’amélioration en 7 étapes décrit comment mesurer et rendre compte de ces mesures. Toute amélioration se produit selon le cycle P-D-C-A (Plan [planifier]-Do [faire]-Check [vérifier]-Act [agir]). Le plan de CSI débouche sur un plan d’amélioration des services (SIP). La section suivante explique comment une organisation peut définir un tel plan.

Activités, méthodes et techniques Si la gestion des niveaux de service découvre que quelque chose peut être amélioré, elle le passera au CSI. CSI peut développer des activités pour compléter ces améliorations. CSI créera un SIP pour les exécuter. Cela transformera “l’amélioration” en un processus informatique avec des entrées, des activités, des sorties, des rôles et des rapports. CSI mesurera et traitera ces mesures dans un processus d’amélioration continu (Figure 13.1). Cela se fera en sept étapes depuis la mesure jusqu’à l’amélioration : 1. Que devrait-on mesurer ? – Quelle serait la solution idéale ? Cela doit s’inscrire dans la vision (Phase I du modèle CSI) et précéder l’évaluation de la situation actuelle (Phase II du modèle CSI). 2. Que peut-on mesurer ? – Cette étape suit la Phase III du modèle CSI : Où voulons-nous aller ? En cherchant ce que l’organisation peut mesurer, on découvre de nouveaux besoins du métier et de nouvelles options informatiques. L’analyse des écarts sert au CSI pour trouver les zones à améliorer et à planifier (Phase IV du modèle CSI). 3. Collecter les données (mesures) – pour vérifier si l’organisation a atteint son but (Phase V du modèle CSI), on doit effectuer des mesures. Les mesures doivent suivre la vision, la mission, les buts et les objectifs de l’organisation. 4. Traiter les données – le traitement des données est également nécessaire à des fins de surveillance. Cela se fait en fonction des facteurs clés de succès (CSF) et des indicateurs clés de performance (KPI) établis.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

330

Fondations de la Gestion des Services selon ITIL V3

5. Analyser les données – les divergences, tendances et explications possibles sont préparées pour être présentées au métier. Ceci constitue également une partie importante de la Phase V du modèle CSI. 6. Présenter et utiliser les informations – la partie prenante est informée de l’atteinte ou non des objectifs (toujours la Phase V). 7. Mettre en œuvre les actions correctives – créer des améliorations, établir une nouvelle base de référence et commencer le cycle par le haut.

1. Définir ce qu’il faut mesurer

7. Mise en œuvre des actions correctives

2. Définir ce qui est mesurable Objectifs

6. Présenter et utiliser l’information. Audit, résumé, plans d’action, etc

5. Analyser les données Relations ? Tendances ? Selon les plans ? Objectifs atteints ? Action corrective ?

3. Collecter les données (mesurer) Qui ? Comment ? Quand ? Intégrité des données

4. Traiter les données Fréquence ? Format ? Système ? Précision ?

Figure 13.1  La processus d’amélioration CSI (processus d’amélioration en 7 étapes)

Le cycle est précédé et clôturé par l’identification de la vision et des buts (identifier). À ce stade, la vision, la stratégie, les buts tactiques et opérationnels sont saisis dans une charte. Cette étape retourne à la Phase I du modèle CSI : déterminer la vision. La Figure 13.2 montre comment le modèle CSI et le processus d’amélioration CSI s’entremêlent. Les étapes 1 et 2 devraient découler directement des objectifs stratégiques, tactiques et opérationnels de l’organisation. Elles sont itératives : à chaque étape, il faut se demander si on mesure ce qui devrait être mesuré et si les valeurs mesurées sont fiables et sûres. Répondre à ces questions en collaboration avec le business pour lui assurer une fourniture d’informations utiles à l’étape 6. Si aucune base de référence n’a été établie, cette mesure doit se faire en premier lieu. Les premiers résultats des mesures constitueront la base de référence. Chaque niveau sera reporté dans le tableau de ce processus : les buts et objectifs stratégiques, la maturité tactique du processus, la métrique opérationnelle ainsi que les KPI. De cette façon, une spirale de connaissances est développée : les informations provenant de l’étape 6 dans le niveau opérationnel constituent les entrées pour l’étape 3 (collecter les données) du niveau tactique, et les informations du niveau tactique fourniront les données pour le niveau stratégique (Figure 13.3). Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans l’amélioration continue des services

331

Modèle CSI 1. Ce qu’il faut mesurer ?

CSI Processus d’amélioration

I. Déterminer la vision

7. Mettre en œuvre des actions correctives

6. Présenter et utiliser l’information

II. Déterminer la situation actuelle

VI. Conserver cet élan

III. Où voulons-nous aller?

V. Vérifier

IV. Planifier

5. Analyser les données

2. Ce qu’on peut mesurer ? 4. Traiter les données 3. Collecter les données (mesurer)

Figure 13.2  Connexion entre le modèle CSI et le processus d’amélioration CSI.

Si peu de données sont disponibles, on peut d’abord déterminer un système de mesure de base. Commencez une collecte de données cohérentes, par exemple, en demandant aux collaborateurs d’enregistrer les données de la même façon. On peut également mesurer la maturité du processus pour les processus actuels afin de trouver ceux qui s’éloignent le plus des meilleures pratiques. Toutefois, cela décèlera seulement un manque de données, aucune nouvelle information ne sera collectée de cette façon. La mesure ne doit jamais devenir un but en soi. Avant qu’un manager ne décide ce qu’il va mesurer et pendant combien de temps, il doit se demander pourquoi il devrait mesurer ceci et comment il va diffuser les résultats. Cela dépend du but du manager. Les quatre raisons habituelles pour lesquelles il faut mesurer sont : • valider – pour tester avant de prendre des décisions • diriger – donner des directions au métier pour atteindre les objectifs • justifier – soutenir la nécessité de certaines actions • intervenir – déterminer un point à partir duquel des actions correctives ou des changements sont nécessaires pour le processus Il est important de ne pas perdre de vue ces raisons, y compris pendant les mesures ellesmêmes. Après chaque rapport, le manage doit se demander : “Avons-nous (encore) besoin de

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

332

Fondations de la Gestion des Services selon ITIL V3

Etape 1

Etape 2

Etape 7

Gestion opérationnelle

Buts

Etape 6

Etape 1

Etape 2

Etape 3

Etape 5

Etape 4

Etape 3 Buts Etape 7

Etape4

Step 6 Etape 1

Etape 5

Gestion tactique

Etape 2

Etape 3 Buts Etape 7

Etape 4

Etape 6

Etape 5

Gestion stratégique

Figure 13.3  Spirale de connaissances

cela ?” Les questions “Qu’est-ce que je mesure réellement ?” et “Comment vais-je retrouver ces informations ?” sont également très importantes ; ces questions doivent revenir à chaque étape. La responsabilité en revient au propriétaire de chaque tableau de bord, qui doit créer des rapports utiles en s’assurant que le client les utilise vraiment. Si on suit les sept étapes du processus d’amélioration, ces questions apparaîtront d’elles-mêmes. Davantage de détails sur ces étapes suivent.

Étape 1 – Que devrait-on mesurer ? Dans un monde parfait, les propriétaires de service déterminent ce qui devrait être mesuré. Pour cette raison, ils produiront un tableau des activités nécessaires aux processus de gestion des services ou pour la fourniture des services. Ensuite, ils planifieront les mesures qui indiqueront si les services fournissent réellement ce qui a été convenu avec le métier, et la façon avec laquelle ils peuvent mesurer si les processus se déroulent sans heurts. La liste finale devrait refléter les visions, les missions, les buts et les objectifs du métier et des IT, alignés l’un avec l’autre. Ceci devrait aboutir sur un certain nombre de CSF, ainsi que sur des cibles de niveau de service. Les fiches de poste du personnel informatique devraient également y être associées. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans l’amélioration continue des services

333

Dans cet objectif, il est primordial d’échanger avec le métier et les fournisseurs de services en utilisant le catalogue des services et ses exigences (SLR) comme préalable à la définition des prestations. Déterminez les priorités en fonction de celles du métier. Pour cela, il est important de se remémorer la liste des fournisseurs de services internes et externes : que devrait-on mesurer chez eux pour déterminer s’il est possible de fournir ce service ? Entrées pour l’étape 1 : • exigences de niveau de service et objectifs • catalogue des services • vision, mission, buts et objectifs de l’organisation dans son ensemble et dans les différentes unités • exigences légales • exigences de gouvernance • budget • tableau de bord équilibré (BSC) Les sorties de l’étape 1 sont une liste de ce que l’on devrait mesurer, y compris : • les facteurs clés de succès CSF • les indicateurs clés de performance KPI • les métriques • les mesures

Étape 2 – Que peut-on mesurer ? Une divergence peut apparaitre entre votre liste idéale de l’étape 1 et les options réelles. En se basant sur les outils existants, la culture organisationnelle et la maturité des processus, il faut déterminer ce que l’on peut mesurer. Produisez un tableau de ce qui a été mesuré, établissez les rapports et les bases de données que l’organisation génère et vérifiez qu’ils sont mis à jour. Déterminez également le risque si l’on décide de ne pas mesurer quelque chose : quels seront les coûts par rapport aux coûts des mesures ? Si l’on ne peut mesurer quelque chose, alors celle-ci ne devrait pas être intégrée dans l’accord sur les niveaux de service (SLA). Enfin, déterminez les différences entre la liste idéale et la liste des mesures possibles. Il est possible que les outils existants doivent être ajustés, ou que de nouveaux outils soient requis pour se rapprocher de la liste idéale. De plus amples renseignements sur les CSF et les KPI se trouvent dans la section “Concepts de base” des CSI au chapitre 7 (Métrique et KPI). L’étape 4 du processus CSI, données des processus, fournit également des renseignements supplémentaires. Entrées pour l’étape 2 : • dressez une liste qui comprenne ce qu’il faut mesurer à l’étape 1, y compris les CSF, les KPI et les métriques • les flux de processus • les procédures

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

334

Fondations de la Gestion des Services selon ITIL V3

• les instructions de travail • les manuels techniques et d’utilisation pour les outils existants • les rapports existants Sorties de l’étape 2 : • liste de ce que l’on peut mesurer, y compris les CSF, les KPI et les métriques • liste des ajustements requis pour les outils • liste des nouveaux outils requis

Étape 3 – Collecter les données (mesurer) Les étapes 1 et 2 indiqueront les données requises et mesurables. Définissez les mesures selon le SMART. Pour collecter des données, il faut surveiller. Cela peut se faire en utilisant des outils, mais aussi manuellement. La surveillance devrait se concentrer sur un service, un processus, un outil, une organisation ou un CI. Cela ne doit pas toujours être en relation avec l’infrastructure. Cette surveillance peut également se concentrer sur la détermination du degré d’adéquation du personnel avec le processus. CSI met l’accent sur la découverte de zones à améliorer. Celles-ci sont souvent des exceptions à la règle, telles que les incidents non résolus. Les outils et les personnes peuvent fournir des avertissements pour les exceptions. Si une organisation satisfait les exigences du SLA de façon cohérente, la CSI peut aussi voir s’il est possible de satisfaire le même niveau à des coûts réduits, ou s’il est possible de fournir un niveau de service plus élevé. La conception d’un nouveau service ou l’ajustement d’un service existant est l’occasion parfaite pour inclure les exigences de surveillance dans les besoins du service. Les besoins métier de surveillance évolueront dans le temps. C’est la raison pour laquelle l’exploitation des services et la CSI doivent concevoir un processus qui aide le métier et les IT à trouver un accord sur ce qui devrait être surveillé et pourquoi. Si le personnel collecte les données manuellement, il doit s’accorder sur les aspects suivants : • Qui est responsable de la surveillance et de la collecte des données ? • Comment les données seront-elles collectées ? • Quand et à quelle fréquence les données seront-elles collectées ? • Quels sont les critères qui garantissent l’exactitude et la fiabilité des données ? La collecte de données consiste à mettre en œuvre les activités suivantes : • En se basant sur les plans d’amélioration des services (SIP), les buts, les objectifs et les besoins du métier, spécifier les activités du processus qu’il faut surveiller : – spécifier les besoins de surveillance – définir les besoins de collecte de données – enregistrer les résultats – demander l’approbation des départements informatiques internes

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans l’amélioration continue des services

335

• Déterminer comment et à quelle fréquence il faut collecter les données. • Déterminer les outils requis, les développer ou les acheter, ou personnaliser les outils existants. • Tester et installer l’outil. • Rédiger les procédures de surveillance et les instructions de travail. • Créer un plan de surveillance et le discuter ; demander l’approbation des fournisseurs de services informatiques internes et externes. • Planifier la disponibilité et la capacité. • Commencer la surveillance et la collecte des données. • Organiser les données de façon logique dans un rapport. • Évaluer les données pour s’assurer qu’elles sont correctes et utiles. Entrées pour l’étape 3 : • dresser une liste de ce que l’on devrait mesurer • dresser une liste de ce que l’on peut mesurer • dresser une liste de ce que l’on mesurera • accords sur les niveaux de service existants (SLA) • nouveaux besoins métiers • surveillance existante et options de collecte des données • planifier la disponibilité et la capacité • plans d’amélioration des services (SIP) • analyses des tendances précédentes • rapport de l’analyse des écarts • enquêtes de satisfaction client Sorties pour l’étape 3 : • planification actuelle de la disponibilité et de la capacité • plan de surveillance • procédures de surveillance • outils sélectionnés • données concernant l’aptitude des IT à satisfaire les attentes du métier • collecte de données • accord sur la fiabilité et l’applicabilité des données Si les données collectées sont inutilisables ou non fiables, elles peuvent toujours être utilisées pour déterminer celles qui seront nécessaires. Dans ce but, répétez les étapes 1 et 2.

Étape 4 – Traiter les données Dans cette étape, les données brutes de l’étape 3 sont traitées dans le format requis pour le public cible. Suivez le parcours de la métrique des KPI et de la CSF, et retournez à la vision, si nécessaire (Figure 13.4). Traduisez les données en une représentation de la performance du service à partir d’une perspective métier. Peu importe au métier de savoir si un serveur était disponible à 99,99% du temps s’il n’a pas pu y accéder à un instant donné. Collectez les données de façon logique pour faire en sorte que leur analyse (étape 5) soit plus facile. Des outils peuvent générer des rapports pour cela. À ce stade, les données deviennent des informations, d’après le modèle DIKW (voir chapitre 11). Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Les fondamentaux de la gestion des services informatiques selon ITIL V3

336

Etape 1

Etape 2

Etape 3

Vision

Buts

Mission

Etape 7

Etape 4

Buts Etape 6

Etape 5

Objectifs CSF Etape 1

Etape 2

KPI Etape 3

Buts

Métriques Mesures

Etape 7

Etape 4

Etape 6

Etape 5

Figure 13.4  De la vision aux mesures et vice-versa.

La collecte de données consiste à mettre en œuvre les activités suivantes : • Définir les besoins de données traitées à partir de la stratégie, des buts et des SLA. • Déterminer comment les données sont traitées ; pour les nouveaux services ou processus, il est préférable de sélectionner des intervalles plus courts ; cela se passe-t-il par heure, par jour, par semaine, par mois ? • Déterminer les regroupements de données selon la méthode d’analyse et le groupe destinataire ; formuler les besoins dans les outils, les développer ou les acheter, tester et installer. • Développer les procédures pour le traitement des données et former les personnes à ces procédures. • Créer un plan de surveillance et en discuter ; demander l’approbation des fournisseurs de services informatiques internes et externes. • Planifier la disponibilité et la capacité. • Commencer le traitement des données. • Regrouper les données d’une façon logique. • Évaluer l’exactitude des données. Entrées pour l’étape 4 : • données collectées par la surveillance • besoins de rapport • accords sur les niveaux de service (SLA) et accords sur les niveaux opérationnels (OLA) • catalogue des services • liste avec les métriques, les indicateurs clés de performances (CSF), les facteurs clés de succès (CSF), les objectifs et les buts • fréquence des rapports • modèles de rapport

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans l’amélioration continue des services

337

Sorties pour l’étape 4 : • planification actuelle de la disponibilité et de la capacité • rapports • données traitées et regroupées de façon logique prêtes pour l’analyse

Étape 5 – Analyser les données Sans analyse, les données restent seulement des informations. Elles ne fournissent pas d’indications sur les zones à améliorer. L’analyse évalue si les services informatiques soutiennent les buts et les objectifs établis. Les données seront appliquées pour répondre à des questions telles que : • Peut-on distinguer des tendances claires ? – sont-elles positives ou négatives ? – sont-elles alignées avec les buts ? – attendait-on ces tendances ? – quelles sont les explications potentielles ? • Faut-il changer quelque chose ? • Satisfera-t-on la planification et les buts ? • Y a-t-il des problèmes structurels sous-jacents ? Discutez des réponses à ces questions au sein de l’organisation, et d’abord avec le département informatique, afin de voir les options d’améliorations en collaboration. Par exemple, pensez à la formation, aux tests et à la documentation. Un début logique consiste à trouver le maillon le plus faible : l’activité de processus la moins efficace. Cela est souvent l’endroit qui peut dégager le plus de bénéfices. En raison des discussions précédentes concernant les options d’amélioration, le département informatique sera le premier à établir un dialogue avec le métier après l’analyse. Une bonne analyse des informations est également à l’avantage du métier. Cela permettra de déterminer de façon plus précise si une amélioration est requise sur la base des buts stratégiques, tactiques et opérationnels. À ce stade, les informations deviennent des connaissances, d’après le modèle DIKW.

Étape 6 – Présenter et utiliser les informations (rapports de service) Étape 6, les rapports de service, (voir aussi la section 13.2 “Rapports de service” pour une description plus détaillée) doivent traduire les connaissances en sagesse, nécessaire à la prise de décisions stratégiques, tactiques et opérationnelles. Appuyez, par des faits et de façon convaincante, toute valeur ajoutée que les IT apporte au métier. Pour cela, il convient de présenter les informations aux différentes parties prenantes, à tous les niveaux de l’organisation. Intégrez l’utilisation des techniques de marketing et de communication. Ajustez le message et la méthode selon le groupe destinataire et ses exigences. Normalement, les groupes destinataires possibles sont au nombre de trois : le métier (activité de l’organisation), la direction (informatique) et l’organisation informatique interne. Les membres du personnel aux différents niveaux de l’organisation ont des besoins différents. Il faut donc distinguer les catégories de personnel et leurs besoins, tels que les stratèges, les directeurs, les gestionnaires et les superviseurs, les chefs d’équipe et le personnel.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

338

Fondations de la Gestion des Services selon ITIL V3

Afin de fournir des rapports utiles au client, ces rapports devraient être rédigés depuis une perspective métier, c’est-à-dire, à partir d’une perspective de bout en bout – les détails de fonctionnement de l’infrastructure technique par laquelle les services lui sont fournis lui important peu – il s’intéressera uniquement au service en lui-même. Prendre le temps nécessaire pour établir un référentiel de rapports, en collaboration avec le métier et la conception des services : une politique formulée selon les règles de rédaction des rapports. Déterminez cela pour chaque unité métier, afin de distinguer, par exemple, les besoins de la production et ceux de la vente. Une fois que cela a été déterminé, les données peuvent facilement être traduites en rapports significatifs, parfois même de façon entièrement automatisée.

Étape 7 – Mettre en œuvre les actions correctives Une organisation ne sera pas en mesure de mettre en œuvre immédiatement toutes les options d’amélioration définies. Pour cette raison, il convient d’attribuer des priorités aux options sur la base des objectifs organisationnels et des réglementions externes définies dans la stratégie des services. C’est après cette étape que la conception des services pourra développer des améliorations que la transition des services déploiera ensuite dans l’environnement de production, et que l’exploitation incorporera dans les opérations quotidiennes. Pendant tout le cycle, il faut continuer à mesurer, analyser et rédiger des rapports afin de vérifier que les SLA et les KPI répondront aux besoins attendus. De plus, il faudra continuer à porter une attention particulière à la communication, à la formation et à la documentation. Il convient également d’évaluer rétrospectivement si les améliorations souhaitées ont produit les effets escomptés en termes de profits, ROI et VOI. Il est alors possible de vérifier si des améliorations supplémentaires sont nécessaires et de repartir de l’étape 1.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans l’amélioration continue des services

339

13.2 Rapport des services Introduction Le processus de rapport des services est le processus qui génère et de fournit des rapports sur les résultats atteints et sur les développements en termes de niveaux de service. Il convient de s’accorder avec le métier sur la mise en page, les contenus et la fréquence des rapports. La Figure 13.5 montre comment le processus de rédaction de rapports des services convertit les connaissances en sagesse, nécessaire à la prise de décisions stratégiques, tactiques et opérationnelles.

Le métier Définir les Politiques de reporting et les Règles Converger

Point de vue Business

Reporting de Service

Traduire et Mettre en œuvre

Publier Lien IT, Education et Communication

Figure 13.5  Processus de rédaction de rapports des services

Activités, méthodes et techniques Le processus de rédaction de rapports distingue les activités suivantes : • collecter les données • traiter les données en informations et les appliquer dans l’organisation • publier les informations • mettre au point les rapports pour le métier Soutenez le processus à l’aide d’un ensemble de bonnes pratiques.

Collecter les données Les départements informatiques collectent de grandes quantités de données, qui ne suscitent pas toutes le même intérêt pour le métier. Il convient donc de commencer par définir le but et le groupe destinataire du rapport et de prendre en compte la façon dont le rapport sera utilisé. Estce que la direction va le lire, est-ce que les managers et les responsables de département peuvent

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

340

Fondations de la Gestion des Services selon ITIL V3

le consulter en ligne ou allez-vous présenter les résultats lors d’une réunion ? Et que fera-t-on du rapport par la suite ?

Traiter et appliquer les données Le business aime avoir une vue générale et hiérarchisée de la performance au cours de la période de temps écoulée. Mais il est surtout intéressé par les événements passés pouvant avoir un impact, aujourd’hui ou dans le futur, sur la performance du métier et sur la façon dont les départements informatiques vont lutter contre ces menaces. Présentez les données en citant des références aux éléments de service comme des objets de contrats facturables. Traitez ces données dans un langage que le métier comprend. Rendez-compte non seulement du fait que le département informatique a atteint ou non les engagements du SLA, mais indiquez aussi les incidents qui se sont produits, ce que le département informatique a fait pour les résoudre et pour éviter leur répétition, et présentez comment l’IT convertit des exceptions positives en pratiques standards. Ne vous concentrez pas uniquement sur le passé mais aussi sur le futur. C’est une excellente opportunité marketing pour le département informatique de clarifier sa valeur ajoutée pour le business. Si possible, connectez la valeur directement aux expériences positives ou négatives du métier.

Publier les informations Publiez les informations pour les différentes parties prenantes à tous les niveaux de l’organisation et utilisez les techniques de marketing et de communication. Adaptez le message et la méthode au groupe destinataire et à ses besoins à partir d’une perspective métier. Normalement, les groupes destinataires possibles sont au nombre de trois : • Le métier : veut savoir si le fournisseur de services informatiques a fourni les services promis, en termes d’accords sur les niveaux de service (SLA) et quelles mesures ont été prises par le fournisseur de services le cas échéant. • la direction informatique : veut savoir si les facteurs clés de succès (CSF) et les indicateurs clés de performance (KPI) ont été atteints. Il recherche les améliorations stratégiques et tactiques qui sont nécessaires. Il a besoin de présentations fréquentes sous la forme d’un tableau de bord informatique équilibré (IT BSC). • L’organisation informatique interne : s’intéresse aux KPI et aux métriques, afin de situer, planifier et coordonner le potentiel d’amélioration.

Adapter les rapports au business Sélectionnez les groupes de données en fonction du groupe destinataire. Par exemple, le métier veut souvent connaître la durée de l’indisponibilité d’un service ; car un pourcentage de disponibilité ne fournit pas d’indications sur ses opportunités d’utilisation du service. Le fait que le mainframe ou le service ait été disponible tout le temps ne représente pas une information utile pour le métier. Ce dernier sera plus intéressé par le fait qu’il ne pouvait pas accéder au service. Observez cela à partir d’une perspective de bout en bout.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Fonctions et processus dans l’amélioration continue des services

Mesures processus de gestion informatiques Bénéfices 3ème dégrée

341

Mesures cœur de Mesures stratégiques cœur métier Business de métier informatiques Bénéfices 1èr dégrée Bénéfices 2ème dégrée • Chiffre d’Affaires • Part de marché • Bénéfice • ROE

Balanced Scorecard Structure d’excellence IT Business ; EFQM; Malcolm Baldrige; ISO 20000; Mesures informatiques Principes Deming; Modèle ITIL opérationnels Bénéfices 4ème dégrée Gestion de Service informatique Mesures opérationnels dans processus individuels: Centre de Services, Incident, Problème et Changement, Mise en Production, Disponibilité, Capacité, Coût par transaction

Figure 13.6  Les différents niveaux organisationnels et leurs besoins

La Figure 13.6 illustre les quatre niveaux organisationnels différents et leurs intérêts. 1. Stratèges – Ils veulent des rapports courts, avec beaucoup d’attention sur les risques, sur l’image de l’organisation, la rentabilité et les économies de coûts. 2. Directeurs – Ils veulent des rapports plus détaillés qui résument le développement mesuré en temps, qui indiquent la façon dont les processus soutiennent les objectifs de l’entreprise et les avertissent des risques. 3. Gestionnaires et superviseurs – Ils s’occupent d’observer les buts, la performance de l’équipe et du processus, la distribution des ressources et les initiatives d’amélioration. Les mesures et les rapports doivent indiquer comment les résultats du processus y contribuent. 4. Chefs d’équipe et collaborateurs – ils cherchent à mettre en évidence la contribution individuelle aux résultats de l’entreprise ; mettez l’accent sur la fixation de métriques individuelles, la reconnaissance de leurs compétences et la prise en compte du potentiel de formation, ceci afin de les impliquer dans les processus. Prenez en compte les objectifs du métier lors de la préparation des présentations. Ce n’est qu’à ce moment là que le département informatique peut répondre à la question sur sa valeur ajoutée. À part les exceptions négatives, toute présentation devrait également comprendre une liste de résultats positifs (anticipés). Adoptez une approche pratique : indiquez ce qui s’est passé et ce que le département informatique a fait pour le résoudre. Et pour éviter que cela se répète, indiquez ce que le département informatique fait pour transformer les exceptions positives en pratiques standards. Un tableau montrant ce qui a été fait et ce qui n’a pas été fait, n’est pas forcément compliqué, voir le Tableau 13.1. Prenez le temps, avec le métier et à l’aide d’une ébauche de services, de préparer un cadre de rapport orienté-métier : une politique qui est formulée selon les règles de rédaction des rapports.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

342

Période => Janvier Target A B C D E F Légenda : But atteint : But non atteint : But menacé :

Fondations de la Gestion des Services selon ITIL V3

Février

Mars

Avril

Mai

Juin

Juillet

Août

Tableau 13.1  Vue générale des réalisations des niveaux de service accomplies

Elle devrait au moins contenir : • les groupes destinataires et leur vue du service fourni • l’accord sur ce qui devrait être mesuré et mis dans un rapport • la définition de tous les termes et des limites supérieures et inférieures • la base pour tous les calculs • la planification des rapports • l’accès aux rapports et les médias utilisés • les réunions pour discuter des rapports Définissez cela avec le métier. De cette façon, il est possible de distinguer les départements de production de celui des ventes, par exemple. Toutefois, tous les rapports doivent s’intégrer dans un même rapport cadre. Une fois cela établi, les données peuvent simplement être converties en rapports significatifs, parfois même de façon automatisée. Pour ce faire, il convient de fournir des réponses claires aux questions de base ; indiquez où se trouvent les menaces et les difficultés, où le nombre de menaces a diminué, et ce qui a été amélioré. Il convient également d’adapter le média au groupe destinataire : rapports imprimés, en ligne ou présentation orale. Une rédaction soignée et efficace des rapports est cruciale pour la réussite et la continuité d’un système de rapports qui crée de la valeur pour le métier. Pour bien faire, il est nécessaire d’évaluer en permanence si les rapports existants fournissent des informations claires et dépourvues d’ambiguïté sur les performances du département informatique, et ajustez vos rapports le cas échéant.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

343

Références

Application Management. (2002). OGC. London: TSO. Bon, J. van, M. Pieper, & A. van der Veen (Eds.) (2006). Foundations of IT Service Management, based on ITIL. Zaltbommel: Van Haren Publishing for itSMF. Business Perspective Volume 1. (2004). OGC. London: TSO. Business Perspective Volume 2. (2006). OGC. London: TSO. Cambridge Advanced Learner’s Dictionary, http://dictionary.cambridge.org/ ICT Infrastructure Management. (2002). OGC. London: TSO. ITIL. Continual Service Improvement (2007). OGC. London: TSO. ITIL. Service Design (2007). OGC. London: TSO. ITIL. Service Operation (2007). OGC. London: TSO. ITIL. Service Strategy (2007). OGC. London: TSO. ITIL. Service Transition (2007). OGC. London: TSO. Kaplan, R., & D. Norton (1992, January-February). The Balanced Scorecard - measures that drive performance. Harvard Business Review, Vol. 70, No. 1, p. 71-79. Kaplan, R., & D. Norton (1993, September-October). Putting the Balanced Scorecard to work. Harvard Business Review, Vol. 71, No. 5, p. 134-142. Kotter, J.P. (1996). Leading Change. Cambridge (MA): Harvard Business School Press. Mintzberg, H. (1994). The Rise and Fall of Strategic Planning: reconceiving roles for planning, plans, planners. New York: The Free Press. Nolan, R. (1973). Managing the computer resource: a stage hypothesis. Communications of the ACM, Vol. 16, Issue 7, July, p. 399 - 405. Planning to Implement Service Management. (2002). OGC. London: TSO. Rummler, G. A., & A.P. Brache (1995, 2nd edition). Improving Performance: How to Manage the White Space in the Organization Chart. San Francisco: Jossey-Bass. Security Management. (1999). OGC. London: TSO. Service Delivery. (2001). OGC. London: TSO. Service Support. (2000). Office of Government Commerce (OGC). London: TSO. Software Asset Management. (2003). OGC. London: TSO. Zeithaml, V.A., A. Parasuraman, & L. Berry (1990). Delivering Quality Service. New York: The Free Press. (SERVQUAL model). Van Grembergen W., De Haes S., Guldentops E. (2003). Structures, Processes and relational mechanisms for Information Technology Governance: Theories and practices, Strategies for Information Technology Governance, book edited by Van Grembergen W., Idea Group Publishing.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

344

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

345

Glossaire

Acceptation (Acceptance) Accord formel sur le fait qu’un service, processus, plan des TI, ou autre livrable est achevé, précis, fiable et satisfait aux exigences spécifiées. L’acceptation est habituellement précédée d’une évaluation ou d’un test, elle est souvent nécessaire avant de passer à l’étape suivante d’un projet ou d’un processus. Voir Critères d’acceptation d’un service. Gestion des Accès (Access Management) (Exploitation de Services) Le processus responsable d’autoriser les utilisateurs à faire usage des services des TI, des données ou autres actifs. La Gestion de l’accès contribue à protéger la confidentialité, l’intégrité et la disponibilité des actifs en assurant que seuls les utilisateurs autorisés peuvent accéder ou modifier les actifs. La Gestion de l’accès est parfois appelée Gestion des Droits ou Gestion de l’Identification. Accès concurrents (Concurrency) Mesure du nombre d’utilisateurs engagés dans une même opération au même moment. Accord (Agreement) Document décrivant un arrangement formel entre deux parties ou plus. Un accord exécutoire ne devient légal que s’il fait partie d’un contrat. Voir Accord sur les niveaux de service, Accord sur les niveaux opérationnels. Accord sur les niveaux de service (SLA) Service Level Agreement (SLA) (Conception de services) (Amélioration continuelle du service) Un accord entre un fournisseur de service des TI et un client. Le SLA décrit le service des TI, documente les cibles de niveau de service et spécifie les responsabilités du fournisseur de service des TI et du client. Un seul SLA peut couvrir plusieurs services des TI ou plusieurs clients. Voir Accord sur les niveaux opérationnels (OLA). Accord sur les niveaux opérationnels (OLA) Operational Level Agrement (OLA) (Conception de service) (Amélioration continue du service) Un accord entre un fournisseur de services des TI et une autre partie de la même organisation. Un OLA soutient la livraison du fournisseur de services des TI en services aux clients. L’OLA définit les biens ou les services qui seront fournis et les responsabilités des deux parties. Par exemple, il doit y avoir un OLA : • entre le fournisseur de services des TI et un service Achats afin d’obtenir le matériel dans les délais attendus. • entre le centre de service et un groupe d’assistance afin de fournir la résolution d’un incident dans les délais attendus. Voir Accord sur les niveaux de service (SLA). Accrédité (Accredited) Officiellement autorisé à prendre en charge un Rôle. Par exemple, une personne accréditée ou un organisme accrédité peut être autorisée à fournir une formation ou à procéder à des Audits.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

346

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Actif (Asset) (Stratégie de Services) Toute ressource ou capacité. Les actifs d’un fournisseur de service regroupent tout ce qui peut contribuer à la fourniture d’un service. Les actifs peuvent appartenir à une des catégories suivantes : Gestion, Organisation, Processus, Compétences, Personnel, Informations, Applications, Infrastructure, et Capital financier. Actif de service (Service asset) Toute capacité ou ressource d’un fournisseur de service. Voir Actif. Activité (Activity) Ensemble d’actions permettant d’obtenir un résultat spécifique. Les activités sont habituellement définies sous la forme de parties de processus ou de plans et sont documentées dans des procédures. Adapté au besoin (Fit for purpose) Terme informel servant à décrire un processus, un élément de configuration, un service des TI etc, capable de satisfaire ses objectifs ou ses niveaux de service. Etre adapté nécessite une conception, une implémentation, un contrôle et un entretien adéquats. Alerte (Alert) (Exploitation de Services) Avertissement qu’un seuil a été atteint, que quelque chose a changé, ou qu’une panne s’est produite. Les avertissements sont souvent créés et gérés par les outils de Gestion du Système et sont gérés par le Processus de Gestion des Événements. Amélioration Continue des Services (CSI) (Continual Service Improvement (CSI)) (Amélioration continue du service) Une étape du cycle de vie d’un service des TI et le titre d’une des publications phare de l’ITIL. L’amélioration continuelle du service a en charge la gestion des améliorations des processus de gestion des services des TI et des services des TI eux-mêmes. La performance d’un fournisseur de services informatiques est continuellement mesurée et des améliorations sont apportées aux processus, aux services des TI et à l’infrastructure des TI afin d’accroître leur efficience, leur efficacité et leur rendement. Analyse chronologique (Chronological Analysis) (Exploitation de Services) Technique contribuant à l’identification des causes possibles de problèmes. Toutes les données disponibles concernant le problème sont collectées et triées par date et période afin de fournir une périodicité détaillée. Ceci rend possible l’identification des événements ayant pu être déclenchés par d’autres. Analyse coûts-bénéfices (Cost Benefit Analysis) Activité ayant pour but d’analyser et de comparer les coûts et les bénéfices impliqués dans une ou plusieurs actions en cours. Voir Étude de business, Valeur nette actuelle, Tarif de retour interne, Retour sur investissement, Valeur sur investissement. Analyse d’impact de la défaillance d’un composant (CFIA) (Component Failure Impact Analysis) (Conception de services) Technique contribuant à l’identification de l’impact de la défaillance d’un CI sur les services informatiques. On dresse un tableau avec la liste des services des TI d’un côté et les CI de l’autre. Ce qui permet l’identification des CI cruciaux (ceux qui peuvent être la cause de la défaillance de plusieurs services des TI) et des services des TI fragiles (ayant plusieurs points de défaillance uniques).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

347

Analyse d’impact sur le business (BIA) (Business Impact Analysis) (Stratégie de Services) La BIA est l’activité de la gestion de la continuité du business qui identifie les fonctions business vitales et leurs dépendances. Ces dépendances peuvent inclure des sous-traitants, des gens, d’autres processus business, des services informatiques, etc. La BIA définit les besoins de la reprise des services des TI. Ces besoins incluent les objectifs de temps de reprise, les objectifs de point de reprise et les cibles de niveau de service minimum pour chacun des services informatiques. Analyse de Kepner & Tregoe (Kepner & Tregoe Analysis) (Exploitation de Services) (Amélioration continue du service) Une approche structurée pour résoudre un problème. Le problème est analysé en termes de “quoi, où, quand et autres”. Les causes possibles sont identifiées. La cause la plus probable est testée. La cause réelle est vérifiée. Analyse de la cause première (RCA) (Root Cause Analysis) (Exploitation de Services) Une activité qui identifie la cause fondamentale d’un incident ou d’un problème. La RCA se concentre typiquement sur les défaillances de l’infrastructure des TI. Voir Analyse de la défaillance du service. Analyse de la valeur de dérangement (Pain Value Analysis) (Exploitation de Services) Technique aidant à identifier l’impact sur le business d’un ou de plusieurs problèmes. Une formule sert à calculer la valeur de dérangement, elle est basée sur le nombre d’utilisateurs affectés, la durée de l’indisponibilité, l’impact sur chaque utilisateur et le coût pour le business (s’il est connu). Analyse de l’écart (Gap Analysis) (Amélioration continuelle du service) Activité ayant pour but de comparer deux ensembles de données et d’identifier leurs différences. L’analyse des écarts sert fréquemment à comparer un ensemble d’exigences avec ce qui a été réellement fourni. Voir Benchmarking. Analyse de tendance (Trend Analysis) (Amélioration continuelle du service) Analyse des données permettant d’identifier des schémas relatifs au temps. L’analyse des tendances est employée par la Gestion des problèmes afin d’identifier les défaillances habituelles ou les éléments de configuration fragiles, et par la Gestion de la capacité comme outil de modélisation pour prédire un futur comportement. Elle est aussi utilisée comme outil de gestion pour identifier les déficiences dans les processus de gestion des services des TI. Analyse des défaillances de service (SFA) (Service Failure Analysis) (Conception de services) Activité qui a pour raison d’identifier les causes sous-jacentes d’une ou plusieurs interruptions du service des TI. La SFA identifie également les opportunités d’amélioration des processus et des outils du fournisseur de service des TI et pas seulement celles de l’infrastructure des TI. La SFA est une activité de type projet avec des contraintes de temps, plutôt qu’un processus d’analyse courant. Voir Analyse de la cause fondamentale (RCA). Analyse des modes et effets des défaillances (FMEA) (Failure Modes and Effects Analysis) Approche permettant d’évaluer l’impact potentiel des défaillances. La FMEA implique d’analyser ce qui pourrait arriver suite à la défaillance de chacun des éléments de configuration jusqu’à leur effet sur le business. La FMEA est souvent utilisée par la gestion de la sécurité des informations et le Plan de continuité des services des TI.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

348

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Analyse par arbre de pannes (FTA) (Fault Tree Analysis) (Conception de services) (Amélioration continue du service) Technique pouvant être utilisée pour déterminer la chaîne des événements ayant conduit à un problème. L’analyse par arbre de panne représente la chaîne d’événements dans un schéma utilisant la notation Booléenne. Analyse SWOT (SWOT Analysis) (Amélioration continuelle du service) Une technique qui revoit et analyse les forces et les faiblesses internes d’une organisation, ainsi que les opportunités et les menaces extérieures auxquelles elle doit faire face. SWOT signifie Forces (Strengths), Faiblesses (Weakness), Opportunités (Opportunity) et Menaces (Threats). Analytique de services (Service Analytics) (Stratégie de Services) Technique servant à évaluer l’impact des incidents sur le business. Les analytiques de service modélisent les interdépendances entre les divers éléments de configuration, et les dépendances des services des TI envers les éléments de configuration. Anatomie de la performance (Performance Anatomy) (Stratégie de service) Une approche de la culture organisationnelle qui intègre et gère activement leadership et stratégie, développement des équipes, progrès technologique, gestion des performances et innovation. Appel (Call) (Exploitation de Services) Un appel téléphonique au Centre de Services de la part d’un utilisateur. Un appel peut se concrétiser par la journalisation d’un incident ou d’une demande de service. Application (Application) Logiciel fournissant les fonctions nécessaires à un service informatique. Une application est exécutée sur un ou plusieurs serveurs ou clients. Voir Gestion des applications, Portefeuille d’applications. Aptitude (Capability) (Stratégie de Services) L’aptitude d’une organisation, d’une personne, d’un processus, d’une application, d’un élément de configuration, ou d’un service des TI à mener à bien une activité. Les aptitudes sont les actifs intangibles d’une organisation. Voir Ressouces. Architecture (Architecture) (Conception de services) Structure d’un système ou d’un service informatique, incluant les relations des composants les uns avec les autres et avec leur environnement. L’architecture inclut également les standards et les principes qui régissent la conception et l’évolution du système. Article commercial prêt à l’emploi (COTS) (Commercial off the Shelf ) (Conception de services) Application logicielle ou Middleware pouvant être achetée auprès d’un fournisseur externe. Assemblage (Assembly) (Transition de Services) Un élément de configuration élaboré à partir d’un certain nombre d’autres éléments de configuration. Par exemple un élément de configuration serveur peut contenir des éléments de configuration pour les cartes-mères, les disques durs, les cartes mémoire, etc ; un élément de configuration de service informatique peut contenir

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

349

plusieurs matériels, logiciels et d’autres éléments de configuration. Voir Éléments de configuration d’un composant, Construction. Assurance qualité (QA) (Quality Assurance) (Transition de service) Processus en charge d’assurer que la qualité d’un produit, d’un service ou d’un processus fournira la valeur escomptée. Attribut (Attribute) (Transition de Services) Une information concernant un élément de configuration. Par exemple, le nom, l’emplacement, le numéro de version et le coût. Les attributs des éléments de configuration sont enregistrés dans la Base de Données de Gestion des Configurations (CMDB). Voir Relations. Audit (Audit) Inspection et vérification formelle permettant de s’assurer qu’un standard ou un ensemble de principes a bien été suivi, que les enregistrements sont précis ou que les objectifs d’efficience et d’efficacité ont été atteints. Un audit peut être effectué par des groupes internes ou externes. Voir Certification, Évaluation. Base de connaissances (Knowledge Base) (Transition de service) Une base de données logique contenant les données utilisées par le système de gestion des connaissances du service. Base de donnée des fournisseurs et des contrats (SCD) (Supplier and Contract Database) (Conception de services) Une base de données ou un document structuré servant à gérer les contrats de sous-traitance tout au long de leur cycle de vie. La SCD contient les attributs clés de tous les contrats avec les sous-traitants et doit faire partie du Système de gestion des connaissances du service (SKMS). Base de données des erreurs connues (KEDB) Known Error Database (KEDB) (Exploitation de Services) Une base de données contenant tous les enregistrements des erreurs connues. Cette base de données est créée par la gestion des problèmes et utilisée par la gestion des incidents et des problèmes. La base de données des erreurs connues fait partie du Système de gestion des connaissances du service. Base de reference (Baseline) (Amélioration continuelle du service) Une mesure ou image servant de point de référence. Par exemple : • Une base de référence ITSM peut servir de point de départ pour mesurer l’effet d’un Plan d’Amélioration du Service. • Une base de référence de performance peut servir à mesurer l’évolution des performances dans le temps d’un service des TI. • Une base de référence de Gestion des Configurations peut permettre de restaurer une infrastructure des TI selon une configuration connue si un changement ou une mise en production a échoué. Benchmark (Benchmark) (Amélioration continuelle du service) État enregistré de quelque chose à un moment précis. Un test de performance peut être effectué pour une configuration, un processus, ou tout autre ensemble de données. Par exemple, un test de performance peut servir à : • L’amélioration continuelle du service, afin d’établir l’état actuel des améliorations de gestion. • La Gestion de la Capacité, pour documenter les caractéristiques des performances pendant les opérations normales. Voir Benchmarking, Base de référence Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

350

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Benchmarking (Benchmarking) (Amélioration continuelle du service) Action de comparer un test de performance à une base de référence ou à une meilleure pratique. Le terme Benchmarking signifie également créer une série de tests de performance dans le temps, et comparer leurs résultats afin de mesurer la progression ou l’amélioration. Besoin (Requirement) (Conception de service) Un énoncé formel de ce qui est nécessaire. Par exemple, une exigence de niveau de service, une exigence de projet, ou les Livrables exigés par un processus. Voir Énoncé des exigences. Bibliothèque des supports définitifs (DML) (Definitive Media Library) (Transition de Services) Un ou plusieurs endroits dans lesquels les versions définitives et approuvées de tous les éléments de configuration logiciels sont stockées en toute sécurité. La DML peut aussi contenir des CI associés tels que licences et documentation. La DML est une zone de stockage logicielle unique même si les lieux sont multiples. Tout logiciel de la DML est sous le contrôle de la Gestion des changements et de la Gestion des mises en production et est enregistré dans le Système de gestion des configurations. Seul un logiciel issu de la DML est acceptable pour être utilisé dans une mise en production. Boucle de contrôle (Monitor Control Loop) (Exploitation de Services) Surveiller le résultat d’une tâche, d’un processus, d’un service des TI ou d’un élément de configuration  ; et le comparer à une valeur prédéfinie  ; puis prendre les mesures appropriées en se basant sur cette comparaison. Institut de Normalisation Britannique British Standards Institution (BSI) Organisme national des standards pour le Royaume-Uni ayant en charge leur création et leur évolution (équivalent de l’AFNOR en France et le BNQ au Québec). Voir http://www.bsi-global.com pour de plus amples informations. Voir ISO. Budget (Budget) Consolidation des éléments financiers prévisionnels d’une organisation ou d’une unité opérationnelle, comprenant les prévisions de recettes et de dépenses sur une période donnée. Voir Budgétiser, Planifier. Budgétisation (Budgeting) Activité de prévision et de contrôle des budgets. Comprend un cycle de négociation périodique pour définir les budgets futurs (habituellement annuels) ainsi que la surveillance quotidienne et l’ajustement des budgets en cours. Business (Business) (Stratégie de Services) Une société dans son ensemble ou une Organisation composée d’un certain nombre d’unités Business. Dans le contexte de l’ITSM, le terme Business inclut le secteur public et les organisations non commerciales, ainsi que les compagnies. Un fournisseur de services informatiques fournit des services informatiques à un Client au sein d’un Business. Le fournisseur de services informatiques peut faire partie du même Business que ses Clients (fournisseur de services interne) ou faire partie d’un autre Business (fournisseur de services externe). Calendrier des changements (Change Schedule) (Transition de Services) Document qui établissant la liste de tous les changements approuvés et leurs dates d’implantation prévues. Un calendrier des changements est parfois appelé calendrier prévisionnel des changements, bien qu’il contienne quand même des informations sur les changements déjà effectués. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

351

Capability Maturity Model (CMM) (Capability Maturity Model) (Amélioration continuelle du service) Le modèle de maturité d’aptitude pour logiciel (aussi connu sous le nom de CMM et SW-CMM) est un modèle servant à identifier les meilleures pratiques, afin d’améliorer le processus la maturité du processus. Le CMM a été développé par le SEI (Software Engineering Institute) de l’Université de Carnegie Mellon University. En 2000, le SW-CMM a fait l’objet d’une transition vers le modèle CMMI® (Capability Maturity Model Integration). Dès lors, le SEI a cessé de faire évoluer le modèle SW-CMM, ses méthodes d’évaluation associées, ni ses supports de formation. Capability Maturity Model Integration (CMMI) (Capability Maturity Model Integration) (Amélioration continuelle du service) Le modèle de maturité d’aptitude à l’intégration est une approche d’amélioration de processus développée par le SEI (Software Engineering Institute) de Carnegie Mellon University. Le CMMI fournit aux organisations des éléments essentiels à l’efficacité des processus. Il peut servir à guider l’amélioration de processus au cours d’un projet, au sein d’une division ou d’une organisation dans son ensemble. Le CMMI contribue à intégrer des fonctions organisationnelles traditionnellement séparées, définit les buts et les priorités de l’amélioration des processus, établit les préceptes des processus qualité et fournit un point de référence pour l’évaluation des processus en cours. Voir http://www.sei.cmu.edu/cmmi pour de plus amples informations. Voir CMM, Amélioration continuelle, Maturité. Capacité (Capacity) (Conception de services) Le rendement maximum qu’un élément de configuration (CI) ou un service informatique puisse fournir en répondant aux Objectifs de Niveau de Service. Pour certains types de CI, la capacité peut être la taille ou le volume, par exemple un disque dur. Capacité de traitement (Throughput) (Conception de services) Une mesure du nombre de transactions ou autres opérations effectuées dans un délai donné. Par exemple, 5000 e-mails envoyés par heure ou 200 accès disque par seconde. Capitalisation (Capitalization) (Stratégie de Services) Identification d’un coût majeur sous la forme de capital, sans acquisition d’actif. Ceci permet d’étaler l’impact du coût sur plusieurs périodes comptables. L’exemple le plus courant est le développement logiciel ou l’achat d’une licence logicielle. Catalogue des services (Service Catalogue) (Conception de services) Une base de données ou un document structuré comportant des informations sur tous les services des TI réels, dont ceux qui sont disponibles pour leur déploiement. Le catalogue des services est la seule partie du portefeuille des services rendue publique aux clients, et sert de support de vente et de fourniture des services des TI. Le catalogue des services comprend des informations sur les livrables, les prix, les points de contact, les processus de commande et de demande. Voir Portefeuille des contrats. Catégorie (Caterory) Groupe d’objets nommés ayant quelque chose en commun. Les catégories servent à regrouper des choses similaires. Par exemple, les types de coûts servent à regrouper des types de coûts similaires. Les catégories d’incidents servent à regrouper des types d’incidents similaires, les types de CI à regrouper des types d’éléments de configuration similaires.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

352

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Cause première (Root Cause) (Exploitation de Services) La cause sous-jacente ou originelle d’un incident ou d’un problème. Centre d’appels (Call Center) (Exploitation de Services) Une Organisation ou une unité business qui gère un grand nombre d’appels téléphoniques reçus et émis. Voir Centre de Services. Centre d’assistance (Help Desk) (Exploitation de Services) Un point de contact pour les utilisateurs pour signaler (journaliser) des incidents. Un centre d’assistance est habituellement davantage orienté technique qu’un centre de services et ne fournit pas un point de contact unique pour toutes les interactions. Le terme “centre d’assistance” est souvent employé à la place de centre de services. Centre de coûts (Cost Center) (Stratégie de Services) Unité business ou un projet auquel des coûts sont affectés. Un centre de coût ne facture pas les services qu’il fournit. Un fournisseur de services informatiques peut fonctionner comme un centre de coût ou un centre de profit. Centre de profit (Profit Centre) (Stratégie de service) Une unité business qui facture les services fournis. Un centre de profit peut être créé avec l’objectif de faire des profits, de rembourser des coûts ou de fonctionner à perte. Un fournisseur de service des TI peut fonctionner comme un centre de coûts ou un centre de profit. Centre de Services (Service Desk) (Exploitation de Services) Le point de contact unique entre le fournisseur de service et les utilisateurs. Un centre de services typique gère les incidents et les demandes de service, ainsi que les communications avec les utilisateurs. Certification (Certification) Publier un certificat pour valider la conformité à un standard. La certification comporte un audit formel réalisé par une structure indépendante et accréditée. Le terme Certification signifie également décerner un certificat pour valider la qualification d’une personne. Chaîne d’approvisionnement (Supply Chain) (Stratégie de Services) Les activités d’une chaîne de valeur exécutées par des sous-traitants. Une chaîne de sous-traitance implique de multiples sous-traitants, chacun ajoutant de la valeur au produit ou au service. Voir Réseau de valeur. Chaîne de valeur (Value Chain) (Stratégie de Services) Une suite de processus qui crée un produit ou un service des TI ayant une valeur pour un client. Chaque étape de la séquence se construit sur les précédentes et contribue à l’ensemble du produit ou du service. Voir Réseau de valeur. Changement (Change) (Transition de Services) L’ajout, la modification ou la suppression de quoique que ce soit pouvant avoir un effet sur les services des TI. L’étendue doit inclure tous les services des TI, éléments de configuration, processus, documentation, etc.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

353

Changement standard (Standard change) (Transition de Services) Un changement pré-approuvé présentant peu de risque, relativement commun et qui sera exécuté selon une procédure ou une instruction de travail. Par exemple, la réinitialisation d’un mot de passe ou la fourniture d’un équipement standard à nouvel employé. Des RFC ne sont pas requises pour implanter un changement standard, RFC qui sont journalisées et suivies selon un mécanisme différent, tel qu’une demande de service. Voir Modèle de changement. Changement urgent (Emergency Change) (Transition de Services) Un changement qui doit être introduit dès que possible. Par exemple pour résoudre un incident majeur ou implémenter un correctif de sécurité. Le processus de gestion des changements doit normalement avoir une procédure spécifique pour gérer les changements d’urgence. Voir Comité consultatif des changements d’urgence. Chargé de clientèle (Account Manager) (Stratégie de Services) Un rôle très proche de celui du Gestionnaire des Relations Business, mais qui comporte davantage d’aspects commerciaux. Il a principalement en charge les Clients Externes. Charge de travail (Workload) Les ressources nécessaires pour délivrer une partie identifiable d’un service des TI. Les charges de travail peuvent être classées par catégorie, selon leurs utilisateurs, groupes d’utilisateurs ou leurs fonctions au sein d’un service des TI. Cela sert à assister l’analyse et la gestion de la capacité, les performances, l’utilisation des éléments de configuration et des services des TI. Le terme “charge de travail” est parfois utilisé comme un synonyme de “débit”. CI Composant (Component CI) (Transition de Services) Élément de configuration faisant partie d’un assemblage. Par exemple, un CI carte-mère ou cartemémoire peut faire partie d’un CI serveur. Cible de niveau de service (Service Level Target) Service Level Target (Conception de services) (Amélioration continuelle du service) Un engagement documenté par un accord sur les niveaux de service (SLA). Les cibles de niveau de service sont basées sur les exigences de niveau de service (SLR) et doivent assurer que la conception d’un service des TI est adaptée aux besoins. Les cibles de niveau de service doivent être SMART et sont habituellement basées sur les KPI. Classification (Classification) Action d’assigner une catégorie à quelque chose. La classification permet d’assurer une gestion et des rapports cohérents. Les CI, incidents, problèmes, changements, etc. sont habituellement classés. Client (Client) Terme générique représentant une clientèle, le business ou un client du business. Par exemple, le Gestionnaire de Clientèle peut être synonyme de Gestionnaire des comptes. Le terme Client peut également signifier : • Un ordinateur employé directement par un Utilisateur, par exemple un PC, un ordinateur de poche ou un poste de travail. • Une partie d’une application Client-Serveur à laquelle l’Utilisateur est directement interfacé. Par exemple un Client e-mail.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

354

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Client (Customer) Personne qui achète des biens ou des services. Le client d’un fournisseur de service informatique est la personne ou le groupe qui définit et convient des cibles de niveau de service. Le terme “client” est aussi utilisé parfois de manière informelle pour désigner les utilisateurs, par exemple “il s’agit d’une organisation orientée Client”. Client business (Business Customer) (Stratégie de Services) Bénéficiaire d’un produit ou d’un service issu du business. Par exemple, si le business est la fabrication de véhicules alors le client business est celui qui achète un véhicule. Client externe (External Customer) Un client qui travaille à un business différent de celui du fournisseur de services des TI. Voir Fournisseur de service externe, Client interne. Client interne (Internal Customer) Un client qui travaille dans la même entité ou organisation que celui du fournisseur de services des TI. Voir Fournisseur de service interne, Client externe. Clôture (Closure) (Exploitation de Services) Action de modifier l’état d’un incident, d’un problème, d’un changement, etc. en lui attribuant l’état Fermé. Clôturé (Closed) (Exploitation de Services) L’état final du cycle de vie d’un incident, d’un problème, d’un changement, etc. Lorsque l’état est devenu Fermé, plus aucune action n’est effectuée. COBIT (COBIT) (Amélioration continuelle du service) Le COBIT (Control Objectives for Information and related Technology) établit les préceptes et les meilleures pratiques de gestion des processus des TI. Le COBIT est publié par l’IT Governance Institute. Voir http://www.isaca.org/ pour de plus amples informations. Code de bonne pratique (Code of Practice) Principe publié par un service public ou un organisme de standardisation, tel que ISO ou BSI. De nombreux standards sont basés sur un code de pratique et une spécification. Le code de pratique décrit les meilleures pratiques recommandées. Cold standby (Cold Standby) Équivalent de Gradual Recovey (Reprise graduelle). Comité consultatif sur les changements (CAB) (Change Advisory Board) (Transition de Services) Un groupe de personnes qui conseille le Gestionnaire des Changements dans l’évaluation, la définition des priorités et le calendrier des changements. Ce comité est habituellement composé de représentants de toutes les branches au sein du fournisseur de services informatiques, du business et des tierces parties tels que les soustraitants. Comité consultatif sur les changements urgents (ECAB) (Emergency Change Advisory Board) (Transition de Services) Un sous-ensemble du Comité consultatif des changements qui prend les décisions concernant les changements d’urgence à fort impact. Les membres de l’ECAB peuvent être nommés au moment de la réunion et la composition de l’ECAB dépend de la nature du changement d’urgence. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

355

Composant (Component) Terme générique signifiant une partie d’un objet plus complexe. Par exemple, un système informatique peut être un composant d’un service informatique, une application peut être un composant d’une unité de mise en production. Les composants faisant l’objet d’une gestion doivent être des éléments de configuration. Comptabilité (Accounting) (Stratégie de Services) Le processus qui est chargé d’identifier les coûts réels de fourniture des services des TI, de les comparer avec les budgets prévus et de gérer les écarts avec le budget. Conception (Design) (Conception de services) Activité ou processus qui identifie les besoins puis définit une solution pour satisfaire ses besoins. Voir Conception de services. Conception de Services (Service Design) (Conception de services) Une phase du cycle de vie d’un service des TI. La conception d’un service comporte un certain nombre de processus et de fonctions, c’est le titre d’une des publications phares de l’ITIL. Voir Conception. Confidentialité (Confidentiality) (Conception de services) Principe de sécurité nécessitant que les données ne soient accessibles qu’à des personnes autorisées. Configuration (Configuration) (Transition de Services) Terme générique servant à décrire un groupe d’éléments de configuration fonctionnant ensemble pour fournir un service informatique ou une partie significative d’un service informatique. Le terme Configuration sert également à décrire les réglages des paramètres d’un ou de plusieurs CI. Configuration de reference (Configuration Baseline) (Transition de Services) Base de référence d’une configuration ayant été formellement convenue et qui est gérée via le processus de Gestion des changements. Une base de référence de configuration servira de base aux futurs constructions, mises en production et changements. Conformité (Compliance) Assurer qu’un standard ou un ensemble de principes est suivi, qu’une comptabilité correcte et cohérente est appliquée ou que diverses pratiques ont été employées. Construction (Build) (Transition de Services) Activité qui consiste à assembler un certain nombre d’éléments de configurations afin de créer une partie d’un service des TI. Le terme Construction fait aussi référence à une mise en production dont la distribution a été autorisée. Par exemple Construction un serveur ou Construction d’un ordinateur portable.Voir Base de référence de configuration. Contrat (Contract) Accord exécutoire légal entre deux parties ou plus.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

356

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Contrat de service (Service Contract) (Stratégie de Services) Un contrat pour fournir un ou plusieurs services des TI. Le terme “Contrat de service” signifie également tout accord pour fournir des services des TI, que ce soit un contrat légal ou un SLA. Voir Portefeuille des contrats. Contrat de sous-traitance (UC) (Underpinning Contract) (Conception de services) Un contrat passé entre un fournisseur de services des TI et une tierce partie. La tierce partie fournit des biens ou des services qui soutiennent la fourniture d’un service des TI à un client. Le contrat de sous-traitance définit les cibles et les responsabilités qui sont nécessaires pour atteindre les cibles de niveau de service convenues d’un SLA. Contre-mesure (Countermeasure) Peut faire référence à n’importe quel type de contrôle. Le terme “Contre-mesure” est souvent utilisé pour faire référence à des mesures qui augmente la Résilience, la Tolérance de panne ou la Fiabilité d’un service des TI. Control Objectives for Information and related Technology (COBIT) (Control Objectives for Information and related Technology) Voir COBIT. Contrôle (Control) Moyen permettant de gérer un risque, en s’assurant que l’objectif business est atteint, ou en s’assurant qu’un processus est suivi. Exemples de contrôles : Polices, Procédures, Rôles, RAID, verrous, etc. Un contrôle est parfois appelé contremesure ou mesure de sécurité. Le terme “contrôle” signifie également un moyen de gérer l’utilisation ou le comportement d’un élément de configuration, d’un système ou d’un service des TI. Contrôle de processus (Process Control) Activité de planification et de mise sous contrôle d’un processus, ayant pour objectif d’accomplir le processus d’une manière efficace, efficiente et cohérente. Contrôle des configurations (Configuration Control) (Transition de Services) Activité ayant en charge la gestion pertinente, des ajouts, modifications ou suppressions de CI. Par exemple, en soumettant une demande de changement ou une demande de service. Contrôle des operations (Operations Control) Synonyme de Contrôle de l’exploitation des TI. Contrôle des Opérations Informatiques (IT Operations Control) (Exploitation de Services) Fonction en charge de la surveillance et du contrôle des services des TI et de l’infrastructure des TI. Voir Pont d’exploitation. Copie de sauvegarde (Backup) (Backup) (Conception de services) (Exploitation de Services) Copie des données permettant de protéger l’original de toute perte d’intégrité ou de disponibilité.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

357

Corrections de trajectoire (Course Corrections) Changements apportés à un plan ou à une activité en cours d’avancement, pour garantir l’atteinte des objectifs fixés. Les corrections de cours résultent d’un processus de surveillance de l’avancement. Couplage téléphonie-informatique (CTI) (Computer Telephony Integration) (Exploitation de Services) Terme générique recouvrant toutes sortes d’intégrations entre ordinateurs et systèmes de téléphonie. Ce terme sert principalement à désigner des systèmes où une application affiche des écrans détaillés relatifs aux appels reçus et émis. Voir Distribution automatique des appels, Réponse vocale interactive. Coût (Cost) Quantité financière dépensée pour une activité, un service informatique ou une unité business spécifique. Les coûts consistent en coût réel (argent), notion de coût comme le temps des employés, et l’amortissement. Coût direct (Direct Cost) (Stratégie de Services) Coût de fourniture d’un service des TI pouvant être attribué dans sa globalité à un Client, un Centre de coût, un Projet, etc. Par exemple, le coût de la fourniture de serveurs ou de licences logicielles non partagés. Voir Coût indirect. Coût d’opportunité (Opportunity cost) (Stratégie de service) Un coût servant à prendre une décision pour choisir entre différents investissements. Le coût d’opportunité représente le revenu qui aurait été généré en utilisant les ressources d’une autre façon. Par exemple, le coût d’opportunité d’acheter un nouveau serveur peut inclure une activité d’amélioration du service qui n’a pas été effectuée et qui aurait eu un coût. L’analyse du coût d’opportunité fait partie des processus de prise de décision, bien qu’il ne soit pas traité comme un coût réel dans aucun relevé financier. Coût fixe (Fixed cost) (Stratégie de Services) Un coût qui ne varie pas avec l’usage d’un service des TI. Par exemple le coût du matériel pour un serveur. Voir Coût variable. Coût indirect (Indirect Cost) (Stratégie de Services) Un coût de fourniture d’un service des TI ne pouvant pas être affecté dans sa globalité à un Client spécifique. Par exemple, le coût de la fourniture de serveurs ou de licences logicielles partagés. Également nommé Frais généraux. Voir Coût direct. Coût marginal (Marginal cost) (Stratégie de service) Le coût pour continuer à fournir un service des TI. Le coût marginal ne comprend pas l’investissement déjà effectué, par exemple le coût de développement d’un nouveau logiciel et la fourniture d’une formation. Coût opérationnel (Operational Cost) Coût résultant du fonctionnement des services des TI. Souvent des paiements répétitifs. Par exemple les coûts en personnel, maintenance du matériel et électricité (également appelés “dépenses courantes” ou “dépenses de fonctionnement”). Voir Augmentation de capital.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

358

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Coût total d’utilisation (TCU) (Total Cost of Utilization) (Stratégie de Services) Une méthodologie qui aide à la prise de décision en termes d’investissement et d’approvisionnement en service. Le TCU évalue l’ensemble du coût pour le client du cycle de vie d’un service des TI. Voir Coût total de possession. Coût total de possession (TCO) (Total Cost of Ownership) (Stratégie de Services) Une méthodologie qui aide à la prise de décision en termes d’investissement. Le TCO évalue l’ensemble du coût de la possession tout au long du cycle de vie d’un élément de configuration, pas seulement le coût initial ou son prix d’achat. Voir Coût total d’utilisation. Coût unitaire (Unit Cost) (Stratégie de Services) Le coût pour le fournisseur de services des TI de la fourniture d’un composant unitaire d’un service des TI. Par exemple, le coût d’un ordinateur de bureau ou d’une transaction. Coût variable (Variable Cost Dynamic) (Stratégie de Services) Un coût dépendant de la manière dont un service des TI est utilisé, du nombre de produits fabriqués, du nombre et du type d’utilisateurs, ou de quoique ce soit d’autre ne pouvant pas être fixé à l’avance. Voir Dynamique des coûts variables. Coûts de fonctionnement (Running Costs) Synonyme de Coûts opérationnels CRAMM (CRAMM) Méthodologie et outil d’analyse et de gestion des risques. Le CRAMM a été développé par le gouvernement britannique, mais est maintenant une propriété privée. De plus amples informations sont disponibles sur http://www.cramm.com/ Critères d’acceptation d’un service (SAC) (Service Acceptance Criteria) (Transition de Services) Un ensemble de critères permettant d’assurer qu’un service des TI correspond à sa fonctionnalité et aux exigences de qualité et que le fournisseur de service des TI est prêt à faire fonctionner ce nouveau service des TI dès qu’il aura été déployé. Voir Acceptation. Culture (Culture) Ensemble de valeurs qui sont partagées par un groupe de personnes, incluant certaines attentes sur la manière dont les gens doivent se comporter, sur leurs idées, leurs opinions et leurs pratiques. Voir Vision. Culture de service (Service Culture) Un culture orientée client. Les objectifs majeurs d’une culture du service sont la satisfaction du client et aider le client à atteindre ses objectifs métier. Cycle de Deming (Deming Cycle) Synonyme de Planifier-Faire-Vérifier-Agir (Plan-Do-Check-Act).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

359

Cycle de vie (Lifecycle) Les différentes étapes de la vie d’un service des TI, d’un élément de configuration, d’un incident, d’un problème, d’un changement, etc… Le cycle de vie définit les catégories d’état et les transitions d’un état à un autre sont autorisées. Par exemple : • Le cycle de vie d’une application comprend les besoins, la conception, la construction, le déploiement, l’exploitation, l’optimisation. • Le cycle de vie étendu d’un incident comprend la détection, la réponse, le diagnostic, la réparation, la reprise, la restauration. • Le cycle de vie d’un serveur peut comprendre : commandé, reçu, en test, en marche, au rebut, etc. Cycle de vie de la gestion du (des) service(s) (Service Management Lifecyle) Une approche de la gestion des services des TI qui met l’accent sur l’importance de la coordination et des contrôles pendant les diverses fonctions, processus et systèmes nécessaires pour gérer le cycle de vie complet des services des TI. Le cycle de vie de la gestion du/des service(s) est une approche qui prend en compte la stratégie, la conception, la transition, l’exploitation et l’amélioration des services des TI. Cycle de vie détaillé d’un incident (Expanded Incident Lifecycle) (Gestion de la disponibilité) Étapes détaillées du cycle de vie d’un incident. Ces étapes sont la détection, le diagnostic, la réparation, la reprise, la restauration. Le cycle de vie étendu d’un incident aide à comprendre toutes les contributions à l’impact des incidents et à planifier comment mieux les contrôler et les réduire. Data-to-Information-to-Knowledge-to-Wisdom (DIKW) (Data-to-Information-to-Knowledge-to-Wisdom) Une manière de comprendre les relations entre les données, les informations, les compétences et l’action prudente. Le schéma DIKW montre comment chacun de ses éléments influe sur les autres. De secours (Standby) (Conception de services) Fait référence aux ressources qui ne sont pas nécessaires à la fourniture des services des TI réels, mais sont disponibles pour soutenir les plans de continuité des services des TI. Par exemple, un centre de données de secours peut être tenu à jour afin de soutenir des arrangements de Reprise immédiate ou rapide, Reprise intermédiaire ou Reprise graduelle. Défaillance (Failure) (Exploitation de Services) Perte de la possibilité de fonctionner selon les spécifications ou de fournir le résultat requis. Le terme de Défaillance peut s’appliquer à des services des TI, des processus, des activités, des éléments de configuration, etc. Une défaillance est souvent la cause d’un incident. Demande de changement (RFC) (Change Request) Équivalent de Request for Change (RFC). Demande de changement (RFC) (Request for Change) (Transition de service) Une demande formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. Le terme RFC est souvent utilisé à contresens pour signifier Enregistrement de changement ou le changement lui-même.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

360

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Demande de changement (RFC) (Request for Change) (Transition de Services) Une proposition formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. Le terme RFC est souvent utilisé à contresens pour signifier Enregistrement de changement ou le changement lui-même. Demande de service (Service Request) (Exploitation de Services) Une demande d’un utilisateur pour avoir une information, un conseil ou pour bénéficier d’un changement standard ou encore pour avoir un accès à un service des TI. Par exemple, pour réinitialiser un mot de passe, ou fournir des services des TI standard à un nouvel utilisateur. Les demandes de service sont habituellement gérées par un centre de services et ne nécessitent pas de RFC pour être soumises. Voir Satisfaction de la demande. Dépendance (Dependency) Relation directe ou indirecte d’un processus ou d’une activité l’un avec l’autre. Dépense opérationnelle (OPEX) Operational Expenditure (OPEX) Synonyme de Coût opérationnel. Déploiement (Deployment) (Transition de Services) Activité en charge du déplacement de tout matériel, logiciel, documentation processus, etc. nouveau ou modifié dans son environnement réel. L’implantation fait partie du processus de gestion des mises en production et de l’implantation. Voir Déploiement. Déploiement (Rollout) (Transition de Services) Synonyme de Déploiement ( ! !). Souvent utilisé pour faire référence à des déploiements complexes ou en plusieurs phases ou à des déploiements sur de multiples lieux. Dépréciation (Depreciation) (Stratégie de Services) Mesure de la réduction de la valeur d’un actif tout au long de sa durée de vie. Elle est basée sur l’usure, la consommation ou autre facteur de réduction en termes de valeur économique utile. Description de poste (Job Description) Un document définissant les rôles, responsabilités, compétences et savoir-faire exigés par une personne en particulier. La description d’un poste peut inclure de multiples rôles, par exemple les rôles du gestionnaire des configurations et du gestionnaire des changements peuvent être cumulés par une seule personne. Détection (Detection) (Exploitation de Services) Étape du cycle de vie d’un incident. La détection résulte du fait qu’un incident devient connu du fournisseur de services. La détection peut être automatique ou être le résultat de la journalisation d’un incident par un client. Développement (Development) (Conception de services) Processus en charge de la création ou de la modification d’un service des TI ou d’une application. Sert aussi à désigner le rôle ou le groupe qui procède au travail de développement.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

361

Diagnostic (Diagnosis) (Exploitation de Services) Étape du cycle de vie d’un incident ou d’un problème. Le but du diagnostic est d’identifier une solution de contournement pour un incident ou la cause fondamentale d’un problème. Diagramme d’Ishikawa (Ishikawa diagram) (Exploitation de Services) (Amélioration continue du service) Une technique qui aide à identifier toutes les causes possibles d’un problème. Inventée à l’origine par Kaoru Ishikawa, le résultat de cette de technique est un schéma ressemblant à une arrête de poisson. Diagramme en arêtes de poisson (Fishbone Diagram) (Fishbone diagram) Synonyme de diagramme d’Ishikawa. Dimensionnement des applications (Application sizing) (Conception de services) Activité ayant en charge la compréhension des besoins en ressources nécessaires pour soutenir une nouvelle application, ou un changement majeur apporté à une application existante. Le dimensionnement des applications contribue à ce que le service des TI atteigne ses Objectifs de Niveau de Service convenus en termes de capacité et de performances. Direction informatique (IT Directorate) (Amélioration continuée du service) Direction au sein d’un fournisseur de services, chargée de développer et de fournir des services des TI. Plus répandu dans les départements du gouvernement britannique. Disponibilité (Availability) (Conception de services) Capacité d’un élément de configuration ou d’un service des TI à réaliser sa fonction convenue lorsque c’est nécessaire. La disponibilité est déterminée par la fiabilité, la facilité de maintenance, la facilité de service, la performance et la sécurité. La disponibilité est habituellement calculée sous la forme d’un pourcentage. Ce calcul est basé le plus souvent sur le temps de service convenu et le Temps d’indisponibilité. La meilleure pratique consiste à calculer la disponibilité en se basant sur les mesures du service des TI effectuées côté Business. Disponibilité continue (Continuous Availability) (Conception de services) Approche ou une conception visant à obtenir une disponibilité totale. Un service des TI à disponibilité continue n’a pas de période d’indisponibilité, qu’elle soit planifiée ou non. Disponibilité projetée du service (PSA) (Projected Service Availability) (manquant ?) (le signe PSA figure dans la liste des acronymes). Planning de disponibilité de service revu et corrigé pour prendre en compte les arrêts planifiés de service. Distribution automatique d’appels (ACD) (Automatic Call Distribution) (Exploitation de Services) Usage d’une technologie de l’information permettant de diriger un appel téléphonique vers la personne la plus compétente dans un laps de temps le plus court possible. L’ACD est aussi appelée Distribution d’appel automatisé. Document (Document) Information sous une forme lisible. Un document peut être papier ou électronique. Par exemple, une politique, un accord sur les niveaux de service (SLA), un enregistrement d’incident, un schéma d’aménagement d’une salle informatique. Voir Enregistrement.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

362

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Dossier business (Business case) (Stratégie de Services) Justification d’un élément de dépense significatif. Inclut des informations sur les coûts, les bénéfices, les options, les points de controverse, les risques et les problèmes potentiels.Voir Analyse des Coûts et des Bénéfices. Dossier de changement (Change case) (Exploitation de Services) Technique utilisée pour prévoir l’impact des changements proposés. Les études de changement emploient des scénarios spécifiques pour clarifier l’étendue des changements proposés et apporter l’aide d’une Analyse des Coûts et des Bénéfices. Voir Étude de cas. Driver (Driver) Facteur influençant la stratégie, les objectifs ou les besoins. Par exemple une nouvelle législation ou les actions des concurrents. Droits (Rights) (Exploitation de Services) Droits ou permissions garanties à un utilisateur ou à un rôle. Par exemple, le droit de modifier des données particulières ou d’autoriser un changement. Dynamique des coûts variables (Variable Cost Dynamic) (Stratégie de Services) Technique servant à comprendre comment des coûts globaux sont influencés par les nombreux éléments variables complexes qui contribuent à la fourniture de services des TI. Économies de gamme (Economies of scope) (Stratégie de Services) Réduction de coût qui est attribuée à un service des TI en utilisant un actif existant dans un autre but. Par exemple, fournir un nouveau service des TI à partir d’une infrastructure des TI déjà existante. Voir Économies d’échelle. Économies d’échelle (Economies of scale) (Stratégie de Services) Réduction du coût moyen qui est rendue possible en augmentant l’usage d’un service des TI ou d’un actif. Voir Économies d’étendue. Efficacité (Effectiveness) (Amélioration continuelle du service) Mesure permettant de savoir si les objectifs d’un processus, d’un service ou d’une activité ont été atteints. Un processus ou une activité efficace est celui ou celle qui atteint les objectifs convenus. Voir KPI. Efficience (Efficiency) (Amélioration continuelle du service) Mesure permettant de savoir si la bonne quantité de ressources a été utilisée pour un processus, un service ou une activité. Un processus efficient atteint ses objectifs avec un minimum de temps, d’argent, de personnel ou autres ressources. Voir KPI. Elément de Configuration (CI) (Configuration Item) (Transition de Services) Tout composant devant être géré afin de fournir un service des TI. Les informations concernant chaque CI sont enregistrées dans un enregistrement de configuration au sein du Système de gestion des configurations

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

363

(CMS) où elles sont tenues à jour pendant tout son cycle de vie par la Gestion des configurations. Les CI sont sous le contrôle de la Gestion des changements. Les CI comprennent habituellement les services des TI, le matériel, les logiciels, les immeubles, les personnes et la documentation formelle tels que la documentation des processus et les SLA. Elément de coût (Cost Element) (Stratégie de Services) Niveau moyen de catégorie auquel des coûts sont attribués en termes de budget et de comptabilité. Le niveau de catégorie le plus élevé étant le type de coût. Par exemple, un type de coût en “personnel” peut avoir des éléments de coût tels que, salaires, participation du personnel, dépenses, formation, heures supplémentaires, etc. Les éléments de coût peuvent encore être décomposés en unités de coût. Par exemple, l’élément de coût “dépenses” peut inclure des unités de coût, comme Hôtels, Transport, Repas, etc. Elément d’investissement (Capital Item) (Stratégie de Services) Un actif qui est intéressant pour la gestion financière car sa valeur est supérieure à une certaine valeur financière établie. Énoncé de mission (Mission Statement) L’énoncé de mission d’une organisation est une description brève mais complète du but et des intentions générales de cette organisation. Il définit ce qui doit être accompli, mais ne dit pas comment y parvenir. Enregistrement (Record) Document contenant les résultats ou d’autres sorties d’un processus ou d’une activité. Les enregistrements sont la preuve du fait qu’une activité a été réalisée, il peut s’agir d’un document papier ou électronique. Par exemple un rapport d’audit, l’enregistrement d’un incident ou les minutes d’une réunion. Enregistrement d’erreur connue (Known Error Record) (Exploitation de Services) Un enregistrement contenant les détails d’une erreur connue. Chaque enregistrement d’erreur connue documente le cycle de vie d’une erreur connue, ce qui inclut son état, sa cause première et la solution de contournement. Dans certaines implémentations, les erreurs connues sont documentées à l’aide de champs supplémentaires dans l’enregistrement d’un problème. Enregistrement d’un changement (Change Record) (Transition de Services) Enregistrement contenant tous les détails d’un changement. Chaque enregistrement de changement documente le cycle de vie d’un seul changement. Un enregistrement de changement est créé pour chaque demande de changement ayant été reçue, même pour celles qui seront rejetées par la suite. Les enregistrements de changement doivent référencer les éléments de configuration qui ont été affectés par le changement. Ils sont stockés dans le Système de Gestion des Configurations. Enregistrement d’un problème (Problem Record) (Exploitation de Services) Un enregistrement contenant les détails d’un problème. Chaque enregistrement documente le cycle de vie d’un seul problème. Enregistrement d’un incident (Incident Record) (Exploitation de Services) Un enregistrement contenant les détails d’un incident. Chaque enregistrement d’incident documente le cycle de vie d’un seul incident. Enregistrement d’une configuration Configuration Record (Transition de Services) Enregistrement contenant tous les détails d’un élément de configuration. Chaque enregistrement de configuration documente le cycle de vie d’un seul CI. Les enregistrements de configuration sont stockés dans une base de données de gestion des configurations. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

364

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Enregistrement d’une mise en production (Release Record) (Transition de service) Enregistrement dans la CMDB qui définit le contenu d’une mise en production. Un enregistrement de mise en production a des relations avec tous les éléments de configuration qui sont affectés par la mise en production. Entente de réciprocité (Reciprocal Arrangement) (Conception de service) Une Stratégie de continuité de service. Un accord entre deux organisations qui partagent des ressources en cas d’urgence. Par exemple, l’espace d’une salle informatique ou un ordinateur central. Environnement (Environment) (Transition de Services) Sous-ensemble de l’infrastructure des TI servant à un but particulier. Par exemple : Environnement réel, Environnement de test, Environnement de construction. Il est possible que plusieurs environnements partagent un même élément de configuration, par exemple les environnements de test, et réel peuvent utiliser différentes partitions d’un même ordinateur central. Sert également à désigner un environnement physique pouvant signifier un aménagement, l’air conditionné, un système électrique, etc. L’environnement sert également de terme générique pour désigner les conditions extérieures pouvant influencer ou affecter quelque chose. Environnement de construction (Build environment) (Transition de Services) Un environnement contrôlé où des applications, des services informatiques et autres constructions sont assemblés avant d’être transférés dans un environnement de test ou dans un environnement réel. Environnement de développement (Development Environment) (Conception de services) Un environnement servant à créer ou à modifier des services des TI ou des applications. Les environnements de développement ne sont normalement pas soumis aux mêmes degrés de contrôle que les environnements de test ou les environnements réels. Voir Développement. Environnement de production (Live environment) (Transition de service) Un environnement contrôlé contenant des éléments de configuration utilisé pour fournir des services des TI à des clients. Environnement de production (Production Environment) Environnement de production. Environnement de tests (Test Environment) (Transition de Services) Un environnement sous contrôle servant à tester des éléments de configuration, des constructions, des services des TI, des processus, etc. Équipe (Shift) (Exploitation de Services) Un groupe ou une équipe devant exécuter un rôle spécifique pendant une période donnée. Par exemple, il peut y avoir quatre postes de personnel de contrôle de l’exploitation des TI pour soutenir un service des TI qui est utilisé 24 heures sur 24. Erreur (Error) (Exploitation de Services) Déroulement de conception ou un dysfonctionnement erroné qui provoque une défaillance d’un ou de plusieurs éléments de configuration ou services des TI Une faute commise par une personne ou un processus défectueux ayant un impact sur un CI ou un service des TI est aussi appelé une erreur. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

365

Erreur connue (KE) (Known Error) (Exploitation de Services) Un problème ayant une cause première et une solution de contournement documentées. Les erreurs connues sont créées et gérées tout au long de leur cycle de vie par la gestion des problèmes. Les erreurs connues peuvent aussi être identifiées par le développement ou les sous-traitants. Escalade (Escalation) (Exploitation de Services) Activité qui obtient des ressources supplémentaires lorsqu’elles sont nécessaires pour atteindre les cibles de niveaux de services ou satisfaire les attentes du client. L’escalade peut être nécessaire au sein de tout processus de gestion des services des TI, mais est le plus souvent associée à la gestion des incidents, à la gestion des problèmes et à la gestion des réclamations des clients. Il y a deux types d’escalades : Escalade fonctionnelle et Escalade hiérarchique. Escalade fonctionnelle (Functionnal Escalation) (Exploitation de Services) Transférer un incident, un problème ou un changement à une équipe technique ayant un plus haut degré d’expertise pour aider dans l’escalade. Escalade hiérarchique (Hierarchic Escalation) (Exploitation de Services) Informer ou impliquer davantage des niveaux plus seniors du management afin d’aider dans le processus d’escalade. ESourcing Capability Model for Client Organisations (eSCM-CL) (ESourcing Capability Model for Client Organisations) (Stratégie de Services) Un cadre de travail destiné à guider les organisations dans leurs analyses et leurs prises de décisions sur les Modèles et les Stratégies de l’Approvisionnement en Service. L’eSCM-CL a été développé par Carnegie Mellon University. Voir eSCM-SP. eSourcing Capability Model for Service Providers (eSCM-SP) (ESourcing Capability Model for Service Providers) (Stratégie de Services) Un cadre de travail destiné à aider les fournisseurs de services des TI à développer leur Capacité de Gestion des services des TI à partir d’une perspective d’Approvisionnement en Service. L’eSCM-CP a été développé par Carnegie Mellon University. Voir eSCM-CL. Estimation (Estimation) L’utilisation de l’expérience pour fournir une valeur approximative d’une Métrique ou d’un Coût. L’estimation est aussi employée dans la Gestion de la Capacité et la Gestion de la Disponibilité comme méthode de Modélisation la moins chère et la moins précise. Estimation de la valeur du service (Service Valuation) (Stratégie de Services) Une mesure du coût total de la fourniture d’un service des TI et la valeur totale pour le business de ce service des TI. L’évaluation du service permet d’aider le business et le fournisseur de services des TI à convenir de la valeur du service des TI. Étiquette (tag) (Tag) (Stratégie de Services) Un code court servant à identifier une catégorie. Par exemple les tags EC1, EC2, EC3, etc peuvent servir à identifier différents résultats des clients lors de l’analyse et de la comparaison des stratégies. Le terme Marquage fait aussi référence à l’activité de marquer des objets. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

366

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Évaluation (Assessment) Inspection et analyse permettant de vérifier qu’un standard ou un ensemble de principes a bien été suivi, que les enregistrements sont précis ou que les objectifs d’efficience et d’efficacité ont été atteints. Voir Audit. Évaluation (Evaluation) (Transition de Services) Processus en charge de l’estimation d’un service des TI, nouveau ou changé, afin de s’assurer que les risques ont été gérés et aider à déterminer s’il faut procéder au changement. L’évaluation est aussi employée pour comparer un résultat actuel avec un résultat escompté, ou pour comparer une alternative à une autre. Évaluation des risques (Risk Assessment) Les étapes initiales de la gestion des risques. Analyser la valeur des actifs par rapport aux métiers, identifier les menaces envers ces actifs et évaluer comment chaque actif est vulnérable à ces menaces. L’évaluation du risque peut être quantitative (basée sur des données chiffrées) ou qualitative. Événement (Event) (Exploitation de Services) Un changement d’état ayant de l’importance pour la gestion d’un élément de configuration ou un service des TI. Le terme “événement” est aussi employé pour désigner une alerte ou une notification créée par un service des TI, un élément de configuration ou un outil de surveillance. Les événements requièrent habituellement du personnel d’exploitation des TI qu’il initie une action ce qui conduit le plus souvent à la journalisation d’incidents. Exécution (Fulfilment) Effectuer des activités visant à satisfaire une nécessité ou une exigence. Par exemple en fournissant un nouveau service des TI, ou en répondant à une demande (requête ?) de service. Exécution des requêtes (Request Fulfilment) (Exploitation de Services) Processus en charge de la gestion du cycle de vie de toutes les demandes de  changement. Exécution des requite (Request Fulfilment) (Exploitation de Services) Processus en charge de la gestion du cycle de vie de toutes les demandes de changement. Exigence de niveau de service (SLR) (Service Level Requirement) (Conception de services) (Amélioration continuelle du service) Une exigence du client pour un aspect particulier d’un service des TI. Les SLR sont basés sur les objectifs business et servent à négocier les cibles de niveau de service convenues. Exploitation continue (Continuous operation) (Conception de services) Approche ou concept visant à éliminer les périodes d’indisponibilité d’un service des TI. Notez que des éléments de configuration spécifiques peuvent être indisponibles alors que le service des TI reste disponible. Exploitation de Services (Service Operation) (Exploitation de Services) Une étape du cycle de vie d’un service des TI. L’Exploitation de Services comporte un certain nombre de processus et de fonctions, c’est également l’intitulé d’une des publications-phares de l’ITIL. Voir Opération.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

367

Exploitation ou Fonctionnement (Operation) (Exploitation de Services) Gestion quotidienne d’un service des TI, d’un système ou d’un élément de configuration ; etc. Une opération peut aussi signifier une activité ou une transaction prédéfinie. Par exemple, charger une bande magnétique, accepter de l’argent à un point de vente ou lire les données d’un disque dur. Exploiter (Operate) Accomplir ce qui est demandé. On dit d’un processus ou d’un élément de configuration qu’il fonctionne s’il fournit les résultats exigés. Fonctionner signifie également effectuer une ou plusieurs opérations.. Par exemple, des opérations quotidiennes sont nécessaires pour effectuer le maintien en condition opérationnel d’un ordinateur. Extensibilité (Scalability) La capacité d’un service des TI, processus, élément de configuration, etc à accomplir sa fonction convenue lorsque la charge de travail ou l’étendue change. Externalisation (Outsourcing) (Stratégie de Services) Utiliser un fournisseur de services externe pour gérer les services des TI. Voir Approvisionnement en service, Fournisseur de services de Type III. Facilité de maintenance (Maintainability) (Conception de service) Mesure permettant de savoir dans quel délai et avec quelle efficacité un élément de configuration ou un service des TI peut être restauré pour retrouver un fonctionnement normal suite à une panne. La facilité de maintenance est souvent mesurée et rapportée sous le nom de MTRS. La facilité de maintenance sert également dans le contexte de développement d’un logiciel ou d’un service des TI pour signifier la possibilité de le changer ou de le réparer facilement. Facilité d’utilisation (Usability) (Conception de services) La facilité avec laquelle une application, un produit ou un service des TI peut être utilisé. Les exigences de facilité d’emploi sont souvent incluses dans l’énoncé des exigences. Facteur clé de succès (CSF) (Critical Success Factor) Événement ou élément contribuant à la réussite d’un processus, d’un projet, d’un plan ou d’un service des TI. Les KPI servent à mesurer l’obtention de chaque CSF. Par exemple, un CSF de “protection des services des TI lors des changements” peut être mesuré par des KPI tels que “pourcentage de réduction des changements défectueux”, “pourcentage de réduction des changements causant des incidents”, etc. Facturation (Charging) (Stratégie de Services) Demande de rétribution financière de la fourniture de services des TI. La facturation des services des TI est optionnelle, et de nombreuses organisations choisissent de considérer leur fournisseur de services informatiques comme un Centre de coût. Facturation modulée (differential charging) (Differential Charging) Une technique utilisée pour soutenir la gestion de la demande en facturant des valeurs différentes pour la même fonction de service informatique selon les heures.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

368

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Facturation notionnelle (Notional charging) (Stratégie de service) Une approche de la facturation des services des TI. Les coûts à facturer aux clients sont calculés et les clients sont informés des frais, mais l’argent n’est pas réellement transféré. La facturation notionnelle est parfois introduite afin d’attirer l’attention des clients sur les coûts qu’ils encourent ou comme préliminaire à l’introduction d’une facturation réelle. Fenêtre de mise en production (Release Window) Synonyme de Fenêtre de changement. Fenêtre des changements (Change Window) (Transition de Services) Une période normale, convenue pendant laquelle des changements ou des mises en production peuvent être implantées avec un impact minimal sur les services. Les fenêtres de changement sont habituellement documentées dans les SLA. Fiabilité (Reliability) (Conception de service) (Amélioration continue du service) Une mesure de la durée pendant laquelle un élément de configuration ou un service des TI peut exécuter sa fonction attendue sans interruption. Habituellement mesurée par le MTBF ou MTBSI. Le terme “Fiabilité” peut aussi servir à établir la probabilité selon laquelle un processus, une fonction, etc… fournira le résultat exigé. Voir Disponibilité. Fonction (Function) Une équipe ou un groupe de personnes ainsi que les outils qu’ils utilisent pour mener à bien un ou plusieurs processus ou activités. Par exemple le centre de service. Le terme Fonction peut aussi avoir deux autres significations : • L’utilité d’un élément de configuration, d’une personne, d’une équipe, d’un processus ou d’un service des TI. Par exemple, une fonction d’un service d’e-mail peut être de stocker et de faire suivre les e-mails envoyés ; une fonction d’un processus business peut être de répartir les biens vers les clients. • Pour répondre correctement à l’utilité que l’on en attend “L’ordinateur fonctionne correctement”. Fonction Business Vitale (VBF) (Vital Business Function) (Conception de services) Une fonction d’un processus métiers qui est cruciale pour le succès des métiers. Les fonctions métiers vitales sont d’une importance considérable pour la Gestion de la continuité des métiers, la Gestion de la continuité des services des TI, la Gestion de la disponibilité. Fournisseur (Supplier) (Stratégie de Services) (Conception de services) Une tierce partie responsable de la fourniture de biens ou de services qui sont nécessaires à la fourniture de services des TI. Exemples de sous-traitants : revendeurs de matériel et de logiciels, fournisseurs de réseau et de télécoms et organisations d’externalisation. Voir Contrat de sous-traitance, Chaîne de sous-traitance. Fournisseur de service externe (External Service Provider) (Stratégie de Services) Un fournisseur de services des TI qui fait partie d’une organisation différente de celle de son client. Un fournisseur de services des TI peut avoir à la fois des clients internes et des clients externes. Voir Fournisseur de services de Type III.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

369

Fournisseur de Service Informatique (IT Service Provider) (Stratégie de service) Un fournisseur de services des TI qui fournit des services informatiques à des clients internes et à des clients externes. Fournisseur de services (Service Provider) (Stratégie de Services) Une organisation qui fournit des services à un ou plusieurs clients internes ou clients externes. Le terme “fournisseur de services” est souvent employé comme synonyme pour Fournisseur de services des TI. Voir Fournisseur de services de type I, Fournisseur de services de type II, Fournisseur de services de type III. Fournisseur de services applicatifs (ASP) (Application Service Provider) (Conception de services) Un fournisseur de service externe qui fournit des services informatiques à l’aide d’applications hébergées dans les locaux du fournisseur de service. Les utilisateurs accèdent aux applications au moyen de connexions réseau avec le fournisseur de service. Fournisseur de services de type I (Type I Service Provider) (Stratégie de Services) Un fournisseur de services interne qui est imbriqué dans une unité business. Il peut y avoir plusieurs fournisseurs de services de type I au sein d’une organisation. Fournisseur de services de type II (Type II Service Provider) (Stratégie de Services) Un fournisseur de services interne qui fournit des services des TI partagés par plusieurs unités business. Fournisseur de services de type III (Type III Service Provider) (Stratégie de Services) Un fournisseur de services qui fournit des services des TI à des clients externes. Fournisseur de services interne (Internal Service Provider) (Stratégie de service) Un fournisseur de services des TI qui fait partie de la même entreprise que celle de son client. Un fournisseur de services des TI peut avoir à la fois des clients internes et des clients externes. Voir Fournisseur de services de Type I, Fournisseur de services de Type II, Internalisation. Fournisseur de services Internet (ISP) (Internet Service Provider) Un fournisseur de services externe qui propose un accès à l’internet. La plupart des ISP fournit aussi d’autres services des TI tels que l’hébergement de sites web. Frais d’investissement (CAPEX) (Capital Expenditure) (Stratégie de Services) Le coût d’achat d’un bien qui deviendra un actif financier, par exemple équipement informatique et immeubles. La valeur de l’actif est amortie sur plusieurs périodes comptables. Frais généraux ou Surcharge (Overhead) Synonyme de Coût indirect. Garantie (Warranty) (Stratégie de Services) Une promesse ou une garantie qu’un produit ou un service répond à ses exigences convenues. Voir Validation et test du service, Garantie du service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

370

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Garantie de service (Service Warranty) (Stratégie de Services) L’assurance qu’un service des TI satisfera les exigences convenues. Il peut s’agir d’un accord formel, tel qu’un accord sur les niveaux de service (SLA) ou d’un contrat, ou bien ce peut être un message marketing ou une image de marque. La valeur business d’un service des TI est générée par la combinaison de l’utilité du service (ce qu’il fait) et la garantie du service (comment il y parvient). Voir Garantie. Gestion de capacité des composants (CCM) (Component Capacity Management) (Conception de services) (Amélioration continuelle du service) Processus en charge de comprendre la capacité, l’utilisation et les performances des éléments de configuration. Les données sont collectées, enregistrées et analysées afin d’être utilisées dans le Plan de capacité. Voir Gestion de la capacité de service. Gestion de Crises (Crisis Management) Processus en charge de la gestion des implications plus larges de la Continuité du Business. L’équipe de gestion de crise est responsable des questions stratégiques, comme la gestion des relations avec les média et la confiance des actionnaires, c’est elle qui décide du déclenchement des Plans de Continuité du Business. Gestion de la Capacité (Capacity Management) (Conception de services) Processus en charge de veiller à ce que la capacité des services des TI et de l’infrastructure des TI puisse répondre aux Objectifs de Niveau de Service d’une manière rentable et ponctuelle. La gestion de la capacité prend en compte toutes les ressources nécessaires pour fournir le service informatique et planifie les besoins du business à court, moyen et long terme. Gestion de la Capacité Business (BCM) (Business Capacity Management) (Conception de services) Dans le contexte de l’ITSM, la gestion de la capacité business est l’activité ayant en charge la compréhension des futures exigences du business afin de les intégrer dans le Plan de capacité.Voir Gestion de la capacité du service. Gestion de la Capacité des Services (SCM) (Service Capacity Management) (Conception de services) (Amélioration continuelle du service) Activité en charge de la compréhension des performances et de la capacité des services des TI. Les ressources utilisées par chaque service des TI et le schéma d’utilisation dans le temps sont collectés, enregistrés et analysés afin de servir à l’élaboration d’un plan de capacité. Voir Gestion de la capacité business (BCM), Gestion de la capacité du composant (CCM). Gestion de la Continuité des Services Informatiques (ITSCM) (IT Service Continuity Management) (Conception de service) Processus en charge de la gestion des risques pouvant avoir un impact grave sur les services des TI. L’ITSCM assure que le fournisseur de services des TI peut toujours fournir les niveaux de service minimum attendus, en réduisant le risque à un niveau acceptable et en planifiant la reprise des services des TI. L’ITSCM doit être conçue pour soutenir la gestion de la continuité du business. Gestion de la Continuité des Services (Service Continuity Management) Synonyme de Gestion de la continuité des services des TI (ITSCM).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

371

Gestion de la Continuité du Business (BCM) (Business Continuity Management) (Conception de services) Il s’agit du processus business en charge de la gestion des risques pouvant avoir un impact sérieux sur le business. La gestion de la continuité du business protège les intérêts des intervenants, la réputation de la marque et sa valeur en créant des activités. Le processus de la BCM implique la réduction des risques à un niveau acceptable et la planification de la reprise des processus business suite à une interruption de celui-ci. La BCM définit les objectifs, l’étendue et les besoins de la Gestion de la continuité du Service des TI. Gestion de la Demande (Demand Management) Activités qui comprennent et influencent la demande du client envers des services et l’approvisionnement en capacité pour satisfaire ces demandes. À un niveau stratégique, la gestion de la demande peut impliquer l’analyse de Schémas d’activité business et de Profils Utilisateurs. À un niveau tactique, elle peut impliquer l’usage d’un coût différentiel afin d’encourager les clients à utiliser les services des TI à des moments moins fréquentés. Voir Gestion de la capacité. Gestion de la Disponibilité (Availability Management) (Conception de services) Processus chargé de définir, d’analyser, de planifier, de mesurer et d’améliorer tous les aspects de la disponibilité des services des TI. La Gestion de la disponibilité est chargée de s’assurer que la disponibilité de tous les Rôles, Outils, Processus, Infrastructures, etc… des TI est adaptée aux Objectifs de Niveau de Service convenus. Gestion de la Sécurité (Security Management) Synonyme de Gestion de la Sécurité de l’Information. Gestion de la Sécurité de l’Information (ISM) (Information Security Management) (Conception de services) Processus qui assure la confidentialité, l’intégrité et la disponibilité des actifs, informations, données et services des TI d’une organisation. La Gestion de la Sécurité de l’Information fait habituellement partie d’une approche organisationnelle de la Gestion de la Sécurité avec une étendue plus large que la fourniture de services informatiques. Elle inclut la manipulation des papiers, l’accès aux bâtiments, les appels téléphoniques, etc, de toute l’organisation. Gestion des Actifs (Asset Management) (Transition de Services) La gestion des actifs est le processus en charge du suivi et du rapport de la valeur ainsi que de la possession des actifs financiers tout au long de leur cycle de vie. La gestion des actifs fait partie d’un processus global de gestion des actifs de service et de gestion des configurations. Voir Registre des actifs. Gestion des Actifs de Services et des Configurations (SCAM) (Service Asset and Configuration Management) (Transition de Services) Processus en charge à la fois de la gestion des configurations et de la gestion des actifs. Gestion des Applications (Application Management) (Conception de services) (Exploitation de Services) La fonction responsable de la gestion des applications tout au long de leur cycle de vie. Gestion des Changements (Change Management) (Transition de Services) Processus en charge de contrôler le cycle de vie de tous les changements. Le principal objectif de la gestion des changements et de rendre possible la mise en œuvre de changements bénéfiques avec un minimum d’interruption des services des TI.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

372

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Gestion des Configurations (Configuration Management) (Transition de Services) Processus en charge de tenir à jour les informations concernant les éléments de configuration nécessaires pour fournir un service informatique ainsi que leurs relations. Ces informations sont gérées tout au long du cycle de vie du CI. La Gestion des configurations fait partie du processus global de Gestion des configurations et des actifs de service. Gestion des Configurations (Configuration Management) (Transition de Services) Base de données servant à rassembler les enregistrements de configuration tout au long de leur cycle de vie. Le système de gestion des configurations tient à jour une ou plusieurs CMDB, chacune d’elles regroupant les attributs des CI, et leurs relations les uns avec les autres. Gestion des Connaissances (Knowledge Management) (Transition de service) Processus en charge de rassembler, analyser, stocker et partager les connaissances et les informations au sein d’une organisation. Le but principal de la Gestion de connaissances est d’améliorer l’efficience en réduisant le besoin de redécouvrir des connaissances. Voir Données-Informations-Connaissances-Sagesse, Système de gestion des connaissances du service. Gestion des coûts (Cost Management) (Stratégie de Services) Terme générique faisant référence au budget et à la comptabilité. Parfois synonyme de Gestion financière. Gestion des Déploiements et des Mises en Production (Release and Deployment Management) (Transition de service) Processus qui regroupe à la fois la préparation au déploiement et la mise en production. Gestion des Événements (Event Management) (Exploitation de Services) Processus en charge de la gestion des événements tout au long de leur cycle de vie. La gestion des événements est une des activités principales de l’exploitation des TI. Gestion des Fournisseurs (Supplier Management) (Conception de services) Processus en charge de s’assurer que tous les contrats avec les sous-traitants soutiennent les besoins du business et que tous les sous-traitants remplissent leurs engagements contractuels. Gestion des Incidents (Incident Management) (Exploitation de Services) Processus en charge de la gestion du cycle de vie de tous les incidents. L’objectif principal de la Gestion des incidents est de rendre le service des TI aux utilisateurs aussi rapidement que possible. Gestion des Installations (Facilities Management) (Exploitation de Services) Fonction en charge de la gestion de l’environnement physique où se trouve située (localisée ?) l’infrastructure des TI. La Gestion des locaux inclut tous les aspects de la gestion de l’environnement physique. Par exemple, électricité et climatisation, gestion de l’accès au bâtiment, et surveillance des conditions environnementales. Gestion des Mises en Production (Release Management) (Transition de service) Processus en charge de la planification, du calendrier et du contrôle du mouvement des mises en production vers les environnements de test et réel. L’objectif principal de la Gestion des mises en production est de s’assurer l’intégrité de l’environnement de production et que des composants testés sont mis en production. La Gestion des mises en production fait partie de la Gestion des mises en production et des déploiements.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

373

Gestion des Niveaux de Service (SLM) (Service Level Management) (Conception de services) (Amélioration continuelle du service) Processus en charge de négocier les accords sur les niveaux de service (SLA) et de s’assurer qu’ils sont atteints. La SLM doit s’assurer également que tous les processus de gestion des services des TI, les accords sur les niveaux opérationnels (OLA) et les contrats de sous-traitance sont adaptés aux cibles de niveau de service. La SLM surveille et établit des rapports sur les niveaux de service, et organise régulièrement des revues avec les clients. Gestion des Opérations (Operations Management) Synonyme de Gestion de l’Exploitation des TI. Gestion des Opérations Informatiques (IT Operations Management) (Exploitation de Services) La fonction assurée par le fournisseur de services des TI qui exécute les activités quotidiennes nécessaires pour gérer les services des TI et assurer le maintien en condition opérationnel l’infrastructure des TI. La Gestion de l’Exploitation des TI inclut le Contrôle de l’Exploitation des TI et la gestion des locaux. Gestion des Performances (Performance Management) (Amélioration continue du service) Le processus en charge des activités quotidiennes de gestion de la capacité. Ceci inclut la supervision, les alertes liées à des dépassements de seuils, l’analyse des performances et leur optimisation, ainsi que la mise en œuvre (ou l’application) des changements relatifs à la performance et à la capacité. Gestion des Problèmes (Problem Management) (Exploitation de Services) Le processus en charge de la gestion du cycle de vie de tous les problèmes. L’objectif principal de la Gestion des problèmes est d’éviter que des incidents ne surviennent et de minimiser l’impact des incidents qui ne pourraient pas être évités. Gestion des Relations Business (BRM) (Business Relationship Management) (Stratégie de Services) Il s’agit du processus ou de la fonction en charge de maintenir une relation avec le business. La BRM inclut habituellement : • La gestion des relations du personnel avec les dirigeants du business. • La fourniture d’une entrée à la gestion du portefeuille des services. • L’assurance que le fournisseur de services informatiques a satisfait les besoins business du client. Ce processus a des liens étroits avec la gestion des niveaux de service. Gestion des risques (Risk Management) Processus en charge d’identifier, évaluer et contrôler les risques. Voir Évaluation du risque. Gestion des Services (Service Management) La gestion du/des service(s)  est un ensemble de possibilités organisationnelles spécialisées destinées à fournir une valeur aux clients sous la forme de service(s). Gestion des Services Business (BSM) (Business Service Management) (Stratégie de Services) (Conception de services) Il s’agit d’une approche de la gestion des services informatiques qui considère les processus business soutenus et la contribution apportée à la création de valeur du business fourni. Ce terme signifie également la gestion des services au business fournis à la clientèle du business.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

374

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Gestion des Services Informatiques (ITSM) (IT Service Management) “L’implantation et la gestion de services des TI de qualité, correspondant à des besoins métier. La gestion des services des TI est effectuée par les fournisseurs de services des TI grâce à un mélange adéquat de personnes, de processus et de technologies de l’information. Voir Gestion des services. Gestion des Statuts (Status accounting) (Transition de Services) Activité en charge de l’enregistrement et du rapport du cycle de vie de chaque élément de configuration. Gestion des Systèmes (System Management) La partie de la gestion des services des TI qui s’intéresse davantage à la gestion de l’infrastructure des TI qu’aux processus. Gestion du Portefeuille des Services (SPM) (Service Portfolio Management) (Stratégie de Services) Processus en charge de la gestion du portefeuille de services. La gestion du portefeuille de services considère les services de par la valeur métiers qu’ils peuvent fournir. Gestion du risque (MoR) (Management of Risk) Méthodologie de l’OGC pour gérer les risques. La MoR inclut toutes les activités nécessaires pour identifier et contrôler l’exposition au risque pouvant avoir un impact sur l’obtention des objectifs business d’une organisation. Voir : http://wwwm-o-r.org/ pour de plus amples informations. Gestion du stockage (Storage Management) (Exploitation de Services) Processus en charge de la gestion du stockage et de la maintenance des données tout au long de leur cycle de vie. Gestion Financière (Financial Management) (Stratégie de Services) Fonction et processus en charge de la gestion du budget, de la comptabilité et des besoins en facturation d’un fournisseur de services des TI. Gestion par la qualité totale (TQM) (Total Quality ManagementM) (Amélioration continuelle du service) Une méthodologie pour gérer l’amélioration continuelle à l’aide d’un système de gestion de la qualité. La TQM établit une culture impliquant toutes les personnes de l’organisation dans un processus de surveillance et d’amélioration continues. Gestion proactive des Problèmes (Proactive Problem Management) (Exploitation de Services) Fait partie du processus de gestion des problèmes. L’objectif de la gestion proactive des problèmes est d’identifier et traiter les causes potentielles d’incidents avant qu’ils ne surviennent. La gestion proactive des problèmes analyse les enregistrements d’incidents et utilise les données collectées par les autres processus de gestion des services des TI pour identifier les tendances ou les problèmes significatifs. Gestion technique (Technical Management) (Exploitation de Services) Fonction en charge de fournir des compétences techniques pour assister les services des TI et la gestion de l’infrastructure des TI. La gestion technique définit les rôles des groupes d’assistance, ainsi que les outils, processus et procédures nécessaires.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

375

Gestionnaire de processus (Process Manager) Rôle dont la responsabilité est de réaliser la gestion opérationnelle d’un processus. Les responsabilités du gestionnaire de processus comprennent la planification et la coordination de toutes les activités nécessaires à son fonctionnement, sa surveillance et l’établissement de tableaux de bords sur le fonctionnement du processus. Il peut y avoir plusieurs gestionnaires de processus d’un même processus, par exemple des Gestionnaires des changements régionaux ou des Gestionnaires de la continuité des services des TI pour chaque centre de données. Le rôle du gestionnaire de processus est souvent confondu avec celui de propriétaire du processus, mais ces deux rôles peuvent être distincts dans les grandes organisations. Gestionnaire de Services (Service Manager) Un gestionnaire qui est responsable de la gestion quotidienne du cycle de vie d’un ou plusieurs services des TI. Le terme “ Gestionnaire du/des service(s)” sert aussi à désigner tout gestionnaire au sein du fournisseur de services des TI. Communément utilisé pour désigner un gestionnaire des relations business, un gestionnaire de processus, un directeur comptable, ou un dirigeant ayant des responsabilités sur l’ensemble des services des TI. Gestionnaire des Relations Business (Business Relationship Manager) (Stratégie de Services) Il s’agit d’un rôle en charge de maintenir une relation avec un ou plusieurs clients. Ce rôle est souvent combiné avec celui du gestionnaire des niveaux de service. Voir Gestionnaire des comptes. Gouvernance (Governance) S’assurer que les politiques et la stratégie sont réellement mises en œuvre et que les processus requis sont correctement suivis. La gouvernance inclut la définition des rôles et des responsabilités, la réalisation de mesures et de rapports, ainsi la réalisation d’actions pour résoudre tout problème identifié. Groupe de pilotage informatique (ISG) (IT Steering Group) Un groupe formel responsable d’assurer que les besoins  métiers d’une part et les stratégies du fournisseur de services des TI et les plans d’autre part sont totalement alignés. Un Comité de direction des TI regroupe des représentants de la direction issus du business et du fournisseur de services des TI. Groupe de support (Support Group) (Exploitation de Services) Un groupe de personnes ayant des compétences techniques. Les groupes d’assistance fournissent l’assistance technique réclamée par l’ensemble des processus de gestion des services des TI. Voir Gestion technique. Guide de bonnes pratiques (guideline) (Guideline) Document décrivant les meilleures pratiques, qui recommandent ce qui doit être fait. La conformité à un principe n’est habituellement pas obligatoire. Voir Standard. Haute disponibilité (High Availability) (Conception de services) Une approche ou un concept tendant à réduire (minimiser ?) ou à cacher les effets d’une défaillance d’un élément de configuration sur les utilisateurs d’un service des TI. Les solutions à haute disponibilité sont conçues pour répondre à un niveau convenu de disponibilité et mettent en oeuvre des techniques telles que la tolérance de panne, la résilience et la reprise rapide afin de réduire le nombre d’incidents, ainsi que leur impact.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

376

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Heures de service (Service Hours) (Conception de services) (Amélioration continuelle du service) Une période convenue pendant laquelle un service des TI spécifique doit être disponible. Par exemple, “Lundi-Vendredi de 8h00 à 17h00 sauf jours fériés” Les heures de service doivent être définies dans un accord sur les niveaux de service (SLA). Heures de support (Support Hours) (Conception de services) (Exploitation de Services) Les heures auxquelles l’assistance est disponible pour les utilisateurs. Normalement ce sont les horaires d’ouverture du Centre de services. L’horaire d’assistance doit être défini dans un accord sur les niveaux de service (SLA) et peut être différent des heures de service. Par exemple, les heures de service peuvent être 24h/24 et l’horaire d’assistance sera 7h00 à 19h00. Historique des changements (Change History) (Transition de Services) Informations concernant tous les changements effectués sur un élément de configuration (CI) pendant sa durée de vie. L’historique des changements comporte tous les enregistrements de changements s’appliquant à ce CI. Hot Standby (Hot Standby) Équivalent de Fast Recovey (Reprise rapide) ou de Immediate Recovey (reprise immédiate). Identification de mise en production (Release Identification) (Transition de service) Convention d’appellation servant uniquement à identifier une mise en production. L’identification de la mise en production inclut normalement une référence à un élément de configuration et à un numéro de version. Par exemple Microsoft Office 2003 SR2. Identification des configurations (Configuration Identification) (Transition de Services) Activité ayant en charge la collecte des informations concernant les éléments de configuration et leurs relations ainsi que la saisie de ces informations dans la CMDB. L’Identification de la configuration est également responsable de l’étiquetage des CI eux-mêmes, afin que les enregistrements de configuration correspondants puissent être retrouvés. Identité (Identity) (Exploitation de Services) Un nom unique servant identifier un utilisateur, une personne ou un rôle. L’identité permet de garantir les droits de cet utilisateur, personne ou rôle. Des exemples d’identités peuvent être un nom d’usage comme SmithJ ou de rôle comme “Gestionnaire des changements”. Impact (Impact) (Exploitation de Services) (Transition de Services) Mesure de l’effet d’un incident, problème ou changement sur les processus business. L’impact est souvent basé sur la manière dont les niveaux de service seront affectés. L’impact et l’urgence servent à assigner une priorité. Incident (Incident) (Exploitation de Services) Une interruption non prévue (planifiée ?) d’un service des TI ou une réduction de la qualité d’un service des TI. La défaillance d’un élément de configuration qui n’a pas encore eu d’impact sur le service est aussi un incident. Par exemple, la défaillance d’un seul des disques d’un ensemble de disques miroirs.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

377

Incident majeur (Major Incident) (Exploitation de Services) La plus haute catégorie d’impact pour un incident. Un incident majeur provoque une interruption significative du business. Indicateur-clé de performance (KPI) (Key Performance Indicator) (Amélioration continue du service) Une mesure servant à gérer un processus, un service des TI ou une activité. De nombreuses mesures peuvent être faites, mais seules les plus importantes d’entre elles sont définies comme étant des KPI et servent réellement à gérer et à établir des rapports sur un processus, un service des TI ou une activité. Les KPI doivent être sélectionnés afin d’assurer que l’efficience, l’efficacité et le rendement sont tous gérés. Voir Facteur de succès crucial. Information de gestion (Management Information) Information servant à soutenir une décision prise par la direction. L’information de gestion est souvent générée automatiquement par des outils soutenant les divers processus de gestion des services des TI. Les informations de gestion incluent souvent les valeurs des KPI tels que “Pourcentage de changements conduisant à des incidents”, ou “taux de résolution immédiate”. Infrastructure informatique (IT Infrastructure) Tout ce qui est nécessaire : matériels, logiciels, réseaux, locaux, etc pour développer, tester, fournir, surveiller, contrôler ou fournir les services des TI. Le terme “Infrastructure des TI” concerne les technologies de l’information dans son ensemble, mais pas les personnes, ni les processus ou la documentation associées. Installation fixe (Fixed Facility) (Conception de services) Un bâtiment permanent, disponible pour être utilisé en cas de besoin par un Plan de continuité de services des TI. Voir Option de reprise, Lieu mobile. Installation portable Infrastructure d’accueil mobile (Portable Facility) (Conception de service) Une construction préfabriquée ou un gros véhicule fourni par une tierce partie qui sera déplacé sur un site lorsqu’un plan de continuité des services des TI le nécessite. Voir Option de reprise, Infrastructure des TI. Instantané (Snapshot) (Transition de Services) L’état actuel d’une configuration tel qu’il a été saisi par un outil de découverte. Également employé comme synonyme de Test de performance. Voir Base de référence. Instruction de travail (Work Instruction) Document contenant des instructions détaillées qui spécifient exactement quelles sont les étapes à effectuer pour mener à bien une activité. Une instruction de travail contient beaucoup de détails qu’une procédure et n’est créée que si des instructions très détaillées sont nécessaires. Intégrité (Integrity) (Conception de services) Principe de sécurité qui assure que les données et les éléments de configuration ne sont modifiés que par un personnel et des activités autorisés. L’intégrité considère toutes les causes possibles de modification, y compris la défaillance logicielle et matérielle, les événements touchant à l’environnement et l’intervention humaine. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

378

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Interface avec le fournisseur de service (SPI) (Service Provider Interface) (Stratégie de Services) Une interface entre le fournisseur de services des TI et un utilisateur, client, processus business ou un sous-traitant. L’analyse des interfaces de fourniture de services aide à coordonner de bout en bout la gestion des services des TI. Internalisation (Insourcing) Synonyme d’approvisionnement interne. International Organisation for Standardization (ISO) (International Organisation for Standardization) L’International Organisation for Standardization (ISO) est le plus grand développeur mondial de standards. L’ISO est une organisation non-gouvernementale qui regroupe un réseau d’instituts nationaux de standards dans 156 pays. De plus amples informations sur l’ISO sont disponibles à l’adresse : http://www.iso.org/ Interruption projetée du service (PSO) (Projected Service Outage) (Transition de service) Document qui identifie l’effet des changements, activités de maintenance et plans de test planifiés sur les niveaux de service attendus. Intervalle moyen entre les défaillances (MTBF) (Mean Time Between Failures) (Conception de service) Mesure permettant de connaître et d’établir un rapport sur la fiabilité. Le MTBF est la durée moyenne pendant laquelle un élément de configuration ou un service des TI peut accomplir sa fonction attendue sans interruption. Il est mesuré à partir du moment où le CI ou le service des TI commence à fonctionner jusqu’à sa prochaine défaillance. Intervalle moyen entre les incidents de service (MTBSI) (Mean Time Between Service Incidents) (Conception de services) Mesure permettant de connaître et d’établir un rapport sur la fiabilité. Le MTBSI est le temps moyen entre deux pannes d’un système ou un service des TI. Le MTBSI est égal à MTBF + MTRS. Invocation (Invocation) (Conception de service) Lancer les étapes définies par un plan. Par exemple déclencher le Plan de continuité du service des TI pour un ou plusieurs services des TI. ISO 9000 (ISO 9000) Terme générique faisant référence à un certain nombre de standards et principes internationaux pour des systèmes de gestion de qualité. Voir http://www.iso.org/ pour de plus amples informations. Voir ISO. ISO 9001 (ISO 9001) Standard international pour les systèmes de gestion de qualité. Voir ISO 9000, Standard. ISO/IEC 17799 (ISO/IEC 17799) (Amélioration continue du service) Code de pratiques ISO pour la gestion de la sécurité de l’information. Voir Standard. ISO/IEC 20000 (ISO/IEC 20000) Spécification et Code de pratiques ISO pour la gestion des services des TI. La norme ISO/IEC 20000 est alignée sur les meilleures pratiques ITIL. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

379

ISO/IEC 27001 (ISO/IEC 27001) (Conception de service) (Amélioration continue du service) Une Spécification ISO pour la gestion de la sécurité de l’information. Le Code de pratiques correspondant est ISO/IEC 17799. Voir Standard. IT Service Management Forum (itSMF) (IT Service Management Forum) Le forum de gestion des services des TI est une organisation indépendante dont le but est de promouvoir une approche professionnelle de la gestion des services des TI. L’itSMF est une organisation composée de bénévoles ayant des représentants dans de nombreux pays du globe (Chapitres itSMF). L’itSMF et ses membres contribuent au développement de l’ITIL et des standards de gestion de service associés. Voir http://www.itsmf.com pour de plus amples informations. ITIL (ITIL) Un ensemble des meilleures pratiques de gestion des services des TI. L’ITIL appartient à l’OGC et consiste en une série de publications proposant des principes pour fournir des services des TI de qualité, ainsi que les processus et les moyens nécessaires pour les soutenir. Voir http://www.itil.co.uk pour de plus amples informations. Ligne de Service (LOS) (Line of Service) (Stratégie de service) Un service essentiel ou service de soutien ayant de multiples Ensemble de niveaux de services de niveaux de services. Une ligne de service est gérée par un responsable produit et chaque Ensemble de niveaux de services est conçu pour soutenir un segment particulier du marché. Liste des actifs (Asset Register) (Transition de Services) Liste des actifs, incluant leur possesseur et leur valeur. Le registre des actifs est maintenu à jour par la Gestion des actifs. Livrables (Deliverable) Quelque chose qui doit être fourni afin de satisfaire un engagement inscrit dans un accord sur les niveaux de service (SLA) ou dans un contrat. Marché potential (Market Space) (Stratégie de service) Toutes les opportunités qu’un fournisseur de services des TI peut exploiter afin de répondre aux besoins des clients. L’espace de marché identifie les éventuels services des TI qu’un fournisseur de services des TI peut espérer fournir. Matrice des responsabilités (Authority Matrix) Synonyme de RACI. (Responsible, Accountable, Consulted, Informed) Maturité (Maturity) (Amélioration continue du service) Une mesure de la fiabilité, de l’efficience et de l’efficacité d’un processus, d’une fonction, d’une organisation, etc. Les processus et fonctions les plus matures sont alignés sur les objectifs et les stratégies business de manière formelle et sont soutenus par un cadre de travail permettant une amélioration continuelle. Meilleures pratiques (Best Practice) Activités ou processus dont le succès a été démontré et qui sont utilisés par de multiples organisations. L’ITIL est un exemple de meilleure pratique. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

380

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Menace (Threat) Tout ce qui peut exploiter la vulnérabilité. Toute cause potentielle d’incident peut être considérée comme une menace. Par exemple, un incendie est une menace pouvant exploiter la vulnérabilité des revêtements de sol inflammables. Ce terme est communément utilisé par la Gestion de la Sécurité de l’Information (ISM) et la Gestion de la continuité du service des TI (ITSCM), mais s’applique aussi à d’autres domaines tels que la gestion des problèmes et la gestion de la disponibilité. Mesures en tension (Tension Metrics) (Amélioration continuelle du service) Un ensemble de mesures associées, dans lesquelles les améliorations d’une des mesures ont un effet négatif sur une autre. Les mesures de tensions ont été conçues pour assurer qu’un équilibre adéquat est obtenu. Métrique (Metric) (Amélioration continue du service) La mesure permet de mieux connaître et d’établir un rapport pour aider à la gestion d’un processus, d’un service des TI ou d’une activité. Voir KPI. Métrique externe (External Metric) Une mesure (métrique ?) servant à mesurer la fourniture de services des TI à un client. Les mesures externes sont souvent définies par les Accords sur les Niveaux de Service (SLA) et font l’objet de rapports aux clients. Voir Mesure interne. Métrique interne (Internal Metric) Une mesure utilisée par un fournisseur de services des TI pour surveiller l’efficience, l’efficacité ou le rendement des processus internes du fournisseur de services des TI. Les mesures internes sont habituellement rapportées au client du service des TI. Voir Mesure externe. Middleware (Middleware) (Conception de service) Logiciel qui relie deux ou plusieurs composants logiciels . Un Middleware est habituellement acheté auprès d’un éditeur de logiciel, plutôt que développé par le fournisseur de services des TI. Mise en production (Release) (Transition de service) Un ensemble de matériels, logiciels, documentations, processus et autres composants nécessaires pour déployer un ou plusieurs changements approuvés, dans les services des TI. Le contenu de chaque mise en production est géré, testé puis déployé comme  une entité autonome. Modèle Model Une représentation d’un système, d’un processus, d’un service des TI ou d’un élément de configuration, etc. qui aide à comprendre ou à prévoir son futur comportement. Modèle de changement (Change Model) (Transition de Services) Une manière répétitive de traiter une catégorie de changements particulière. Un modèle de changement établit des étapes spécifiques prédéfinies qui seront suivies pour réaliser un changement de cette catégorie. Les modèles de changement peuvent être très simples, sans qu’aucune validation ne soit nécessaire (par ex. la réinitialisation d’un mot de passe) ou très complexes avec plusieurs étapes nécessitant des validations (par ex. une mise en production logicielle majeure). Voir Changement standard, Comité consultatif sur les Changements.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

381

Modèle de Kano (Kano Model) (Stratégie de service) Un modèle développé par Noriaki Kano, qui sert à la compréhension des préférences du client. Le modèle de Kano prend en compte les attributs d’un service des TI regroupés par domaine tels que facteurs de base, facteurs d’excitation, facteurs de performance, etc. Modèle Planifier-Faire-Vérifier-Agir (PDCA) (Plan-Do-Check-Act Model) (Amélioration continue du service) Un cycle en quatre phases pour la gestion des processus attribué à Edward Deming. Planifier-Réaliser-Vérifier-Agir est aussi appelé roue de Deming. PLANIFIER : Concevoir ou réviser les processus qui soutiennent les services des TI. REALISER : Mettre en œuvre le plan et gérer les processus. VÉRIFIER : Mesurer les processus et les services des TI, les comparer avec les objectifs et produite un reporting. AGIR : Planifier et mettre en œuvre les changements afin d’améliorer les processus. Modélisation (Modelling) Une technique servant à prévoir le futur comportement d’un système, d’un processus, d’un service des TI ou d’un élément de configuration, etc. La modélisation est fréquemment employée par la Gestion financière, la Gestion de la capacité et la Gestion de la disponibilité. Modélisation analytique (Analytical Modelling) (Stratégie de Services) (Conception de services) (Amélioration de la Continuité du Service) Technique employant des modèles mathématiques pour prévoir le comportement d’un élément de configuration ou d’un service informatique. Les modèles analytiques sont fréquemment employés dans la Gestion de la capacité et la Gestion de la disponibilité. Voir Modélisation. Modélisation par simulation (Simulation modelling) (Conception de services) (Amélioration continuelle du service) Technique ayant pour but de créer un modèle détaillé afin de prédire le comportement d’un élément de configuration ou d’un service des TI. Les modélisations de simulation peuvent s’avérer très précises mais sont aussi onéreuses et longues à développer. Une modélisation de simulation est souvent créée à l’aide d’éléments de configuration réels pouvant être modélisés, mais avec des charges de travail et des transactions artificielles. Elles sont utilisées dans la gestion de la capacité lorsque des résultats précis sont indispensables. Un modèle de simulation est parfois appelé Test de performance. Ne rien faire (Do Nothing) (Conception de services) Une option de reprise. Le fournisseur de services convient formellement avec le Client que la reprise de ce service des TI ne sera pas effectuée. Near-shore (Near-Shore) (Stratégie de service) Approvisionnement en service issu d’un pays proche de celui où est basé le client. Il peut s’agir de la fourniture d’un service des TI ou de fonctions de soutien, tel qu’un centre de services. Voir On-Shore, Off-Shore. Niveau de maturité (Maturity Level) Intitulé d’un niveau dans un modèle de maturité, tel que le Modèle de maturité d’aptitude à l’intégration (CMMI) de Carnegie Mellon.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

382

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Niveau de service (Service Level) Réalisation mesurée et rapportée d’une ou plusieurs cibles de niveau de service. Le terme “Niveau de service” est parfois utilisé de façon informelle pour signifier cible de niveau de service. Objectif (Objective) L’intérêt ou le but défini d’un processus, d’une activité ou d’une organisation dans sa globalité. Les objectifs sont habituellement exprimés par des cibles mesurables. Le terme “Objectif ” est aussi utilisé de manière informelle pour signifier une exigence. Voir Aboutissement. Objectif business (Business Objective) (Stratégie de Services) L’objectif d’un processus business, ou d’un business dans son ensemble. Les objectifs du business soutiennent la vision du business, servent de guide à la stratégie des TI et sont souvent soutenus par les services informatiques. Objectif de maintenance des services (SMO) (Service Maintenance Objective) (Exploitation de Services) Le temps estimé pendant lequel un élément de configuration sera indisponible du fait de l’activité de maintenance planifiée. Objectif de point de reprise (RPO) (Recovery Point Objective) (Exploitation de Services)(Service Design) La quantité maximale acceptable de données pouvant être perdues lors de la restauration d’un service après une interruption. L’objectif d’un point de reprise est exprimé sous la forme d’une durée avant la panne. Par exemple, un objectif de point de reprise d’une journée peut être attendu grâce à des copies de sauvegarde quotidiennes. Les objectifs de point de reprise de chaque service des TI doivent être négociés, acceptés et documentés ; ils doivent servir d’exigences à la Conception de services et aux plans de continuité des services des TI. Objectif de temps de reprise (RTO) (Recovery Time Objective) (Exploitation de Services) (Service Design) La durée maximale accordée à la reprise d’un service après une interruption. Le niveau de service à fournir peut être inférieur aux cibles de niveau de service normales. Les objectifs de temps de reprise de chaque service des TI doivent être négociés, convenus et documentés. Voir Analyse d’impact sur le business (BIA). Observation technique (TO) (Technical Observation) (Amélioration continuelle du service) Technique servant à l’amélioration du service, l’investigation des problèmes et la gestion de la disponibilité. L’équipe d’assistance technique doit surveiller le comportement et les performances d’un service des TI et faire des recommandations pour son amélioration. Office of Government Commerce (OGC) (Office of Government Commerce) L’OGC est propriétaire de la marque ITIL (droits d’auteur et marque déposée). L’OGC est un bureau du gouvernement britannique qui soutient la fourniture du calendrier des acquisitions du gouvernement dans sa tâche en termes d’acquisition collaborative et en élevant les niveaux de capacité et de compétence d’acquisition des différents départements. Il fournit également un soutien aux projets complexes du secteur public. Office of Public Sector Information (OPSI) (Office of Public Sector Information) L’OPSI accorde la licence Crown Copyright au matériel utilisé dans les publications ITIL. Il existe un département du gouvernement britannique qui fournit l’accès en ligne à la législation britannique, accorde les licences de réutilisation

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

383

du matériel sous Crown Copyright, gère les informations du “Fair Trader Scheme”, tient à jour le “Registre des Actifs d’Information du gouvernement”, donne des conseils et établit les principes sur la publication officielle et le Crown Copyright. Off-shore (Off-Shore) (Stratégie de service) Approvisionnement en service issu d’un endroit situé en dehors du pays où est basé le client,le plus souvent un autre continent. Il peut s’agir de la fourniture d’un service des TI ou de fonctions de soutien, tel qu’un centre de services. Voir On-Shore, Proximité (Near-Shore). On-shore (On-Shore) (Stratégie de service) Approvisionnement en service issu d’un endroit situé dans le pays où est basé le client. Voir Off-Shore, Proximité (Near-Shore). Opérationnel (Live) (Transition de service) Fait référence à un service des TI ou à un élément de configuration actuellement utilisé pour fournir un service à un client. Opérationnel (Operational) Le plus bas des trois niveaux de planification et de fourniture (Stratégique, Tactique, Opérationnel). Les activités opérationnelles incluent la planification ou la fourniture quotidienne ou à court terme d’un processus business ou d’un processus de gestion de service des TI. Le terme “Opérationnel” est aussi un synonyme de “En marche”. Opérations business (Business Operations) (Stratégie de Services) Il s’agit de l’exécution de la surveillance et de la gestion au jour le jour des processus business. Opérations informatiques (IT Operations) (Exploitation de Services) Activités effectuées par le Contrôle de l’Exploitation des TI, incluant la gestion de console, le calendrier des tâches, la copie de sauvegarde et la restauration, ainsi que la gestion de l’impression et des données de sorties. L’exploitation des TI est également employée comme synonyme d’Exploitation de Services. Optimisation de la fourniture de services (SPO) (Service Provisioning Optimization) (Stratégie de Services) Analyser les finances et les contraintes d’un service des TI afin de décider si des approches différentes de la fourniture du service pourraient réduire les coûts ou améliorer la qualité. Optimiser (Optimise) Revoir, Planifier et demander des changements afin d’obtenir l’efficience et l’efficacité maximales d’un processus, d’un élément de configuration, d’une application, etc. Option de reprise (Recovery Option) (Conception de service) Une stratégie permettant de répondre à une interruption de service. Les stratégies les plus couramment employées sont Ne rien faire, Solution de contournement manuelle, Arrangement réciproque, Reprise graduelle, Reprise intermédiaire, Reprise rapide, Reprise immédiate. Les options de reprise peuvent faire usage de locaux spécifiques ou de locaux tierces partagés par plusieurs métiers.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

384

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Ordonnancement des travaux (job scheduling) (Job Scheduling) (Exploitation de Services) Planification et gestion de l’exécution de travaux qui ont été requises par un service des TI. Les travaux ordonnancés sont gérés et le calendrier associé est sous la responsabilité de la gestion de l’Exploitation des TI et est le plus souvent automatisé à l’aide d’outils logiciels qui exécutent des tâches par lot ou en ligne selon un calendrier précis. Organisation (Organisation) Une société, une entité légale ou autre institution. Quelques exemples d’organisations qui ne sont pas des sociétés  : International Standards Organisation (ISO) ou itSMF. Le terme Organisation fait parfois référence à n’importe quelle entité disposant de personnes, de ressources et de budgets. Par exemple un projet ou une unité business. Organisme International des Standards (International Standards Organisation)Voir International Organisation for Standardization (ISO). Package de conception de service (SDP) (Service Design Package) (Conception de services) Un ou plusieurs document(s) définissant tous les aspects d’un service des TI et ses exigences à toutes les étapes de son cycle de vie. Un package de conception de service est produit à chaque nouveau service des TI, changement majeur ou suppression d’un service des TI. Package des niveaux de service (SLP) (Service Level Package) (Stratégie de Services) Un niveau défini d’utilité et de garantie pour un Package de services particulier. Chaque SLP est conçu pour satisfaire les besoins d’un schéma d’activité business (PBA) particulier. Package d’un service (Service Package) (Stratégie de Services) Une description détaillée d’un service des TI étant disponible pour les clients. Un package de services comprend un package de niveau(x) de service(s) (SLP) ainsi qu’un ou plusieurs services essentiels et des services de soutien. Package d’un service de base (CSP) (Core Service Package) (Stratégie de Services) Description détaillée d’un service essentiel pouvant être partagé par un ou plusieurs Package de niveau de service. Panne (Fault) Synonyme d’Erreur, dysfonctionnement. Partenariat (Partnership) Une relation entre deux organisations qui implique de travailler en étroite collaboration pour des buts communs et un bénéfice mutuel. Le fournisseur de services des TI doit avoir un partenariat avec le business et avec les tierces parties cruciales dans la fourniture de services des TI. Voir Réseau de valeur. Partie prenante (Stakeholder) Toutes les personnes qui ont un intérêt dans une organisation, un projet, un service des TI etc. Les intervenants peuvent être intéressés par les activités, les cibles, les ressources ou les biens délivrés. Les intervenants peuvent être des clients, des partenaires, des employés, des actionnaires, des propriétaires, etc. Voir RACI.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

385

Performance (Performance) Mesure de ce qui est obtenu ou fourni par un système, une personne, une équipe, un processus ou un service des TI. Périmètre (Scope) La limite ou l’extension jusqu’à laquelle un processus, une procédure, une certification, un contrat, etc s’applique. Par exemple, l’étendue de la gestion des changements peut inclure tous les services des TI réels et les éléments de configuration concernés, l’étendue d’un certificat ISO/IEC 20000 peut inclure tous les services des TI délivrés par le centre de données mentionné. Perspective business (Business Perspective) (Amélioration continuelle du service) Une compréhension du fournisseur de service et des services des TI du point de vue du business et une compréhension du business du point de vue du fournisseur de service. Perspective de contrôle (Control perspective) (Stratégie de Services) Approche de la gestion des services informatiques, processus, fonctions, actifs, etc. Il peut y avoir différentes perspectives de contrôle sur un même service informatique, processus, etc, permettant à différents individus ou à différentes équipes de s’intéresser à ce qui est important et qui relève de leur rôle spécifique. Exemples de perspectives de contrôle : la gestion réactive et proactive au sein des opérations des TI, ou une vision du cycle de vie d’une équipe pour un projet d’application. Pilote (Pilot) (Transition de Services) La mise en œuvre d’un service des TI, d’une mise en production ou d’un processus dans un environnement réel sur un périmètre limité. Un pilote sert à réduire le risque, à obtenir un retour d’expérience et  une validation des utilisateurs. Pipeline des services (Service Pipeline) (Stratégie de Services) Une base de données ou un document structuré qui établit la liste de tous les services des TI qui sont en considération ou en développement, mais ne sont pas encore disponibles pour les clients. Le pipeline de services fournit une vision business des éventuels services des TI futurs et fait partie du portefeuille de services, qui n’est habituellement pas diffusé aux clients. Plan (Plan) Une proposition détaillée qui décrit les activités et les ressources nécessaires pour atteindre un objectif. Par exemple, un plan pour implémenter un nouveau service ou processus. La norme IOS/IEC20000 requiert un plan pour gérer chaque processus de gestion des services des TI. Plan d’amélioration des services (SIP) (Service Improvement Plan) (Amélioration continuelle du service) Un plan formel de mise en œuvre d’améliorations d’un processus ou d’un service des TI. Plan de capacité (Capacity Plan) (Conception de services) Le plan de capacité sert à gérer les ressources nécessaires à la fourniture des services informatiques. Ce plan contient des scénarios correspondant à différentes prévisions d’exigences du business, ainsi que des options cotées pour répondre aux Objectifs de Niveau de Service convenus.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

386

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Plan de continuité des services informatiques (IT Service Continuity Plan) (Conception de service) Plan définissant les étapes nécessaires à la reprise d’un ou de plusieurs services des TI. Ce plan doit aussi identifier les déclencheurs, les personnes impliquées, les moyens de communication, etc. Le plan de continuité de services des TI fait partie d’un plan de continuité du métier. Plan de continuité du business (BCP) (Business Continuity Plan) (Conception de services) Plan définissant les étapes nécessaires à la remise en fonction des processus business suite à une interruption. Ce plan doit aussi identifier les déclencheurs, les personnes impliquées, les moyens de communication, etc. Les plans de continuité des Services des TI représentent une part importante des plans de continuité du business. Plan de disponibilité (Availability Plan) (Conception de services) Plan permettant de s’assurer que les besoins en disponibilité des services des TI, actuels et futurs, peuvent être fournis de manière rentable. Planification (Planning) Une activité ayant pour but de créer un ou plusieurs plans. Par exemple, planification de la capacité. Planification de la capacité (Capacity Planning) (Conception de services) Activité au sein de la gestion de la capacité ayant en charge la création d’un plan de capacité. Planification et Support à la Transition (Transition Planning and Support) (Transition de Services) Processus en charge de planifier tous les processus de transition de service et de coordonner les ressources qui leur sont nécessaires. Ces processus de transition de service sont la Gestion des changements, la Gestion des actifs et des configurations de service (SACM), la Validation et les tests du service, l’Évaluation, et la Gestion des connaissances. PMBOK (PMBOK) Un standard de gestion de projet, tenu à jour et publié par le Project Management Institute. PMBOK signifie Project Management Body of Knowledge. Voir http://www.pmi.org/ pour de plus amples informations. Voir PRINCE2. Point de contact unique (SPOC) (Single Point of Contact) (Exploitation de Services) Fournit un moyen unique et cohérent de communiquer avec une organisation ou une unité métiers. Par exemple, le point de contact unique d’un fournisseur de services des TI est habituellement appelé Centre de services. Point de défaillance unique (SPOF) (Single Point of Failure) (Conception de services) Tout élément de configuration pouvant causer un incident lorsqu’il tombe en panne, et pour lequel une contre-mesure n’a pas été implantée. Un SPOF peut tout aussi bien être une personne, ou une étape d’un processus ou d’une activité, qu’un composant d’une infrastructure des TI. Voir Défaillance. Politique (Policy) Attentes et intentions de gestion formellement documentées. Les politiques servent à diriger les décisions, et à assurer des développements et des implantations cohérents et appropriés des processus, standards, rôles, activités, Infrastructure des TI, etc.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

387

Politique de sécurité (Security Policy) Synonyme de Politique de la Sécurité de l’Information. Politique de sécurité informatique (Information Security Policy) (Conception de services) La politique qui gouverne l’approche que peut avoir une organisation en termes de Gestion de la Sécurité de l’Information. Portefeuille de clients (Customer Portfolio) (Stratégie de Services) Base de données ou un document structuré servant à enregistrer tous les clients du fournisseur de services informatiques. Le portefeuille de clients est le point de vue, qu’a le gestionnaire des relations business, des clients qui reçoivent les services des TI du fournisseur de services informatiques. Voir Portefeuille des contrats, Portefeuille des services. Portefeuille de contrats (Contract Portfolio) (Stratégie de Services) Base de données ou un document structuré servant à gérer les contrats ou les accords de service entre un fournisseur de services informatiques et ses clients. Chaque service informatique fourni à un client doit avoir un contrat ou autre accord, qui sera listé dans le portefeuille de contrats. Voir Portefeuille des services, Catalogue des services. Portefeuille des applications (Application Portfolio) (Conception de services) Une base de données ou un document structuré servant à gérer les applications tout au long de leur cycle de vie. Le portefeuille d’applications contient les attributs clés de toutes les applications. Le portefeuille d’applications peut être implanté sous la forme d’une partie du portefeuille des services ou du système de gestion des configurations. Portefeuille des services (Service Portfolio) (Stratégie de Services) L’ensemble complet des services qui sont gérés par un fournisseur de services. Le portefeuille de services sert à gérer le cycle de vie complet de tous les services et comprend trois catégories : Pipeline de services (proposés ou en développement), Catalogue des services (réels ou disponibles pour la mise-en-oeuvre ), et les services supprimés. Voir Gestion du portefeuille de services, Portefeuille de contrats. Potentiel de service (Service Potential) (Stratégie de Services) La valeur totale possible de l’ensemble des capacités et des ressources du fournisseur de services de TI. Pourcentage d’utilisation (Percentage utilisation) (Conception de service) La durée pendant laquelle un composant est occupé sur une période donnée. Par exemple, si une carte-mère est occupée pendant 1 800 secondes sur une période d’une heure, son utilisation est de 50%. Pratique (Practice) Une façon de travailler ou une manière dont un travail doit être fait. Les pratiques peuvent inclure les activités, processus, fonctions, standards et principes. Voir Meilleures pratiques.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

388

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Prérequis au succès (PFS) (Prerequisite for Success) Une activité qui doit être réalisée ou une condition qui doit être remplie pour permettre la mise en oeuvre réussie d’un plan ou d’un processus. Un PFS est souvent le résultat d’un processus qui se trouve être un atout nécessaire à un autre processus. Prêt à l’emploi (off the shelf ) (Off the Shelf ) Synonyme de “du commerce”. PRINCE2 (PRINCE2) Standard de méthodologie du gouvernement britannique pour la gestion des projets. Voir http://www.ogc.gov.uk/ prince2/ pour de plus amples informations. Voir PMBOK. Principe de Pareto (Pareto principle) (Exploitation de Services) Technique permettant de définir la priorité des activités. Le principe de Pareto dit que 80% de la valeur d’une activité est créée par 20% de l’effort. L’analyse de Pareto est également utilisée dans la Gestion des problèmes afin de définir la priorité des causes possibles d’un problème lors d’une investigation. Priorité (Priority) (Transition de service) (Exploitation de Services) Une catégorie servant à identifier l’importance relative d’un incident, d’un problème ou d’un changement. La priorité est basée sur l’impact et sur l’urgence et sert à identifier le délai acceptable pour la mise en œuvre d’une action Par exemple, le SLA peut statuer que les incidents de Priorité 2 doivent être résolus en 12 heures. Problème (Problem) (Exploitation de Services) La cause d’un ou de plusieurs incidents. Cette cause n’est pas forcément connue au moment de l’enregistrement du problème, et le processus de gestion des problèmes est alors chargé des nouvelles investigations. Procédure (Procedure) Un document contenant les étapes qui indiquent comment  réaliser une activité. Les procédures sont définies comme faisant partie des processus. Voir Instructions de travail. Procédures standard d’exploitation (SOP) (Standard Operating Procedures) (Exploitation de Services) Procédures utilisées par la Gestion de l’exploitation des TI. Processus (Process) Un ensemble d’activités structurées conçues pour atteindre un objectif spécifique. Un processus traite une ou plusieurs entrées définies et les transforme en résultats (sortie). Un processus peut inclure la définition des tout  rôles, responsabilités, outils et contrôles de gestion nécessaires à la fourniture de résultats de manière fiable. Un processus peut définir des politiques, des standards, des principes, des activités et des modes opératoires si c’est nécessaire. Processus business (Business Process) Processus qui est possédé et exécuté par le business. Un processus business contribue à la fourniture d’un produit ou d’un service à un client du business. Par exemple, un revendeur peut avoir un processus d’achat qui contribue à fournir des services à ses clients business (sa clientèle). De nombreux processus business dépendent des services des TI.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

389

Processus de contrôle (Control Processes) Groupe de processus ISO/IEC 20000 incluant la Gestion des changements et la Gestion des Configurations. Processus de gestion des relations (Relationship Processes) Le groupe de processus ISO/IEC 20000 comportant la Gestion des relations métier et la Gestion des sous-traitants. Processus de mise en production (Release Process) Nom utilisé par la norme ISO/IEC 20000 pour le groupe de processus qui inclut la Gestion des mises en production. Ce groupe n’inclut aucun autre processus. Le processus de mise en production est aussi synonyme de processus de gestion des mises en production. Processus de resolution (Resolution Process) Le groupe de processus de la norme ISO/IEC 20000 qui inclut la gestion des incidents et la gestion des problèmes. Processus de resolution (Resolution Process) Le groupe de processus de la norme ISO/IEC 20000 qui inclut la gestion des incidents et la gestion des problèmes. Profil d’utilisateur (UP) (User Profile) (Stratégie de Services) Schéma des demandes des utilisateurs envers les services des TI. Chaque profil utilisateur comporte un ou plusieurs schémas d’activité business (PBA). Pro-forma (pro-forma) Un document modèle ou exemple contenant des données factices qui seront remplacées par les valeurs réelles lorsqu’elles seront disponibles. Programme (Programme) Un certain nombre de projets et d’activités qui sont planifiés et gérés ensemble afin d’atteindre un objectif global et d’autres résultats. PRojects IN Controlled Environments (PRINCE2) (Projects IN Controlled Environments) Voir PRINCE2. Projet (Project) Une organisation temporaire, avec des personnes et autres actifs nécessaires pour atteindre un objectif ou d’autres résultats. Chaque projet a un cycle de vie qui comporte normalement les phases d’initialisation, de planification, d’exécution, de clôture, etc. Les projets sont habituellement gérés à l’aide d’une méthodologie formelle telle que PRINCE2. Propriétaire de processus (Process Owner) Rôle dont la responsabilité est de s’assurer qu’un processus est adapté aux besoins. Les responsabilités du propriétaire de processus comprennent la recherche de sponsors, la conception, la gestion des changements, l’amélioration continue du processus et de ses mesures. Ce rôle est souvent confondu avec celui de de gestionnaire du processus, mais ces deux rôles peuvent être distincts dans les grandes organisations. Propriétaire de service (Service Owner) (Amélioration continuelle du service) Un rôle qui est responsable de la fourniture d’un service des TI spécifique.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

390

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Qualification (Qualification) (Transition de service) Activité qui assure qu’une infrastructure des TI est adaptée et correctement configurée pour soutenir une application ou un service des TI. Voir Validation. Qualité (Quality) La capacité d’un produit, d’un service ou d’un processus à fournir la valeur escomptée. Par exemple, un composant matériel peut être considéré comme étant de bonne qualité s’il fonctionne comme on s’y attend et avec la fiabilité nécessaire. Le Processus Qualité requiert également la possibilité de surveiller l’efficacité et l’efficience, ainsi que leur amélioration si nécessaire. Voir Système de gestion de la qualité. Quick Win (Quick Win) (Amélioration continue du service) Une activité d’amélioration qui est sensée fournir un retour sur investissement à court terme avec relativement peu d’effort et à faible coût. RACI (RACI) (Conception de services) (Amélioration continuelle du service) Modèle servant à définir les rôles et les responsabilités. RACI signifie Responsable de ses Actes, Consulté et Informé. Voir Intervenants. Rapport d’exception (Exception report) Document contenant tous les détails d’un ou de plusieurs indicateurs clés de performance (KPI) ou d’autres objectifs importants ayant dépassé des seuils définis. Par exemple, des cibles sur des accords sur les niveaux de service ( SLA) non atteintes ou sur le point de pas être atteintes, ou une mesure de performance indiquant un problème potentiel de capacité. Rattrapage (Remediation) (Transition de service) Reprise à un état connu après l’échec d’un changement ou d’une mise en production. Rattrapage (Remediation) (Transition de Services) Reprise à un état connu après l’échec d’un changement ou d’une mise en production. Réactivité (Responsiveness) Mesure du temps nécessaire pour répondre à quelque chose. Il peut s’agir du temps de réponse d’une transaction ou de la vitesse à laquelle un fournisseur de service des TI répond à un incident ou à une demande de changement. Réactivité (Responsiveness) Mesure du temps nécessaire pour répondre à quelque chose. Il peut s’agir du temps de réponse d’une transaction ou de la vitesse à laquelle un fournisseur de service des TI répond à un incident ou à une demande de changement. Redondance (Redundancy) Synonyme de Tolérance de panne. Le terme “Redondance” peut aussi prendre le sens d’obsolète ou inutile.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

391

Réglage (tuning) (Tuning) Activité en charge de la planification des changements afin d’avoir un usage efficace des ressources. Le réglage fait partie de la gestion des performances, qui inclut aussi la surveillance des performances et l’implantation des changements requis. Relation (Relationship) Une connexion ou une interaction entre deux personnes ou deux objets. Dans la Gestion des relations métier, il s’agit de l’interaction entre deux fournisseurs de service des TI et le métier. Dans la Gestion des configurations, il s’agit d’un lien entre deux éléments de configuration qui définit une dépendance ou une connexion entre eux. Par exemple, des applications peuvent être liées aux serveurs sur lesquels elles sont installées, des services des TI peuvent avoir de nombreux liens avec tous les CI qui les composent. Relevé des besoins (SQR) (Statement of requirements) (Conception de services) Document contenant toutes les exigences pour l’achat d’un produit, un service des TI nouveau ou changé. Voir Termes de référence. Remue-méninges (brainstorming) (Brainstorming) (Conception de services) Une technique favorisant la génération d’idées dans en mode collaboratif au sein d’une équipe. Les idées ne sont pas revues pendant la session de Brainstorming, mais à une étape suivante. Le Brainstorming est souvent employé par la Gestion des Problèmes pour identifier les causes possibles. Rentabilité (Cost effectiveness) Mesure de l’équilibre entre l’efficacité et le coût d’un service, d’un processus ou d’une activité. Un processus rentable est celui qui atteint ses objectifs avec un coût minimum. Voir KPI, Retour sur investissement, Rapport qualité/prix. Rentabilité (Value for money) (Value for money) Une mesure informelle de la rentabilité. Le rapport qualité/prix est souvent basé sur la comparaison des coûts des solutions alternatives. Voir Analyse des coûts et des bénéfices. Réparation (Repair) (Exploitation de Services) Remplacement ou correction d’un élément de configuration défaillant. Reporting des services (Service Reporting) (Amélioration continuelle du service) Processus en charge de produire et de fournir des rapports concernant l’obtention et les tendances des niveaux de service. Le processus rapport de service devrait inclure l’accord sur le format, le contenu et la fréquence de diffusion de ces rapports avec les clients. Reprise (Recovery) (Conception de service) (Exploitation de Services) Revenir à un état normal de fonctionnement d’un élément de configuration ou d’un service des TI. La reprise d’un service des TI inclut souvent de récupérer les données dans un état connu et cohérent. Après une reprise, plusieurs actions peuvent être nécessaires avant que le service des TI ne soit rendu disponible aux utilisateurs (restauration).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

392

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Reprise graduelle (Gradual Recovery) (Conception de services) Une option de reprise également connue sous le nom de Cold Standby. Une provision est effectuée afin de reprendre le service des TI dans un laps de temps de plus de 72 heures. La reprise graduelle utilise habituellement un lieu fixe ou mobile disposant d’un soutien environnemental et d’un câblage réseau, mais sans systèmes informatiques. Le matériel et le logiciel sont installés en tant qu’éléments du Plan de continuité de services des TI. Reprise immediate (Immediate Recovery) (Conception de services) Une option de reprise également connue sous le nom de Hot Standby. Une provision est effectuée afin de reprendre le service des TI sans aucune perte de service. La reprise immédiate utilise habituellement des technologies de sites miroir, de sites dédoublés avec équilibrage des charges. Reprise intermédiaire (Intermediate Recovery) (Conception de services) Une option de reprise également connue sous le nom de Warm Standby. Des dispositions sont pruses afin de reprendre le service des TI dans un laps de temps compris entre 24 et 72 heures. La reprise intermédiaire utilise habituellement un lieu fixe ou mobile disposant de systèmes informatiques et de composants réseau. Le matériel et le logiciel doivent être configurés et les données doivent être restaurées à partir du Plan de continuité du service des TI. Reprise rapide (Fast Recovery) (Conception de services) Une option de reprise également connue sous le nom de reprise immédiate (Hot Standby). Une provision est effectuée afin de reprendre le service des TI dans les plus brefs délais, normalement en moins de 24 heures. La reprise immédiate utilise habituellement un lieu (local ?) fixe dédié, équipé de systèmes informatiques et de logiciels configurés prêts à fonctionner pour relancer les services des TI. Une reprise immédiate peut prendre jusqu’à 24 heures s’il est nécessaire de restaurer les données à partir de copies de sauvegarde. Réseau de création de valeur (Value Network) (Stratégie de Services) Un ensemble complexe de relations entre deux groupes ou organisations, voire plus. La valeur est générée grâce aux échanges de compétences, d’informations, de biens ou de services. Voir Chaîne de valeur, Partenariat. Résilience (Resilience) (Conception de services) La capacité d’un élément de configuration ou d’un service des TI à résister à une panne ou à avoir une reprise rapide suite à une défaillance. Par exemple, un câble blindé résistera mieux à la défaillance lorsqu’il sera soumis à une tension. Voir Tolérance de panne. Résilience (Resilience) (Conception de services) La capacité d’un élément de configuration ou d’un service des TI à résister à une défaillance ou à avoir une reprise rapide suite à une défaillance. Par exemple, un câble blindé résistera mieux à la défaillance lorsqu’il sera soumis à une tension. Voir Tolérance de panne. Résolution (Resolution) (Exploitation de Services) Action de réparer  la cause fondamentale d’un incident ou d’un problème ou de mettre en oeuvre une solution de contournement. Dans la norme ISO/IEC 20000, le processus de résolution est le groupe qui inclut la gestion des incidents et des problèmes.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

393

Ressource (Resource) (Stratégie de service) Terme générique qui inclut le personnel, le budget alloué à l’infrastructure des TI, et tout autre élément pouvant contribuer à fournir un service des TI. Les ressources sont considérées comme les actifs d’une organisation. Voir Capacité, Actif de service. Restauration du service (Restoration of Service) Voir Restaurer. Restaurer (Restore) (Exploitation de Services) Action de rendre un service des TI aux utilisateurs après une réparation et une reprise suite à un incident. C’est l’objectif principal de la Gestion des incidents. Restaurer (Restore) (Exploitation de Services) Action de rendre un service des TI aux utilisateurs après une réparation et une reprise suite à un incident. C’est l’objectif principal de la Gestion des incidents. Résultat (Outcome) Le résultat issu d’une activité ; du suivre d’un processus, de la fourniture d’un service des TI, etc. Le terme “Résultat” fait tout aussi bien référence à des résultats escomptés, qu’à des résultats réels. Retirer ou Supprimer (Retire) (Transition de service) Suppression définitive d’un service des TI ou d’un autre élément de configuration de l’environnement de production. La suppression est une phase du cycle de vie de la plupart des éléments de configuration. Retour à l’état initial (Back-out) Synonyme de Remède. Retour à la normale (Return to Normal) (Conception de service) Phase d’un plan de continuité de service des TI durant laquelle la totalité des opérations normales est reprise. Par exemple, si un autre centre de données a été utilisé, cette phase remettra en service le premier centre de données et restaurera la possibilité de déclencher à nouveau des plans de continuité de service des TI. Retour à la normale (Return to Normal) (Conception de services) Phase d’un plan de continuité du service des TI durant laquelle la totalité des opérations normales sont recouvrée s. Par exemple, si un autre centre de données a été utilisé, cette phase remettra en service le premier centre de données et restaurera la possibilité de déclencher à nouveau des plans de continuité du service des TI. Retour sur investissement (ROI) (Return on Investment) (Stratégie de service) (Amélioration continuelle du service) Mesure du bénéfice espéré d’un investissement. Dans son sens le plus simple, il s’agit du bénéfice net rapporté par un investissement divisé par la valeur nette des actifs investis. Voir Valeur nette actuelle (NPV), Valeur sur investissement.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

394

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Revue (Review) Évaluation d’un changement, problème, processus, projet, etc. Les revues sont habituellement effectuées à des moments prédéfinis du cycle de vie et surtout après la fermeture. Le but d’une revue étant d’assurer que tous les livrables ont été fournis et d’identifier les opportunités d’amélioration. Voir Revue Post Implantation (PIR). Revue post implémentation (PIR) (Post Implementation Review) Une revue qui se produit après qu’un changement ou un projet a été implanté. Une PIR détermine si le changement ou le projet a été réussi et identifie les opportunités d’amélioration. Risque (Risk) Un événement possible pouvant causer une déficience ou une perte, ou affecter la possibilité d’atteindre des objectifs. Un risque se mesure par la probabilité d’une menace, la vulnérabilité d’un actif à cette menace et l’impact qu’il aurait s’il se produisait. Rôle (Role) Un ensemble de responsabilités, d’activités et d’autorités attribuées à une personne ou à une équipe. Le rôle est défini dans un processus. Une personne ou une équipe peut avoir plusieurs rôles, par exemple, les rôles de Gestionnaire des configurations et de Gestionnaire des changements peuvent être attribués à une même personne. Salle de contrôle (Operations Bridge) (Exploitation de Services) Un lieu physique où les services des TI et l’infrastructure des TI sont surveillés et gérés. Scénario d’utilisation (Use Case) (Conception de services) Technique utilisée pour définir la fonctionnalité requise et les objectifs, et pour la conception de tests. Les études de cas définissent des scénarios réalistes décrivant les interactions entre les utilisateurs et un service des TI ou un autre système. Voir Étude de changement. Schéma d’activité Business (PBA) (Pattern of Business Activity) (Stratégie de service) Profil de charge de travail d’une ou de plusieurs activités métier. Les schémas d’activité métier aident le fournisseur de service des TI à comprendre et à planifier les variations d’activités liées au métier. Voir Profil Utilisateur. Script de diagnostic (Diagnosis Script) (Exploitation de Services) Ensemble structuré de questions structuré utilisé par l’équipe du centre de services pour s’assurer que les questions correctes sont posées et contribuer ainsi à classer, résoudre et assigner les incidents. Les scripts de diagnostic peuvent aussi être mis à la disposition des utilisateurs afin de les aider à diagnostiquer et résoudre leurs propres incidents. Sécurité (Security) Voir Gestion de la Sécurité de l’Information (ISM). Séparation des préoccupations (SoC) (Separation of Concerns) (Stratégie de Services) Une approche, pour concevoir une solution ou un service des TI, qui divise le problème en morceaux pouvant être résolus indépendamment. Cette approche sépare le “quoi” du “comment”.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

395

Serveur (Server) (Exploitation de Services) Un ordinateur connecté à un réseau qui fournit des fonctions logicielles utilisées par d’autres ordinateurs. Serveur vocal interactif (IVR) (Interactive Voice Response) (Exploitation de Services) Sorte de répartiteur d’appels basé sur l’intervention de l’utilisateur, comme l’appui sur une touche et des commandes orales, afin d’identifier la destination correcte des appels reçus. Serviçabilité (Serviceability) (Conception de services) (Amélioration continuelle du service) La capacité d’un sous-traitant tiers à satisfaire aux termes de son contrat. Ce contrat doit inclure les niveaux convenus de fiabilité, de facilité de maintenance et de disponibilité d’un élément de configuration. Service (Service) Un moyen de fournir une valeur à des clients en facilitant les aboutissements que les clients veulent obtenir sans avoir la propriété des coûts ou des risques spécifiques. Service business (Business Service) Un service des TI qui soutient un processus business, par opposition à un service d’infrastructure qui est utilisé en interne par le fournisseur de services informatiques et n’est habituellement pas visible du business. Le terme Service au business signifie également un service qui est fourni aux clients du business par les unités business. Par exemple la fourniture de services financiers aux clients d’une banque, ou de denrées aux clients d’un magasin de détail. La réussite de la fourniture de services au business dépend souvent d’un ou de plusieurs services informatiques. Service d’annuaire (Directory Service) (Directory Service) (Exploitation de Services) Application qui gère les informations concernant l’infrastructure des TI disponibles sur un réseau et les droits d’accès utilisateur correspondant. Service de base (Core service) (Stratégie de Services) Service informatique qui fournit les aboutissements désirés par un ou plusieurs clients. Voir Service de soutien, Package de services essentiels. Service de soutien (Supporting Service) (Stratégie de Services) Un service qui active ou améliore un service essentiel. Par exemple un service d’annuaire ou un service de copie de sauvegarde. Voir Package de services. Service d’Infrastructure (Infrastructure Service) Un service des TI qui n’est pas utilisé directement par le business, mais est nécessaire au fournisseur de services des TI afin qu’il puisse fournir d’autres services des TI. Par exemple les services d’annuaire, les services d’attribution de nom ou de communication. Service informatique (IT Service) Il s’agit d’un service fourni à un ou plusieurs clients par un fournisseur de services des TI. Un service des TI est basé sur l’usage de technologies de l’information et soutient les processus métier du client. Un service des TI est composé d’une combinaison de personnes, de processus et de technologies ; et doit être défini dans un Accord sur les Niveaux de Service (SLA). Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

396

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Service technique (Technical Service) Synonyme de Service d’infrastructure. Services gérés (Managed Services) (Stratégie de service) Une perspective des services des TI qui accentue le fait qu’ils sont gérés. Le terme “services gérés” peut être aussi synonyme de services des TI externalisés. Seuil (Threshold) Valeur d’une mesure qui pourrait provoquer le déclenchement d’une alerte ou la mise en place d’une action de gestion. Par exemple “Incident de Priorité1 non résolu en 4 heures”, “plus de 5 erreurs disque en une heure” ou “plus de 10 échecs de changement en un mois”. SMART (SMART) (Conception de services) (Amélioration continuelle du service) Acronyme pour aider à se souvenir que les cibles des accords sur les niveaux de service et des plans de projet doivent être Spécifiques, Mesurables, Atteignables, en Rapport (Relevant) et Temporellement  opportunes (Timely). Solution de contournement (Workaround) (Exploitation de Services) Réduire ou éliminer l’impact d’un incident ou d’un problème pour lequel une résolution complète n’est pas encore disponible. Par exemple, en redémarrant un élément de configuration défaillant. Les solutions de contournement des problèmes sont documentées dans les enregistrements d’erreurs connues. Les solutions de contournement des incidents qui n’ont pas été associées aux enregistrements des problèmes sont documentées dans les enregistrements d’incidents. Solution de contournement manuelle (Manual Workaround) Solution de contournement nécessitant une intervention manuelle. Une solution de contournement manuelle est aussi utilisée sous le nom d’option de reprise, par laquelle le processus métier opère sans l’usage des services des TI. C’est une mesure temporaire habituellement combinée avec une autre option de reprise. Source Source Voir Approvisionnement en service. Sourcing de services (Service Sourcing) (Stratégie de Services) Stratégie et approche pour décider si un service sera fourni en interne ou pour l’externaliser en employant un fournisseur externe. L’approvisionnement en service signifie également l’exécution de cette stratégie, ce qui inclut : • Approvisionnement interne – Services partagés ou internes utilisant des fournisseurs de services de type I ou de type II. • Approvisionnement traditionnel – Externalisation complète du service en employant un fournisseur de services de type III. • Approvisionnement multidistributeurs – Externalisation majeure, consortium ou sélective employant des fournisseurs de services de type III. Sourcing externe (External sourcing) Synonyme d’Externalisation.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

397

Sourcing interne (Internal sourcing) (Stratégie de service) Utiliser exclusivement des fournisseurs de services des TI de sa propre entreprise pour gérer les services des TI. Voir Approvisionnement en service, Fournisseur de services de Type I, Fournisseur de services de Type II. Spécification (Specification) Une définition formelle des exigences. Une spécification peut servir à définir des exigences opérationnelles ou techniques, et peut être interne ou externe. De nombreux standards publics sont composés d’un code de pratique et d’une spécification. La spécification définit le standard par rapport auquel une organisation peut être soumise à un audit. Standard (Standard) Une exigence obligatoire. Exemples : ISO/IEC 20000 (une norme internationale), une norme de sécurité interne pour une configuration Unix, ou un standard gouvernemental sur la manière de tenir à jour les enregistrements financiers. Le terme “standard” fait aussi référence à un code de pratique ou à une spécification publiée par un Organisme de Standards telle que ISO ou BSI. Voir Principe. Statut (Status) Le nom d’un champ obligatoire dans de nombreux types d’enregistrements. Il indique l’état actuel dans le cycle de vie de l’élément de configuration, l’incident, le problème associé. Stratégie (Strategy) (Stratégie de Services) Un plan stratégique établi pour atteindre les objectifs définis. Stratégie de Services Service Strategy (Stratégie de Services) Le titre d’une des publications phares de l’ITIL. La stratégie de service établit une stratégie globale pour les services des TI et pour la gestion des services des TI. Stratégique (Strategic) (Stratégie de Services) Le plus haut des trois niveaux de planification et de fourniture (Stratégique, Tactique, Opérationnel). Les activités stratégiques incluent la définition des objectifs et la planification à long terme pour avoir une vision globale. Structure des configurations (Configuration Structure) (Transition de Services) Hiérarchie et autres relations entre tous les éléments de configuration composant une configuration. Superutilisateur (Super User) (Exploitation de Services) Un utilisateur qui aide d’autres utilisateurs et les assiste dans leur communication avec le centre de services ou d’autres parties du fournisseur de service des TI. Les super utilisateurs fournissent habituellement une assistance aux incidents mineurs et à la formation. Support de début de vie (ELS) (Early Life Support) (Transition de Services) Soutien apporté à un service des TI, nouveau ou changé, juste après sa mise en production. Au cours d’un soutien précoce, le fournisseur de services des TI peut revoir les KPI, les niveaux de service ainsi que les seuils de surveillance et fournir des ressources supplémentaires à la Gestion des Incidents et des Problèmes.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

398

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Support de deuxième niveau (Second-line Support) (Exploitation de Services) Le deuxième  niveau dans la hiérarchie des groupes d’assistance impliqués dans la résolution des incidents et l’investigation des problèmes. Chaque niveau présente davantage de compétences spécialisées ou dispose de davantage de temps ou d’autres ressources. Support de premier niveau (First-line Support) (Exploitation de Services) Le premier niveau dans la hiérarchie des groupes de soutien impliqués dans la résolution des incidents. Chaque niveau contient davantage de compétences spécialisées ou dispose de davantage de temps ou d’autres ressources. Voir Escalade. Support de troisième niveau (Third-line Support) (Exploitation de Services) Le troisième niveau dans la hiérarchie des groupes d’assistance impliqués dans la résolution des incidents et l’investigation des problèmes. Chaque niveau contient davantage de compétences spécialisées ou dispose de davantage de temps ou d’autres ressources. Support technique (Technical Support) Synonyme de Gestion technique.  Support type Follow the Sun (Follow the Sun Support) (Exploitation de Services) Une méthodologie permettant d’utiliser les centres de service et les groupes de soutien dans le monde entier afin de fournir un service 24x7. Les appels, incidents, problèmes et requêtes de service transitent d’un groupe à l’autre selon différents fuseaux horaires. Suppression (Retire) (Transition de Services) Suppression définitive d’un service des TI ou autre élément de configuration de l’environnement opérationnel . La suppression est une phase du cycle de vie de nombreux éléments de configuration. Surveillance (Monitoring) (Exploitation de Services) Vérification répétée de l’état d’un élément de configuration, d’un service des TI ou d’un processus afin de générer  un événement et de s’assurer que son état réel est connu. Surveillance active (Active Monitoring) (Exploitation de Services) Surveillance d’un élément de configuration ou d’un service informatique à l’aide de vérifications régulières automatisées mettant en évidence son état actuel. Voir Surveillance passive. Surveillance passive (Passive Monitoring) (Exploitation de Services) Surveillance d’un élément de configuration, d’un service des TI ou d’un processus qui dépend d’une alerte ou d’une notification générée par lui-même et décrivant son état. Voir Surveillance active. Surveillance proactive (Proactive Monitoring) (Exploitation de Services)Type de supervision basé sur des modèles d’enchaînement d’événements permettant d’anticiper d’éventuelles défaillances futures. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

399

Surveillance reactive (Reactive Monitoring) (Exploitation de Services) Supervision qui prend les mesures adéquates en fonction d’un événement. Par exemple, soumettre une tâche par lot lorsque la tâche précédente est terminée ou journaliser un incident lorsqu’une erreur s’est produite. Voir Surveillance proactive. Système (System) Un certain nombre de choses reliées entre elles, fonctionnant en réseau pour atteindre un objectif global. Par exemple : • Un système informatique incluant matériel, logiciels et applications. • Un système de gestion, incluant de multiples processus qui sont planifiés et gérés ensemble. Par exemple, un système de gestion de la qualité. • Un système de gestion de base de données ou un système d’exploitation qui comprend plusieurs modules logiciels conçus pour exécuter un ensemble de fonctions associées. Système de gestion (Management System) Le cadre de travail des politiques, processus et fonctions qui assurent à une organisation de pouvoir atteindre ses objectifs Système de Gestion de la Qualité (QMS) (Quality Management System) (Amélioration continuelle du service) Ensemble de processus en charge d’assurer que tout le travail effectué par une organisation est d’une qualité convenable pour satisfaire de manière fiable les objectifs business ou les niveaux de service. Voir ISO 9000. Systéme de Gestion de la Sécurité Informatique (ISMS) (Information Security Management System) (Conception de services) Le cadre de travail de la politique, des processus, standards, principes et outils qui assurent à une organisation qu’elle atteindra ses objectifs de Gestion de la Sécurité de l’Information. Système de Gestion des Configurations (CMS) (Configuration Management System) (Transition de Services) Ensemble d’outils et de bases de données servant à gérer les données de configuration d’un fournisseur de services informatiques. Le CMS comporte également des informations sur les incidents, problèmes, erreurs connues, changements et mises en production ; et peut aussi contenir des informations sur les employés, les soustraitants, unités business, clients et utilisateurs. Le CMS comprend des outils pour collecter, stocker, gérer, mettre à jour et présenter les données concernant tous les éléments de configuration et leurs relations. Le CMS est tenu à jour par la gestion des configurations et est utilisé par tous les processus de gestion des services des TI. Voir Base de données de gestion des configurations, Système de gestion des connaissances du service. Système de Gestion des Connaisances des Services (SKMS) (Service Knowledge Management System) (Transition de Services) Un ensemble d’outils et de bases de données servant à gérer les connaissances et les informations. Le SKMS inclut le système de gestion des configurations, ainsi que d’autres outils et bases de données. Le SKMS stocke, gère, tient à jour et présente toutes les informations dont un fournisseur de service des TI a besoin pour gérer le cycle de vie complet des services des TI. Système d’information de Gestion de la Capacité (CMIS) (Capacity Management Information System) (Conception de services) Répertoire virtuel de toutes les données concernant la gestion de la capacité, habituellement stocké dans des lieux physiques distincts. Voir Système de gestion des connaissances du service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

400

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Système d’information de la Gestion de la Disponibilité (AMIS) (Availability Management Information System) (Conception de services) Répertoire virtuel des données de la gestion de la disponibilité, habituellement stocké dans des lieux physiques distincts. Voir Système de gestion des connaissances du service. Tableau de bord (Dashboard) (Exploitation de Services) Représentation graphique des Performances et de la Disponibilité globale d’un service des TI. Ces graphiques peuvent être mis à jour en temps réel et peuvent aussi être inclus dans les rapports de gestion et les pages web. Les tableaux de bord peuvent servir à soutenir la Gestion des niveaux de service, la Gestion des événements ou le Diagnostic d’un incident. Tableau de bord équilibré (Balanced Scorecard) (Amélioration continuelle du service) Un outil de gestion développé par le Dr. Robert Kaplan (Harvard Business School) et David Norton. Un tableau de bord équilibré permet de décomposer une stratégie en Indicateurs Clé de Performance (KPI). Les performances comparées aux KPI servent à démontrer comment la stratégie a été élaborée. Un tableau de bord équilibré est composé de 4 zones principales, chacune comprenant un petit nombre de KPI. Ces 4 zones sont considérées à des niveaux différents de détails par l’ensemble de l’organisation. Tableau SLAM (SLAM Chart) (Amélioration continuelle du service) Une charte de surveillance des niveaux de service convenus (Service Level Agreement Monitoring Chart) contribue à la surveillance de ceux-ci et à l’établissement de rapports sur l’obtention des cibles de niveau de service. Une charte SLAM utilise habituellement un code couleur pour montrer si chacune des cibles de niveau de service convenue a été atteinte, manquée ou presque atteinte au cours de chacun des douze derniers mois. Tactique (Tactical) (Stratégie de Services) Le niveau intermédiaire des trois niveaux de planification et de fourniture (Stratégique, Tactique, Opérationnel). Les activités tactiques incluent les plans à moyen terme nécessaire pour atteindre des objectifs spécifiques, habituellement sur une période de quelques semaines ou quelques mois. Tarification (Pricing) (Stratégie de service) Une activité qui définit le montant de la facturation due par les clients. Taux de retour interne (IRR) (Internal Rate of Return) (Stratégie de service) Technique permettant d’aider à la prise de décisions concernant l’augmentation de capital. L’IRR calcule une somme permettant de comparer deux ou plusieurs possibilités d’investissements. Un IRR élevé indiqué un meilleur investissement. Voir Valeur actuelle nette, Retour sur investissement. Technologies de l’information (IT) Information Technology (IT) Usage de la technologie pour le stockage, la communication ou le traitement de l’information. La technologie inclut typiquement les ordinateurs et les télécommunications, les applications et autres logiciels. L’information peut inclure les données business, la voix, les images, la vidéo, etc. La technologie de l’information sert souvent à soutenir les processus business via les services des TI.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

401

Temps d’indisponibilité (Downtime) (Conception de services) (Exploitation de Services) Période pendant laquelle un élément de configuration ou un service des TI n’est pas disponible, pendant la période convenue de service. La disponibilité d’un service des TI est souvent calculée à partir de la période convenue de service et de son temps d’indisponibilité. Temps de réponse (Response Time) Mesure du temps nécessaire pour achever une opération ou une transaction. Utilisé par la gestion de la capacité comme mesure de la performance de l’infrastructure des TI et par la gestion des incidents comme la mesure du temps passé à répondre au téléphone ou à démarrer un diagnostic. Temps de service convenu (AST) (Agreed Service Time) (Conception de services) Synonyme d’Heures de Service, communément employé dans le calcul de la Disponibilité. Voir Temps de disponibilité. Temps d’indisponibilité planifié (Planned Downtime) (Conception de service) La période négociée pendant laquelle un service des TI n’est pas disponible. L’indisponibilité planifiée est souvent utilisée pour la maintenance, les mises à jour ou les tests. Voir Fenêtre de changement, Indisponibilité. Temps moyen de réparation (MTTR) (Mean Time To Repair) (Conception de services) Le délai moyen pour réparer un élément de configuration ou un service des TI suite à une panne. Le MTTR est mesuré à partir du moment où le CI ou le service des TI tombe en panne jusqu’à sa réparation. Le MTTR n’inclut pas le temps nécessaire pour reprendre ou restaurer le CI ou le service des TI. Le MTTR est parfois employé incorrectement pour signifier le Délai moyen de restauration d’un service. Temps moyen de restauration du service (MTRS) (Mean Time To Restore Service) (Conception de services) Le délai moyen pour restaurer un élément de configuration ou un service des TI suite à une défaillance. Le MTRS est mesuré à partir du moment où le CI ou le service des TI tombe en panne jusqu’à sa restauration complète afin qu’il retrouve sa fonction normale. Voir Facilité de maintenance, Délai moyen de réparation. Termes de référence (TOR) (Terms of Reference) (Conception de services) Document spécifiant les exigences, l’étendue, les biens à délivrer, les ressources et le calendrier d’un projet ou d’une activité. Test (Test) (Transition de Services) Activité ayant pour but de vérifier qu’un élément de configuration, un service des TI, un processus, etc correspond à ses spécifications ou aux exigences convenues. Voir Validation et test du service, Acceptation. Tierce partie (Third Party) Une personne, un groupe ou un business qui ne fait pas partie de l’accord sur les niveaux de service d’un service des TI, mais est nécessaire pour assurer la fourniture réussie de ce service des TI. Par exemple un fournisseur de logiciels soustraitant, une société de maintenance de matériel ou un département de l’équipement. Les exigences envers les tierces parties sont habituellement stipulées dans des contrats de sous-traitance ou des accords sur les niveaux opérationnels (OLA).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

402

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Tolérance aux pannes (Fault Tolerance) (Conception de services) Possibilité qu’un service des TI ou un élément de configuration puisse continuer à fonctionner correctement après une défaillance d’une partie d’un composant. Voir Résilience, Contre-mesure. Transaction (Transaction) Une fonction séparée exécutée par un service des TI. Par exemple, transférer de l’argent d’un compte bancaire à un autre. Une seule transaction peut impliquer de nombreux ajouts, suppressions et modifications de données. Soit elles réussissent toutes, soit aucune d’entre elles n’est prise en compte. Transition (Transition) (Transition de Services) Un changement d’état, correspondant à un mouvement d’un service des TI ou autre élément de configuration d’une étape de son cycle de vie vers la suivante. Transition de Services (Service Transition) (Transition de Services) Une étape du cycle de vie d’un service des TI. La transition de service inclut un certain nombre de processus et de fonctions et c’est aussi le titre d’une des publications phares de l’ITIL. Voir Transition. Travail en cours (WIP) (Work in Progress) Un état signifiant que des activités ont commencé mais ne sont pas encore terminées. Communément employé comme un état pour les incidents, les problèmes, les changements, etc. Type d’appel (Call Type) (Exploitation de Services) Catégorisation des appels servant à classer les demandes reçues par le Centre de Services. Les types d’appels les plus fréquents sont incident, demande de service et réclamation. Type de CI (CI Type) (Transition de Services) Catégorie servant à classer les CI. Le Type de CI identifie les attributs requis et les relations d’un enregistrement de Configuration. Les Types de CI les plus répandus sont : Matériel, Document, Utilisateur, etc. Type de coût (Cost Type) (Stratégie de Services) Niveau de catégorie le plus élevé auquel des coûts sont attribués, en termes de budget et de comptabilité. Par exemple, matériel, logiciel, personnel, locaux, sous-traitants transfert. Voir Élément de coût, Type de coût. Unité Business (BU) (Business Unit) (Stratégie de Services) Entité opérationnelle du business ayant ses propres plans, mesures, recettes et coûts. Chaque Unité Business possède ses actifs propres et les utilise pour créer de la valeur pour ses clients sous la forme de biens et de services. Unité de coût (Cost Unit) (Stratégie de Services) Niveau de catégorie le plus bas auquel des coûts sont attribués, les unités de coût sont habituellement des éléments pouvant être aisément comptés (par ex. un nombre de personnes, des licences logicielles) ou des choses

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

403

pouvant être aisément mesurées (ex. usage d’une carte-mère, électricité consommée). Les unités de coût sont incluses dans les éléments de coût. Par ex. l’élément de coût “dépenses” peut inclure des unités de coût, comme Hôtels, Transport, Repas, etc… Voir Type de coût. Unité de mise en production (Release Unit) (Transition de service) Composants d’un service des TI qui sont habituellement mis en production ensemble. Une unité de mise en production comprend suffisamment de composants pour exécuter une fonction utile. Par exemple, une unité de mise en production peut être un poste informatique PC comportant matériel, logiciel, licences, documentation, etc. Une autre unité de mise en production peut être une application de paye complète, incluant les Procédures d’exploitation et la formation de l’utilisateur. Urgence (Urgency) (Transition de Services) (Conception de services) Mesure du temps que met un incident, un problème ou un changement à avoir un impact significatif sur les métiers. Par exemple, un incident à fort impact peut avoir une urgence faible, si cet impact n’affecte pas le business avant la fin de l’année fiscale. Impact et urgence servent à attribuer un niveau de priorité. Utilisateur User Une personne qui utilise quotidiennement un service des TI. Les utilisateurs se distinguent des clients, car certains clients n’utilisent pas directement le service des TI. Utilité (Utility) (Stratégie de Services) Fonctionnalité offerte par un produit ou un service des TI pour satisfaire un besoin particulier. L’utilité est souvent résumée par “à quoi ça sert”. Voir Utilité du service. Utilité du service (Service Utility) (Stratégie de Services) La fonctionnalité d’un service des TI du point de vue du client. La valeur business d’un service des TI est générée par la combinaison de l’utilité de ce service (ce qu’il fait) et la garantie du service (comment il y parvient). Voir Utilité. Valeur nette actuelle (NPV) Net Present Value (NPV) (Stratégie de service) Technique d’aide à la prise de décisions concernant une augmentation de capital. La NPV compare les entrées et les sorties d’argent. Une NPV positive indique qu’un investissement est envisageable. Voir Taux de retour interne, Retour sur investissement. Valeur sur investissement (VOI) (Value on Investsment) (Amélioration continuelle du service) Une mesure du bénéfice escompté d’un investissement. La VOI prend en compte à la fois les bénéfices financiers et les bénéfices tangibles. Voir Retour sur investissement. Validation (Validation) (Transition de Services) Activité assurant qu’un service des TI, processus, plan ou autre livrable, nouveau ou changé correspond aux besoins du business. La validation assure que les exigences du business sont satisfaites même si celles-ci ont changé depuis la conception d’origine. Voir Vérification, Acceptation, Qualification, Validation et test du service.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

404

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Validation et Tests de Services (Service Validation and Testing) (Transition de Services) Processus en charge de la validation et du test d’un service des TI, nouveau ou changé. La validation et le test assurent que le service des TI correspond à ses caractéristiques de conception et qu’il répondra aux besoins du business. Variance (Variance) La différence entre la valeur prévue et la valeur réelle mesurée. Souvent utilisée par la Gestion financière, la Gestion de la capacité et la Gestion des niveaux de service, mais pourrait s’appliquer dans de nombreux domaines où des plans sont mis en place. Vérification (Verification) (Transition de Services) Activité s’assurant qu’un service des TI, processus, plan ou autre livrable, nouveau ou changé est complet, précis, fiable et correspond à ses caractéristiques de conception. Voir Validation, Acceptation, Validation et test du service Vérification et audit (Verification and Audit) (Transition de Services) Activités en chargent d’assurer que les informations contenues dans la CMDB sont précises et que tous les éléments de configuration ont été identifiés et enregistrés dans celle-ci. La vérification inclut les vérifications de routine qui font partie des autres processus. Par exemple, vérifier le numéro de série d’un ordinateur lorsqu’un utilisateur saisit un incident. L’audit est une vérification périodique formelle. Version (Version) (Transition de Services) Une version sert à identifier la base de référence spécifique d’un élément de configuration. Habituellement, les versions utilisent une convention pour l’attribution de leur nom permettant de définir une séquence ou de dater chacune des bases de référence. Par exemple, l’application de Paye Version 3 contient une fonctionnalité mise à jour depuis la version 2. Vision (Vision) Description de ce qu’une organisation souhaite devenir dans le futur. Une vision est générée par la direction et sert à influencer la culture et la planification stratégique. Vulnérabilité (Vulnerability) Une faiblesse qui pourrait être exploitée par une menace. Par exemple, un pare-feu ouvert, un mot de passe qui n’est jamais changé ou une moquette inflammable. Un contrôle manquant est également considéré comme une vulnérabilité. Warm Standy ou Reprise à chand (Warm Standby) Équivalent de Immediate Recovey (Reprise immédiate).

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

405

Index

A

C

Accord sur les niveaux de service (SLA) . . 207 Accord sur les niveaux opérationnels (OLA). . . . . . . . . . . . . . 207 Actif de service et la gestion des configurations (SACM) . . . . . . . . . . . 256 Amélioration Continue des Services (CSI).145 Amélioration de service précis . . . . . . . . . 154 Amélioration des services (SIP). . . . . . . . . . 92 Améliorations. . . . . . . . . . . . . . . . . . . . . . 167 Analyse de l’impact. . . . . . . . . . . . . . . . . . 173 Analyse de l’impact du business (BIA) . . . . 92 Analyse de l’impact sur le business (BIA). 227 Analyse des défaillances de service . . . . . . 173 Analyse des écarts. . . . . . . . . . . . . . . . . . . 329 Analyse des parties prenantes. . . . . . . . . . 109 Analyse des risques. . . . . . . . . . . . . . . . . . . 68 Analyse par arbre de pannes. . . . . . . . . . . 173 Analyser les données. . . . . . . . . . . . . . . . . 173 Analyse SWOT . . . . . . . . . . . . . . . . . . . . 163 Application service provision . . . . . . . . . . . 78 Approche de processus. . . . . . . . . . . . . . . 183 Architecture des infrastructures informatiques. . . . . . . . . . . . . . . . . . . . 75 Attributs. . . . . . . . . . . . . . . . . . . . . . . . . . 261 Automatisé ou manuel. . . . . . . . . . . . . . . 268

Capability Maturity Model Integration (CMMI). . . . . . . . . . . . . . . . . . . . . . . . 11 Capacité. . . . . . . . . . . . . . . . . . . . . . . . . . . 25 CASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Catalogue des services. . . . . . . . 36, 204, 203 Catalogue des services techniques. . . . . . . 204 Catégorie du risque . . . . . . . . . . . . . . . . . 250 Centre de services. . . . . . . . . . . . . . . . . . . 127 Centre de services local. . . . . . . . . . . . . . . 323 Changement standard . . . . . . . . . . . . . . . 248 Classification des incidents. . . . . . . . . . . . 299 CMDB fédéré . . . . . . . . . . . . . . . . . . . . . 258 Comité consultatif sur les changements (CAB). . . . . . . . . . . . . . . . . . . . . . . . . 106 Construction. . . . . . . . . . . . . . . . . . . . . . 271 Contrat de sous-traitance (UC) : . . . . . . . 298 Conventions d’attribution des noms. . . . . 261 Couche de données . . . . . . . . . . . . . . . . . 258 Couche de présentation. . . . . . . . . . . . . . 258 Couche de traitement de la connaissance. 258 Couche d’intégration de l’information. . . 258 Critical Succes Factor (CSF). . . . . . . . . . . 150

B Balanced Scorecard (BSC) . . . . . . . . . . . . 162 Base de données de gestion des configurations (CMDB) . . . . . . . . . . . . . . . . . . . . . . 287 Base de données des erreurs connues (KEDB) . . . . . . . . . . . . . . . . 306 Base de référence . . . . . . . . . . . . . . . . . . . 154 Base de référence des configurations. . . . . 259 Benchmark. . . . . . . . . . . . . . . . . . . . . . . . 160 Bibliothèque sécurisée . . . . . . . . . . . . . . . 259 Big bang contre progressif . . . . . . . . . . . . 268

D Data, Information, Knowledge, Wisdom (DIKW). . . . . . . . . . . . . . . . . . . . . . . 151 Demande de changement (RFC). . . . . . . 248 Demande de service. . . . . . . . . . . . . . . . . 303 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . 25 Division. . . . . . . . . . . . . . . . . . . . . . . . . . 114 Documentation des configurations. . . . . . 262 Données. . . . . . . . . . . . . . . . . . . . . . . . . . 151

E Enregistrement des incidents . . . . . . . . . . 298 Équipe. . . . . . . . . . . . . . . . . . . . . . . 114, 184 Équipe de gestion des configurations. . . . 107

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

406

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Équipe de l’exploitation des services. . . . . 125 Escalade hiérarchique. . . . . . . . . . . . . . . . 300 Étiquettes. . . . . . . . . . . . . . . . . . . . . . . . . 261 Évaluation. . . . . . . . . . . . . . . . . . . . . . . . 103 Exigences de gestion et opérationnelles. . . . 82

F Facteurs clés de succès . . . . . . . . . . . . . . . 150 Fonction. . . . . . . . . . . . . . . . . . . . . . 183, 184 Fonctions. . . . . . . . . . . . . . . . . . . . . . . . . 188 Framework de rapports. . . . . . . . . . . . . . . 338

G Garantie. . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Gestion de la capacité. . . . . . . . . . . . . 80, 211 Gestion de la capacité business. . . . . . . . . 213 Gestion de la capacité des composants. . . 214 Gestion de la capacité des services . . . . . . 213 Gestion de la construction et de l’environnement des tests. . . . . . . . . . 107 Gestion de la continuité des services informatiques (ITSCM). . . . . . . . 81, 226 Gestion de la Continuité du Business. . . . 229 Gestion de la demande. . . . . . . . . . . . . . . . 44 Gestion de la disponibilité. . . . . 81, 173, 218 Gestion de la sécurité informatique . . 81, 231 Gestion des accès. . . . . . . . . . . . . . . 121, 313 Gestion des actifs de service et des configurations. . . . . . . . . . . . . . . . . . . 101 Gestion des applications. . . . . . . . . . . . . . 132 Gestion des bases de données. . . . . . . . . . 123 Gestion des changements. . . . . . . . . 170, 246 Gestion des changements organisationnels. . . . . . . . . . . . . . . . . 107 Gestion des connaissances . . . . . . . . . . . . 103 Gestion des déploiements et des mises. . . 102 Gestion des droits. . . . . . . . . . . . . . . . . . . 313 Gestion des événements. . . . . . . . . . . . . . 119 Gestion des fournisseurs. . . . . . . . . . . . . . . 82 Gestion des fournisseurs. . . . . . . . . . . . . 237 Gestion des identités . . . . . . . . . . . . . . . . 313 Gestion des incidents. . . . . . . . . . . . . . . . 119 Gestion des installations et du centre informatique. . . . . . . . . . . . . . . . . . . . 124 Gestion des niveaux de service. . . . . 170, 207 Gestion des niveaux de service (SLM) . . . . 80

Gestion des parties prenantes. . . . . . . . . . 109 Gestion des problèmes réactive. . . . . . . . . 120 Gestion des problèmes. . . . . . . . . . . . . . . 120 Gestion des problèmes proactive. . . . . . . . 120 Gestion des réseaux . . . . . . . . . . . . . . . . . 123 Gestion des risques. . . . . . . . . . . . . . . . . . . 68 Gestion des service d’annuaire . . . . . . . . . 123 Gestion des services business . . . . . . . . . . . 76 Gestion du catalogue des services (SCM). . 80 Gestion du mainframe. . . . . . . . . . . . . . . 122 Gestion du middleware . . . . . . . . . . . . . . 124 Gestion du portefeuille des services (SPM).45 Gestion du serveur et support. . . . . . . . . . 122 Gestion financière . . . . . . . . . . . . . . . . . . . 43 Gestion Internet/web. . . . . . . . . . . . . . . . 124 Gestionnaire CSI. . . . . . . . . . . . . . . . . . . 157 Gestionnaire de la conception des services. 88 Gestionnaire de la disponibilité . . . . . . . . . 89 Gestionnaire de la sécurité. . . . . . . . . . . . . 89 Gestionnaire de l’évaluation des risques . . 107 Gestionnaire des actifs de services. . . . . . . 105 Gestionnaire des applications. . . . . . . . . . 136 Gestionnaire des changements. . . . . . . . . 106 Gestionnaire des CMS. . . . . . . . . . . . . . . 107 Gestionnaire des configurations. . . . . . . . 106 Gestionnaire des connaissances du service.107 Gestionnaire de service. . . . . . . . . . . . . . . 157 Gestionnaire des incidents. . . . . . . . . . . . 138 Gestionnaire des niveaux de service . . . . . . 89 Gestionnaire des problèmes . . . . . . . . . . . 138 Gestionnaire des services . . . . . . . . . . . . . 155 Gestionnaire de transition . . . . . . . . . . . . 105 Gestionnaire du catalogue des services. . . . 89 Gestionnaire du centre de services . . . . . . 137 Gestionnaire du déploiement. . . . . . . . . . 107 Gestionnaire du packaging de mise en production et de la construction. . . . . 107 Gestion proactive des problèmes. . . . . . . . 307 Groupes de centres de services . . . . . . . . . 324

I Identification des incidents. . . . . . . . . . . . 298 Impact. . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Information Systems Examination Board (ISEB) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Instantané . . . . . . . . . . . . . . . . . . . . . . . . 260

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Glossaire

407

K Key Perfomance Indicator (KPI). . . . . . . 150

M Magasin sécurisé. . . . . . . . . . . . . . . . . . . . 259 Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Maturité. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Meilleures pratiques. . . . . . . . . . . . . . . . . . . 9 Mesure. . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Mesures correctives. . . . . . . . . . . . . . . . . . 234 Mesures de détection . . . . . . . . . . . . . . . . 234 Mesures de réduction. . . . . . . . . . . . . . . . 234 Mesures préventives. . . . . . . . . . . . . . . . . 234 Mesures répressives. . . . . . . . . . . . . . . . . . 234 Métrique . . . . . . . . . . . . . . . . . . . . . . . . . 150 Mettre en l’uvre des actions correctives. . . 175 Middleware . . . . . . . . . . . . . . . . . . . . . . . 124 Mise en production . . . . . . . . . . . . . . . . . 267 Mises en production majeures . . . . . . . . . 263 Modèle d’écart des services. . . . . . . . . . . . 163 Modèle de représentation par étapes de CMMI. . . . . . . . . . . . . . . . . . . . . . . . . 12 Modèle CSI. . . . . . . . . . . . . . . . . . . . . . . 329 Modèle de problèmes. . . . . . . . . . . . . . . . 306 Modèle DIKW. . . . . . . . . . . . . . . . . . . . . 287

O Ordonnancement des travaux (Job scheduling). . . . . . . . . . . . . . . . . Organisation proactive. . . . . . . . . . . . . . . Organisation réactive. . . . . . . . . . . . . . . . Outils. . . . . . . . . . . . . . . . . . . . . . . . . . . .

122 116 116 184

P Package de mise en production. . . . . . . . . 268 Packages de services . . . . . . . . . . . . . . . . . . 45 Performance prévue. . . . . . . . . . . . . . . . . 283 Performance réelle . . . . . . . . . . . . . . . . . . 284 Perspective bout-ˆ-bout . . . . . . . . . . . . . . 338 Perspective business . . . . . . . . . . . . . . . . . 338 Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Pièces de rechange dénifitives. . . . . . . . . . 259 Piège des aptitudes. . . . . . . . . . . . . . . . . . . 55 Pilotes . . . . . . . . . . . . . . . . . . . . . . . 269, 272 Plan d’amélioration des services (SIP). . . . 329 Planification et du support ˆ la transition.241

Politiques CSI . . . . . . . . . . . . . . . . . . . . . 152 Portefeuille des services. . . . . . . . . . . . . . . 204 Potentiel de valeur de service . . . . . . . . . . . 43 Priorité. . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Processus d’amélioration CSI. . . . . . . . . . 329 Processus d’amélioration en 7 étapes. . . . . 329 Propriétaires de services . . . . . . . . . . . . . . 332

Q Quatre P . . . . . . . . . . . . . . . . . . . . . . . . . 232

R RACI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Rapide d’application (Rapid Application Development - RAD). . . . . . . . . . . . . . 77 Rapport. . . . . . . . . . . . . . . . . . . . . . 154, 329 Rapports de services. . . . . . . . . . . . . 337, 339 Redondance active. . . . . . . . . . . . . . . . . . 222 Redondance diverse. . . . . . . . . . . . . . . . . 223 Redondance hétérogène. . . . . . . . . . . . . . 223 Redondance homogène . . . . . . . . . . . . . . 223 Redondance passive. . . . . . . . . . . . . . . . . 223 Reporting framework. . . . . . . . . . . . . . . . 341 Représentation continue de CMMI. . . . . . 12 Revue des mises en Ïuvre . . . . . . . . . . . . . 159 Revue port-implémentation (PIR). . . . . . 273 Risk categorization. . . . . . . . . . . . . . . . . . 250

S SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Sagesse. . . . . . . . . . . . . . . . . . . . . . . 151, 339 Salle de contrôle. . . . . . . . . . . . . . . . . . . . 321 Santé opérationnelle. . . . . . . . . . . . . . . . . 117 Sauvegarde et la restauration. . . . . . . . . . . 122 Service Request . . . . . . . . . . . . . . . . . . . . 297 Services à l’étude . . . . . . . . . . . . . . . . . . . . 38 Silos fonctionnels. . . . . . . . . . . . . . . . . . . . 18 SLA multi-niveaux. . . . . . . . . . . . . . . . . . 209 SLA orientés client. . . . . . . . . . . . . . . . . . 208 SLA orientés service. . . . . . . . . . . . . . . . . 208 Stockage et l’archivage . . . . . . . . . . . . . . . 123 Structure des configurations. . . . . . . . . . . 261 Super-utilisateurs. . . . . . . . . . . . . . . . . . . 137 Superutilsateurs . . . . . . . . . . . . . . . . . . . . 325 Superviseur du centre de services . . . . . . . 137 Supervision. . . . . . . . . . . . . . . . . . . . . . . . 47

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

408

Les fondamentaux de la gestion des services informatiques selon ITIL V3

Support de début de vie (ELS). . . . . . . . . 273 Support de premier niveau. . . . . . . . . . . . 127 Support des postes de travail. . . . . . . . . . . 124 Surveillance et contrôle. . . . . . . . . . . . . . 121 Surveillance et contrôle externe . . . . . . . . 319 Surveillance et contrôle externes. . . . . . . . 121 Surveillance et contrôle interne. . . . . . . . . 319 Système de cycles fermés. . . . . . . . . . . . . . 316 Système de gestion de la sécurité informatique (ISMS). . . . . . . . . . . . . . . . . . . . . . . . 232 Système d’information de gestion de la capacité (CMIS). . . . . . . . . . . . . . . . . 215 Système de cycles ouverts. . . . . . . . . . . . . 316 Système de gestion des connaissances des services (SKMS). . . . . . . . . . . . . 287, 310

T Tableau de bord équilibré (BSC) . . . . . . . 162 Tâche. . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Technical Observation Post (TOP). . . . . . 174 Temps moyen de restauration du service (MTRS). . . . . . . . . . . . . . . . . . . . . . . 221 Traiter les données. . . . . . . . . . . . . . . . . . 173 Transition des services . . . . . . . . . . . . . . . . 97 Type I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

U Unité de mise en production . . . . . . . . . . 263

V Valeur ajoutée. . . . . . . . . . . . . . . . . . . . . . 168 Valeur d’approvisionnement. . . . . . . . . . . . 43 Valeur de la provision. . . . . . . . . . . . . . . . 190 Valeur du service . . . . . . . . . . . . . . . . . . . . 25 Valeurs finales. . . . . . . . . . . . . . . . . . . . . . . 50 Valeur sur investissement (VOI). . . . . . . . 168 Vision . . . . . . . . . . . . . . . . . . . . . . . 147, 153

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net