Livre blanc

Gestion de configuration IT Mettre en uvre une CMDB

(Configuration Management Database)

Arnaud Bonneville Edition 4, Novembre 2011

Table des matires

1 2 3 4 4.1 4.2 4.3 4.4 5 5.1 5.2 5.3 5.4 5.5 5.6 6 7 8 Rsum .................................................................................................................................................................... 3 Dfinitions ................................................................................................................................................................. 4 De la gestion dinventaires la CMDB .................................................................................................................... 8 Avant la mise en uvre ........................................................................................................................................... 9 Pourquoi mettre en place une CMDB ? ............................................................................................................... 9 Recensement de lexistant ................................................................................................................................. 10 Dfinition dun modle cible ............................................................................................................................... 11 Dfinition dun plan dimplmentation ................................................................................................................ 13 Lapproche processus ............................................................................................................................................ 14 Les acteurs de la gestion de configuration ........................................................................................................ 14 Planification ........................................................................................................................................................ 15 Identification et nommage .................................................................................................................................. 15 Contrle et maintenance .................................................................................................................................... 17 Vrification et audit ............................................................................................................................................ 17 Production de rapports....................................................................................................................................... 18 Conseils dimplmentation ..................................................................................................................................... 19 A propos de Baccou Bonneville Consultants ......................................................................................................... 20 A propos de lauteur ............................................................................................................................................... 21

Page 2 / 21

www.baccoubonneville.com

1 Rsum
La mise en uvre dans une entreprise dune base de donnes de gestion de configuration, ou CMDB, associe aux processus de gestion de configuration et de gestion des changements, est une tape primordiale permettant au service informatique damliorer la qualit de service fournie aux utilisateurs tout en augmentant son efficacit. Cette dmarche, dcrite dans les bonnes pratiques dIT Service Management (ITIL), ne peut tre effectue sans avoir pralablement bien dfini les principaux objectifs de cette CMDB : analyse dimpact, respect des rgulations Sarbanes-Oxley, amlioration de lefficacit oprationnelle, etc. La mise en place dune CMDB part rarement de zro ; souvent le service informatique dispose dj de bases dinventaires qui dcrivent linfrastructure informatique (serveurs, quipements rseau, applications). Lenjeu de la CMDB est de fdrer tous ces rfrentiels et de relier leurs informations travers un rseau de relations. A travers une tude pralable consistant recenser toutes ces informations, vous serez en mesure de dfinir les informations utiles pour lensemble du service informatique, puis en dduire un modle de donnes cible qui servira de fil conducteur limplmentation de la CMDB. Ce modle cible ne pourra pas tre ralis en une seule tape, vous devrez dfinir une squence dimplantation en respectant les objectifs fixs par la DSI. Pour construire une CMDB, ce nest de loin pas quune question doutils et dinventaires. La russite dun projet de gestion de configuration est conditionne par la mise en place dun processus effectif de gestion de configuration, dont les quatre activits identification et nommage, contrle et maintenance, vrification et audit et production de rapports sont les garants dune CMDB matrise dans le temps. Lorganisation est galement fondamentale. Centre autour dun Responsable de la Gestion de Configuration (Configuration Manager), dun Propritaire du Processus (Process Owner) et de Responsables des CI (CI Owners), cest elle qui aura la charge de sassurer que le contenu de la CMDB sera toujours en phase avec la ralit. Ce livre blanc dtaille les rflexions mener avant de lancer un projet de mise en uvre dune CMDB, aborde les problmatiques dorganisation et de processus, et contient des conseils dimplmentation.

Page 3 / 21

www.baccoubonneville.com

2 Dfinitions
Terme / Acronyme ITIL Information Technology Infrastructure Library Dfinition Constitu d'une srie de modules, ITIL dfinit l'ensemble des processus ncessaires pour la prestation de services informatiques et fournit des rgles de bonnes pratiques. Cr il y a plus de dix ans en Grande-Bretagne, ITIL est devenu de facto le standard international et fait partie du domaine public. Il est indpendant de la technologie et des fournisseurs, applicable tout type d'entreprise. ITIL a vocation dtablir un vocabulaire commun lensemble des acteurs de lindustrie informatique, tout en proposant une dmarche standard de mise en uvre des services informatiques des organisations. ITIL est constitu de deux ensembles principaux de processus : Processus de soutien la fourniture de services informatiques (IT Service Support) Processus de fourniture de services informatiques (IT Service Delivery). Parmi les processus de Service Support, vocation oprationnelle, on retrouve les processus de Gestion dIncidents, de Gestion de Changements, de Gestion de Configuration, de Gestion des Problmes et de Gestion des Versions. Au sein des processus de Service Delivery, vocation stratgique, on trouve les processus de Gestion de Capacit, Gestion de Disponibilit, Gestion de Continuit, Gestion des Niveaux de Services ou Gestion Financire des Services Informatiques. Gestion de Configuration Cest lun des six processus ITIL de Service Support. On considre la gestion de configuration comme le processus au cur de lefficacit dun service informatique. Elle a pour vocation de mettre disposition de tous les autres processus oprationnels et stratgiques une base de donnes, la CMDB, qui contient une description des composants de linfrastructure et de leurs relations. Le processus de gestion de configuration est compos de cinq activits principales : planification, identification et nommage, contrle et maintenance, vrification et audit, production de rapports. Contrairement aux autres processus de service support qui sont plus linaires, linstar de la gestion des incidents o chaque incident suit un parcours dtermin, la gestion de configuration est un processus cyclique, qui sinscrit dans des dmarches damlioration de la qualit utilisant la roue de Deming (PDCA - Plan, Do, Check, Act).

