Clud des DSI. Nouvelle Calédonie ITIL. 14 Mars Xavier SEVIN

Transcription

1 Clud des DSI Nouvelle Calédonie ITIL Xavier SEVIN 14 Mars 2007 Tour Le Centre 4ième étage Ducos Nouméa - tel: / fax : x.sevin@ifc-demos.nc

2 2 ITIL : une approche qualité Beaucoup d organisations informatiques sont focalisées en interne sur des problématiques techniques, Aujourd hui, les organisations métiers ont des attentes fortes sur la qualité des services fournis par l informatique et ces attentes évoluent, Le Service Informatique doit se concentrer sur la qualité de service et avoir une approche orientée Clients, c est-à-dire de rendre les services aux coûts appropriés En d autres termes, les Services de l Information doivent être gérés comme une activité métier

3 3 ITIL : une approche qualité ITIL se concentre sur la fourniture de Services de haute qualité en soulignant les relations avec les Clients Le Service Informatique fournit les services qui ont été contractualisés avec les Clients La partie Service Delivery (Fourniture des Services) est partiellement concernée par la mise en place d accords avec les Clients et par le suivi des objectifs définis dans ces accords Les processus du Service Support (Soutien des Services) peuvent être vus comme apportant une réponse aux changements et aux dysfonctionnements des services définis dans ces accords.

4 4 Diagramme du «Code des Meilleures Pratiques dans la Gestion des Services des Systèmes d Informations»

5 5 La genèse d ITIL Définir une méthode pour recenser et cataloguer les meilleures pratiques en matière de gestion de Production Informatique Il s agit d une «méthode» : ensemble de procédés (pratiques) Parler avec le même vocabulaire et des mêmes process quel que soit le service informatique

6 6 ITIL : une collection de livres IT Infrastructure Library (IT = Information Technology) ITIL recense, synthétise et détaille les meilleures pratiques dans la fourniture de services informatiques

7 7 Le framework

8 8 Gestion des niveaux de service (SLAs)

9 9 Pourquoi une Gestion des Niveaux de Services? Cette gestion (SLM) est indispensable pour permettre à toute organisation des SIs de déterminer le niveau à délivrer pour supporter les métiers de l entreprise d initialiser un suivi pour identifier si les niveaux demandés ont été atteints ou non et, si non, pourquoi Les Accords de Niveaux de Services (SLAs ou Service Level Agreements) définissent des objectifs spécifiques sur lesquels les performances de l organisation des SIs peuvent être jugées.

