Une entreprise compétitive exige aujourd’hui des services aux performances prévisibles et fiables. Leurs bons fonctionnements sont liés à l’état des composants du SI et aux liens qui existent entre eux.

ITIL V3 présente le processus des Actifs et des Configurations ou SACM (Service Asset and Configuration Management) comme socle de base à l’ensemble de tous les autres processus. « Il doit fournir un référentiel contrôlé de l’ensemble des composants nécessaires à la fourniture des services ». Les composants de ce référentiel doivent être identifiés, maintenus et documentés. Les relations entre ces composants doivent être identifiées et gérées pour permettre des analyses d’impact, des analyses de cause et du reporting.

La gestion des actifs et des Configurations s’appuie à la fois sur :

• la CMDB (Configuration Data Base Management) ou base de données logique de gestion des configurations, référentiel qui a pour objectif d’apporter une vue unifiée et avant tout actualisée des ressources informatiques (équipements, logiciels et utilisateurs des applications, …), et qui modélise les relations logiques entre elles pout maitriser les chaines de services.

• le système de gestion de ce référentiel qui intervient au niveau organisationnel et au niveau des différents environnements de travail (développement, tests, recette, production).

C’est la pertinence des informations fournies par la CMDB qui permet de supporter efficacement l’ensemble des processus. ITIL définit la CMDB comme le système opérationnel indispensable à la connaissance et à la maitrise des composants pertinents de ces chaines de services.

Plusieurs projets de CMDB complètes ont été initialisés mais de nombreuses organisations ont échoué dans leur tentative de mise en œuvre. D'autres s'arrêtent dès qu'elles ont obtenu une première amélioration dans la Gestion des Incidents. Les gains potentiels des Gestions des Changements, Mises en production, Disponibilités et Capacités n’ont alors jamais pris corps.

Les raisons de ces arrêts sont liées :

• à la complexité de la réflexion sur le modèle de la CMDB

• aux besoins considérables en ressources pour la maintenir à jour.

• à la nécessité de faire évoluer régulièrement son périmètre en créant de nouveaux services.

• à la maintenance de l’ensemble de ces informations en adéquation avec l’infrastructure toujours changeante d’un SI.

ITIL V3 introduit le concept de « integrated CMDB » ou CMDB fédérée qui accepte maintenant l’idée qu’une entreprise puisse avoir plusieurs CMDB sources. Ce concept de CMDB fédérée apporte une réponse pragmatique aux problématiques et aux enjeux des entreprises, tout en permettant une vision globale de l’ensemble des CMDBs.

De nombreuses dimensions restent à considérer lors de la construction d’une CMDB

• L’intégration et la mise en cohérence des sources d’informations

• Le cycle de vie pour chaque composant (CI)

• L’héritage potentiel entre les CI

• L’accès à l’information (interface utilisateur)

• Le lien potentiel entre chaque CI et l’ensemble des processus

• Les utilisateurs de la CMDB

De nombreux écueils sont à éviter :

• Confusion entre gestion de parc et CMDB

• Omission de la mise en place du processus de gestion des configurations

• Mauvaise identification des acteurs (fournisseurs, clients)

• Mauvaise prise en compte du niveau de maturité des futurs utilisateurs de la CMDB

• Définition d’un niveau de granularité trop fin (augmentation de la complexité)

• Gestion des interfaces d’alimentation trop complexes ou des saisies manuelles trop nombreuses

En général, la mise en œuvre d’une CMDB prend de six mois à deux ans, selon les objectifs fixés par l’entreprise.

La définition des objectifs à atteindre par l’utilisation de la CMDB est essentielle à la réussite du projet, car c’est à partir de ces objectifs que pourront être précisés les éléments de configuration (CI), leurs niveaux de détail, les modes de mise à jour et de contrôle (changement, réconciliation). La définition des types de relations entre les CI est particulièrement liée aux objectifs recherchés.

On peut noter, parmi ces objectifs :

• La maîtrise du périmètre IT : services critiques, à forte volumétrie, impactés par de nombreux changements, La conception de la CMDB ne peut se réaliser en une seule étape. Des projets trop ambitieux ont subi des échecs. Mieux vaut concevoir un modèle plus simple et partir des apports attendus plutôt que des données et obtenir un consensus sur les attentes.

• La connaissance technique de composants et de leurs relations.

• Le support à d’autres processus ITIL définis dans le périmètre du projet. Les informations seront spécifiques selon qu’il s’agit de connaître l’impact d’un incident, d’organiser un changement ou de suivre les coûts, des éléments de configuration. Les types de relations entre les CI seront alors adaptés.

• Le niveau de détail des CI est également lié aux activités et fonctions qui utiliseront les données de la CMDB.

• Dans une vision idéale de la CMDB, toutes les informations devraient être recensées, mais l’expérience et les bonnes pratiques montrent qu’un tel projet doit être développé par étape et qu’en conséquence le dimensionnement à court terme doit s’accompagner d’une vision sur le futur proche et lointain.

Les éditeurs proposent des outils d’extraction et réconciliation de données puissants, mais face au volume important de informations à remonter, il faut opérer des choix.

En conséquence, la mise en œuvre d’une CMDB ne peut se concevoir sans une approche projet cohérente de modélisation des informations nécessaires à la fourniture des services. La modélisation doit tenir compte des objectifs à court et long terme qui sont à l’origine de la définition du modèle de CMDB mais également des capacités de mise à jour de l’ensemble des composants et de leurs relations.

Avant toute mise en œuvre, même si les grands éditeurs proposent des CMDB « clés en main », la modélisation de la CMDB devient une étape obligatoire et permet d’obtenir suffisamment tôt dans le projet le consensus de tous les acteurs sur le contenu cible.

La société ISC (International Software Company) propose le logiciel EGEN/SKD, première solution collaborative de modélisation du marché, qui permet de réduire les risques et les coûts liés à la mise en œuvre d’une CMDB, intégrant à la fois un outil et une méthode.

Le principe de EGEN/SKD consiste à centraliser les attentes des contributeurs, futurs utilisateurs de la CMDB, à les valider et à vérifier automatiquement la cohérence de l’ensemble des besoins pour construire un référentiel répondant aux exigences des processus.

E-GEN/SKD a été conçu en s’appuyant sur des études résultant d’expériences terrain, qui ont analysé les bonnes et les mauvaises pratiques des projets de mise en œuvre de CMDB . EGEN/SKD impose une démarche structurée et industrielle de définition du modèle de la CMDB et trace l’ensemble des informations nécessaires à la maintenance de la CMDB. Une définition précise des rôles de chacun des acteurs du projet, techniques et fonctionnels, garantie une parfaite maîtrise du cycle de modélisation. Les spécifications détaillées de la CMDB cible sont générées et mises à jour automatiquement au fur et à mesure de son évolution dans le temps.

Les étapes de la méthode qui structure EGEN/SKD permettent :

• Une démarche contrôlée de création du modèle (classes, attributs, relations)

• La centralisation assistée des besoins des contributeurs

• La traçabilité de l’ensemble des actions et décisions du projet

• La réduction des coûts de mise en œuvre liés à la génération automatique de la documentation et du code permettant la définition de la structure dans la CMDB cible.

• La réduction des coûts de maintenance de la CMDB, et la sécurisation de la prise en compte des besoins futurs

A ce jour, le logiciel E-GEN/SKD constitue une valeur ajoutée à toutes les solutions de CMDB du marché, et propose en option, des générateurs automatiques pour les CMDB suivantes :

• Atrium, BMC

• CA-CMDB, CA

• u-CMDB, HP