Identification et Nommage Production de Rapports Contrle et Maintenance

Vrification et Audit

La gestion de configuration n'est pas le processus qui dclenche les mises jour de la CMDB cest la gestion des changements qui s'en charge , mais c'est le processus qui met disposition
Page 4 / 21

www.baccoubonneville.com

Terme / Acronyme CMDB Configuration Management Database

Dfinition une CMDB et qui permet de la faire voluer dans le temps. Base de donnes contenant toute linformation pertinente sur les composants de linfrastructure informatique utiliss par lorganisation, ainsi que les relations entre ces composants. Chaque composant est rfrenc en tant que Configuration Item (CI). Quelques exemples de CI : un serveur, une application mtier, un routeur, une baie de disques, etc. Alimente et mise jour travers le processus de gestion des changements, la CMDB est utilise par un grand nombre de processus oprationnels ou stratgiques, tels que la gestion des incidents ou la gestion de capacit. Un grand nombre dditeurs de logiciels ont inclus une CMDB dans leur offre, mais le Gartner a rcemment dfini quatre fonctionnalits indispensables pour rellement parler de CMDB : Rconciliation Mapping et visualisation graphique Fdration Synchronisation La rconciliation est une fonctionnalit fondamentale qui permet de confronter les donnes de la CMDB avec dautres sources de donnes, tels que des outils dinventaire automatique. Les mcanismes de rconciliation permettent de raccrocher un CI avec des donnes provenant dautres outils, des fins daudit de la CMDB ou de rapprochement de sources de donnes htrognes. La visualisation graphique est sans conteste une fonctionnalit essentielle lexploitation des donnes de la CMDB. Dans un contexte o les relations entre CIs prennent toute leur importance, il est important de pouvoir reprsenter les relations sous forme graphique afin de mieux apprhender linfrastructure en vitant de cliquer de manire fastidieuse dun CI lautre pour obtenir une comprhension globale dun systme. Le graphique ci-dessous montre par exemple les relations entre un CI serveur et des CI applicatifs, eux-mmes relis d'autres CI serveurs ou applicatifs.

Page 5 / 21

www.baccoubonneville.com

Terme / Acronyme

Dfinition

La fdration est un concept qui permet de donner la CMDB une notion de base de donnes logique. Grce la fdration, il est inutile de recopier des donnes depuis des bases htrognes dans la CMDB, il suffit dtablir les liens entre les deux bases en identifiant les cls de rconciliation, pour que lutilisateur puisse naviguer dans la CMDB comme si toutes les donnes taient physiquement prsentes dans la mme base de donnes. La synchronisation est enfin le dernier lment important qui permet dchanger de manire rgulire les donnes de rfrence de la CMDB vers dautres applications, qui doivent tre alimentes avec des informations dinventaire pour leurs besoins propres. CI Configuration Item Un CI est un lment unitaire de la CMDB. On dfinit un CI par quatre composantes : Statut Traabilit Attributs Relations Le statut fait rfrence au cycle de vie du CI. Pour un CI matriel, un cycle de vie peut tre : Command, Livr, Install, En production, Arrt, En panne, Mis au rebut. Pour un CI applicatif, un exemple de cycle de vie serait : En production, Arrt, Dmissionn. La traabilit fait rfrence lhistorisation des modifications apportes au CI. Etant donn que la mise jour dun CI est effectue travers le processus de gestion des changements, la traabilit permettra de sassurer que le CI na pas fait lobjet de mises jour non contrles (activit Vrification et Audit du processus de gestion de configuration). Les attributs sont les champs dinformation propres au CI, et qui varient selon la classe de CI. Ainsi, un numro de srie sera propre aux CI de type matriel, alors quun numro de version sera plutt prsent sur des CI de type logiciel. Les relations avec les autres CI font partie intgrante du CI. Une relation a donc une caractristique particulire dappartenir deux CI en mme temps. Les responsables des CI ont donc la charge de veiller ce que leurs CI et toutes leurs relations soient constamment jour. Classe de CI Les CI de mme nature sont groups en classes, chaque classe disposant de caractristiques propres. Tous les CI dune mme classe auront des comportements similaires, comme par exemple le cycle de vie. Quelques classes typiques de CI : Matriel (avec des sous-classes de type Serveur, Equipement Rseau, Baie de disque, Lecteur de bande), Application mtier, Documentation.

Responsable du CI Le Responsable du CI, ou CI owner, est la personne en charge de sassurer de la cohrence dun ou de plusieurs CI dans la CMDB. Ils jouent un rle prpondrant dans les activits de CI owner contrle et maintenance et de vrification et audit. Les Responsables de CI peuvent avoir en charge la tenue jour dune classe de CI, dun primtre gographique ou fonctionnel, ou de toute combinaison de ces lments.

Page 6 / 21

www.baccoubonneville.com

Terme / Acronyme Plan de gestion de configuration Configuration Management Plan