10 10 But de la Gestion des Niveaux de Services Maintenir et améliorer la qualité de service des SIs à travers un cycle permanent d accords, de suivi et de reporting sur l atteinte des objectifs et sur les actions menées pour éradiquer la mauvaise qualité (support des métiers ou justification des coûts Une meilleure relation entre SIs et services métiers peut être développée à partir de la gestion de ces Accords Périmètre Accords de Niveaux de Service (SLAs) sur tous les services fournis par les Sis Contrats sous-jacents (UCs ou Underpinnings contracts) et Accords de Niveaux Opérationnels (OLAs ou Operational Level Agreements) sur tous les fournisseurs internes et externes

11 11 La Gestion des Niveaux de Service recouvre la préparation, la coordination, la rédaction, la signature, le suivi et le reporting des Accords de Niveaux de Service (SLAs) la revue permanente de l atteinte des objectifs pour s assurer que la qualité de service requise et budgétairement justifiable est maintenue et améliorée progressivement

12 12 Le processus

13 13 Qu est-ce qu un «Service»? Piste à suivre : hiérarchisation des Services service métier (celui vu d un Client) service Infrastructures services réseaux service applicatif etc. Forme initiale du Catalogue : matrice, table ou tableau

14 14 Structuration des Accords de Niveaux de Service (SLA) Plusieurs options : basée sur les Services : Un SLA couvre un Service et tous les Utilisateurs de ce service basée sur les Clients : Accord unique pour un groupe de Clients couvrant tous les services qu ils utilisent. Les Clients préfèrent ce type d Accord car plus simples pour eux et un seul signataire identifié. Dans la réalité, une combinaison des deux types services et clients peut être plus appropriée La définition des moyens de mesure (métrologie) aligner l Accord avec les moyens techniques aligner l Accord avec la perception Clients des Services (Il est nécessaire d avoir une vue complète sur les composants utilisés par un Service) aligner l Accord avec les moyens du Centre de Services prise en compte des Demandes de Changement dans l Accord

15 15 Revue des Contrats sous-jacents (UCs) et Accords des Niveaux Opérationnels (OLAs) La plupart des équipes informatiques dépendent d autres acteurs (internes et externes) pour atteindre leurs objectifs Les contrats sous-jacents doivent être revus en même temps : externes : contrats de sous-traitance internes : Accords de Niveau Opérationnels

16 16 Eléments optionnels communs à tous les Accords Introduction titre et brève description de l Accord signatures dates : début, fin, revue périmètre de l Accord : ce qui est couvert et ce qui est exclu responsabilités du fournisseur de Services et des Clients description des Services couvert Heures de service heures normales de service (et jours) demandes d extension des heures de couverture (combien de temps à l avance) heures et jours spéciaux (jours fériés), calendrier du Service

17 17 Eléments optionnels communs à tous les Accords Disponibilité normalement exprimé en pourcentage sur les heures de service (spécifier la période et la méthode de mesure) A reporter sur les contrats sous-jacents et les Accords de Niveaux Opérationnels (SLOs) Plus facile : définir les périodes d indisponibilité maximale acceptables Fiabilité normalement exprimé comme le nombre maximum de ruptures de service, ou le temps moyen entre les ruptures (MTBF) ou le temps moyen entre incidents systèmes (MTBSI)

18 18 Eléments optionnels communs à tous les Accords Support heures de support (si différent des heures de service) demande d extension des heures de support heures et jours spéciaux (jours fériés) temps maximum de réponse temps maximum de résolution des Incidents (par priorité) Débit Débit, flux, nombre d accès simultanés, etc. normaux (permet de définir quand on passe au dessus de ces limites pour se situer hors Accord) Temps de réponse des transactions Heures pour les traitements batch heures maximales pour fournir les données en entrée heures maximales pour fournir les résultats en sortie

19 19 Eléments optionnels communs à tous les Accords Continuité de service et Sécurité brève description des Plans de Continuité Informatique et quand les déclencher aspects sécurité, notamment les obligations des Utilisateurs (sauvegarde des PCs non gérés par la production, changement régulier des mots de passe) détails des objectifs de performance des Service (fonctionnement en dégradé lors d un Plan de Continuité) Refacturation détail de la périodicité et des formules de calcul Reporting et revue des Services

20 20 Gestion financière Il est nécessaire de mettre en place des processus budgétaires et comptables et parfois un processus de refacturation aux clients.

21 21 Trois processus principaux Budgétisation : processus de prévision et de contrôle des dépenses dans une organisation un cycle périodique de négociation pour définir les budgets (généralement annuel) suivi jour après jour de ces budgets Comptabilité ensemble de processus permettant à la production Informatique de comptabiliser la manière dont sont dépensés les budgets (ventilation par Clients, Service, activité) nécessite de réelles compétences comptables et financières Facturation : ensemble de processus nécessaires pour refacturer aux Clients le coût des Services qu ils utilisent

22 22 Lien entre les trois processus

23 23 Les bénéfices de la gestion financière Les bénéfices des Utilisateurs sont réalisés au travers de Services améliorés résultant d une utilisation efficace des dépenses informatiques La Gestion Financière permet d accrocher le Service Informatique aux métiers de l entreprise: évite les dérives du Service Informatique (ne travaille que sur les besoins Informatiques) évite les tentations des organisations métiers de monter des informatiques parallèles

24 24 Les bénéfices de la gestion financière augmentation de la confiance en mettant en place et en gérant des budgets meilleures informations sur les coûts pour les décisions d investissements informatiques meilleures informations pour déterminer le coût global (Total Cost of Ownership) pour les Services fournis une meilleure utilisation des ressources informatiques dans l entreprise meilleur professionnalisme des équipes au sein de la production informatique

25 25 Gestion de la disponibilité

26 26 Pourquoi? 1. Depuis plusieurs années, l interdépendance entre activités métiers et activités informatiques est parvenue à un point tel que si l informatique s arrête, l entreprise s arrête 3. L activité économique nécessite de plus en plus un fonctionnement 7/7 et 24/24 (mondialisation, commerce électronique, flexibilité, etc.) 5. Les Clients sont de plus en plus «volatils» (un Client ne pouvant pas être satisfait immédiatement en raison de l Indisponibilité d un service passera chez un concurrent) La Disponibilité fait partie de la réputation d une entreprise

27 27 L amélioration de la Disponibilité ne peut seulement débuter que lorsque l on a compris comment les Services des SIs supportent les activités Métiers

28 28 La Gestion de la Disponibilité couvre la définition, l implémentation, la métrologie et la gestion de la Disponibilité de l infrastructure des SIs

29 29 Conception de la disponibilité

30 30 Métrologie de la disponibilité Trois cibles différentes à prendre en considération : 1. l organisation de support informatique 2. la perspective Utilisateurs (fréquence, durée et périmètre impacté) 3. la perspective Métiers (la contribution de la Disponibilité aux fonctions vitales)

31 31 Gestion de la continuité (des services)

32 32 Pourquoi? Lors d une interruption importante des activités (métiers et/ou informatiques), la DSI doit être capable de continuer à fournir un niveau pré-déterminé et accepté de Services pour soutenir les activités métiers critiques Pour ne pas faire perdre d argent aux activités métiers ou, en cas d interruption très importante, pour permettre à l entreprise de survivre

33 33 La continuité de service concerne l entreprise entière Pour l entreprise Plan d urgence (Contingency Planning) ou Gestion de la Continuité Métiers (BCM ou Business Continuity Management) Prévoit tous les scénarios de reprise pour toutes les activités : métiers : Plan de Continuité Métiers (Business Continuity Planning) informatiques : Plan de Gestion de la Continuité des Services (IT Service Continuity Management Planning) Pour la DSI Sous-ensemble des Plans et Gestions Métiers La Disponibilité des Services (Gestion de la Disponibilité) met en place et gère des technologies permettant de diminuer les risques (redondance du matériel, politique de sauvegarde/restauration, etc.). La Gestion de la Continuité des Services s appuie sur la Gestion de la Disponibilité des Services (et d autres processus) et nécessite l implication de la Direction de l entreprise (et tous les niveaux hiérarchiques)

34 34 Le processus de gestion

35 35 Toute l entreprise (voir précédente présentation du club sur le PCA)

36 36 Gestion de la capacité

37 37 La Gestion des Capacités a la responsabilité d assurer que la Capacité de l infrastructure des SIs est en adéquation avec les demandes croissantes des organisations métiers (coût et performance) Le processus comprend : le suivi des performances et débits des Services et des composants de l infrastructure les activités d optimisation (tuning) sur l utilisation des ressources existantes la compréhension des demandes en ressources informatiques et la production de prévisions pour les futures demandes l influence sur les demandes de ressources, peut-être en collaboration avec le processus de Gestion Financière la production d un Plan de Capacités pour assurer la qualité des Services fournis

38 38 Pourquoi? Fournit les données nécessaires pour décider : quels composants remplacer (plus de CPU, d espace disque, de bande passante réseau, etc.) quand les remplacer (pas trop tôt car sur-coût dû à la surcapacité et pas trop tard car problèmes de performance et insatisfaction des Utilisateurs, loupé sur des opportunités métiers) combien cela va coûter (données prévisionnelles financières destinées à l établissement des budgets informatiques)

39 39 Le processus

40 40 Les trois sous-processus Gestion des Capacités Métiers S assurer que les futurs besoins métiers en matière de Services des SIs sont pris en compte, prévus et mis en oeuvre en temps voulu Gestion des Capacités Services S assurer que les performances de tous les Services (tous les Accords de Niveau de Services ou SLAs) sont suivis, mesurés et analysés Gestion des Capacités Ressources S assurer que tous les composants de l infrastructure qui ont des ressources finies sont suivis, mesurés et analysés

41 41 La Gestion des Capacités Métiers Nouveaux besoins et nouvelles opportunités en provenance de différentes sources et pour des raisons diverses : es organisations métiers le processus lui-même Par exemple : évolution matérielle pour prendre un avantage concurrentiel en mettant en place une nouvelle technologie mise en place d une activité de tuning pour résoudre un problème de performance

42 42 La Gestion des Capacités Services S assurer que les performances de tous les Services (tous les accords de Niveau de Services ou SLAs) sont suivis, mesurés et analysés Prend la suite du sous-processus de la Gestion des Capacités Métiers dès que les nouveaux Services sont opérationnels Réactif : sur Incidents ou Problèmes de performance Services Pro-actif : analyse des tendances de performance Services

43 43 La Gestion des Capacités Ressources S assurer que tous les composants de l infrastructure qui ont des ressources finies sont suivis, mesurés et analysés L utilisation des ressources doit être optimale Réactif : sur Incidents ou Problèmes de performance composants Pro-actif : analyse des tendances de performance omposants Veille technologique : être à l écoute des opportunités technologiques (apports et coûts) Robustesse de l infrastructure en liaison avec le processus de Gestion de la Disponibilité

44 44 Activités quotidiennes

45 45 Facteurs critiques de succès prévisions métiers justes connaissance de la stratégie et des prévisions de la DSI compréhension des technologies actuelles et futures capacité de démonstration sur la rentabilité des dépenses proposées interactivité avec les autres processus de Gestion des Services capacité à prévoir et à implémenter la capacité des SIs en alignement avec les besoins métiers

46 46 Centre de services

47 47 Vue d ensemble Point de contact essentiel opérationnel entre Clients, Utilisateurs, équipes production et organisations tierces Point unique entre les différents acteurs Stratégique : probablement la fonction la plus importante dans l organisation Le Centre de Services est la seule composante visible du niveau de service et du professionnalisme d une organisation (perception et satisfaction clients) En interne : représente les intérêts des utilisateurs

48 48 Rôles et responsabilités (très variables selon les organisations) Rôle premier : l enregistrement et le suivi de la vie des incidents qui affectent les services fournis aux utilisateurs et aux Clients. Résolution rapide des Incidents ou escalade vers deuxième et troisième niveau de support pour diagnostic et résolution Point de contact unique : tenir informé l Utilisateur de l état d avancement de la résolution de son Incident et d une éventuelle solution de contournement Transférer à la Gestion des Problèmes (si en dehors des Accords de Niveau de Service)

49 49 Rôles et responsabilités (très variables selon les organisations)

50 50 Vue d ensemble

51 51 Profils En général, le Centre de Services est en première ligne et sous la pression des Utilisateurs (parfois, des demandes déraisonnables à gérer) Rôle ingrat mais aussi peut-être le plus important de la production informatique («c est un challenge») Connaissances techniques en fonction du périmètre En premier : compétences relationnelles des personnes (chaque contact avec un Utilisateur est une opportunité pour améliorer la perception Utilisateurs) Ne pas confondre réactivité (quick fixes) et service professionnel Les Clients et Utilisateurs doivent être assurés qu un incident signalé sera traité de manière professionnelle

52 52 Gestion des incidents

53 53 Objectif principal Restaurer aussi vite que possible le fonctionnement normal des services et minimiser l impact négatif sur les activités métiers et s assurer ainsi que les meilleurs niveaux de qualité de service et de disponibilité sont maintenus. Le «fonctionnement normal des services» s entend ici comme le fonctionnement des services dans les limites des Contrats de Niveaux de Service (SLAs)

54 54 Définition d un incident «tout événement qui ne fait pas partie du fonctionnement standard d un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service.» Exemples : application : non disponible, erreur programme empêchant l Utilisateur de travailler, E/S disques excessifs matériel : système HS, remontée d alerte automatique, sortie imprimante bloquée demandes de services : demande d information, de conseil ou de documentation, oubli d un mot de passe

55 55 Extensions de la définition Demandes pour un nouveau service (ou l extension d un service existant) sont considérées comme des demandes de Changement (RFCs) mais assimilées à des incidents en pratique (traitement identique) et traitées dans le cadre de la Gestion des incidents Remontées d alertes automatiques (espace disque saturé par ex.) : souvent considérées dans l exploitation courante; ces événements sont traités dans le cadre de la gestion des incidents même si le service délivré aux utilisateurs n est pas affecté

56 56 Processus de gestion des incidents

57 57 Actions principales à l enregistrement enregistrement du détail (symptôme, etc.) s il s agit d une Demande de Service, utilisation de la procédure associée l élément de configuration (CMDB) à l origine probable de l incident est associé à la fiche assignation de la priorité adéquate et communication à l utilisateur d un identifiant d incident l incident est évalué et, si possible, la solution est donnée (incident fréquent ou erreur connue) l incident est assigné au support de niveau deux si besoin ou la fiche est complétée et fermée si la solution a été donnée

58 58 Actions principales à la fermeture confirmer la résolution avec l Utilisateur ou l émetteur définir la catégorie de la solution apportée compléter l enregistrement de l Incident fermer l Incident en vérifiant que : les détails de la solution sont clairs et lisibles les codes de refacturation sont renseignés (costcentre) les temps passés sur l incident sont renseignés ceci est indispensable pour éviter les conflits entre équipes de support et clients sur la validité de la fermeture accès restreint à l option de fermeture des Incidents (typiquement le responsable du Centre de Services gère ces accès)

59 59 Incidents et problèmes Un incident est la conséquence d échecs ou d erreurs dans l infrastructure informatique La cause d un incident peut être évidente et peut être éradiquée directement sans investigation complémentaire en : réparation immédiate, solution de contournement, demande de Changement Quand la cause sous-jacente d un Incident n est pas connue, il est nécessaire de définir un problème Un Problème est ainsi le signe d une erreur inconnue dans l infrastructure

60 60 Incidents et problèmes Plusieurs incidents peuvent sembler partager la même origine donnant lieu à la définition d un problème unique Un Problème est indépendant des incidents associés. L analyse du Problème peut continuer même si les incidents ont été résolus et fermés Résolution d un Problème : 1. Identification de l erreur sous-jacente 2. Mise au point d une solution de contournement ou émission d une Demande de Changement. Le Problème devient alors une Erreur Connue.

61 61 Définitions Problème : La cause inconnue d un ou de plusieurs Incidents Erreur connue : Problème diagnostiqué correctement et pour lequel il existe une solution de contournement ou une Demande de Changement a été émise Demande de Changement : Une demande d ajout, de modification, d évolution, de suppression de composant(s) de l infrastructure informatique ou pour tout autre aspect de la Production Informatique

62 62 Gestion des problèmes «L expérience montre que 20% des Problèmes causent 80% des dégradations de services»

63 63 Le processus En sortie En entrée Détails des Incidents de la Gestion des Incidents Détails des Configurations de la base de données de Gestion des Configurations Toute solution de contournement mise en place par la Gestion des Incidents Génération des Erreurs Connues Emission de Demandes de Changement (RFCs) Mise à jour de l enregistrement du Problème (incluant une solution définitive et/ou de contournement) Fermeture de l enregistrement de Problème Réponse sur la correspondance entre Incidents et Problèmes/Erreurs Connues Informations de synthèse

64 64 Le processus

65 65 Gestion des changements «Le meilleur choix pour pallier temporairement aux incidents causés par des erreurs logicielles est de revenir à un état ou une version précédente stable [ ] plutôt que de tenter un changement non préparé et potentiellement dangereux.»

66 66 Objectif Demande de Changement : évaluer les risques de sa mise en oeuvre et la continuité de l activité métier pendant et après cette mise en oeuvre Essentiel pour trouver un équilibre entre la nécessité d un Changement et l impact (négatif) de ce changement Indispensable pour lisser les transitions

67 67 Gestion de projet (études) et Gestion des Changements

68 Périmètre des Changements gérés 68 Matériels Equipements et logiciels réseaux Logiciels système Applications en production Toutes les documentations et procédures relatives à l exploitation, au support et à la maintenance des systèmes de production Pour les applications, les Changements sous la responsabilité des équipes de développement suivront les procédures de Gestion des Changements (travail commun)

69 69 Approbation des Changements Le gestionnaire de Changements fait vivre le processus mais c est le Comité Consultatif des Changements (Change Advisory Board ou CAB) qui est l autorité de décision pour approuver une Demande de Changement (sauf Changement mineur) Le CCC ou C3 est constitué des représentants de la plupart des autres fonctions de l entreprise La Gestion des Configurations doit s assurer que toutes les informations de configuration sont fournies (impacts possibles détectés et présentés correctement)

70 70 Processus En entrée du processus : Demandes de Changement CMDB Dates souhaitées de mise en production des changements En sortie du processus : Dates souhaitées de mise en production des Changement Demandes de Changement Comptes-rendus et actions du CCC (CAB) Rapports sur les activités Gestion des Changements

71 71 Développement des applications et Gestion des changements L homologation est sous le contrôle de la validation fonctionnelle Clients donc il faut s y intégrer La gestion du changement doit être au courant des développements qui sont sous la responsabilité des études Budgets de la Gestion des Changements : la meilleure pratique consiste à ce que les budgets de développement intègrent le coût de la Gestion des Changements (ex.: devis et refacturation)

72 72 Le processus

73 73 Le processus

74 74 La planification et la coordination des implémentations Préconisation forte : l implémentation des Changements doit impérativement se faire en tenant compte des impératifs de calendrier des lignes métiers plutôt que des impératifs de calendrier de la production informatique Constaté régulièrement : des arrêts le weekend pour des Changements majeurs mais des arrêts pour maintenance pendant les heures de service

75 75 La planification et la coordination des implémentations Mise à jour et publication (Intranet) par la Gestion des changements de : Calendrier prévisionnel des Changements (Forward Schedule of Changes ou FSC) Détails de tous les Changements approuvés et leurs dates prévisionnelles d implémentation Prévisions de Disponibilité des Services (Projected Service Availability ou PSA) Détails des Changements concernant le respect des Contrats de Niveaux de Service (Service Level Agreements ou SLAs) et la disponibilité des services concernés

76 76 Gestion des Nouvelles versions (ou Mise en production)

77 77 Objectifs planifier et superviser le Déploiement d un logiciel et du matériel associé élaborer et implémenter les outils de distribution et d installation des Changements s assurer que les matériels et logiciels changés sont traçables, sûrs et que seules les versions correctes, autorisées et testées sont installées communiquer et de gérer les attentes des Clients pendant la planification et le déroulement des déploiements valider le contenu exact d une Distribution et le scénario de Déploiement en liaison avec la Gestion des Changements d installer les nouvelles versions logicielles et les matériels en production en respectant les procédures de la Gestion des Changements et des Configurations de s assurer que les distributions d origine de tous les logiciels sont stockées et sécurisées dans la Bibliothèque des Versions Logicielles Définitives (Definitive Software Library ou DSL) et que la CMDB est mise à jour

78 78 Périmètre planification, conception, élaboration, configuration et homologation des matériels et logiciels pour créer un ensemble de composants destiné à être déployé en production (kit d installation ou de déploiement) planification et préparation du Déploiement d un Changement à un ensemble d Utilisateurs et de sites communication, préparation et formation à un Changement audits matériels et logiciels avant et après l implémentation d un Changement déploiements des Changements mise à jour de la CMDB et de la DSL

79 79 Activités et cycle de vie d un Changement

80 80 Gestion des configurations

81 81 Objectifs rendre compte à l organisation de tous les biens et configurations de la Production Informatique fournir de l information pertinente sur les configurations pour supporter les autres processus fournir des bases solides pour la Gestion des Incidents, des Problèmes, des Changements et des Nouvelles Versions comparer l information stockée à l infrastructure et corriger les différences

82 82 Activités de base Planification : planification et définition du processus, de l organisation et des techniques Identification : Sélectionner et identifier les composants de l infrastructure Contrôle : S assurer que les composants sont modifiés avec les autorisations nécessaires (Demande de Changement) Conservation de l historique : Traçabilité de l évolution d un composant (développement, test, production ou en stock) Vérification et audit : Vérification de l existence physique des composants répertoriés et de la validité des informations

83 83 Identification des Eléments de Configuration Sélectionner, identifier et étiqueter les Eléments de Configuration (CIs ou Configuration Items) avec leurs «propriétaires», leurs relations et leurs documentations pour les intégrer dans la CMDB (Configuration Management DataBase) Décision : niveau de détail à trouver (équilibre entre quantité et facilité de gestion) De plus en plus complexe avec l évolution des technologies : Utilisateurs avec poste de travail accédant à une application financière accédant à une base de données, le tout sur des sites et des systèmes différents Permet une Gestion des Changements efficace par la connaissance rapide de l impact d un Changement sur l infrastructure

84 84 La base de données des Configurations (CMDB) Quelques exemples d interrogation : contenu d une livraison (versions des composants et documentations) composants et versions en environnements de test et de production éléments affectés par un Changement autorisé et planifié toutes les Demandes de Changement pour un élément composants achetés chez un fournisseur durant une période donnée équipements et logiciels sur un site particulier (audit par ex.) les éléments prévus pour être actualisés (upgrades), remplacés ou démontés Changements et Problèmes associés à un élément éléments impactés par un Problème

85 85 La Bibliothèque Logicielle des versions définitives ou Definitive Software Library (DSL) Bibliothèque physique protégée dans laquelle sontstockées les versions définitives et validées de tous les composants applicatifs de la CMDB Peut aussi contenir les kits d installation des logiciels externes (socle technique) Mise à jour strictement contrôlée par la Gestion des Changements et des Nouvelles Versions

86 86 Ou en êtes vous? (Modèle de maturité du Gartner Group)

87 87 L équipe DEMOS vous remercie. Nous restons à votre entière disposition pour enrichir et prendre en compte l ensemble de vos remarques et réactions complémentaires.