Dfinition Document tabli par le Responsable du Processus de gestion de configuration, en liaison avec le Responsable de la Gestion de Configuration. On retrouve dans ce document les lments suivants : Primtre, objectifs et justifications de la CMDB Plan dimplmentation de la CMDB (issu de lactivit de planification) Modle de donnes (classes de CI, attributs applicables, types de relations, relations autorises/interdites) Rgles de gestion de la CMDB Rles et responsabilits des acteurs Rgles daudit Indicateurs de performance (KPI Key Performance Indicators) Evolutions planifies de la CMDB, en cours ou venir.

Page 7 / 21

www.baccoubonneville.com

3 De la gestion dinventaires la CMDB

La complexit toujours croissante des environnements informatiques et le maillage des applications dans les rseaux dentreprises rendent complexe la comprhension de linfrastructure. Au cours des dix dernires annes, les grandes entreprises ont toutes structur leurs services de support informatique pour accompagner leur dveloppement et ont cr leur help desk. Paralllement ces help desks, elles ont mis en uvre une gestion de parc pour tenir une liste dinventaires jour, que ce soit des inventaires de serveurs ou de postes de travail. Certaines dentre elles ont galement initi des procdures de gestion des changements afin de matriser les changements sur linfrastructure et limiter les impacts des arrts non programms de serveurs, invariablement suivis de nombreux incidents ouverts par les utilisateurs qui ntaient pas au courant. Cest ce moment quest arriv ITIL. Les responsables informatiques ont alors ralis qu linstar de Monsieur Jourdain, ils faisaient de lITIL sans le savoir, du moins en partie. Tout au plus fallait-il remplacer un peu de vocabulaire (Help Desk par Service Desk, Intervention planifie par Changement, etc). Mais il est un domaine pour lequel ITIL apporte un plus par rapport ce que toutes ces entreprises faisaient de manire intuitive, cest la gestion de configuration IT et la CMDB. Les entreprises avaient dj recours la gestion de configuration logicielle en utilisant des outils de contrle de source, mais ITIL a ouvert une formidable extension de la traditionnelle gestion des inventaires de matriel informatiques en y ajoutant une notion cl : la notion de relations. En fait la gestion dinventaires et la gestion de configuration nont pas tout fait les mmes objectifs. La gestion dinventaires traditionnelle permet de : tenir jour un inventaire des quipements physiques, de leur statut et de leur emplacement ; fournir aux services financiers des moyens de contrler leur gestion dimmobilisations ; fournir des mtriques aux services informatiques qui pratiquent la refacturation. La gestion de configuration ne remet pas en cause ces objectifs, mais permet den ajouter : inventorier les composants non physiques de linfrastructure (par exemple les serveurs virtuels, les applications mtiers, les clusters, etc.) ; mais surtout, comprendre les interdpendances entre les composants de linfrastructure. Cette comprhension ouvre des portes un grand nombre dutilisations : analyse de risques, gestion de capacit, gestion des problmes La gestion de configuration nest pas un but en soi, elle doit tre considre comme un pr-requis visant atteindre des objectifs beaucoup plus ambitieux. Cest ce que nous allons dvelopper par la suite dans ce document.

Page 8 / 21

www.baccoubonneville.com

4 Avant la mise en uvre

Dans ce chapitre, nous aborderons les rflexions mener avant de lancer un projet de mise en uvre dune CMDB.

4.1 Pourquoi mettre en place une CMDB ?

La premire question que le responsable de ltude charg de la mise en place dune CMDB devra rsoudre est de dfinir prcisment les objectifs business atteindre une fois la CMDB mise en place. Cette question, si logique quelle soit, est en fait complexe rsoudre, car selon les responsables informatiques, on obtiendra diffrentes rponses : Ainsi, pour un responsable de Help Desk, la CMDB doit permettre damliorer lefficacit des agents en leur donnant le moyen de corrler des incidents ouverts par des utilisateurs sur une application des vnements dtects sur des serveurs. Cette facult danalyse dimpact ractive est fondamentale pour rduire le temps de rsolution des incidents. Pour un responsable de Data Center, la CMDB doit garantir que les changements soient faits de manire contrle, et quil ny a pas dintervention pirate sur des composants de linfrastructure. Pour un responsable financier, la CMDB doit tre un moyen de vrifier que les ressources informatiques sont correctement utilises, par exemple en vrifiant si les contrats de maintenance souscrits pour des serveurs sont en phase avec le niveau de service attendu par lutilisateur de lapplication qui tourne sur ce serveur. Pour un responsable applicatif, la CMDB doit fournir aux oprationnels le moyen de comprendre limpact des changements dun composant de larchitecture sur les applications quil gre. L o la question devient ensuite un casse-tte, cest que toutes les quipes cites ci-dessus seront des acteurs part entire du processus de gestion de configuration, et que pour leur vendre lide de la mise en place dune CMDB, ils doivent pouvoir y trouver un intrt. Cest l quintervient le Directeur Informatique ou le DSI dans la dfinition des objectifs principaux de la mise en place dune CMDB et leur communication tous les dpartements du service informatique. Si lobjectif prioritaire de la CMDB est de permettre lentreprise datteindre les niveaux de conformit attendus par les rgulations SarbanesOxley (SOX), la manire dimplmenter la CMDB et la gestion de configuration seront diffrents par rapport un objectif prioritaire damliorer lanalyse dimpact sur les incidents et changements sur linfrastructure informatique. Le DSI doit donc dfinir, dans la lettre de cadrage du projet, quel est lobjectif prioritaire de la CMDB, pour que tous les acteurs du service informatique lintgrent lors de sa mise en place.

Page 9 / 21

www.baccoubonneville.com

4.2 Recensement de lexistant

Avant la mise en uvre de la CMDB, nous recommandons de mener une phase dtude dopportunit au cours de laquelle on dterminera le modle de donnes cible de la CMDB ainsi que les priorits dimplmentation. Dans une grande entreprise ou administration, il est trs rare que lon parte dune page blanche, et il est parier que chaque dpartement dispose dj de ses propres donnes dinventaire. Cela va du simple fichier Excel une base de donnes labore, voire loutil dadministration qui dispose de son propre inventaire. Il est extrmement important didentifier les inventaires et outils locaux, car ce sont eux qui causeront le plus de problmes lors de la mise en uvre, lorsque la nouvelle CMDB devra devenir une base de rfrence. La premire tape consiste recenser auprs de chaque quipe du service informatique les donnes dont elle dispose, la faon dont ces donnes sont maintenues, et surtout lutilit de ces donnes. Gardez lesprit que lors de cette tape, une analyse exhaustive doit tre mene. Ainsi, partez du principe que tous les dpartements du service informatique grent des donnes qui peuvent avoir vocation se retrouver dans une CMDB ; les dpartements oprationnels (quipes systme, rseau, applicatives, support) sont videmment consulter, mais nomettez pas les fonctions support telles que la finance, la gouvernance IT ou la qualit. Gardez-vous dexclure cette tape certains services, certains outils ou certaines donnes, ne prsumez pas de leur utilit future pour la CMDB. Les questions poser chacun de ces dpartements sont les suivantes (le mieux est de toutes les regrouper dans un formulaire que vous ferez remplir chaque quipe) : Quels sont les outils, bases, fichiers consults/mis jour par lquipe ? Quelles sont les grandes classes d'informations manipules par l'quipe (serveurs, contrats) Vient ensuite l'inventaire proprement dit des informations utilises par lquipe. Pour chaque donne, demander : le nom de la donne la provenance de cette donne l'utilit de cette donne pour l'quipe (vous dcouvrirez que certaines quipes maintiennent des donnes qui ne leur servent rien, et ne servent personne d'autre !) le processus de mise jour de la donne. Pour cet inventaire de donnes, proposez vos interlocuteurs de vous fournir un export de leurs bases, en complment du remplissage du formulaire, afin que vous puissiez dterminer le type de donnes, leur fiabilit et taux de remplissage.

Page 10 / 21

www.baccoubonneville.com

4.3 Dfinition dun modle cible

Sur la base des retours que vous obtiendrez, il vous sera possible de construire un dictionnaire des donnes consolid, dans lequel vous rfrencerez chaque donne que vous avez obtenue, les quipes qui en disposent, la source de linformation, la manire dont la donne est obtenue (remonte automatique ou processus manuel).

Information

Type

Nom de la relation

Cardinalit

Mise jour Nombre de auto fois possible ? demand CI No No Yes Yes No No No No Yes Yes No No No No No No CI No No No No 10 10 10 5 5 3 6 9 7 9 6 5 5 3 5 5 1 8 8 1 2 1

Dept 1

Dept 2

Dept 3

HARDWARE ASSET CI Inventory Number Attribut Serial Number Attribut Software configuration (OS, Service Pack) Attribut Hardware configuration (Cpu, Ram, Disk) Attribut Purchase cost Attribut Location on site (office, room #) Attribut Product (brand, model, reference) Attribut Location Relation Software, patch installations Relation Changes, Incidents Relation Maintenance Contract Relation SLA Relation Config/Monitoring tools Relation Administrators Relation Documentation items (incl. monitoring instr.) Relation Activity/Destination Relation SOLUTION CI Name Attribut Usage Attribut Environment (preprod, prod, simu) Attribut Status (development, production, decommissionned, stopped) Status

Located in Contains Concerned by Covered by Ruled by Managed with Administrated by Documented with Asset usage

(1) - (0,n) (0,n) - (0,n) (0,n) - (0,1) (0,1) - (0,n) (0,1) - (0,n) (0,n) - (0,n) (0,n) - (0,n) (0,n) - (0,n) (0,n) - (0,n)

CI CI CI X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

CI X X X X X X X X X

CI CI CI CI X X X X X X X

Une fois le travail ralis avec lensemble des retours du service informatique, vous serez alors en mesure de fournir une premire version de la modlisation de la CMDB. Lapproche adopter pour cette modlisation est une approche objet - une approche de type Merise peut aussi convenir mais lapproche objet est celle utilise par la plupart des CMDB aujourdhui -. A partir des donnes recenses (1), regroupez-les par thme homogne (2) et supprimez les doublons en construisant des classes parentes (3), afin dlaborer progressivement vos futures classes de CI (4). Le petit exemple suivant illustre ce travail de modlisation.
Dictionnaire de donnes Numro de srie du serveur Marque du serveur Modle du serveur Date de fin de garantie du serveur Numro de srie du routeur Marque du serveur du routeur Modle du routeur Numro du port du routeur Connexions entre ports du routeur Nom de l'application SLA de l'application Serveurs utiles pour l'application

SERVEUR N srie Marque Modle Fin garantie

ROUTEUR N srie Marque Modle

PORT N port Routeur Connexions APPLICATION Nom SLA Serveurs

MATERIEL N srie Marque Modle SERVEUR:matriel Fin garantie ROUTEUR:matriel

PORT N port Routeur Connexions APPLICATION Nom SLA Serveurs

MATERIEL

SERVEUR (n-n) APPLICATION

ROUTEUR (0-n) PORT (n-n)

Page 11 / 21

www.baccoubonneville.com

Dept 4 X

En ce qui concerne les attributs retenir dans chacune des classes de CI, il nest pas conseill de reprendre toutes les donnes recenses par chacun des services. Le conseil que nous vous donnons est de positionner une donne comme attribut candidat ds lors que cette donne est utilise au moins par deux dpartements du service informatique. Nous avons ainsi eu lexemple dune quipe systme qui recensait linventaire complet de la configuration matrielle des serveurs (cartes, disques, barrettes mmoires et slots de connexion), en utilisant des outils dinventaires automatiques. Par la suite nous avons vu que la plupart de ces donnes ne servaient qu cette quipe systme, et avons prfr ne pas inclure ces attributs qui alourdiraient la CMDB sans pour autant fournir une valeur ajoute pour lorganisation. Lors de la construction du modle cible, demandez-vous galement quel sera leffort fournir pour maintenir les donnes dans la CMDB. En reprenant lexemple ci-dessus, nous avons fait apparatre la notion de port, ce qui signifie que chaque port de routeur sera gr comme un CI. Un routeur 48 ports gnrera donc 49 Cis et 48 relations, rien que pour dcrire un seul routeur ! Il est plus vraisemblable que face ce choix, on prfrera simplifier la description de la CMDB en ajoutant un attribut nombre de ports au CI routeur, et en positionnant les relations entre routeurs plutt quentre les ports des routeurs, surtout s'il n'y a aucun moyen de rcuprer les donnes de manire automatique. La dtermination de la granularit des CI est un facteur cl de succs essentiel la russite de votre CMDB. Au terme de cette analyse vous aurez dfini les principales classes de CI qui devront tre gres dans votre CMDB, ainsi que les attributs et relations possibles pour chacune de ces classes.

Ce modle de donnes cible est confronter au modle propos par la plateforme d'IT Service Management que vous aurez choisie (ou que vous utilisez peut-tre dj). La plupart des solutions (BMC Remedy, HP ServiceCenter, CA UniCenter Service Desk) proposent en effet un modle prdfini de CMDB. Vous devrez peut-tre effectuer quelques ajustements pour que le modle dfinitif soit compatible avec la philosophie de la CMDB de votre solution d'ITSM.

Page 12 / 21

www.baccoubonneville.com

4.4 Dfinition dun plan dimplmentation

Dans ce chapitre, nous aborderons les rflexions mener avant de lancer un projet de mise en uvre dune CMDB. Une fois le modle de donnes cible dfini, toute la question sera de se demander par quoi il faut commencer ! En fonction des priorits et objectifs fournis par la DSI, vous ne serez peut-tre pas en mesure de dmarrer l'implmentation de toutes les classes de CI et les relations en une seule phase. Lordre dimplmentation doit galement permettre de rpondre le plus rapidement possible aux objectifs de la DSI. Ici comme pour beaucoup dautres projets, on devra tablir les quick wins qui permettront de rendre la CMDB efficace le plus rapidement possible. Voici quelques conseils de bon sens pour dterminer l'ordre d'implmentation des informations de votre CMDB : Avant de pouvoir crer des relations entre deux CI, les deux CI doivent exister ! Il est donc ncessaire de commencer par un inventaire des principales classes de CI "physiques" (serveurs, baies de disques, quipements rseau). Votre socit dispose certainement dj d'inventaires d'quipements informatiques, il s'agira donc de rcuprer ces inventaires, de les reformater pour les rendre compatibles avec le modle de donnes que vous avez dfini, peut-tre de lancer des campagnes d'inventaires physiques pour construire ou remettre jour cette liste. Une fois les classes de base dans la CMDB, on pourra alors commencer travailler sur les classes "non physiques" et les relier par des relations des CI physiques. Par exemple, les serveurs virtuels ou logiques (clusters) ne peuvent tre documents qu'une fois leurs nuds physiques connus. La dfinition des classes suivantes dpendra ensuite des priorits fixes par la DSI : description des applications et de leurs relations, description de la topologie du rseau, description des interfaces, etc. Le plan dimplmentation fera lobjet dune documentation spcifique que lon trouve dans le plan de gestion de configuration (Configuration Management Plan). Il indiquera les phases successives mettre en uvre pour que le modle cible de la CMDB soit atteint.

Page 13 / 21

www.baccoubonneville.com

5 Lapproche processus
La mise en uvre dune CMDB ne se rsume pas un travail de modlisation de donnes et dimports dans une base de donnes. La dfinition des processus lis la CMDB est un facteur cl de succs essentiel pour la russite dun projet de CMDB. A linstar de tout inventaire, la CMDB naura de valeur que si elle reflte une image la plus fidle de la ralit. Pour cela, vous devez pouvoir garantir que tout changement sur linfrastructure sera reflt par une mise jour de la CMDB ; cette fin, votre projet de mise en uvre doit laborer les processus cls de maintien de la CMDB.

5.1 Les acteurs de la gestion de configuration

Avant dentrer dans le dtail des cinq activits de gestion de configuration, attardons-nous sur les principaux rles qui entrent en uvre dans un projet de CMDB. Nous avons identifi trois rles-cls dans la conduite du processus de gestion de configuration. Le Chef de Projet aura un rle prpondrant dans la mise en uvre initiale de la CMDB. Il participe toutes les phases de mise en uvre initiale dune CMDB, de la dfinition de objectifs de la CMDB en passant par le recensement des donnes, la dfinition du modle cible, des processus et de lorganisation requis pour la gestion de configuration. Le succs dun projet de mise en place dune CMDB sera conditionn par une quipe projet efficace, communicante et ayant le soutien de la DSI. Le Propritaire du Processus (Process Owner) sera en charge de dfinir et de tenir jour le Plan de Gestion de Configuration, en ligne avec les objectifs fixs par le DSI. Il na pas un rle oprationnel mais un rle stratgique. Le Responsable de Gestion de Configuration (Configuration Manager) sera le chef dorchestre de la gestion de configuration et de la CMDB, le Gardien du Temple . Il devra veiller la bonne excution du Plan de Gestion de Configuration. Ayant un rle oprationnel, il sera responsable des tches suivantes : Dfinition et mise jour du modle de donnes (classes de CI, attributs, types de relations) Participation aux actions de peuplement initial de la CMDB Formation des acteurs Contrle de cohrence de la CMDB Production de rapports Dtection danomalies et contrle de leur correction. Le Responsable du CI (CI Owner) est la personne qui veille ce que les donnes relatives aux CI quil gre soient toujours correctes dans la CMDB. Faisant partie dune quipe oprationnelle (administrateur systme, responsable applicatif), le Responsable du CI est la personne qui se porte garant de la justesse de la CMDB pour la partie qui le concerne. En fonction des organisations, la mise jour de la CMDB sera effectue soit par ses soins (modle dcentralis), soit par une quipe centrale sur la base des indications que le responsable du CI fournira travers les changements (modle centralis). Dans une CMDB, il est important de toujours savoir qui est le Responsable dun CI afin que lorganisation informatique sache vers qui se tourner en cas de question ou de problme. La rpartition des Responsables de CI peut tre : Technique : on affectera les Responsables de CI par dcoupage technique : Serveurs Unix, Routeurs, Applications SAP Gographique : on affectera les Responsables de CI par localisation, pays ou continent Mixte : en utilisant une combinaison des deux premiers critres.
Page 14 / 21

www.baccoubonneville.com

5.2 Planification
Lactivit de planification constitue lapproche stratgique de la mise en uvre dune CMDB. Elle sous-tend bien entendu la dfinition du plan projet, mais cette activit vocation perdurer aprs le projet initial de mise en uvre. Comme nous lavons dj voqu, le Responsable du Processus a vocation maintenir le Plan de Gestion de Configuration, comportant notamment le phasage des volutions apporter la CMDB. Si le projet initial est fondamental, une certaine forme dactivit projet perdurera pour les volutions ultrieures. En effet, il ne suffit pas de dcider de lancer un inventaire pour ajouter une classe de CI, encore faut-il disposer des ressources et du budget pour tendre la CMDB. A ce titre, il conviendra pour les phases successives de les grer en mode projet.

5.3 Identification et nommage

Le processus dIdentification et Nommage est la partie correspondant justement au mode projet dcrit ci-dessus. Une fois que les processus et rles sont dfinis, il faut implmenter la premire phase de la CMDB, puis procder aux extensions lors de phases ultrieures. Pour toutes ces phases, le processus suivre sera toujours le mme : Analyse du besoin : le Responsable du Processus et le Responsable de la Gestion de Configuration doivent en premier lieu analyser la demande dvolution qui est faite. Cette demande peut tre trs simple (par exemple ajout dun attribut une classe de CI existante) ou beaucoup plus complexe (ajout de classes de CI et de relations). Cette analyse doit valuer les lments suivants : Pertinence du besoin : ce besoin exprim a-t-il une justification par rapport aux objectifs de cadrage de la DSI ? Peut-il servir lamlioration de la comprhension de linfrastructure par lorganisation ? Complexit de mise en uvre : ce besoin est-il facilement ralisable ? (donnes disponibles ou ncessitant un inventaire, implication des quipes concernes dans la gestion de configuration, rpartition gographique, etc.) Cot dimplmentation : toute volution de la CMDB est considrer comme un projet, il sagit donc dvaluer le cot de lopration, et ventuellement de confronter ce cot des possibilits dconomies ou de gains pour prouver sa justification business. Dfinition et validation des volutions du modle de donnes : une fois le besoin justifi, le Responsable de Gestion de Configuration sera charg de dfinir comment ce besoin se traduira dans la CMDB. Pour chaque nouvelle donne ou classe de CI ajouter, il faudra dfinir : Le nom et le type de la donne Sa charte de nommage La liste de valeurs possibles (pour des listes fermes) Son caractre facultatif ou obligatoire Les contraintes particulires associes la donne. Lancement du projet dimplmentation : une fois les volutions du modle de donnes valides, le projet dimplmentation devra assurer les tches suivantes : Mise en place initiale de la CMDB, ou modification de la CMDB existante en cas dvolution du modle Collecte des donnes initiales (rcupration de listes existantes ou projet complet dinventaire) Peuplement de la CMDB Mise en place de rapports spcifiques le cas chant Mise en place dinterfaces dchange de donnes spcifiques le cas chant Formation des acteurs sur les modifications de la CMDB Mise jour du Plan de Gestion de Configuration

Page 15 / 21

www.baccoubonneville.com

Au terme de cette phase didentification et nommage, la CMDB ou son volution est en production. Ce sont les activits de contrle et maintenance, vrification et audit et production de rapports qui prennent le relais.

Page 16 / 21

www.baccoubonneville.com

5.4 Contrle et maintenance

Cette activit est la cl de vote du maintien jour de la CMDB. Si vous chouez dans la mise en place de cette activit, votre CMDB perdra trs vite de la valeur, et la photo quelle prsentera ne sera plus en phase avec la ralit. Comme nous lavons dj voqu, cest cet endroit que la gestion de configuration sinterface avec la gestion des changements. Lactivit contrle et maintenance vise sassurer que toute mise jour de la CMDB est faite de manire contrle, en dautres termes quil y a une demande de changement (RFC) associe cette mise jour. En fonction des outils disponibles et de votre stratgie de mise jour de la CMDB, deux approches sont possibles : La mise jour de la CMDB constitue une tche part entire du changement, et elle est faite manuellement par le Responsable du CI ou une quipe centrale, selon le modle choisi (centralis ou dcentralis) La mise jour de la CMDB est faite de manire automatique grce des outils dinventaire et des mthodes de rconciliation. Dans ce cas, il y a tout de mme une tche dans le changement pour sassurer que la remonte automatique sest bien droule. Il est noter que certains attributs ou relations ne pourront jamais tre remonts de manire automatique, car ce ne sont pas ncessairement des donnes techniques (par exemple, une relation entre un CI et un contrat de maintenance). Lapproche retenue sera donc en gnral mixte : remontes dinventaire contrles pour des attributs ou relations techniques, mise jour manuelle pour des attributs non techniques ou jugs trop critiques pour tre mis jour automatiquement. Quoi quil en soit, si vous optez pour des mises jour automatiques ou des mises jour manuelles, vous devrez pouvoir dtecter dans la CMDB les fameuses mises jour de CI non contrles, par exemple en produisant un rapport sur les CI mis jour alors quaucun ticket de changement ne leur tait associ. Ce qui constitue une trs bonne transition pour lactivit suivante.

5.5 Vrification et audit

Parmi les tches les plus importantes du Responsable de la Gestion de Configuration, la vrification et laudit ont leur place de choix. Sans ces activits, il serait difficile de contrler la pertinence de la CMDB dans le temps, et de garantir aux acteurs de lorganisation informatique que cette base de rfrence est en phase avec la ralit. Pour ce faire, plusieurs outils sont la disposition du Responsable de la Gestion de Configuration : Dtection danomalies par les autres processus : les processus de gestion des incidents, de gestion des changements, de gestion des problmes font tous appel la CMDB un moment donn. Lors de cette consultation de la base, lagent du service informatique peut dtecter une incohrence dans la CMDB. Il lui appartient alors de la faire connatre, par exemple en ouvrant une demande de changement pour remettre jour la base de donnes. Production de rapports danomalies : une fois la CMDB en place, on peut imaginer un nombre important de rapports permettant de dtecter des anomalies. Par exemple, en listant les serveurs qui ne font jamais lobjet de demande de changement, ou en affichant les CI en statut arrt/retir, mais toujours relis un autre CI, ou encore en listant les CI qui ne sont pas affects un responsable de CI.

Page 17 / 21

www.baccoubonneville.com

Quelle que soit la mthode de dtection de lanomalie, le travail raliser par la suite est toujours le mme : Comprendre lorigine de lanomalie et en informer lauteur Ouvrir une demande de changement pour remettre jour la base par rapport la ralit Documenter les bonnes pratiques et conseils pour que ce problme ne survienne plus.

5.6 Production de rapports

La dernire activit du processus de Gestion de Configuration est affecte au Responsable de la Gestion de Configuration. Elle consiste mettre disposition de lorganisation informatique des rapports ou des extractions de la CMDB, pour diffrents usages. Cette mise disposition peut prendre plusieurs formes : Cration et envoi rgulier ou ponctuel dun rapport suite une demande dune quipe du service informatique Mise disposition doutils permettant aux utilisateurs deffectuer leurs propres requtes sur la base Cration dinterfaces pour synchroniser le contenu de la CMDB avec dautres rfrentiels. Nous insistons particulirement sur le dernier point. En effet, lun des cueils franchir lors de la mise en place dune CMDB est de susciter ladhsion des quipes oprationnelles. Souvent, celles-ci utilisent dj leur propre base dinventaire ou outil dadministration. Comme il nest pas possible de supprimer tous ces outils ou bases qui rpondent des besoins spcifiques, nous recommandons fortement de les coupler la CMDB travers des mcanismes de synchronisation. La CMDB doit toujours tre considre comme la base de rfrence, depuis laquelle les autres outils vont pouvoir remettre jour leur rfrentiel de donnes de manire rgulire.

Page 18 / 21

www.baccoubonneville.com

6 Conseils dimplmentation
Pour terminer ce livre blanc nous souhaitons vous faire partager quelques conseils tirs de notre exprience dimplmentation du processus de gestion de configuration et dune CMDB. Obtenez un sponsor fort auprs du DSI. Si lintrt de la mise en uvre de la CMDB nest plus peru par la direction informatique, il le sera dautant moins par les oprationnels. La direction informatique doit offrir son support la mise en uvre dune gestion de configuration, au risque de perdre beaucoup de temps lors de limplmentation, voire de mener le projet lchec. Sachez pourquoi vous mettez en uvre une CMDB. Nous ne le rpterons pas assez, la dfinition des objectifs atteindre est fondamentale pour savoir comment construire sa CMDB et quelles priorits de mise en uvre dfinir. Mettez en place lorganisation oprationnelle au plus tt dans votre projet (Propritaire du Processus, Responsable de la Gestion de Configuration), pour que ces nouveaux acteurs puissent travailler la mise en uvre initiale et prendre le relais efficacement par la suite pour les oprations dextension de la CMDB. Soyez modeste dans la dfinition du modle cible et limitez le nombre dattributs. Positionnez les attributs absolument indispensables au fonctionnement des autres processus de service support, et vitez les attributs qui ne servent qu peu de personnes. Recherchez les quick wins . En mettant en place des briques qui apporteront vite de laide aux acteurs du service informatique, vous susciterez plus facilement ladhsion des troupes. Connectez votre CMDB aux autres outils oprationnels, pour lui donner un caractre de rfrentiel unique de lentreprise et garantir sa mise jour par lensemble des acteurs. Ne laissez pas votre CMDB isole ! Dans chaque service, appuyez-vous sur les personnes qui ont mis en place, dvelopp ou qui administrent les outils locaux, notamment lors des phases de validation du modle de donnes et de collecte des inventaires. Ils joueront un rle de prescripteur au sein de leur quipe. Vendez votre CMDB aux quipes du service informatique. Faites-le avant la mise en uvre, une fois le modle cible dfini, pour prsenter votre plan de mise en place, mais galement en cours de mise en place et en fin de mise en uvre. La communication projet autour de la CMDB, de la gestion de configuration et de leur apport pour le service informatique est importante pour obtenir une bonne implication des quipes. Une fois la CMDB initiale en place, adoptez la dmarche des petits pas . En amliorant petit petit votre CMDB et en communiquant rgulirement sur les nouveauts, vous viterez un effet tunnel entre deux volutions majeures et maintiendrez un niveau dinformation rgulier sur lavancement de la CMDB.

Page 19 / 21

www.baccoubonneville.com

7 A propos de Baccou Bonneville Consultants

Baccou Bonneville Consultants est un cabinet de conseil indpendant ddi aux directions informatiques des grandes entreprises et administrations. Lentreprise a t cre en 1995 par Serge Baccou et Arnaud Bonneville. Base Paris, la socit intervient en France et ltranger. Nos consultants sont spcialiss dans les quatre domaines suivants : Continuit Informatique Le Conseil sur la Continuit Informatique permet de structurer et renforcer la dmarche de Continuit Informatique en cohrence avec les dernires normes internationales en vigueur. Une telle dmarche inclut notamment lanalyse des impacts en cas de rupture de continuit (Business Impact Analysis), la rdaction des Plans de Secours Informatiques (PSI) et les exercices associs. IT Service Management Baccou Bonneville Consultants propose une gamme de prestations daccompagnement des entreprises dans la transformation de la Direction Informatique en tant que centre de Services informatiques. En structurant les Etudes et la Production informatique pour orienter son action autour de Services, pris en charge de bout en bout travers le cycle de vie propos par ITIL, Baccou Bonneville Consultants propose de vous laccompagner dans la dfinition de vos objectifs et la mise en uvre dune stratgie d'IT Service Management. Direction de Programme Le ple comptences de Baccou Bonneville Consultants propose des profils pour la dfinition et la conduite de grands programmes de transformation. Management de Transition Nos managers de transition rponde un besoin de direction dun dpartement ou dun service informatique, gnralement pour amorcer ou accompagner une phase de changement. Il peut senvisager dans des situations de crise ou dans des situations o il sagit davantage de mener un projet stratgique, de rentabiliser loutil de production ou encore de grer une forte croissance. Le sige de Baccou Bonneville Consultants est situ Paris. La socit intervient en France et ltranger.

Page 20 / 21

www.baccoubonneville.com

8 A propos de lauteur
Arnaud Bonneville est Cogrant et Consultant Principal de Baccou Bonneville Consultants depuis sa cration en aot 1995. Il est certifi ITIL Foundation et PMP (Chef de Projet Professionnel). Responsable de loffre de services IT Service Management et Direction de Programme de Baccou Bonneville Consultants, son parcours professionnel sest enrichi de nombreuses expriences quil met aujourdhui votre disposition. Il est spcialis dans des missions de gestion de projets informatiques et de consulting pour des environnements internationaux complexes.

info@baccoubonneville.com www.baccoubonneville.com SARL au capital de 13.000 75 boulevard Haussmann - 75008 Paris, France Tlphone +33 (0)1 44 01 51 61 RC Paris 402 081 491 SIRET 402 081 491 00050 - NAF 6202A N TVA FR15 402 081 491