cmdb

Club des Responsablesd’Infrastructure et de Production

LiVR

E BL

ANC

Juin 2010

L’OBSERVATOIREdes Directeursd’Infrastructureset de Production

CMDB Enquête et Analyse des Tendances

PAG

E 3

Table matièresdes

EDITORIAL 5

1 CONTEXTE ET DEMARCHE 61.1 LE GROUPE DE TRAVAIL CMDB DU CRiP 6 1.1.1 Responsables du groupe et des sous-groupes 6

1.1.2 Participants au groupe de travail 6

1.1.3 Rédacteur et contributeurs à la rédaction 7

1.2 LA DEMARCHE 8

2. CONSTATS PRINCIPAUX DE L’ENQUETE 92.1 LE CONTEXTE DE L’ENQUETE 92.2 LE PROJET CMDB 10 2.2.1 Éléments généraux 10

2.2.2 Organisation 11

2.2.3 Déroulement 12

2.2.4 Atteintes des objectifs 13

2.2.5 Points clés 14

2.3 LES CHOIX RELATIFS A LA CMDB 15 2.3.1 Outil(s) 15

2.3.2 Processus associé(s) 16

2.3.3 Tableaux de bord et reporting 18

2.3.4 Points clés 19

3. DECISION DE METTRE EN PLACE UNE CMDB 213.1 LA PROBLEMATIQUE ADRESSEE 213.2 LA REPONSE PROPOSEE 223.3 LA DEMARCHE ET MOYENS PRECONISES 243.4 LES RECOMMANDATIONS DU CRIP 27 3.4.1 Les pièges à éviter 27

3.4.2 Quelques suggestions… 27

4. STRUCTURER ET DEFINIR SON MODELE DE CMDB 294.1 LA PROBLEMATIQUE ADRESSÉE 294.2 LA REPONSE PROPOSEE 304.3 LA DEMARCHE ET MOYENS PRECONISES 364.4 LES RECOMMANDATIONS DU CRIP 37 4.4.1 Les pièges à éviter 37

4.4.2 Quelques suggestions… 37

5. CHOISIR SON OUTIL CMDB 395.1 LA PROBLEMATIQUE ADRESSÉE 395.2 LA REPONSE PROPOSEE 40 5.2.1 Les fonctions discriminantes, les questions à se poser 40

5.2.1.1 Démarrage de la démarche projet de sélection 40

5.2.1.2 Les outils intégrés, les outils modulaires 40

5.2.1.3 Terminologie 41

5.2.1.4 Les processus ITIL couverts 41

5.2.1.5 Le méta-modèle 42

5.2.1.6 Fonctions d’édition, de navigation, de requêtage 45

PAG

E 4

5.2.1.7 Analyse d’impact 47

5.2.1.8 Alertes, propagation d’indisponibilité … 47

5.2.1.9 Technologie de base de données 47

5.2.1.12 Définition de rôles, contrôle d’accès 50

5.2.1.13 Les coûts 50

5.2.1.14 Le tableau des solutions du marché 51

5.2.2 Les facteurs d’influence sur la réponse 52

5.2.2.1 Standard CMDB Federation 52

5.2.2.2 Offres SaaS (Software as a Service ou fourniture de logiciels sous forme de services) 52

5.2.2.3 Evolutions des technologies supportées 53

5.3 LA DEMARCHE ET MOYENS PRECONISES 53 5.3.1 Les étapes 53

5.3.2 Les ressources 54

5.4 LES RECOMMANDATIONS DU CRIP 54 5.4.1 Pièges à éviter 54

5.4.2 Quelques Suggestions… 54

6. CONCLUSIONS DE L’ETUDE 556.1 UN SUJET ANCIEN AVEC UN ECLAIRAGE NOUVEAU 556.2 UN OUTIL TACTIQUE 556.3 UN OUTIL FEDERATEUR 566.4 UNE COHERENCE ENTRE OUTIL, PROCESSUS ET ORGANISATION 56

A PROPOS DU CRiP 58

ITIFORUMS, Une relation stratégique et privilégiée avec le CRiP 61

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

5 Li

VRE

BLA

NC

Le groupe de travail CRIP CMDB a vu le jour au cours du second semestre 2008 et a pour objectif de traiter le sujet « CMDB » dont il est tant question aujourd’hui dans les entreprises, chez les consultants et les éditeurs.

Initialement composé de sept personnes, les premières réunions de travail ont surtout consisté à se mettre tous d’accord sur ce que chacun entendait par le terme CMDB, et la mise au point d’une définition et d’une terminologie commune pour adresser ce sujet n’a pas été si simple !

La définition que nous avons retenue de la CMDB est la suivante :

« La CMDB (Configuration Management DataBase) a pour but de rassembler toutes les informations descriptives et opérationnelles des composants gérés du système d’informations, ainsi que des liens entre composants. Dans la pratique d’aujourd’hui, la CMDB s’appuie sur plusieurs outils et/ou bases de données et/ou fichiers. »

Après être parti sur une étude globale du processus de gestion des configurations, nous avons décidé de rester dans le cadre uniquement de l’outil CMDB, même si une démarche CMDB ne peut être dissociée des processus qui vont avec.

Nous avons alors pu mettre en commun nos expériencessur ce sujet afin d’approfondir les sujets à traiter, notamment :

- Le projet CMDB • Point de départ, état des lieux • Sponsoring, positionnement dans la stratégie

de l’entreprise • Le périmètre : quels processus et quels acteurs ? • Etapes du projet

- La CMDB proprement dite • Fonctionnement • Contenu • Outil(s) • Retours d’expérience

Pour traiter ces sujets, nous avons utilisés trois outils :- Le questionnaire CMDB adressé aux sociétés

membres du CRIP, dont nous faisons la restitution dans ce livre blanc

- Des groupes de réflexion, réunis dans un premier temps à raison d’une séance pour le groupe complet tous les mois et demi,

- Fin 2009 et sur tout le premier semestre 2010, la création de trois sous-groupes de réflexion qui se sont réunis indépendamment des réunions à groupe complet

C’est au total pas moins de vingt-cinq réunions qui ont permis de produire ce livre blanc, avec la participation d’une quinzaine de membres actifs !

Nous avons choisi, au regard des premiers retours de l’enquête et des sujets de discussions au sein du groupe d’approfondir pour ce livre blanc trois thèmes, posés sous forme de questions, qui font l’objet chacun d’un chapitre :

- Pourquoi mettre en place une CMDB ?- Comment structurer et modéliser sa CMDB ?- Comment choisir son outil ?

L’approche du groupe de travail est de fournir dans ce livre des réflexions d’opérationnels sur l’implémentation d’une CMDB au sein d’une entreprise. Les points de vue et les conseils proposés viennent tout droit de nos retours d’expérience, dans l’optique de fournir notamment des pistes de réflexion, des pièges à éviter, des modes opératoires, …

Ce livre est le fruit d’une implication très forte des membres du groupe de travail car la rédaction a été réalisée par sept membres du groupe. (Ce que vous sentirez peut être dans le style !). Je tiens également à remercier Lionel Loyer de la société CG2 Conseil pour son éclairage sur certaines problématiques liées à la CMDB.

En espérant que ce livre blanc réponde à vos attentes sur ce sujet « CMDB » et vous soit une aide dans vos projets en cours ou pour l’évolution de la CMDB existante, je vous souhaite une bonne lecture.

Frédérick PAQUETLeader du Groupe de travail CMDB

THALES

Edito rial

PAG

E 6

CONTEXTE ET DEMARCHE

1.1 LE GROUPE DE TRAVAIL CMDB DU CRiP

1.1.1 Responsables du groupe et des sous-groupes

FrédérickPAQUET

JorisDAUMONT

FabriceJOSSERAND

ChristianVILLEMOT

THALES CA CIB La Banque Postale CRiP

1.1.2 Participants au groupe de travail

ADP GSI Jean-Luc GALLO

Allianz Eric CONSTANZO

Crédit Agricole CIB Joris DAUMONT

Crédit Foncier David LEBROCH

Cellfish Media Emmanuel VIENNOT

CRIP Christian VILLEMOT

ESSILOR Anne JAFFRE

Groupe Casino Gilles CORRON

La Banque Postale Fabrice JOSSERAND

La Banque Postale Véronique BARDET

MANPOWER Alain MAJERLHOLC

PSA Peugeot-Citroën Jeannine BAC

PSA Peugeot-Citroën Fabrice COLIN

Société Générale SGCIB Thierry CHAMFRAULT

STIME Mamy ANDRIANARIVONY

THALES Frédérick PAQUET

1

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

7 Li

VRE

BLA

NC

1.1.3 Rédacteur et contributeurs à la rédaction

JeannineBAC

FabriceCOLIN

MamyANDRIANARIVONY

PSA Peugeot-Citroën

PSA Peugeot-Citroën STIME

D’autre part, nous avons pu compter pour le travail de relecture à la participation des personnes suivantes :

- Eric CONSTANZO – Allianz- Emmanuel VIENNOT – Cellfish Media- Anne JAFFRé – Essilor- Alain MAJERHOLC – Manpower- François STEPHAN – Thales

PAG

E 8

1.2 LA DEMARCHE

Dans le cadre de ses groupes de travail, le CRIP procède à des enquêtes internes auprès de ses membres afin de dresser une cartographie de l’existant. La photographie ainsi obtenue permet de mieux cerner les problématiques sur lesquelles les groupes de travail se penchent.

A l’initiative du groupe de travail CMDB, une enquête a été réalisée courant 2009 auprès des membres actifs du CRIP.

Le questionnaire support de l’enquête, présenté aux membres du CRIP lors de la réunion plénière de mars 2009, visait à établir un panorama global des projets de CMDB sur base d’environ 200 questions classées selon quatre axes principaux :

- Le contexte des sociétés ayant un intérêt pour la CMDB ; - L’organisation du projet de CMDB ; - Les résultats du projet de CMDB en termes de structuration,

d’outillage, de processus et de tableaux de bord ; - Le retour d’expérience des sociétés ayant mené un projet de CMDB.

Les premiers résultats du questionnaire, présentés lors de la réunion plénière de juin 2009, ont servi de base de réflexion aux trois sous-groupes de travail.

En parallèle des travaux des trois sous-groupes, les résultats de l’enquête ont été complétés et le groupe de travail s’est étoffé par l’arrivée de nouveaux participants.Nous avons, dans le cadre de nos réflexions, décidé d’aborder le sujet CMDB dans un angle de base contrôlée, principalement en liaison avec les processus de chan-gement et de mise en production.

On peut en effet distinguer deux types de bases de données, celle qui est centrée sur les processus et celle qui est une vue temps réel de la situation.Il s’agit d’une différence très importante qui se répercute dans la démarche de mise en œuvre car nous partons du principe qu’il ne suffit pas d’avoir une information temps réel, il faut également savoir si ce qui nous est remonté est bien ce que nous aurions du avoir.

Amélioration de la disponibilitédes services :

contrôle de la gestion des changements

Amélioration de la réponse aux utilisateurs :Support / gestion des incidents / demandes

Contrôlesen amont

Gestion des demandeset des changements

Gestion des MEPet des configurations

Contrôlesen aval

Contrôle par échantillonage

Inventaire ou analysepar outils

CMDB Informations Contextuelles

Informationsnon contrôlées

Informationscontrôlées

Mise à jour automatique

Identification et analysedes écarts avant mise à jour

Bases de données : informations sur le SI

Source : CG2 Conseil

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

9 Li

VRE

BLA

NC

CONSTATS PRINCIPAUX DE L’ENQUETE

2.1 LE CONTEXTE DE L’ENQUETE

Les entreprises ayant répondu au questionnaire de l’enquête sont de taille impor-tante ou très importante dont la production informatique est très majoritairement répartie sur 2 sites informatiques ou plus :

- Le nombre d’utilisateurs est, pour la moitié du panel de réponses, supé-rieur à 1000, à l’exception d’une entreprise, et pour l’autre moitié, supérieur à 5000 ;

- L’effectif de la DSI est, pour la moitié du panel de réponses, supérieur à 100 personnes, à l’exception d’une entreprise, et pour l’autre moitié, supérieur à 500.

Répartition par nombre de postes de travail

Répartition par nombre de serveurs

2

PAG

E 10

Répartition par nombre d’applications

Les nombres de matériels et d’applications, bien que plus variables sont également représentatifs car les répondants sont issus de grandes sociétés françaises.

Le pourcentage assez modeste de réponse au questionnaire, à savoir environ 35 % des entreprises ayant des membres adhérents au CRIP, s’explique en partie par le fait que la majorité des entreprises ayant répondu :

- Soit ont réalisé un projet de CMDB et envisagent une évolution de leur CMDB,

- Soit prévoient d’en mener un à court terme.

La totalité des entreprises ayant répondu au questionnaire sont engagées dans une démarche ITIL. Il est d’ailleurs significatif de constater que le début en 2001 de la formalisation des projets CMDB et le rythme de croissance du nombre de projets coïncide avec l’émergence et l’essor d’ITIL en France. Cette préoccupation est rela-tivement ancienne puisque pour la majorité des entreprises interrogées, le premier projet CMDB date de plus de 3 ans voire jusqu’à 8 ans.

Ce type de projet, qu’il soit mené de manière indépendante ou dans le cadre d’un programme plus vaste, est généralement mené en parallèle d’une démarche d’alignement sur un ou plusieurs référentiels de bonnes pratiques (ITIL, CMMI, e-SCM, …), et en juxtaposition avec un ou plusieurs projets stratégiques (réorganisation, chan-gements d’infrastructures, évolutions applicatives majeures, …).

2.2 LE PROJET CMDB

2.2.1 éléments généraux

Près de 55 % des répondants déclarent un projet réalisé au sein de leur entreprise, et environ 20 % ont indiqué qu’un projet était prévu. Pour tous les membres le posi-tionnement du projet CMDB dans la stratégie de l’entreprise est considéré comme majeur ou important.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

11

LiVR

E B

LAN

C

Un projet CMDB s’étale typiquement sur 1 à 2 ans et essentiellement perçu comme un projet technique (cf. section 2.2.2 « Organisation »).

Environ 25 % des entreprises ayant répondu ont précisé qu’aucun projet CMDB n’était réalisé ni prévu, principalement du fait de :

- L’absence de besoin avéré ; - Le manque de ressources ou de sponsor pour initier le projet.

2.2.2 Organisation

Dans la majorité des cas le projet CMDB est porté par la Production Informatique, et plus rarement par la DSI.

Si la Production Informatique est impliquée dans la totalité des projets CMDB, il est à noté que la participation des autres entités de l’entreprise est généralement limitée voire quasiment nulle.

Implication des entités

La prépondérance de la Production Informatique et la faible implication des autres entités de l’entreprise traduit la perception du projet CMDB comme un projet essen-tiellement technique.

La participation réduite des équipes des Études surprend de prime abord dans la mesure où les applications sont souvent intégrées dans la CMDB et ce d’autant plus lorsque la possibilité de réaliser des analyses d’impact constitue un des objectifs de la mise en place de la CMDB.

PAG

E 12

Ce constat s’explique essentiellement par le fait que la CMDB reste avant tout associée au référentiel ITIL souvent perçu comme spécifique à la Production Informatique.

A contrario la participation du Contrôle de Gestion apparaît significative, notamment si la CMDB est développé à partir d’une gestion de parc préexistante, et qu’elle a pour objectif de disposer d’informations de volumétries fiables pour des besoins financiers.

Dans le cadre de leur projet CMDB, les entreprises ont généralement recours à des prestations externes auprès de :

- Sociétés de conseil dans plus de 80 % des cas pour des besoins d’assistance à maîtrise d’ouvrage (expertise, assistance, …) ;

- Editeurs dans environ 65 % des cas essentiellement pour des besoins de maîtrise d’œuvre.

Le recours préférentiel à des consultants ITIL plutôt qu’à des spécialistes tech-niques étonne en regard du positionnement essentiellement technique des projets CMDB. Ce choix résulte en partie de la complexité à structurer et formaliser les informations à intégrer dans la CMDB. Mais surtout ces chiffres s’expliquent par l’option d’outillage de type « solution propriétaire », retenue dans plus d’un tiers des cas et supposant une maîtrise technique en interne.

2.2.3 Déroulement

La décision d’initier un projet CMDB est généralement motivée par un constat initial d’insatisfaction globale sur :

- Les sources de données ou référentiels existants ; - Et dans une moindre mesure les outils en place ou les processus de gestion

des données.

Même si la définition de la structure de la CMDB est logiquement positionnée en début de projet, les réponses au questionnaire montrent que le choix de l’outil ou la validation du périmètre sont effectués préalablement dans plus de 2/3 des cas.

Bien que ce constat s’explique par l’existence de référentiels ou de sources d’informations avant le projet CMDB d’une part, et par le souci de prise en compte des limitations et structures des outils retenus d’autre par, ce séquencement pose des difficultés :

- En termes d’évolutivité de la CMDB mise en œuvre : la plupart des entreprises ayant mené un premier projet CMDB ont dû la restructurer en profondeur pour pouvoir intégrer les nouveaux besoins ;

- En termes de charge de maintien à jour et de cohérence des données contenues dans la CMDB : certaines informations sont dupliquées dans différents objets de la CMDB et leurs évolutions au cours du temps finissent par introduire des divergences.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

13

LiVR

E B

LAN

C

Les processus de gestion de la CMDB sont logiquement définis préalablement à la mise en place de l’outil. Ils s’appuient généralement sur le processus ITIL de Gestion des Configurations.

Enfin les résultats de l’enquête marquent une nette préférence pour un chargement et un démarrage progressif de la CMDB, ce qui constitue une bonne pratique pour limiter les effets de jeunesse et garantir la possibilité de corriger d’éventuelles imperfections sans avoir à manipuler des volumétries d’information trop importantes.

2.2.4 Atteintes des objectifs

Dans le questionnaire nous avions demandé dans les premières parties quels étaient les objectifs (parmi une liste définie) attendus de la mise en place de la CMDB, et dans le retour d’expérience, quels étaient les objectifs atteints (toujours avec la même liste).Le graphique ci-dessous représente les proportions de réponses par objectif initial, objectif final et le taux d’atteinte de l’objectif (calculé en fonction du nombre de personnes ayant atteint un objectif initial, et non de personnes ayant atteint un des objectifs listés sans qu’il ne soit initialement prévu).

Ce graphe confirme l’atteinte à près de 90 % du principal objectif attendu d’un projet CMDB à savoir « Disposer d’informations fiables ».

PAG

E 14

En revanche, il révèle une difficulté marquée, taux d’atteinte des objectifs autour de 75 % voire 50 %, pour atteindre des objectifs souvent positionnés comme importants lors du démarrage du projet CMDB à savoir :

- Garantir l’unicité des sources de données, - Supporter les processus ITIL, - Contrôler les modifications faites sur le SI, - Pouvoir réaliser des analyses d’impact (environ 50 %), - Réduire le nombre d’incidents.

L’analyse des objectifs atteints, attendus ou non au démarrage, met en exergue les gains réels d’un projet CMDB. Parmi les 5 objectifs en tête l’objectif « Pouvoir réaliser des analyses d’impact » apparaît à nouveau en retrait avec un taux inférieur à 40%. Outre les principaux objectifs attendus, on peut noter les bénéfices suivants qui excèdent les objectifs attendus :

- Clarifier la responsabilité des référentiels ; - Gérer les actifs financiers.

2.2.5 Points clés

Un projet CMDB ne doit pas se limiter à la Production Informatique ni même à la DSI car certaines des informations de la CMDB peuvent être, et généralement sont, des données d’entreprise (liste et données des utilisateurs, localisations géographiques, …).

Ainsi les membres ayant mené un projet CMDB insistent sur l’importance d’avoir un sponsor d’un niveau hiérarchique adapté et une implication de la Direction. En regard de la durée significative d’un projet CMDB, ils soulignent également l’im-portance de soutenir l’implication des acteurs et de communiquer tout au long du projet.

Les écueils potentiels d’un tel projet remontés par les membres du CRIP concer-nent principalement :

- La justification du projet CMDB au démarrage ; - La difficulté de recueillir les informations pendant le projet ; - La charge d’alimentation initiale de la CMDB lors du démarrage opérationnel ; - Ou encore l’efficience de la mise à jour des données en phase opérationnelle.

Certaines de ces problématiques, et des éléments permettant de les traiter, sont présentés dans les chapitres suivants.

Le dernier point souligne notamment la nécessité de veiller à la cohérence entre l’organisation, les processus et les outils mis en place qui est essentielle à la réus-site d’un projet CMDB.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

15

LiVR

E B

LAN

C

2.3 LES CHOIX RELATIFS A LA CMDB

2.3.1 Outil(s)

Le principal enjeu d’une CMDB est de disposer d’un outil de centralisation et fédérateur pour la DSI.

Entités utilisatrices de la CMDB

Bien qu’il s’agisse d’un outil essentiellement dédié à la DSI, il est intéressant de noter que l’enquête atteste qu’il est également utilisé par le Contrôle de Gestion de plus des trois-quarts des entreprises.

Le rapprochement entre les entités impliquées dans le projet CMDB et les entités utilisatrices de la CMDB semble paradoxal. Par exemple, les Études sont considérées comme des acteurs actifs du projet CMDB dans seulement 25 % des cas alors que cette entité est utilisatrice de la CMDB dans près de 75 % des cas. L’implication plus marquée des Études dans le projet CMDB permettraient de mieux prendre en compte leurs besoins propres et probablement par la même occasion de favoriser l’atteinte des objectifs de capacité d’analyse d’impact et de fiabilisation des opérations de maintenance.

Ce sentiment est renforcé par le retour d’expérience attestant que les outils de CMDB ne sont pas cantonnés aux données des environnements de production et de pré-production mais couvrent également les environnements de qualification, d’intégration et de développement dans environ 75 % des entreprises consultées.

Le contenu de la CMDB est particulier à chaque entreprise car, d’une part il répond à des besoins spécifiques, et d’autre part il est souvent adapté au périmètre de responsabilité de la Production Informatique, principal acteur du projet CMDB.

De façon générale, les principales informations détaillées de la CMDB concernent :

- La cartographie du réseau ; - Les matériels d’informatiques (serveurs, postes de travail, …)

et les systèmes d’exploitation associés ;

PAG

E 16

- Les personnes en relation avec la Production Informatique (utilisateurs des matériels informatiques, acteurs de la DSI, …) ;

- Et la localisation des matériels et des personnes (site, bâtiment, bureau ou salle, …).

Les informations sur les applications techniques (middleware, outils d’exploitation, …) ou sur les applications fonctionnelles (logiciels, applications métiers, …) sont souvent plus macroscopiques.

Au-delà des informations contenues dans la CMDB, les liens entre les composants se révèlent comme essentiel et probablement l’un des premiers intérêts d’une CMDB. A ce titre il est significatif de noter que si des liens sont formalisés dans plus de 90 % des entreprises consultées, ceux-ci sont typés dans environ 80 % des cas.

Ainsi les données sont disponibles dans la CMDB et la possibilité d’analyse des relations entre les différents composants du SI est favorisée par ces liens. Les membres soulignent d’ailleurs l’importance des requêtes et des fonctionnalités d’interrogation.

Pour ce faire, le langage des requêtes est formaté, des fonctions d’interrogation évoluées sont implémentées dans la moitié des cas, et les outils sont très majoritairement pourvus d’un système de navigation graphique.

Concernant le choix de l’outil, l’enquête montre qu’un progiciel du marché a été préféré à une solution propriétaire dans près de 65 % des entreprises consultées.

On note également, avec les retours des groupes de travail, que beaucoup d’entreprises ont commencé à implémenter leur CMDB avec des solutions développées par leurs propres moyens, avant d’étudier le passage sur un progiciel du marché.

Les membres affichent une satisfaction quasi unanime sur les outils choisis et sur leur implémentation.

2.3.2 Processus associé(s)

Comme souligné précédemment, les entreprises ayant réalisé, ou prévoyant de mener un projet CMDB, s’inscrivent aussi dans une démarche ITIL.

De fait, les processus sont formalisés et documentés, dans la plupart des entreprises sous la responsabilité de la Production Informatique.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

17

LiVR

E B

LAN

C

Niveau de dépendance des processus à la CMDB

L’efficacité de la CMDB vis-à-vis du support des processus est illustrée ci-contre avec la convention suivante :

- Niveau 0 – Indépendant ; - Niveau 2 – Favorisé ; - Niveau 4 – Très dépendant.

Cette figure met en exergue la dépendance des processus de Support des Services à la CMDB. Au contraire les processus de Fourniture des Services sont considérés comme qua-siment indépendants de la CMDB.

On retrouve ici le schéma classique de représentation des processus ITIL V2 :

PAG

E 18

Les activités du processus de Gestion des Configurations sont en grande partie im-plémentées :

- Élaboration/évolution de la CMDB ; - Normalisation des informations ; - Chargement de masse ; - Contrôle des modifications ; - Inventaire et vérification réguliers des données.

A l’opposé, l’activité d’audit et de revue périodique du processus est formalisée et effective dans seulement la moitié des entreprises consultées.

Les modifications sont généralement détectées par les inventaires réalisés périodi-quement, et seulement dans 70 % des cas suite à un événement initiateur déclenché par un autre processus (incident, changement, mise en production, …). Cette carac-téristique confirme la prépondérance du besoin de fiabilité des données par rapport à la volonté de contrôle des processus mis en œuvre pour tracer les modifications apportées aux composants du SI (utilisation de la CMDB en mode base contrôlée).

Les écarts détectés lors des inventaires sont cependant analysés pour identifier la cause de leur origine dans plus de 90 % des entreprises consultées. Cette analyse est majoritairement faite a posteriori afin de ne pas décaler la mise à jour des infor-mations corrigées. La répartition entre le choix d’inventaires manuels ou automa-tiques est à peu près équivalente.

Étant données les volumétries importantes de données (on peut rapidement at-teindre entre 20 000 à 50 000 CI) et la difficulté de conserver des informations fiables dans la durée, il est essentiel de définir les processus de maintien à jour de la CMDB préalablement au démarrage opérationnel du projet.

L’option de privilégier un démarrage et un chargement progressif de la CMDB concourt aussi à se prémunir de ce risque potentiel.

2.3.3 Tableaux de bord et reporting

Pertinence et taux de mesure des indicateurs

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

19

LiVR

E B

LAN

C

Les résultats de l’enquête sur la pertinence et le taux de mesure des indicateurs clés de performance sont illustrés ci-dessus.

La pertinence est évaluée sur une échelle de 4 – Pertinent à 0 – Non pertinent.

Le taux de mesure des indicateurs est aussi évalué sur une échelle de 0 à 4, le ni-veau maximal traduisant une mesure de l’indicateur dans 100 % des entreprises consultées.

Les tableaux de bord sont généralement élaborés avec une fréquence mensuelle. Ces rapports sont diffusés, également mensuellement, au sein de la Production Informatique et selon les contextes à la Direction Informatique ou à l’entité Qualité et Méthodes. Le fait qu’aucune des entreprises consultées n’a indiqué une diffusion aux Études est à nouveau symptomatique que la CMDB demeure considéré comme étant du périmètre exclusif de la Production Informatique.

Cette mise en œuvre assez limitée s’explique en partie par l’absence ou la parci-monie des tableaux de bord proposés en natif dans les outils de CMDB d’une part, et par la difficulté de définir des indicateurs pertinents et facilement mesurables d’autre part.

Ce constat est amplifié par le besoin d’équilibre entre disposer d’informations fiables et maîtriser ces informations, ce qui engendre une incertitude quant à la pertinence des indicateurs retenus.

Quoi qu’il en soit, l’analyse des résultats de l’enquête sur la pertinence des indica-teurs proposés démontre l’intérêt de suivre les écarts et d’analyser leur origine, et de façon flagrante la pertinence de la mesure de l’utilisation de la CMDB. La mise en place et le maintien à jour d’une CMDB constitue en effet un effort très impor-tant et les bénéfices en résultant sont typiquement illustrés par la mesure de cet indicateur.

2.3.4 Points clés

La nécessité de veiller à la cohérence entre l’organisation, les processus et les ou-tils mis en place qui est essentielle à la réussite d’un projet CMDB est à nouveau mise en exergue par les constats de l’enquête.

Le processus de Gestion des Configurations du référentiel ITIL vise essentiellement à contrôler le respect des processus de Soutien des Services, et en particulier la Gestion des Changements et la Gestion des Mises en Production. L’enquête révèle que les entreprises consultées adaptent souvent ce processus pour répondre au be-soin primordial de disposer d’informations fiables, un membre ayant même indiqué que ce processus n’était pas implémenté au sein de son entreprise.

L’importance de l’efficience de la mise à jour des données est soulignée dans les conclusions de l’enquête. Un taux de fiabilité des informations d’au moins 80 % est souvent admis pour garantir une confiance et une utilisation effective de la CMDB.

PAG

E 20

Compte tenu des volumétries des données manipulées, il est impératif de disposer d’un outil de CMDB adapté. Bien que cet outil soit souvent considéré comme interne à la Production Informatique, il apparaît clairement que son périmètre est en réa-lité plus large et qu’il conviendrait d’impliquer toutes les entités de la DSI voire des interlocuteurs externes à la DSI.

Les outils disponibles sur le marché sont de plus en plus matures et offrent une meilleure adaptation aux besoins des entreprises. Aussi le choix de solutions pro-priétaires est-il de moins en moins fréquent. Cependant cette tendance n’influence en rien les spécificités du périmètre de la CMDB propres à chaque entreprise. Il ressort d’ailleurs de l’enquête qu’il est très difficile voire utopique d’imaginer une structure universelle de CMDB qui convienne à tous les contextes.L’évolutivité des outils et surtout de la structure de la CMDB constituent un critère essentiel de réussite. En effet même si les membres s’estiment quasi unanimement satisfait des outils mis en place, l’évolutivité et la facilité de maintenance sont éga-lement soulignées. C’est pourquoi de nombreuses entreprises disposant déjà d’une CMDB, prévoient de faire évoluer en profondeur leur outil, voire de changer d’outil, pour pallier leurs limitations actuelles.

Afin de garantir la prise en compte de ces considérations nombre de membres in-sistent sur le besoin d’accompagnement, de formalisation et d’implication de tous les acteurs avant le choix de l’outil …

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

21

LiVR

E B

LAN

C

DECISION DE METTRE EN PLACE UNE CMDB

3.1 LA PROBLEMATIQUE ADRESSEE

> Pourquoi avoir traité ce sujet ?

Parce qu’il n’est pas toujours facile d’identifier à quel moment et quels sont les critères qui permettent de lancer efficacement ce type de projet.

Lors des réunions du groupe de travail, il est apparu que les besoins en activités et reporting transverses aux organisations de production informatique sont de plus en plus nécessaires.La production informatique s’étant constituée autours de silos métiers dans la plupart des sociétés, les réponses à ces nouveaux besoins n’étaient plus adaptées (consolidation des différentes données très coûteuses en temps, et très complexes).La plupart des organisations ayant un niveau de complexité important de leurs infrastructures s’orientent alors vers des outils pour gérer leurs données de manière transverse.

La CMDB est une réponse possible à ces problématiques et ces nouveaux enjeux.

Une CMDB n’apparaît pas de façon spontanée ou isolée dans une entreprise. On ne se dit pas un beau matin : « Tiens, et si je mettais en place une CMDB … ». C’est généralement dans un cadre plus global, comme celui d’une démarche qualité structurée, par exemple, que l’idée de mettre en place une CMDB émerge.L’approche est orientée « processus ITIL » puis « outillage ». Très vite est identifié le besoin de disposer d’une base de données, sans savoir exactement si ce sera la CMDB.

> Comment a-t-il été traité ?

Trois sociétés ont, plus particulièrement, approfondi les motivations de cette décision, lors de quelques ateliers en sous groupes, à savoir Crédit Agricole CIB (anciennement Calyon) représenté par Joris Daumont, Crédit Foncier représenté par David Lebroch et Thales représenté par Frédérick Paquet, leader du groupe CMDB.

Lors de ces réunions, les participants se sont appuyés sur deux éléments principaux :

- Leur retour d’expérience sur leurs projets respectifs, - Le questionnaire CRIP CMDB, repris et consolidés de l’expérience des

sociétés, membres du CRIP, qui leur a été proposé en mai 2009, sur lequel il y a eu 15 réponses (sur 40 sociétés interrogées à l’époque) :

• 85% sont dans une démarche ITIL (les autres ont prévues de lancer cette démarche prochainement)

• 60% sont dans des démarches de réorganisation interne • 75% ont lancé ou vont lancer un projet CMDB

3

PAG

E 22

Les éléments qui participent à la décision de déclencher le projet de construction et de mise en place d’une CMDB, au sein d’un organisme, tournent autour des points que nous détaillerons dans les paragraphes qui suivent.

3.2 LA REPONSE PROPOSEE

Notre première constatation, c’est la corrélation entre un projet CMDB et une démarche processus.Dans tous les cas que nous avons étudiés, le projet CMDB venait en support aux processus ITIL mis en place dans la société.

Dans la majorité des cas la décision de mettre en place une CMDB s’appuie sur les limites de fonctionnement des processus sans CMDB.

Il est intéressant de constater que majoritairement les sociétés implémentent leurs processus sans CMDB (du moins initialement), mais en s’appuyant sur de multiples bases existantes, faisant office de « pseudo » CMDB, en attendant mieux.C’est grâce à une certaine maturité dans ces processus que l’organisation peut alors se rendre compte de l’aboutissement de la CMDB.A l’inverse, il semble naturel de ne pas mettre une CMDB en place de façon exogène aux processus, tout au plus, elle pourrait s’implémenter en même temps que les processus.

Nos retours d’expérience mettent en évidence l’impossibilité de monter une CMDB sans processus.Nous avons constaté chez plusieurs des sociétés du panel que les projets CMDB s’étaient fait en plusieurs phases : - Mise en place des processus avec une « pseudo » CMDB, ou pas - Selon le cas • On met en place une « pseudo » CMDB • On réfléchit au projet d’une vraie CMDB (sur la base de l’expérience

acquise dans le fonctionnement des processus) - Mise en place d’une nouvelle CMDB, avec réadaptation / évolution des

processus

Un projet CMDB ne devrait pas être vu comme un projet uniquement technique mais également comme un projet d’organisation.

On représente usuellement la CMDB, soit comme support aux processus, formant ainsi un socle, soit comme au centre de la chaîne de processus.La CMDB doit avoir un rôle de facilitateur auprès des opérationnels afin que ceux-ci trouvent une vraie valeur ajoutée dans leur travail quotidien :

- Diminution du travail administratif (de plus en plus croissant) - Baisse du risque opérationnel - Amélioration de la capacité de faire du reporting - Possibilité de tracer le travail effectué (besoins de refacturation, de preuves, …)

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

23

LiVR

E B

LAN

C

Dans le questionnaire CRIP CMDB, nous avions posé une question libre sur « Pourquoi avoir lancé un projet CMDB ? ». Nous vous livrons ici l’ensemble des verbatims que les entreprises nous ont communiqués :

- Cartographie et maîtrise des composants gérés par la sous-direction. Articulation avec les processus à implémenter.

- Support des processus ITIL. - Gestion des configurations, analyse d’impact, Service Level Management. - Besoin transversal aux processus déployés ou en cours de l’être. - Meilleure efficacité de tous les autres processus. - Fournir en priorité des informations aux processus «Soutien des services». - Remplacer 6 référentiels isolés par un référentiel unique, pour assurer la

cohérence des données, et simplifier leur mise à jour et leur utilisation. - Référentiel unique - fournir les analyses d’impact pour les gestions Incident

et Changement.

Pour synthétiser la réponse que nous donnons sur les raisons qui peuvent entrainer la décision de mettre en place une CMDB, de façon pragmatique, nous retenons :

- Des bases disparates, qui ne communiquent pas et desquelles il n’est pas possible ou difficile de sortir des indicateurs fiables robustes et efficaces.

- Des processus qui existent, certes parfois imparfaits, mais qui ne peuvent pas s’appuyer sur une base fondatrice, ni s’en nourrir ni l’alimenter.

- Des responsabilités inexistantes, mal identifiées ou pas suffisantes. - Pas d’indicateur pour piloter les processus via les bases de données - Des opérationnels qui n’adhèrent pas au respect des processus du fait d’un

outillage bancal adossé à des bases trop diverses, entrainant trop de mises à jour et les épuisant. Avec, de plus, ce sentiment de ne jamais bien faire en perdant un temps fou.

- Un mélange de CI (Configuration Item) pas importants et de CI qui le sont. Ce qui est du business et ce qui n’en est pas. Ce qui est dans le PRA (Plan de Reprise d’Activité), …, rendant nécessaire la possibilité de classifier ces CI et de se concentrer sur ce qui est important pour le business

- Une mauvaise coordination entre les équipes due à de grandes carences de communication, à l’absence de données fiables et uniques

- Gains financiers sur le fonctionnement et la maîtrise des risques - Optimisation des organisations - Transparence vis à vis des utilisateurs ou clients

Bien entendu, ces éléments listés ci-dessus vont dépendre du contexte de l’entreprise, et plusieurs facteurs peuvent venir appuyer plus particulièrement un élément par rapport à un autre. Parmi les facteurs qui peuvent influer sur la décision de lancer un projet CMDB plus rapidement ou facilement, on retrouve principalement :

- L’environnement de production : de plus en plus complexe (multi-technologies, sécurisation des données, …), une CMDB devient nécessaire pour en assurer une maîtrise globale.

PAG

E 24

- Les gains attendus : ROI direct (financier) et/ou sur l’amélioration des processus.

- Audit : besoins de preuves, reporting, contrôles lors de suivi de normes (ISO 20 000, SOX, régulateur – lois, commissaires aux comptes, inspections internes, …)

- Services supplémentaires : possibilité de vendre ces informations consolidées et cette transparence aux clients (internes ou externes)

3.3 LA DEMARCHE ET MOYENS PRECONISES

Le réflexe commun de toutes sociétés, lorsque la création d’outillage se pose, est généralement de faire un tour d’horizon des outils et bases de données déjà disponibles en interne.

Ensuite il est souvent procédé à l’évaluation de l’effort nécessaire pour commencer à adapter les outils ou « peindre » ces bases de données en « CMDB ».

En effet, il est assez aisé de décréter qu’une base d’asset, faite plutôt dans un esprit de gestion de patrimoine, peut servir de CMDB. Mais c’est omettre le rôle profond de la CMDB, qui est de partager entre les équipes de production et les utilisateurs des informations avec des données justes, de l’asset au service business modélisé. Nous sommes de facto tous tombés d’accord sur le service que devrait nous rendre une CMDB, et donc les types de CI pourraient être par exemple :

- Les serveurs - Les mainframes - Les applications - Les stockages - Les locaux - Les incidents / problèmes / changements - Les services techniques - Les SLA - Les services applicatifs

> Démarche globale pour la mise en place

Nous en sommes venus à établir une démarche « type » à suivre pour la mise en place de son projet CMDB :

- En pré-requis, avoir une démarche processus dans la production informatique • A minima gestion des changements et incidents • Cette démarche processus est tout de suite inscrite dans un plan

d’amélioration continue - Faire l’inventaire de tous les outils ou bases utilisés par la production et

mettre en place cette « pseudo » CMDB, et faire la distinction • Outils ou bases potentielles pour participer à la « pseudo » CMDB • Outils ou bases qui ont vocation à alimenter ou s’interfacer avec la CMDB • Outils ou bases qui peuvent être supprimés et intégrés dans la CMDB

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

25

LiVR

E B

LAN

C

- Identifier les limites des processus en place s’articulant sur la « pseudo » CMDB • Cette étape intervient après des retours d’expérience et l’atteinte d’un

certain niveau de maturité sur le fonctionnement des processus - Tirer les conséquences des dysfonctionnements et manquements en vue de

la modélisation de la CMDB cible - Revoir ou réajuster les processus - Entrer dans une nouvelle boucle d’amélioration continue de la CMDB et des

processus

> Démarche projet

Un projet CMDB reste un projet complexe à mener, nous constatons d’ailleurs que 80% sociétés ayant répondu au questionnaire et ayant mis en place une CMDB se sont fait aider par des cabinets de consulting (en tant qu’expert, assistance de projet et/ou en acteur sur le projet) et qu’ils se sont également fait accompagner par l’éditeur dans 65% des cas. Bien entendu, cela a été fait avant que le livre blanc CMDB ne paraisse .

Pour un projet CMDB qui part sur de bonnes bases, nous avons listé un certain nombre de points que nous recommandons de traiter, afin d’éviter tout « nervous breakdown », que l’on peut regrouper en deux catégories : - Des bonnes pratiques usuelles d’une démarche projet • Définir un vrai cadre projet (MOA, MOE) • Avoir un sponsor • Disposer des moyens associés (budget, ressources) • Organiser des comités de pilotage • Publier des indicateurs de suivis - Des bonnes pratiques d’une démarche projet sur lesquelles on va plus

particulièrement insister sur : • Conduite du changement : primordial dans le cadre d’un projet d’outillage

de production, à prendre en compte le plus tôt possible (Maquette, POC (Proof Of Concept), spécifications)

• Impact sur l’organisation : comme nous l’avons dit précédemment, un projet CMDB est surtout un projet d’organisation. Dans le projet CMDB, nous recommandons de prendre en compte dès le début l’après projet, avec notamment :

1. Un responsable CMDB pouvant être la même personne que le responsable de la gestion de Configuration

2. Des indicateurs de suivi de la CMDB et du processus 3. Des comités de suivi de processus de Gestion de Configurations

(parexemple pour les circuits d’homologation de nouveaux types de CI) 4. Un plan d’amélioration continue • Choix du périmètre : Etape essentielle pour une CMDB, que nous traitons

dans le chapitre suivant, mais qui va conditionner tout le projet. 1. Environnements : Prod, Dev, Préprod, Intégration, Test, … 2. Relations entre CI 3. Criticité pour le business 4. Finances

PAG

E 26

• Communication : Un risque fort nous est apparu, c’est le manque de communication autour de la CMDB. La communication qui annonce la naissance d’une CMDB ou qui donne des nouvelles de son état de santé n’est pas suffisante, il faut également :

1. Une communication pour faire de la CMDB la pierre angulaire des échanges entre les équipes opérationnelles, les clients, la direction, les auditeurs, …

2. Une communication sur la base des informations enregistrées, bien sûr, mais également sur la base de statistiques à des fins de reporting, car une démarche de cette nature qui ne se mesure pas, est véritablement un risque sur le plan de l’efficacité, mais aussi sur le plan de la crédibilité. Un reporting dont l’objectif est d’être en partie injecté dans les instances de gouvernance.

• Responsable / Propriétaire du CI : Nous recommandons fortement qu’un des critères d’homologation des CI dans la CMDB soit d’associer à chaque CI un propriétaire identifié avec un processus de mise à jour des données associé. Il sera alors l’interlocuteur pour toute activité sur ce CI tout au long de son cycle de vie.

• Relation avec les autres processus : La CMDB a pour vocation à servir de socle pour les processus, aussi bien ITIL que métier. Par exemple, afin que le service desk puisse convenablement renseigner l’utilisateur, les attributs devraient permettre de connaître les éléments qui ont affecté le CI :

- Incident/problème en cours, oui/non et si oui lequel, quel impact business, qui l’a en charge, délais de résolution, …

- Changement en cours, oui/non et si oui, sa substance, son impact business, qui en est propriétaire, la ressource est elle indisponible, pour combien de temps, y a-t-il un contournement en cours/possible …

Nous avons constaté que généralement les entreprises ayant mis en place une CMDB avant les processus, ont eu des dysfonctionnements sur le plan de l’organisation et de l’amélioration des services.

Par ailleurs, dans nos entreprises, nous devons bien entendu répondre aussi à différents besoins, comme par exemple :

- Gérer les immobilisations et/ou bien gérer les actifs. La vie des actifs s’appuyant sur les processus ITIL

- Gérer les incidents, les changements.

Toutes les étapes que nous venons de mentionner ne sont ni exhaustives ni obligatoires, mais correspondent à nos retours d’expériences de sociétés ayant plutôt réussi leur projet CMDB.

Dans le cadre du projet CMDB, deux étapes essentielles sont à adresser : - La structuration et le modèle de données de la CMDB - Le choix de l’outil CMDB.

Ces deux points sont traités dans les chapitres suivants.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

27

LiVR

E B

LAN

C

3.4 LES RECOMMANDATIONS DU CRIP

3.4.1 Les pièges à éviter

Parmi tous les échanges recueillis dans le groupe de travail, nous avons sélectionné plusieurs pièges à prendre en compte dans le cadre du projet CMDB

- Ne pas savoir suffisamment expliquer au sponsor la différence entre une base asset et une CMDB et donc confondre base asset et CMDB : un CI n’est pas qu’un asset :

• CI qui n’est pas un asset. Exemples : un service (métier, applicatif, technique, …), une personne, un local (salle, …)

• Tout Asset peut potentiellement être un CI. Exemple : serveur, logiciel, … - Il peut y avoir plusieurs bases qui constituent les référentiels de la CMDB,

mais attention à en limiter le nombre, et à garder une responsabilité unique et transverse, même si chacune de ces bases sont sous la responsabilité de différentes personnes.

- Négliger le travail sur l’adhésion des opérationnels. Un nouvel outil pour des équipes de production informatique qui est mis en place sans les opérationnels a de fortes chances de provoquer un rejet et voire pire, d’engendrer la naissance de bases parallèles spécifiques à chaque métier et non consolidées entre elles.

- Une démarche non outillée ou mal outillée entraîne des écritures sans cohérences, faites à la main, sans réel contrôle, source d’erreurs et de conflits

- Attention à tous les outils de déversement massifs (abordés par ailleurs dans ce livre blanc) qui, dans le cadre de la mise en place d’un projet CMDB peuvent faire perdre de vue ce qui est essentiel au business.

- Ne pas avoir nommé ou identifié le responsable de CMDB, et bien sûr, de l’impliquer dans le projet

- Ne pas avoir d’engagement durable de la direction - Ne pas mesurer l’efficacité et l’impact de la CMDB sur le fonctionnement de

la production

3.4.2 Quelques suggestions…

En complément des différentes informations relatives au projet CMDB et aux facteurs de décisions, nous avons établit les remarques / conseils suivants :

- S’assurer du fort sponsoring de la direction (nous insistons sur ce point car nous jugeons ce point essentiel), par exemple : identifier un budget, participer à la communication, à la fixation d’objectifs des collaborateurs, …

- Déterminer dès le début du projet l’organisation cible - Disposer d’une conduite du changement efficiente, car s’agissant

d’opérationnels, si les équipes ne participent pas à la conception et la mise en œuvre de la CMDB (alors qu’elle est là aussi pour répondre à leurs besoins), le risque de non adhésion est très élevé.

- S’assurer que les bases qui existaient avant la CMDB et qui n’ont plus raison d’être après sont bien supprimées

PAG

E 28

- Nous pensons que la CMDB devrait comporter en priorité les CI business, c’est-à-dire ceux qui servent à produire de la plus value pour l’entreprise, (directement dans un premier temps). Les CI non business (ceux qui ne sont pas dans un PRA – Plan de Reprise d’Activité - par exemple) sont à prendre en considération, mais préjuger de leur intégration dans la CMDB et sans priorité forte. Ces CI devraient être sélectionnés un à un, et tous les attributs renseignés. Car ce qui peut sembler un peu rigide dans un premier temps peut s’avérer payant par la suite.

- Le rôle de responsable CMDB est très important, il doit être visible dans l’organisation (participer aux différents comités de gouvernance, …) et avoir les moyens (financiers, ressources, …) de mener à bien les politiques de gestion des configurations.

- Il faut prendre en compte qu’une CMDB n’est pas un outil figé, donc que dès sa conception il faut envisager ses futures évolutions (modèle de données, interfaçage avec les outils, les processus ou les autres bases)

- Dans le cadre de la prise de décision de la mise en place d’une CMDB, on constate que la CMDB permet de sensibiliser le client, au travers de la notion de coûts de service que l’on peut gérer, sur les coûts de production et les devis de fourniture de nouveaux services. C’est un facteur à valeur ajoutée pour le client.

En synthèse, comme le disent nos amis Japonais : « Poka-yoke ! », qui signifie.éviter les erreurs (Mot Japonais signifiant « éviter » (Yokéry) « les erreurs » (Poka). Dispositif pour éviter les erreurs à leur source).

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

29

LiVR

E B

LAN

C

STRUCTURER ET DEFINIR SON MODELE DE CMDB

4.1 LA PROBLEMATIQUE ADRESSéE


La définition de la structure de la CMDB est une activité cruciale de la gestion des configurations. Il faut être vigilent sur ce point car :

- La modélisation de la CMDB ne pourra être revue sans impacter lourdement les processus clients (Gestion des incidents, problèmes, changements, mise en production, …) et les outillages qui s’appuieront sur elle,

- Cette activité représente une charge de travail non négligeable et nécessite des intervenants avec des compétences multiples (modélisation, connaissance fonctionnelle et technique pointue, …) souvent difficiles à trouver en interne.

Lors de la mise en place d’une CMDB plusieurs questions reviennent systématiquement concernant sa structure et son contenu :

- Quels types de CI doivent être définis ? (choix du périmètre) - Quelle granularité choisir pour les CI ? (profondeur) - Quel cycle de vie pour les CI ? (statuts) - Quelles relations mettre en place entre les CI ? quelles règles d’impact ?

(primordial pour les analyses d’impact/de cause) - Quelles configurations de référence ? (prise d’image du SI ou CI de

références)

Il faut bien garder également à l’esprit : - Pour quoi faire ? : uniquement pour disposer d’informations à jour et fiables

ou contrôler le respect des processus ITIL - Comment alimenter la CMDB ? - Quelle politique d’accès aux données ? (sécurité) - Comment va-t-on contrôler la mise à jour (gestion des changements et des

mises en production) du contenu da la CMDB ? - Comment confronter le contenu de la CMDB et les inventaires ? - Comment va-t-on positionner la CMDB par rapport aux données qu’elle

contient : la CMDB est le référentiel maître (MDR – Master Data Repository) ou la CMDB synchronise / fédère un ou plusieurs référentiels maîtres ?

Ces derniers points ne sont néanmoins pas traités dans ce document car représentent des sujets à part entière.

4

PAG

E 30


Cinq sociétés ont plus particulièrement approfondi le sujet, lors de plusieurs ateliers en sous-groupes : La banque postale, représentée par Fabrice Josserand, PSA Peugeot-Citroën, représenté Jeannine Bac et Fabrice Colin, ADP GSI, représenté Jean-Luc Gallo, STIME, par Mamy Andrianarivony et Thales, par Frédérick Paquet.

Nous avons étudié la structure des CMDB mises en place par les participants de ce sous-groupe ainsi que la démarche qu’ils ont suivie pour y parvenir.


> Typologie des CI et granularité

En croisant l’ensemble des modèles de CMDB nous retrouvons une typologie de CI commune :

Famille de CI Types de CI Exemples Personnes Localisations site, bâtiment, bureau, pilier, local technique Entités

Organisation

Sociétés/Clients/Mainteneurs Change Incident IT Process Problem Niveaux de services OLA, SLA Engagements et

services Services Informatiques

Services métier, services d'infrastructure, services applicatifs (SOA)

Applications internes Applications métier

Logiciels/progiciels

Logiciels bureautiques, Outils de développement, Outils d'exploitation et de production, ERP, CRM, …

SGBD Oracle, DB2, SQLServeur Middleware Tuxedo, ETL, Serveurs Web Systèmes d'exploitation Unix, Windows, Mainframe, OS400

Applicatifs

Patchs

Postes de travail station, portable, ultraportable, poste intégré, tablette, client léger

Périphériques postes de travail

écran, graveur, imprimantes, disques, webcam, lecteur code barre,

Serveurs physiques Serveur, lame, châssis, consoles de management hardware

Eléments internes à des serveurs cartes réseaux

Serveurs virtuels zone, partition logique, sysplex, Virtual IO Server

Regroupement de serveurs Cluster, ferme (applicative, d'infrastructure), grappe

Téléphonie PABX, passerelle SIP, IPBX, audioconférences,

Equipements mobiles Téléphones mobiles, cartes 3G, PDA Audiovisuel Téléviseurs, visioconférences

Réseau

switch, routeur, tap, sonde, borne wifi, gateway VPN, répartiteur de charge, serveur de temps, modem accélérateur réseau, analyseur de flux, ligne réseau

Sécurité firewall, sonde IDS, proxy, boitier antispam, boitier antivirus

Stockage Baie, Routeur SAN, Switch SAN, Disques, dispositif de stockage virtuel

Ressources réseau @IP, VLAN, LAN, url

Sauvegarde VTL, Robot, Baie de sauvegarde, lecteur de robot, armoire de robot

Equipements

Infra Technique Rack, Climatisations, Onduleurs

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

31

LiVR

E B

LAN

C

Ces types de CI restent volontairement génériques. En effet, ces types de CI et la granularité associée sont à adapter :

- A chaque contexte d’entreprise (industriel, bancaire, ….) - Au périmètre à couvrir (datacenter, postes de travail, ….) - Au besoin processus: gestion des incidents, des changements, des

demandes, analyse d’impact, …

Il faut toujours se poser la question : à quoi va servir ce type de CI ? N’est-il pas préférable de se limiter à un attribut porté par un autre type de CI ou une relation ?

Exemple de choix de granularité :

• Si on souhaite déclarer des incidents/changements sur Switchs uniquement

Connexion switch <> serveurs

• S’il est nécessaire de pouvoir déclarer des Incidents/changements sur chaque port des Switchs

Connexion switch > port > serveur

PAG

E 32

A retenir que même dans les CMDB les plus complexes on retrouve toujours moins de 100 types de CI (50 en moyenne).

Il est à noter que la gestion des documents n’est pas une priorité pour la moitié des sociétés ayant participé à la rédaction de ce livre blanc alors que toutes les autres familles sont systématiquement implémentées.

Le choix de la clé (identifiant unique de chaque CI) reste primordial pour garantir la fiabilité de la CMDB. Souvent il s’impose de lui-même toutefois il faut bien s’assurer :

- Qu’une réconciliation est possible avec les autres référentiels en utilisant cette clé

- Que cette clé est connue et peut être retrouvée facilement (typiquement elle ne doit pas être un code interne impossible à retrouver sur le CI, elle ne doit pas être un numéro de série)

La complétude des attributs des CI n’est pas un critère déterminant dans la ré-flexion car ils sont facilement modifiables à postériori.

La notion d’héritage entre types de CI (conception proche des modèles objets) per-met de limiter la complexité de conception. Toutefois cette notion d’objet n’est pas compréhensible par les utilisateurs finaux de la CMDB. La notion d’héritage doit donc être transparente pour ces utilisateurs.

> Le cycle de vie associé aux CI

Les statuts suivants relèvent des bonnes pratiques de la gestion du cycle de vie des biens matériels et immatériels :

Statut Description Réservé L’élément de configuration est réservé pour

une utilisation future ou dans le cadre d'un projet

En commande/ en développement

L’élément de configuration est commandé, planifié.

Reçu L'élément de configuration est disponible mais n'est pas encore installé. Par exemple, il est positionné mais non encore câblé (ex d’une baie).

Installé Statut Installé. L’élément de configuration est en place et opérationnel

Utilisé L’élément de configuration est utilisé. PRA L’élément de configuration est réservé pour

les plans de reprise d'activité En maintenance L’élément de configuration est en cours de

maintenance programmée ou suite à une panne

En Stock Statut Entrepôt. L’élément de configuration est stocké dans un entrepôt. Il est à disposition pour un dépannage rapide ou toute autre utilisation

Hors service / Sorti du parc

L’élément de configuration n’est plus en service (retirés, ….) Il est souvent à sortir, à détruire ou à vendre

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

33

LiVR

E B

LAN

C

En théorie chaque type de CI peut avoir son cycle de vie propre (par exemple : ma-tériels et applications ont des cycles de vie et des terminologies d’états qui peuvent différer). Toutefois les outils imposent parfois d’avoir un seul ensemble d’états pour tous les types de CI. Les CI passent dans ce cas par tout ou partie de ces statuts.

> Les relations entre les CI

Les relations entre les CI constituent la valeur ajoutée fondamentale de la CMDB. Les relations fournissent une cartographie du SI qui rend possible :

- Les analyses d’impact dans le cadre d’un changement ou d’un incident - Les analyses de cause dans le cadre d’un incident.

Voici les relations que l’on retrouve communément entre les grandes familles de CI que nous avons évoquées précédemment :

Organisation IT Process Engagements

et services Applicatifs Équipements Documents

Organisation Héberge

Est le manager

Est impactée A souscrit Fournit

Est responsable

de

Est responsable

de

Est responsable

de

IT Process Impacte Lié Impacte Impacte Impacte Utilise Impacte

Engagements et services

Est souscrit Est Fourni

Est impacté Concerne concerne concerne

Applicatifs Est sous

responsabilité de

Est impacté Participe Utilise Est utilisé

Est hébergé par

Est concerné par

Équipements Est sous

responsabilité de

Est impacté Participe Héberge

Est composé de

Fait partie de Prend ses

ressources de Fournit des

ressources à Sauvegarde

Est sauvegardé

par Utilise

Est utilisé par Contient

Est contenu dans

Est relatif à Connecté à

Est concerné par

Documents Est sous

responsabilité de

Est impacté Est utilisé

Concerne Concerne Fait référence à

PAG

E 34

Exemple de liens entre CI

Les relations peuvent porter des attributs. Par exemple sur une relation du type «connecté à « entre un serveur et un switch on pourra retrouver comme attributs : vitesse, port de connexion, statut, …

Les outils proposent des relations unidirectionnelles ou parfois systématiquement bidirectionnelles. Ce sens des relations est structurant pour la réalisation des analyses d’impact et de cause.

Il est important d’identifier clairement qui est responsable de chaque relation («propriétaire»). Cela se comprend notamment lorsque les CI reliés dépendent d’entités différentes (par exemple : propriétaire de la relation «Application» <installée sur> «Serveur»). A ce titre, on peut également considérer que les relations sont gérées comme des CI.Si les relations sont unidirectionnelles, nous recommandons de partager au sein de l’entreprise une règle de définition de leur sens (toujours des services vers l’infrastructure par exemple).

Lors de la définition des relations entre CI, nous proposons de toujours de poser la question suivante :Est-ce qu’il n’est pas préférable de définir un attribut porté par chaque CI plutôt qu’une relation (factorisation de la relation sur le CI) ?

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

35

LiVR

E B

LAN

C

Ces étapes sont très importantes car la richesse des outils de CMDB réside dans leur «convivialité» dans la navigation entre les CI et leur requêtage en utilisant les liens qui les relient.

> Les règles d’impact

Les règles d’impact exploitent les relations entre des instances de CI pour identifier les impacts sur les utilisateurs finaux.

Exemples de règles d’impact :

Application mono-serveur : «Application1» <-> «serveur1» > impact 100%Application hébergée sur une ferme de serveurs : «Application2» <-> «cluster de serveur» > impact 50% (ou pas d’impact)

Switch non redondé :«Serveur» <-> «switch1» > impact 100%Switch redondé :«Serveur 1» <-> «switch1» > impact 50%«Serveur 1» <-> «switch2» > impact 50%

La définition de ces règles d’impact est proche du métier mais l’ensemble doit rester cohérent au sein de l’organisation pour avoir un traitement similaire des analyses.

Toutefois, l’implémentation de ces règles reste fortement liée à l’outil choisi (porté par la relation, défini de façon spécifique, …).

Configurations de référence, ou modèles

Les configurations de référence, ou modèles, ont deux usages :

- La définition d’une référence qui servira de modèle et par rapport à laquelle on pourra contrôler la conformité d’autres CI. Par exemple :

• poste de travail «développeur» • serveur web release 1.2 • …

- L’historisation des états d’un groupe de CI, de leurs attributs et des relations qui les unissent.

• en vue de pouvoir faire un retour arrière rapidement suite à des changements multiples,

• de retrouver le contexte d’un environnement à un instant donné.

Dans le cas de configurations de référence ayant pour but d’historiser un contexte, il faut définir précisément le périmètre (quels CI, quels attributs, quelles relations) ainsi que la fréquence/évènement déclencheur de la prise de «photo».

PAG

E 36

Les configurations de référence («Baseline») sont à définir en même temps que le modèle de la CMDB mais ne sont absolument pas impératives. Elles dépendent fortement des outils choisis et des contextes.

> Les facteurs d’influence sur la réponse

Avant tout, la définition de la structure et du contenu d’une CMDB est étroitement liée aux processus à outiller.

Le choix des outils est un point extrêmement structurant. Il est notamment très lié à l’écosystème informatique (outils existants pour le support des processus, interfaçage avec des inventaires, …) et à la stratégie des entreprises. Le «Choix de l’outil» est traité dans un autre chapitre de ce livre blanc.

On notera également que le choix de la méthode de définition du modèle est lié à l’existant ou à l’absence d’existant. On pourra ainsi partir d’un modèle vierge totalement adapté au contexte de l’entreprise ou s’appuyer sur des modèles standards (DMTF CIM, modèles «standard» des progiciels, …).


L’approche généralement retenue est de partir sur un besoin précis et d’étendre le périmètre en fonction des nouveaux besoins. Il est en effet difficile de prévoir l’ensemble du contenu de la CMDB du premier coup, nous privilégions une approche itérative.

Nous préconisons donc les étapes suivantes :

1. Homologation du CI : • Identifier les besoins et le périmètre à partir des objectifs qui sont

fixés à la CMDB. La CMDB n’est pas une fin en soi, c’est l’usage des données qu’elle va contenir qui est primordial.

• Identifier les propriétaires de chaque CI/relation et le cycle de vie associé.

• Modéliser le CI et ses relations 2. Vérifier la capacité à alimenter le modèle retenu. Il faut privilégier autant

que possible l’alimentation automatique, sous réserve de bien appliquer les deux points suivants, des CI et des relations afin de garantir la qualité des données.

3. Prévoir un «nettoyage» des données en amont de la mise en production de la CMDB, car il faut éviter de présenter des données globalement fausses/erronées/mal renseignées.

4. En mode récurrent s’assurer en permanence de la fiabilité et la mise à jour des données (revues régulières avec les propriétaires de CI/relations, traitement des erreurs de réconciliation et les rejets, réaliser les audits, …)

Pour définir la structure et le contenu d’une CMDB, nous recommandons d’avoir une équipe projet constituée des compétences suivantes :

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

37

LiVR

E B

LAN

C

- Chef de projet de mise en œuvre avec une culture transversale du SI et de l’entreprise, assisté de spécialistes en modélisation pour la conception du modèle de la CMDB (culture «objet», UML, MERISE, …)

- Les fournisseurs de données : «Sachant» technique de chaque domaine/métier,

- Les clients : Les pilotes des processus, … - Les intégrateurs pour les alimentations de la CMDB et les interfaçages

avec d’autres référentiels.

Il est relativement difficile de trouver des compétences pointues sur les CMDB en interne dans les productions des DSI, ces métiers relevant plus des études.

Cette définition du contenu et de la structure peut être modélisée sur des outils traditionnels de bases de données. Nous noterons à ce propos l’existence de l’outil eGen SKD de la société ISC, le seul que nous ayons vu qui est spécialisé dans la modélisation de CMDB.


4.4.1 Les pièges à éviter

En partageant entre les membres du groupe, nous avons essayé de lister plusieurs pièges ou points à éviter lors de la définition de son modèle de CMDB, nous les résumons ci-après :

- Figer son modèle et ne pas le prévoir évolutif. La modélisation des aspects «virtuels», notamment, peut rapidement devenir un casse-tête si l’on n’est pas assez souple dans les évolutions

- Eviter l’effet « poubelle » : créer une multitude de CI et de relations qui ne seront in fine soit pas utilisés, soit pas alimentés. Il faut traiter l’alimentation de la CMDB en même temps que la définition de sa structure.

- Ne pas effectuer de «pilote» sur le sujet avant de lancer un projet sur toute la DSI. Un pilote permet de gagner en maturité. Il faut bien garder à l’esprit la cible globale.

- Ne pas identifier dans la mission des opérationnels l’alimentation et la qualité de la CMDB (chaque CI et relation doit avoir un responsable qui les maintiendra à jour).

- Se tromper de casting pour le gestionnaire des configurations (approche «qualité», connaissance de l’entreprise, …) ou pour l’équipe projet (connaissance des modélisations, …).

4.4.2 Quelques suggestions…

A contrario des pièges listés ci-dessus, voici une liste de quelques points que nous conseillons de prendre en compte dans le cadre de la définition de son modèle :

- Définir dès le départ très clairement le périmètre et les objectifs de la CMDB, ce qu’elle couvrira, et ce qu’elle ne couvrira pas, ceci toujours dans

PAG

E 38

l’objectif de raisonner globalement, de pouvoir ainsi anticiper les évolu-tions, et être sûr de ne rien oublier

- Tenir compte des outils d’inventaires qui seront susceptibles d’alimenter la CMDB et de maintenir la qualité de celle-ci.

- Faire appel à des consultants spécialistes du domaine. - Rechercher des expériences dans des contextes similaires - Penser également à la traçabilité de l’information, indispensable pour avoir

une CMDB dont les données gérées, sur lesquelles on peut faire des ana-lyses, des audits, du suivi.

- Penser à intégrer la réflexion sur la sécurité d’accès aux informations dès l’établissement du modèle, car il s’agit d’un sujet complexe qui peut influer sur le modèle

- Modéliser sa CMDB en se basant sur la réalité opérationnelle. Sur du moyen terme, il est préférable de rajouter une classe définissant la réalité que de vouloir simplifier. Le temps gagné dans la modélisation sera perdu par 10 dans l’étape d’intégration.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

39

LiVR

E B

LAN

C

5CHOISIR SON OUTIL CMDB

5.1 LA PROBLEMATIQUE ADRESSéE


Un projet CMDB est un projet transverse au sein de l’entreprise, il requiert un investissement important en temps, il convient donc de faire les bons choix au départ. Celui de l’outil CMDB constitue une étape importante pour laquelle nous proposons ce chapitre afin de présenter et d’organiser les questions à se poser, les critères différenciateurs. L’offre s’est considérablement développée ces dernières années, à partir d’outils de gestion des actifs, d’outils intégrés préexistants, mais aussi avec des solutions spécifiques, dédiées, et novatrices pour quelques unes.

Nous citons ensuite les facteurs potentiels d’évolution : progrès techniques et normatifs, apparition d’offres SaaS. Au-delà de la description des fonctions et de l’inventaire des offres, nous indiquons pour terminer les grandes lignes d’une démarche de sélection du produit ou d’un ensemble de produits.

Nous avons joint un relevé d’un certain nombre d’offres du marché, cet inventaire n’est sans doute pas exhaustif, il correspond à une vue du marché début 2010. Dans la plupart des cas, nous avons caractérisé l’offre sur la base des critères différentiateurs explicités dans ce chapitre : le tableau reflète ainsi la compréhension des sociétés du CRIP sur les produits et leurs fonctions.


Six sociétés ont, plus particulièrement, étudié la problématique du choix de l’outil, lors de quelques ateliers en sous groupes, à savoir ESSILOR, représenté par Anne Jaffré, STIME, par Mamy Andrianarivony, Casino, par Gilles CORRON, Société Générale, par Thierry Chamfrault, Thales, par Frédérick Paquet et le CRIP par Christian Villemot.Le sous-groupe a développé la présentation des fonctions différenciatrices à partir des constats et retours d’expériences respectifs des membres du sous-groupe. Un représentant de l’ITSMF nous a aidé à intégrer la vision professionnelle ITIL.

Nous avons croisé ces constats avec les visions exprimées dans des articles récents (01 Informatique, Gartner), et avec une étude réalisée par la société CG2 Conseil.

La liste des offres a été construite en analysant les sites WEB respectifs des éditeurs, et en ajoutant les retours d’expériences des membres du sous-groupe ainsi que les éléments collectés via le questionnaire.

PAG

E 40


5.2.1 Les fonctions discriminantes, les questions à se poser

5.2.1.1 Démarrage de la démarche projet de sélection

Il est rare qu’un démarrage de projet CMDB se fasse en terrain vierge : à minima, toute production dispose de référentiels existants, plus ou moins partiels, de formats divers et variés ; au-delà de ces référentiels, certains processus de soutien et fourniture des services peuvent déjà être supportés par un ou plusieurs produits, progiciels ou développement « maison ».

Le contexte et l’existant sont donc des paramètres incontournables à prendre en compte : dans la mesure où le choix n’a pas encore été déjà fait préalablement au projet CMDB, il faut se positionner sur l’architecture à retenir :

- La (nouvelle) CMDB est intégrée au sein d’une suite de composants (de gestion des services) d’une offre d’un même éditeur,

- La (nouvelle) CMDB constitue un module autonome doté de ses propres fonctionnalités de gestion, et auquel viendront s’interfacer les composants préexistants ou non pour la gestion des services : ces composants, dotés de leurs propres référentiels, pourront provenir d’un ou de plusieurs éditeurs, y compris de solutions « maison ».

5.2.1.2 Les outils intégrés, les outils modulaires

Deux approches se retrouvent en effet dans les architectures des produits du marché pour mettre en place une CMDB :

- Architecture « intégré » : Le produit (ou la suite de produits d’un même éditeur) fonctionne avec une base d’informations unique pour tous les processus de Gestion des Services Informatiques. La base centralise toutes les informations concernant les éléments de configurations (CI) et les relations entre les CI. Son méta-modèle est le plus souvent figé ou peu modifiable. Cette approche est bien adaptée s’il n’y a pas ou peu d’existant, ainsi que pour des organisations petites et moyennes.

- Architecture « modulaire » : Le produit de gestion CMDB est organisé autour d’une base d’information ouverte pouvant recueillir d’autres sources d’informations : la base peut s’interfacer avec une ou plusieurs sources d’informations (des CMDB secondaires). Le méta- modèle est par conception évolutif et modulaire. Cette approche convient bien dans le cas de référentiels déjà existants.

Dans cette approche de construction « modulaire », les mécanismes d’interface (peuplement et usages ultérieurs) avec les référentiels externes sont appelés « fédération ». Ces fonctions sont décrites plus après dans ce document

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

41

LiVR

E B

LAN

C

5.2.1.3 Terminologie

La notion de CMDB (Configuration Management Data Base) a été introduite en premier. Le CMS (Configuration Management System) a été introduit plus récemment, mais il est désormais utilisé largement par les éditeurs. Le CMS accueille non seulement les éléments de la CMDB mais aussi d’autres éléments comme les données des actifs par exemple :

- CMDB : C’est une définition apparue dans les versions 1 et 2 d’ITIL. Nous l’avons défini en préambule à ce livre blanc. Elle a un rôle de soutien en produisant des informations fiables pour les processus des Gestion des Service.

- CMS : c’est une définition proposée dans la version 3 d’ITIL pour mieux répondre à la réalité des organisations délivrant les Services. Le CMS se différencie de la définition CMDB ITIL V2 sur 3 points :

• C’est un système soutenant la Gestion des Actifs de Service et des Configurations (« Service Assets and Configuration Management »). C’est un ensemble d’outils et de bases de données servant à la gestion des données des configurations d’un fournisseur de services informatiques.

• Il peut recueillir des informations de plusieurs CMDB physiques qui pourront être fédérées au sein d’une CMDB maître.

• Il permet de lier les informations de configuration avec les informations des incidents, problèmes, erreurs connues, changements, mises en production ainsi que les informations sur les utilisateurs, les sous-traitants et les clients.

Dans la suite, nous nous limiterons à la CMDB, sachant que beaucoup d’offres intègrent ou évoluent vers le CMS.

5.2.1.4 Les processus ITIL couverts

La CMDB est le cœur de la Gestion des Services, elle peut fournir toutes les informations nécessaires pour rendre des services efficaces aux utilisateurs et satisfaire les exigences exprimées dans le contrat de service (SLA).

Parmi les critères différenciateurs des outils, on peut vérifier sur les produits identifiés, une fois que les processus à gérer auront été sélectionnés (présent et futur) :

- le méta-modèle : permet-il d’accueillir toutes les informations relatives aux besoins des différents processus ITIL sélectionnés ?

- le niveau de support des processus sélectionnés.

PAG

E 42

5.2.1.5 Le méta-modèle

> Introduction

La CMDB est intrinsèquement une modélisation du système d’information axée sur les composants techniques (infrastructure) et sur leurs relations avec les composants applicatifs (urbanisation) et métiers (processus, services, organisations…). En tant que telle, elle doit s’appuyer sur un modèle de données capable de représenter ces 3 axes, suivant des degrés de précision qui dépendent du contexte et des besoins définis pour la CMDB. Ce modèle est lui-même défini à partir d’un méta-modèle. Dans le cadre du choix d’un outil de gestion des configurations, l’objectif de l’analyse du méta-modèle des outils est donc d’évaluer sa capacité à produire un modèle de données correspondant aux besoins et au contexte. Cette analyse peut se faire avec les critères suivants.

> Conformité avec les besoins

Le critère prioritaire d’analyse d’un méta-modèle est sa conformité avec les besoins exprimés pour la CMDB. Cela paraît une évidence mais il ne faut pas oublier que la mise en œuvre d’une CMDB, comme tout projet, doit se faire en fonction de besoins clairement exprimés, et non comme simple conséquence de l’outillage de tel ou tel processus ITSM. La réalité montre que la gestion des incidents ou la gestion des changements peut être faite sans CMDB, avec des limitations.

Pour chaque besoin on vérifiera la capacité du méta-modèle à représenter les objets concernés et leurs interrelations

- Pour une modélisation des composants techniques matériels : • les serveurs (modèle, fabricant, n° de série, CPU, mémoire, disques,

…) ; • les éléments de réseaux LAN/WAN (switchs, routeurs, VLAN, ports

physiques, …) ; • les éléments de réseaux SAN (baies, disques, unités logiques, …) ; • la localisation des éléments dans les centres de données (salles,

racks, étagères, …) ; • …

- Pour une modélisation des composants techniques logiciels : • Les OS, • les bases de données et leur configuration (SGBD, version,

structure…) • les composants web (serveurs HTTP, webapp J2EE ou .Net,

connexions aux bases de données…) • les composants de flux synchrone (messagerie applicative) ou

asynchrone (transfert de fichiers) • les relations avec les composants techniques matériels • …

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

43

LiVR

E B

LAN

C

- Pour une modélisation des composants applicatifs : • les applications et leurs modules ; • les zones, quartiers, blocs de l’urbanisation ; • les relations avec les composants techniques logiciels • ...

- Pour une modélisation des composants métiers : • les organisations • les processus métiers avec leurs activités, tâches… • les services, au sens du catalogue de services de l’IT • les relations avec les composants applicatifs • …

> Conformité avec l’existant - Idéalement, le choix d’une CMDB devrait être fait après une revue de

l’existant, qui aura permis de faire une liste des référentiels des composants destinés à être représentés dans la CMDB. Que ces référentiels soient ou non remplacés par la CMDB, leur modèle de données doit pouvoir être produit, tout ou partie en fonction des besoins, par le méta-modèle de la CMDB.

- Un point particulier concerne les identifiants dans les référentiels existants : la CMDB doit pouvoir utiliser ces identifiants pour la réconciliation des données.

> Gestion du cycle de vie

Une activité importante autour de la CMDB est la gestion du cycle de vie des CI, de leur entrée à leur sortie. Il faut donc s’assurer que le méta-modèle permet de représenter l’état d’un CI, éventuellement de représenter l’historique des changements d’états et des évènements ayant provoqué ces changements. Le cycle de vie des CI doit être autant que possible adressé spécifiquement dans l’expression des besoins et la revue de l’existant car il s’agit d’un élément fortement dépendant du contexte.

Exemple :

Actif – Planifié, Actif – Utilisé,

Inactif – Archivé, Inactif – Épuré, Inactif - Spare

PAG

E 44

> Historisation des mises à jour, des versions L’historique doit permettre de tracer toutes les modifications (création, mise à jour, suppression) effectuées sur les CI qu’ils soient modifiées manuellement ou automatiquement (le mode de mise à jour doit aussi être repérable). Le nom du modificateur, la date et l’heure de modification, ainsi que les champs modifiés doivent être repérables.

Le produit peut fournir une fonction d’historisation de versions de l’ensemble ou sous-ensemble d’une configuration : une version historisée pourra ainsi servir de référence, alias Baseline.

Le temps et le nombre de versions conservées peuvent être limités. Par contre, la possibilité de repartir d’une version antérieure peut être un critère déterminant.

> Evolutivité

- En fonction des critères d’analyse précédents, il sera possible d’identifier les écarts avec le méta-modèle des CMDB « out of the box » (fourni). Nous pourrons donc analyser les capacités des CMDB à pouvoir faire évoluer leur méta-modèle afin de réduire ces écarts.

- Dans ce cadre, un méta-modèle basée sur une hiérarchie de classes d’objets est un avantage car l’extension par spécialisation (ou héritage) y est naturelle. Cette remarque est aussi valable pour les relations entre objets, qui peuvent être des instances de classes de relations.

- Il faut aussi porter attention aux modalités d’extension du méta-modèle et aux impacts :

• Se fait-elle à chaud ou à froid ? • Peut-elle être réalisée en environnement de développement puis

transportée sous forme de package en environnement de production ? • Quel retour-arrière est possible ? • Rend-elle nécessaire un traitement de mise à jour sur les données ? • …

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

45

LiVR

E B

LAN

C

> Conformité avec les bonnes pratiques ITIL

Si une CMDB est conforme aux besoins et à l’existant, ou que son méta-modèle est suffisamment évolutif pour assurer cette conformité, un autre axe d’analyse est la conformité du méta-modèle aux bonnes pratiques ITIL. ITIL ne fournit pas de méta-modèle standard, tels que le propose le DMTF (Distributed Management Task Force) avec le modèle CIM (Common Information Model). Si ITIL V2 propose une description de la CMDB basée sur des CI, des attributs et des relations, ITIL V3, en étendant le périmètre de la CMDB, propose plutôt des fonctions autour d’un nouveau référentiel, le CMS (Configuration Management System). La complétude du méta-modèle sur le périmètre du CMS peut donc être un critère important dans le choix d’une CMDB.

5.2.1.6 Fonctions d’édition, de navigation, de requêtage

Une fonction d’édition de tous les composants (techniques, métiers) ainsi que des informations métiers (organisation, catalogue de services, …) doit être disponible. Des sélections pourront être faites tant au niveau des composants que des champs caractérisant ces composants ou des informations provenant du méta-modèle.

> Vues adaptées aux métiers : - Les vues peuvent être paramétrables via des profils utilisateurs : • au niveau des sélections, des champs affichés • au niveau de la présentation : dessin d’une baie, d’une salle de Data

Centre, … • pour des raisons de Sécurité / confidentialité

- On distingue plusieurs types de vues : • la vue du CI et de ses caractéristiques • la vue des liens entre les CI • la vue des liens entre CI et événements (changements, incidents,

problèmes)

> Les états (reporting) peuvent être définis lors de la phase de spécifications et développés ou paramétrés à ce moment là. Il peut être statique (c’est-à-dire ne pas être modifiable sans développement) ou évolutif (Ce qui peut avoir un impact sur les performances de la CMDB, notamment sur la base de données, voir plus après dans le document), bien que l’expérience montre que les besoins en reporting évoluent également dans le temps, donc une interface simple de création d’états peut être un plus

> La cartographie est une fonction de présentation et de navigation :

- La cartographie permet de repérer facilement tous les liens entre CI (par : exemple pour un composant technique, l’ensemble des composants applicatifs qui sont rattachés).

- La cartographie peut être représentée graphiquement, et tous les outils vont dans ce sens.

PAG

E 46

> Suivi des modifications

- Les informations de suivi des modifications peuvent être récupérées : • par envoi d’alertes automatiques sur la modification des CI (les

administrateurs ou aux personnes intéressées par ces modifications peuvent s’abonner et recevoir par email les informations lors de changements – qui peuvent ou non être paramétrables – ex – abonnement lors de la création d’un type particulier de CI)

• par consultation des modifications au cas par cas.

> Export Excel / autre format

La fonction export Excel est-elle présente en natif dans l’outil ? Dans ce cas, l’export doit être lié aux sélections qui ont été faites. Quelles sont les versions d’Excel acceptées ? Si l’export Excel n’est pas disponible, un export sous forme de fichier « txt ou csv » est-il mis à disposition ?

> Requêtage

Outre les modalités de consultation intégrées dans l’outil CMDB (vues, …), ainsi que les fonctions de navigation de type cartographie, l’outil peut disposer d’une fonctionnalité de requêtage. Si oui cette fonctionnalité demande-t-elle des connaissances techniques (SQL par exemple) ou existe-t-il un outil d’assistance au requêtage (via « drag and drop » par exemple) ?

> Reporting statique ou analyse multidimensionnelle

Le reporting mis à disposition dans l’outil peut se présenter sous forme d’un reporting statique (tableaux de bord prédéfinis) ou multi-dimensionnel (il sera alors possible de choisir les axes d’analyse et également de pouvoir zoomer sur les données). Exemple : dans le premier cas, un rapport du nombre d’équipements par type (serveur, poste de travail, …) indiquera le nombre global par type défini. Dans le second cas, il sera possible (par simple « click ») pour les postes de travail par exemple, de connaître le nombre de PC fixes, le nombre de portables, le nombre de PC industriel, puis en clickant encore, d’avoir le nombre par nom de fournisseur.

> Lien avec d’autres outils

- La fonctionnalité de reporting peut être incluse dans l’outil CMDB ou il peut être nécessaire de connecter un autre outil de reporting (Hyperion, Cognos, BO,...)

- Un outil de reporting est-il imposé par l’éditeur de la CMDB? Est-ce qu’il y en a un seul ou plusieurs ? Dans le cas de l’utilisation d’un outil externe, du support est-il fourni par l’éditeur de l’outil CMDB ?

- Dans le cas d’outil externe, les licences sont-elles fournies par l’éditeur de la CMDB ? Il faut en tenir compte dans le coût global de la solution.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

47

LiVR

E B

LAN

C

5.2.1.7 Analyse d’impact

Pendant la phase d’expression de besoins, il est nécessaire d’inventorier les usages d’analyse d‘impact qui seront entrepris à l’aide de l’outil CMDB, ainsi que le croisement éventuel avec des profils ou rôles : ci-dessous, une liste non exhaustive d’exemples de telles requêtes d’analyse :

- Comprendre et d’analyser les configurations qui contribuent à la livraison des services aux clients.

• Evaluer les effets d’une action d’un changement sur une configuration et d’apprécier l’ampleur et les risques induits sur les Services par le changement.

• Comprendre le service impacté par un incident et contribuer aux diagnostiques pour sa résolution.

• Analyser l’historique des changements, des incidents ou des problèmes pour trouver la solution définitive d’un problème.

• Comprendre et aider à la prise de décision sur le déploiement de nouveaux composants et sur l’évolution de l’infrastructure.

• Analyser l’utilisation et l’approvisionnement des ressources, et les solutions d’optimisation des capacités des CI.

• Analyser la disponibilité et la continuité des services. • Evaluer les coûts de l’infrastructure en cas de renouvellement.

5.2.1.8 Alertes, propagation d’indisponibilité …

La fonction d’analyse d’impact résulte d’une demande explicite de l’utilisateur : le produit peut aussi fournir une fonction paramétrable permettant par exemple la remontée d’une alerte d’indisponibilité d’un service suite à un événement de type incident. Ce mécanisme pourra alors s’appliquer à tout type d’événement : capacité disque, charge CPU, …

5.2.1.9 Technologie de base de données

Dans le domaine des produits CMDB, il existe deux technologies de bases de données :

- Base objet : les données sont représentées sous forme d’objets, on les classe de manière hiérarchique et chaque objet possède des données d’état et des fonctions pour les manipuler.

- Base relationnelle : données stockées dans des tables qui ont des relations entre elles.

En complément, la technologie de Cube OLAP (On-line Analytical Processing) permet l’accès à des informations déjà agrégées selon les besoins utilisateurs, de manière simple et rapide. Ces cubes s’appuient sur des tables relationnelles et/ou multidimensionnelles. Ils sont principalement utilisés pour du « datamining », afin de prédire et simuler des informations.

PAG

E 48

Le modèle de Base de Données Relationnelle, notamment pour l’interfaçage avec d’autres sources de données dans le cadre de fédérations de référentiels peut se révéler complexe et peu performant. Il s’avère moins souple pour les évolutions et les fonctions de recherche peuvent être très lourdes lorsque le nombre de données devient important.

5.2.1.10 Fédération, Réconciliation / normalisation, synchronisation

Le produit de gestion CMDB peut adresser les trois fonctions majeures relatives à l’alimentation et à la mise à jour doivent être analysées : ces fonctions sont à croiser avec l’architecture sélectionnée et l’expression de besoin concernant les référentiels externes ainsi que la mise en œuvre des processus de gestion des configurations au sein de l’entreprise :

- Intégration, fédération : les données de la CMDB peuvent être intégrées à partir de référentiels externes (données intégrées), ou rester résidentes dans d’autres référentiels (données fédérées). Dans les deux cas, il faut s’interfacer au référentiel extérieur pour le peuplement et les mises à jour, ainsi que lors des accès.

• La mise en œuvre de l’intégration repose sur des connecteurs fournis

(ou vendus) par l’éditeur de l’outil CMDB ou celui du référentiel extérieur.

• La mise en œuvre de la fédération repose sur des fonctions intrinsèques de l’outil de gestion CMDB : concept de méta-modèle. On décrit les attributs de la donnée fédérée stockée dans son référentiel externe : la CMDB « maître » devient ainsi une « méta-CMDB », simple à écrire, beaucoup plus complexe à mettre en œuvre et à fiabiliser. Le standard « CMDB Federation » est un facilitateur, en particulier dans l’approche « modulaire » (potentiellement multi-éditeurs) citée ci-dessus, sous réserve que les éditeurs adhèrent au standard.

• A noter qu’il existe des solutions simplifiées de fédération consistant à utiliser un outil de reporting multi-bases pour visualiser les données résidentes des référentiels externes.

- Normalisation, réconciliation : les CI (intégrés ou fédérés) peuvent donner lieu à des doubles si leur identification (clé) n’est pas normalisée dans les différents référentiels extérieurs : c’est particulièrement courant dans une approche fédérée, et de même, lorsque le domaine couvert par la CMDB « maître » franchit des frontières de domaines gérés par des équipes séparées (exemple : systèmes, réseau). La normalisation des identifications de CI est donc un idéal rarement atteint dans la pratique. La réconciliation consiste à identifier puis alerter et/ou corriger ces identifications différentes. La non-normalisation peut aussi correspondre à la prise en compte d’objets à des niveaux différents, baie de disques et volume disque par exemple : dans ce cas, la réconciliation impliquera une agrégation. Le produit pourra fournir

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

49

LiVR

E B

LAN

C

des outils de définition des règles de réconciliation. - Synchronisation : les informations contenues dans la CMDB doivent

représenter l’état certifié (géré) tel qu’il résulte du processus de gestion des changements. Il faut donc pouvoir synchroniser les changements réels avec la mise à jour de la CMDB, puis de manière récurrente contrôler puis corriger les écarts constatés entre l’état géré et le réel remonté par les outils.

5.2.1.11 Outils d’inventaire et de découverte

Un outil d’inventaire remonte les actifs d’un certain type. Un outil de découverte va remonter les éléments d’inventaire et les relations associées.

De nombreuses solutions du marché mettent en avant des outils de découverte automatique. Ces outils fournissent des aides incontestables lorsqu’ils sont bien utilisés :

- Ils peuvent être très efficaces dans le cadre d’un processus bien préparé (avec de multiples recettes) et bien contrôlé, avec validation des CI et des relations : cela garantit le respect de la règle d’or : « ne rentre dans la CMDB que des CI validés ». Ce mode de fonctionnement constitue un choix structurant pour le processus de gestion des configurations.

- Ils sont particulièrement intéressants pour des éléments techniques de configuration qui ne pourraient pas être maintenus à jour manuellement sans une certaine automatisation.

Par contre, il est important de rappeler quelques points à surveiller :

- Un actif n’est pas forcément un CI, et pourtant les outils d’inventaire / découverte remontent en général des actifs : exemple, une baie de disque est un actif, mais le CI est en général un volume disque : une réconciliation est nécessaire.

- Le risque est important qu’un outil d’inventaire / découverte remonte des informations très ou trop détaillées pour ce qu’on souhaite gérer : là aussi, une réconciliation (manuelle) sera nécessaire pour associer les informations détaillées avec le ou les CI que l’on a choisi de gérer : la charge pourra alors très lourde, en particulier si l’outil de découverte est utilisé de manière systématique.

- Plus généralement, les outils d’inventaire / découverte remontent les informations selon leur propre méta-modèle, modèle auquel il faut donc être capable de s’interfacer, et donc là aussi, réconciliation.

- Ne pas oublier également les contraintes imposées par les composants de sécurité (firewall) qui peuvent limiter le domaine de découverte, et alourdir le coût des serveurs de découverte,

- Importance de la réconciliation des données avant mise à jour, - Comment s’assurer que l’outil remonte bien tous les éléments ? Si certains

sont éteints ou non joignables lors du passage de la sonde ? Il faut donc prévoir tous les scénarios de traitement.

PAG

E 50

5.2.1.12 Définition de rôles, contrôle d’accès

Une CMDB étant un outil contenant un nombre très important d’informations, la définition des rôles et des contrôles d’accès associés est une étape très importante.A ces rôles seront associés des « vues », telles que définies précédemment dans ce chapitre.

D’une manière générale, on peut dissocier grossièrement les populations qui auront accès à la base, à s’avoir ceux qui auront un accès en consultation et ceux qui auront un accès en modification.

Cette répartition dépend de chaque structure et du périmètre fonctionnel de l’outil choisi.

Une fois le curseur positionné, les rôles et les accès associés pourront être définis plus précisément indépendamment des différents acteurs potentiels, on pourra par exemple avoir une liste de rôles tels que :

• Responsable d’affaire • Comité des changements (CAB) • Chef de Projet • Responsable des changements • Responsable des mises en production • Responsable métier • Responsable des Assets • Responsable des Configurations • Administrateur métier (BDD, Windows, Unix, LAN, WAN, …) • Coordinateur du changement • Architecte • Réceptionniste du matériel • Client • Référant technique • Agent du Service Desk • Gestionnaire des Incidents • Superviseur • Direction de la production • Direction informatique • …

Certains de ces rôles peuvent se cumuler, ou même n’être attribués que temporairement (coordinateur d’un changement par exemple)

5.2.1.13 Les coûts

Les coûts de licence et de maintenance des progiciels constituent un poste important, et il existe une grande diversité de mode de facturation, par module, par nombre d’utilisateurs identifié ou flottant, en bundle, selon le nombre de CI, …. Il est

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

51

LiVR

E B

LAN

C

important de considérer aussi les postes suivants : - Coûts d’intégration : fonction du niveau de personnalisation souhaité (et/

ou nécessaire compte tenu du progiciel choisi) et du nombre de référentiels existants. Ce poste peut être particulièrement lourd pour les solutions complexes réalisées sur la base des produits des grands éditeurs.

- Coûts récurrents d’administration technique : exemple, jusqu’à 1 ETP pour les solutions des grands éditeurs, comparé à 1 à 3 jours par mois pour des solutions plus petites.

- Coûts récurrents d’administration fonctionnelle, là aussi fonction de la complexité de la solution mise en œuvre, du nombre de référentiels, …

- On peut enfin faire une analyse sur 5 ans en intégrant une migration de version logicielle de l’éditeur avec une certaine charge de réingénierie d’intégration, et les impacts en cascade dans le cas de configurations multi- éditeurs (qui aggrave d’ailleurs le risque d’une telle situation de migration).

5.2.1.14 Le tableau des solutions du marché

Le tableau ci-dessous recense les offres du marché les plus notables : les grands éditeurs et les moins grands côtoient des offres Open Source, ainsi que quelques solutions SAAS. Outre les noms de produits, éditeurs, et éventuellement suite associée, nous avons retenu dans ce tableau quelques colonnes caractérisant les différentes solutions - approche modulaire / intégré, modèle évolutif / figé, Option SAAS -, un commentaire, et une identification des nouveaux entrants et des évolutions notables.

Editeur Support en France open source Nom du produit spécifique CMDB Nom ou lien de la suite logicielle

de gestion des servicesArchitecture intégrée ou

modulaireMéta-modèle

personnalisableSaaS

Nouveaux entrants ou évolutions

notablesASG oui ASG MetaCMDB ASG Business Service Platform Intégré X

Avocent / Landesk LanDesk IT Service Management Intégré

AXIOS ouiModule Assyst de gestion des actifs

et des configurationsHelp Desk et incidents, problèmes,changements, niveaux de service

intégré Limitée

BMC oui BMC Atrium CMDB Enterprise Manager Remedy IT Service Management Suite modulaire EtendueCA oui CA CMDB Service and It Management modulaire Etendue Option

CMDBInfo oui ECDB ToolSet modulaireEasyCMDB Suite complète soutien des services ITIL intégré Option

EMC² (rachat de Infra en 2008)

oui Infra : Suite complète soutien des services ITIL intégré X

FirescopeFirescope ConfigurationManagement Data Base

Modulaire Etendue X

Front Range oui Front Range ITSM Intégré Etendue avec paramétrage standard livré

GLPI oui Gestion libre de parc informatique intégré Limitée HP oui HP Universal CMDB HP Service Management Center modulaire Etendue option

iET Solutions iET ITSM Configuration Management iET ITSM Intégré X

IBM Tivoli ouiIBM Tivoli Change and

Configuartion Management Data BaseGestion des systèmes et des actifs

Interlink Software Service Configuration Manager Modulaire

ISILOG ouiIWS 2009 Suite complète soutien des services ITIL

intégré Limitée Option

Mexon iET CMDB Discovery and Intelligence iET ITSM intégréN(I)² oui N(I)² Configuration Center N(I)² Management Center modulaire Etendue X

Novell (Managed Objects) oui Novell MyCMDB modulaire XONECMDB oui One CMDB

PS'SOFT ouiPS SOFT IT Asset Management

Next Generation (ITAM NG)PS Soft Service Management intégré Limitée

Pytheas oui Pytheas Asset Management Pytheas Service Desk / Center intégré LimitéeQpit Quism : Universal ITIL Service Manager intégré Limitée

ServiceNow Service Now.com : IT Service Management intégré Exclusiv. SaaS Sextant oui MPI : Gestion de service IT compatible ITIL intégré Limitée

Staff & Line oui Easyvista 2009 intégré Etendue Option Symantec oui Altiris Total Management Suite intégré Limitée

Symphion CMDB Snif Managed Service

Provider

PAG

E 52

Nous renvoyons le lecteur, pour des informations complémentaires, à des articles parus ces derniers mois :

- Comparaison des outils ITSM paru dans 01 Informatique Octobre 2009 - IT Service View CMDB, Vendor Landscape, Gartner, 2009

5.2.2 Les facteurs d’influence sur la réponse

5.2.2.1 Standard CMDB Federation

Le standard « CMDB Federation » : BMC, CA, Fujitsu, HP et IBM ont initié en 2006 une démarche élevée en juillet 2009 au rang de standard DMTF. Ce standard est pour l’instant encore peu intégré dans l’offre actuelle. Ce standard décrit le modèle et les services que doit fournir un outil CMDB pour fédérer plusieurs référentiels, ainsi que les services que pourront fournir les référentiels externes partenaires. Le modèle comprend :

- La CMDB fédérée, - Une interface avec les fournisseurs de données : les référentiels externes

ou plutôt les logiciels associés, - Une interface avec les utilisateurs de données : les outils de reporting, de

data mining).

Les services fournis par la CMDB seront utilisés par les fournisseurs de données et les utilisateurs de données. Quatre séries de services :

- Services d’administration de la CMDB : permet de décrire et d’abonner un référentiel externe en décrivant son modèle de données,

- Services de gestion du modèle de la CMDB : permet de décrire le méta-modèle des ressources – CI, relations, process, gérés dans la CMDB.

- Services de Requêtes soumises à la CMDB, - Services d’abonnement et de notification sur événements (changement, …).

De leurs cotés, les référentiels externes pourront fournir deux types de services :

- Services de Requêtes soumises au référentiel, - Services d’abonnement et de notification sur événements (changement, …).

5.2.2.2 Offres SaaS (Software as a Service ou fourniture de logiciels sous forme de services)

Quelques offres apparaissent avec une option SaaS et même en SaaS exclusif pour l’une d’entre elles.

Pour l’entreprise utilisatrice, il s’agit de l’accès à distance par le réseau Internet à des applications hébergées et exploitées par un fournisseur de services qui facture un droit d’usage.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

53

LiVR

E B

LAN

C

Le mode Saas peut être considéré dans certains projets comme un moyen de mettre la CMDB plus rapidement en place, et de ne se concentrer que sur les spécifications et paramétrage.

Il peut apporter des avantages sur :

- Le plan financier : réduction des budgets d’investissement et de la prise de risque sur les projets, TCO (Total Cost of Ownership) réduit…,

- Le plan fonctionnel : rapidité de déploiement, connectivité, évolutivité permanente...

Néanmoins, la prudence est de mise sur la jeunesse du marché (pérennité des fournisseurs,…) et sur la notion d’externalisation (confidentialité des données, disponibilité, sécurité, …).

Comme dans toute externalisation, il faut conserver la maîtrise des données.

5.2.2.3 Evolutions des technologies supportées

Selon la complexité de certaines architectures et la taille des sociétés, les modèles de données peuvent avoir à évoluer (nous avons parlé précédemment de circuit d’homologation de nouveaux CI), et notamment la CMDB peut être une base importante d’une stratégie « Cloud Computing », car elle permet de gérer les bases d’infrastructures nécessaires pour fournir ces services de « Cloud ».Plus particulièrement, on peut imaginer une CMDB au travers de laquelle seraient gérés directement :

- La modélisation de « Cloud » et Virtualisation de serveurs en relation avec les composants physiques de l’infrastructure : cela est clé pour une CMDB dans ce contexte

- Le provisionning de serveurs (comme pour du PaaS ou SaaS) : l’activation de ces serveurs peut se faire au travers d’une demande de changement standardisée qui s’appuie sur les informations disponible en base


5.3.1 Les étapes

Nous recommandons une démarche en 4 étapes :

- Elaboration du cahier des charges en fonction de : • l’expression de besoin, - les choix structurants : approche « intégré / modulaire », … - Recherche des solutions sur le marché (éventuellement RFI) et des entités en

charge de leur commercialisation et support local, identification de consultants possédant l’expérience de sélection.

- Consultation pour constitution d’une Short list à partir des réponses papier. - Maquettages des solutions short listées : un point important sera la mesure du

temps de modélisation par les différents soumissionnaires. Dans la mesure du

PAG

E 54

possible, cette étape sera réalisée par l’éditeur lui-même.5.3.2 Les ressources

Nous recommandons de rassembler pour cette étape de choix de produit(s) un panel le plus représentatif possible des futurs utilisateurs : il est en particulier fondamental d’associer pendant le maquettage et le choix final ceux qui auront à utiliser les écrans et fonctions du ou des produits sélectionnés. On peut alors créer un groupe de contributeurs au projet qui spécifiera et validera les étapes, afin de renforcer l’adhésion des équipes et de se positionner dans la futur organisation : par exemple, les équipes de production impliquées dans les étapes d’avancement du projet peuvent commencer à modifier leurs référentiels ou façons de traiter les données afin de rendre la transition encore plus facile.L’assistance de consultants spécialisés pour le choix de l’outil peut s’avérer utile.


5.4.1 Pièges à éviter

Dans ce chapitre aussi, nous vous proposons une liste de différents éléments que nous considérons comme des pièges, qu’il faut garder en tête dans la démarche de choix de l’outil CMDB :

- Prise de décision hâtive suite à démo marketing brillante. - Sous-estimer les coûts d’intégration initiale. - Sous-estimer les coûts d’administration technique et fonctionnelle de l’outil. - Sous-estimer les coûts de maintenance, d’autant plus dans le scénario «

modulaire » multi-éditeurs où le risque de modification de méta-modèle de l’un ou de l’autre à l’occasion d’un changement de version est présent.

- Surestimation de l’apport des outils d’inventaire et de découverte : si la mise en œuvre est inadaptée, le risque d’effet « poubelle » est présent.

- Survalorisation du critère sur les capacités de modélisation de la virtualisation (et par extension Cloud) : cette modélisation est le plus souvent assez limitée sur le terrain, car très lourde à suivre.

5.4.2 Quelques Suggestions…

- Choisir l’outil après la mise en place des process ITIL, ou bien l’inverse, mais il faut être conscient qu’on devra alors s’adapter au modèle de l’ERP !,

- Faire réaliser un maquettage pour les solutions short-listées sur un périmètre le plus représentatif possible, avant la décision,

- Impliquer tous les futurs utilisateurs lors de l’élaboration du cahier des charges et du processus de choix de l’outil,

- La mise en place de l’outil CMDB est un projet : prévoir MOA et MOE séparées, conduite du changement, communication, adhésion des utilisateurs,

- En fonction de la situation de votre organisation, intégrer des scénarii d’évolutions dans les objectifs généraux de la solution : externalisation, fusion / acquisition,

- Tenir compte des outils d’inventaires qui seront susceptibles d’alimenter la CMDB,

- Demander à pouvoir visiter un client de l’outil (si possible sans l’éditeur) qui l’a implémenté dans son entreprise.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

55

LiVR

E B

LAN

C

CONCLUSIONS DE L’ETUDE

Ce Livre Blanc de l’observatoire des Directeurs d’Infrastructure et de Production est dédié à la CMDB (Configuration Management DataBase). Ce livre est la résultante de l’analyse d’une enquête auprès des membres du CRIP, des réflexions des groupes et des sous-groupes de travail.Les points suivants se dégagent et méritent l’attention.

6.1 UN SUJET ANCIEN AVEC UN ECLAIRAGE NOUVEAU

La CMDB est étroitement liée à démarche ITIL, et la préoccupation croissante d’adresser ce sujet coïncide avec l’essor du référentiel de bonnes pratiques. Si le besoin de référentiels de données et de leur gestion est une problématique ancienne, son caractère essentiel est mis en lumière lors de la mise en place des processus ITIL. Et ce n’est certainement pas un hasard si dans la majorité des cas, la décision de mettre en place une CMDB s’appuie sur les limites de fonctionnement des processus sans CMDB.

La notion de CMDB est apparue dans ITIL V1 et V2 et alors cantonnée à un concept de base de données, elle a d’ailleurs vu son périmètre et sa nature évoluer dans ITIL V3 où on parle maintenant de CMS (Configuration Management System).

La CMDB suppose une vision globale et apporte donc un éclairage nouveau sur les référentiels de données traditionnellement limités à des considérations techniques.

6.2 UN OUTIL TACTIQUE

Le fait d’avoir dû préciser une définition commune du terme CMDB pour le groupe de travail (comme mentionné au début de ce livre) montre qu’il est impératif de clarifier explicitement les objectifs et attendus de la CMDB.

La question primordiale lorsqu’on parle de CMDB n’est en effet pas : « qu’est-ce que c’est ? », mais « pour quoi faire ? ». La CMDB se définit avant tout par son but, et c’est pourquoi il s’agit d’un outil essentiellement tactique.

La décision de mettre en place une CMDB est détaillée dans le chapitre 3. La CMDB est un moyen d’apporter une plus value à la gestion des services rendus aux utilisateurs et aux clients. Elle ne se restreint donc pas à la DSI mais concerne l’ensemble de l’entreprise.

L’adéquation du niveau hiérarchique de sponsoring, l’importance du rôle de responsable de CMDB et leur visibilité dans l’organisation constituent des facteurs clés qui conditionnent la réussite du projet CMDB.

6

PAG

E 56

6.3 UN OUTIL FEDERATEUR

Une CMDB est complexe parce que les volumétries de données sont importantes (plusieurs milliers voire plusieurs dizaines de milliers de composants), et parce que les informations sont globales à l’entreprise (matériels, applications, … mais aussi organisations, locaux. Services).

La CMDB doit fédérer les visions de l’ensemble des intervenants sur les composants du SI, tout en préservant les domaines de responsabilité de chacun. La conduite du changement et la communication autour du projet sont de fait essentiels à sa réussite.

Si toutes les étapes que nous proposons dans le circuit d’homologaton peuvent paraître lourdes pendant l’élaboration du modèle de la CMDB, celle-ci une fois en place devient un formidable vecteur pour fédérer l’ensemble des acteurs, en particulier de la DSI, autour d’une vision commune.

La définition de la structure de la CMDB, et de son modèle, constitue le point de départ du projet CMDB. Le chapitre ‎4, consacré à cette problématique, souligne la valeur ajoutée de la CMDB à savoir la formalisation des relations entre les CI, et le caractère spécifique de son contenu au contexte et aux besoins de l’entreprise.

La structure de la CMDB doit également être adaptable au cours du temps pour répondre à des besoins d’évolution du périmètre couvert ou de changements importants (réorganisation, nouvelles technologies, …).

6.4 UNE COHERENCE ENTRE OUTIL, PROCESSUS ET ORGANISATION

Trop souvent considéré à tort comme un projet purement technique, la CMDB est un projet global qui suppose une parfaite cohérence entre l’outil, les processus et l’organisation.

Afin de limiter le risque de dérive vers une démarche s’appuyant sur les outils techniques pour constituer la CMDB, nous préconisons de mener le projet CMDB par itérations favorisant une mise en place progressive et si possible avec une phase de validation sur un pilote. En particulier nous soulignons que le niveau de granularité de la CMDB doit être fonction du besoin et non de la capacité à faire.

Cette approche garantit la capacité d’adaptation de la CMDB en cas d’inadéquation avec les processus ou avec l’organisation.

Le choix de l’outil de CMDB constitue à ce titre une étape clé du projet CMDB. Cette problématique est détaillée dans le chapitre 5, qui propose notamment une revue des fonctions à attendre de la part des outils du marché. Même si les outils du marché apparaissent de plus en plus matures, nous préconisons fortement de procéder à des maquettages pour vérifier que l’outil satisfait bien les besoins et non que ce sont les processus et l’organisation qui devront être conformes à l’outil. Ce principe

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

57

LiVR

E B

LAN

C

est également applicable en cas de préférence pour une solution propriétaire, ce qui est le cas dans 1/3 des entreprises consultées.La cohérence entre outil, processus et organisation doit être soutenue par la constitution d’une équipe pluridisciplinaire. Les acteurs du projet CMDB doivent permettre de couvrir les besoins en compétences :

- De modélisation, - Opérationnelles sur les problématiques fonctionnelles

(processus, ergonomie, …), - Techniques (bases de données, outils d’inventaire, …), - Organisationnelles (conduite du changement, communication, …).

En conclusion, le projet CMDB ne doit pas être vu comme un projet uniquement technique mais également comme un projet d’organisation. La mise en place d’une CMDB peut se révéler un projet long et complexe, mais c’est un extraordinaire outil fédérateur au sein de l’entreprise, en terme de : - Mise en partage et sécurisation de la connaissance • Il transcende les frontières entre les domaines (Réseau – Système –

BDD, Production – Etudes, DSI – Métier – Finance), • Il réduit la courbe d’apprentissage des intervenants, • Il diminue le risque de perte de connaissance avec le départ

d’« experts historiques » de l’organisation. • Partage d’informations et de bonnes pratiques

Il n’y a pas de démarche ITIL structurante sans CMDB

PAG

E 58

Le credo du CRiP : Indépendance par rapport aux fournisseurs et sociétés de consulting

Le mode de fonctionnement Actuellement, dix groupes de travail thématiques se réunissent tout au long de l’année. 4 autres groupes sur les thèmes Base de Données, Réseaux, Orchestration et Efficacité Energétique sont en cours de création. Les travaux de ces groupes sont présentés à l’ensemble des membres deux fois par an lors des plénières et à l’occasion de la Convention annuelle du CRiP au sein d’itiForums.

Président :• Philippe SERSOT - CA-CIB - CTO

Vice-présidents :• Marc LIMODIN

LA BANQUE POSTALE Directeur des Techniques et Infrastructures

• François STEPHAN - THALES Directeur Technique

• Eric STERN ORANGE-FRANCE TELECOM Responsable Expertise Environnement Technique

• Noël CAVALIERE PSA PEUGEOT-CITROËN Responsable de l’Architecture Technique

• Olivier MAUPATE IT Director

• Claude CORIAT – RENAULT Responsable Stratégie et Politiques Techniques

• Jean-Paul AMOROS GDF SUEZ CTO

• Pascal PICCHIOTTINO BOUYGUES TELECOM Responsable Département Infrastructure SI Réseau

• Frédéric DIDIER CREDIT FONCIER Directeur Production Informatique

Secrétaire : Michel GROSBOST

Trésorier : Gilles ALBERT SOCIETE GENERALE-PAEN Technology Strategy Manager

Le Bureau exécutif

Le CRiP (Association Loi 1901) compte 95 grandes entreprises ou entités utilisatrices des technologies de l’information, adhérentes ou en cours d’adhésion.Il rassemble une communauté de plus de 550 membres, responsables d’infrastructure ou de production.

Le CRiP est un cercle de confiance, lieu d’échanges et d’informations entre les différents membres confrontés aux mêmes défis financiers, technologiques et organisationnels.

Objectifs- Etre plus performant dans les métiers de l’infrastructure et de la

production - Partager nos visions et retours d’expériences - Echanger et travailler sur • les technologies • les ressources humaines • les organisations et processus • les approches financières des projets • les relations avec les offreurs - Promouvoir notre fonction au sein des entreprises - S’appuyer sur les travaux du CRiP pour asseoir une position au sein de

notre entreprise - Créer un réseau de communication rapide et efficace entre dirigeants.

Le CRiP a fêté sa deuxième année d’existence le 16 Novembre 2009

Ces deux premières années ont été riches en contributions diverses : création et animation de dix groupes de travail, création d’une cellule d’intelligence économique, publication de 4 livres blancs, création d’une Base Projets, organisation des trois plénières annuelles, mise en place du site web www.crip-asso.fr, de la Newsletter et prise en charge des comités de programme, des présentations, des retours d’expériences, des tables rondes de la Convention annuelle du CRiP aux journées itiForums.

Je voudrais remercier les membres du bureau et tous ceux, nombreux, qui participent aux groupes de travail. Cet excellent travail, en équipe, contribue au large développement de notre club utilisateur. Pour l’avenir, nous voulons poursuivre et amplifier cette façon de procéder au service des Responsables d’Infrastructure et de Production, avec la volonté affirmée d’être un cercle de confiance réciproque.Nous souhaitons, ainsi, parfaire les maîtrises, partager les retours d’expériences, analyser et parvenir à améliorer les organisations, les ressources humaines, les technologies, les approches financières du SI et les processus de décision.

Nous chercherons également à promouvoir et à légitimer les missions de ces responsables au sein de leur entreprise et à développer une approche pragmatique des Infrastructures et de la Production.

Enfin, nous nous appliquons à développer la notoriété du CRiP et à faire en sorte que notre association devienne une référence vis-à-vis des fournisseurs du marché.

Nous devons nous attacher à recruter de nouveaux membres tout en amplifiant notre politique volontariste de communication avec itiForums (Conférence, Reportages Vidéos, Cercle i, i Connect).

J’espère que cet esprit d’équipe, construit tout au long de ces deux premières années, nousconduira à développer ce lieu d’échanges constructifs concernant nos préoccupations quotidiennes, permettant à chacun d’apprécier le bien-fondé de notre association. Nous sommes convaincus que vous serez nombreux à nous rejoindre.

Philippe SERSOT Président du CRiP

CTO CA-CIB

A propos du CRiP

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

59

LiVR

E B

LAN

C

Au delà du groupe de travail CMDB,13 autres de travail sont actifs à ce jour

Livre BlancEnquête et Analyse

de Tendances du Stockage(édité en novembre 2009)

STOCKAGEAnimé par Jean-Pierre DUMOULINDirecteur Technique InfrastructurePSA PEUGEOT-CITROËN

Objectifs : Identifier et partager les bonnes pratiques dans le domaine du stockage

Thèmes abordés : - Virtualisation du stockage : quelles

solutions pour quels besoins ? - Les principaux besoins - Virtualisation du Stockage

SAN & blocks, NAS & Fichiers, Tape & Librairies de sauvegarde

- Virtualisation dans le SAN o dans la baie, InBand ou Outband

- Techniques de réplication du stockage inter-sites dans une optique PRA et « DataCenter Virtuel »

- VTL - Déduplication du stockage primaire

CRIP ThématiqueStockage

13 octobre 2010

MÉTIERSAnimé par Marc LIMODIN Directeur des Techniqueset des InfrastructuresLA BANQUE POSTALE

Objectifs :Traiter - de l’évolution des métiers d’infrastructure

et de production - des problématiques de ressources

humaines - des problématiques d’organisation - Partager pour être plus performant et

anticiper sur : • Les bonnes pratiques • Les modèles d’organisation alignement

avec les métiers • Le sourcing / la formation • L’adaptabilité des ressources aux

processus et technologies • Identifier des thèmes à travailler en

sous-groupe

Thèmes abordés : - Evolution des métiers - Facteurs d’évolution - Les nouveaux métiers - Les métiers en devenir - Les métiers en retrait - La sous-traitance - Les problématiques RH

LOW COST Animé par Frédéric DIDIERDirecteur Production InformatiqueCREDIT FONCIER

Objectifs : - Inventorier les pratiques d’infrastructures

en rupture avec les pratiques usuelles en vue de réduire les coûts.

- Etre une référence permanente des pratiques : • pour les responsables d’infrastructure • un guide de bonnes pratiques

- Inciter les fournisseurs à offrir des solutions low-cost

Thèmes abordés : - L’impact des techniques de virtualisation

pour les serveurs et pour les postes de travail

- Automatisation de la gestion des systèmes,

- Mesure de la pénétration de l’Open source - Utilisation des composants

”grand public“ et ”jetables“ (mais recyclables !)

- Impact de la standardisation des processus de production autour d’ITIL

- Sourcing, externalisation, offshoring - Approches financières - Mutualisation inter-entreprises - Réduction des services et du support - Abaissement des exigences

sur les data centers - Green IT, gestion de l’énergie

SGBDAnimé par Jean-Paul VEZARDResponsable DBASOCIETE GENERALE

Objectifs et Thèmes : - Performance et Métrologie• Identifier les métriques Systèmes, SGBD

et Applicatifs représentatifs du niveau de performance et des coûts

• Identifier les outils de métrologie à mettre en place depuis la phase de spécification jusqu’à l’exploitation

• Identifier les challenges majeurs chez les utilisateurs

• Élaborer la cartographie solutions actuellement utilisées

- Les BD Open Source, une opportunité ou un leurre pour réduire les couts ?

- Recenser les solutions de Hautes disponibilités pour les base de données (locales ou Campus)

DATACENTERAnimé par Claude CORIATResponsable Stratégie et Politiques Techniques - RENAULT

Objectifs : Mettre en avant les meilleures pratiques en production du DataCenter de demain.

Thèmes abordés :- Processus d’efficacité énergétique - Qualification et Benchmarking- PUE : Identification des indicateurs de

mesure de performance des DataCenters - Outillage pour la mesure et la bonne

gestion du Froid - Suivi de la consommation électrique- Initiatives Green DataCenter :

démarches d’optimisation - Liste et caractéristiques des différents

hébergeurs - Comment (ré-)urbaniser les salles

informatiques ?- Audit des DataCenters- Green datacenter : Automatisation sur les

opérations (automatisation et outils…), - Retour d’expérience sur la mise

en œuvre des processus ITIL

CLOUD COMPUTINGAnimé par François STEPHAN Directeur IT TransformationTHALES

Objectifs : - Définir la compréhension et la traduction

opérationnelle par les membres du CRIP des modèles de Cloud Computing

- Identifier les composantes clés, selon le CRIP, des solutions de Cloud Computing pour les entreprises/administrations et organisations IT

- Décrire les expériences et stratégies des membres du CRIP sur le Cloud Computing

Thèmes abordés : - Définition des concepts :

Cloud Computing, SaaS, IaaS, etc. - Gains attendus et gains constatés - Sécurité des solutions de Cloud Computing - Modèles Cloud Computing : public,

privé, mixte - Retours d’expériences, attentes

et roadmaps des membres du CRIP

GOUVERNANCEAnimé par Jean-Paul AMOROSCTOGDF SUEZ

Objectifs et thèmes : - Partager les retours d’expérience d’alignement métiers des productions

présentes au CRIP - Proposer des kits opérationnels aux productions informatiques pour réaliser

cet alignement (par exemple des catalogues de services, des bench sur les prix, des format de reporting,….).

- Partager sur la gouvernance des contrats fournisseurs en général (outsour-cing, forfait,…), mais aussi en particulier (microsoft,…)

- Comment développer de la valeur ajouté dans des contextes fortement outsourcés…

ORCHESTRATIONAnimé par Hugues FONDEUXResponsable Projet INFRA 2.0PSA-PEUGEOT CITROEN

Objectif : Obtenir des gains de productivité tout en améliorant la qualité de service et l’efficacité opérationnelle, c’est indéniablement l’automatisation des processus de l’exploitation.

Thèmes abordés : - Les besoins adressés par un orchestrateur :

• le provisioning de ressources • la gestion de fermes de serveurs • le traitement automatisé d’incidents aux Opérations • l’automatisation du travail des industrialisateurs, des experts logiciels • l’accélération des PRA (Plans de Reprise d’Activité) • le déploiement d’applications ...

-Le rythme de déploiement -Les bonnes pratiques de mise en œuvre et les difficultés rencontrées -Les éléments de rentabilité- Les outils du marché ou de l’open source : leur perception, leurs spécificités… -L’impact de ces outils sur les processus d’exploitation

EFFICACITE ENERGETIQUEAnimé par Eric STERNResponsable Expertise Environnement TechniqueORANGE FT GROUPE

Objectifs: -Mettre en avant les meilleures pratiques, et les actions à mener pour soit, diminuer la consommation, soit améliorer l’efficacité énergétique de l’ensemble des composants d’infrastructure et d’environnement technique de nos sites de production.-Proposer un certain nombre d’indicateurs pertinents qui permettent de s’éva-luer en terme d’efficacité et de suivre l’évolution des consommations.

Thèmes abordés : - Comment mesurer son efficacité énergétique ?- Quels indicateurs pour évaluer et quelle pertinence ? Quelles sont les voies qui menent à une meilleure efficacité énergétique ?- Actions autour de l’environnement technique - Optimisation du conditionne-

ment d’air, des chaînes de distribution électriques, ...- Actions sur l’infrastructure technique - Consolidations, virutalisations, ...- Outillage de mesures- Processus de gestion des capacités électriques, climatiques, ...- Design de site, localisation, isolation, ...- Urbanisme des salles informatiques, gestion des flux d’air, …

z/OSAnimé par Bruno KOCHDirecteur Délégué Architecture Système MainframeCAISSE EPARGNE

Thèmes et Objectifs : - Analyser les caractéristiques

et l’organisation de la plate forme « z » chez les utilisateurs

- Elaborer la cartographie matérielle et logicielle chez les utilisateurs

- Identifier les évolutions majeures chez les utilisateurs

- Comprendre le positionnement de la plate forme « z » au sein des SI et les orientations à court et moyen terme

- Identifier les acteurs du marché - Analyser les tendances du marché

ARCHITECTURE TECHNIQUE D’ENTREPRISEAnimé par Alain BALAGUER Responsable ArchitectureBOUYGUES TELECOM

Objectifs :- Une analyse des modèles émergents

tournés vers la standardisation et la mise en oeuvre de modules opérationnels pour la construction d’un système d’information.

Thèmes abordés : - Les composantes de l’architecture

classique • L’ architecture des processus

métiers • L’ architecture applicative • L’ architecture des données • L’ architecture technique- La modularisation- Les différents modèles lies à : • la résilience serveurs et données • la virtualisation des applications • la virtualisation des serveurs

et du stockage • les clouds privés • la mobilité des accès aux SI • l’authentification et l’habilitation

PRA Animé par Luc VRIGNAUDResponsable Diffusion Support et SécuritéMACIF

Objectifs : Analyser les architectures des infrastructures de secours et de cohérence applicative, les aspects spécifiques liés à l’outsourcing, les critères de validation puis de MCO du PRA, l’organisation et le processus de déclenchement.

Thèmes abordés :- Validation probante d’un PRA- Comment négocier un contrat d’out-

sourcing ?- Architectures de secours et

cohérence applicatives d’un PRA- Maintien en Condition

Opérationnelle d’un PRA- Critères de déclenchement d’un PRA- Concepts et vocabulaire PRA

VIRTUALISATION SERVEUR & POSTE DE TRAVAILAnimé par Marie Christine MOULLART Responsable Exploitation/Direction Infrastructures et SupportGENERALI

Objectifs :- Recenser des expériences et les solutions

à maturité, - Analyser les enjeux et le positionnement

vis-à-vis des métiers, - Décrire la démarche projet.

Thèmes abordés : - Les différentes solutions de virtualisation- Cartographie des systèmes en production- Arguments en faveur de la virtualisation- Les bonnes pratiques, les pièges,

les limites- Les fournisseurs et l’offre- Les impacts projets/homes/processus- Les gains financiers et niveaux de services

Livre BlancAnalyse et Tendance,

vers le Datacenter idéal(édité en juin 2009

à l’occasion de la Convention CRIP/ITIFORUMS)

Livre BlancAnalyse et Grandes Tendances

du Cloud Computing(prévu en juin 2010

à l’occasion de la ConventionCRIP/ITIFORUMS)

CRIP ThématiqueVirtualisation Serveurs

19 mai 2010

Livre BlancAnalyse et Tendance, PRA 2010

(prévu en novembre 2010)

CRIP Thématiquez/OS

16 septembre 2010

En association avec

CRIP Thématique

Datacenter Facilities

17 novembre 2010Livre BlancAnalyse et Tendance,

(prévu en novembre 2010)

PAG

E 60

L’Observatoire des Directeurs d’Infrastructure et de Production est une initiative du CRiP. Cet observatoire regroupe l’ensemble des documents produits par les groupes de travail. A l’usage des membres du CRiP, ces documents sont de plusieurs types :

• Enquête et Analyse des tendances• Livre Blanc : les meilleurs pratiques • Dossier d’analyse des innovations technologiques

et d’aide à la rédaction d’appel d’offre• Fiches pratiques

Les Enquêtes et Analyses de tendances sont issues de questionnaires renseignés par les membres du CRiP. L’analyse des résultats recueillis permet de mesurer et d’observer l’évolution des enjeux des CTOs et de leurs infrastructures. En outre, elle met en relief les grandes tendances liées aux principaux challenges des productions informatiques. Dans le cadre de l’Observatoire des Directeurs d’Infrastructure et de Production, chaque groupe de travail actif apporte une contribution importante dans l’élaboration de documents de référence.Actuellement, dix groupes de travail CRiP sont actifs : DataCenter, Stockage, Could Computing, Low Cost, z/OS, Métiers, CMDB, PRA, Architecture Technique, Virtualisation Serveur & Poste de Travail. Dans les prochains mois, le CRiP prévoit le démarrage de groupes de travail supplémentaires: les réseaux, les bases de données, le Green IT, l’Orchestration.

Depuis plus de deux ans, bon nombre de documents ont été publiés.

Parmi les plus significatifs, on mentionnera :- Livre Blanc Enquête et Analyse des Tendances Serveurs- Enquête et Analyse des Opérations informatiques - Enquête et Analyse des tendances liées au Datacenter- Livre Blanc Meilleures Pratiques du DataCenter- Enquête et Analyse des Tendances du Stockage- Fiche Pratique Alignement Stratégique de la Production

Informatique aux Métiers de l’Entreprise- Dossier Technique Datacenters :

Efficacité Energétique et indicateurs de performances

Tous ces ouvrages produits ou en cours de production deviennent inéluctablement une référence importante pour les CTOs.Ils permettent de s’affranchir d’études parfois longues et coûteuses et de se « benchmarker » par rapport aux grandes tendances actuelles. Plus généralement, ils sont des outils reconnus pour l’amélioration de la productivité.

Les livrables du CRiP

Les CRiP Thématiques

Charte d’Ethique et d’Engagement du CRiP

Le Club des Responsables d’Infrastructure et de Production est constitué sur la base de valeurs et de principes d’action et de comportement, fon-dés sur des rapports de confiance permanents entre ses membres. Les membres sont les représentants des sociétés adhérentes du CRiP.

Principes d’action· Respect de la loyautéLes membres du CRiP ont pour principe la loyauté à l’égard des autres par-ticipants afin d’instaurer et de maintenir des relations de confiance durables. · Participation activeLes sociétés adhérentes au CRiP et leurs représentants membres du CRiP s’engagent à contribuer activement à la vie du Club en apportant leur expé-rience et leur savoir faire aux travaux collectifs. Les sociétés adhérentes s’engagent- à répondre dans un délai convenable aux différents questionnaires qui

pourraient leur être envoyés- à faire participer au moins un de ses représentants à au moins un groupe

de travail ou à une cellule- à favoriser la participation de ses représentants aux plénières du CRiP- à promouvoir le CRiP au sein de leur organisation Les membres représentants s’engagent- à se comporter en ambassadeur du CRiP et à promouvoir le CRiP auprès

de leurs pairs et des fournisseurs

- à participer activement dans la mesure de leurs compétences, de leurs moyens, et de leurs autorisations internes aux conférences CRiP/ itiForums, soit en tant que membre d’un comité de programme, à travers un témoignage, une table ronde ou en aidant à la production de contenu.

Principes de comportement· ConfidentialitéChaque membre du CRiP s’engage à ne pas divulguer à des tiers les infor-mations professionnelles présentées, sans accord explicite des membres émetteurs et du bureau exécutif du Club. Chacun des participants, membre permanent ou occasionnel, s’interdit d’utiliser directement ou indirectement, à des fins personnelles, des informations sensibles qu’il pourrait détenir dans le cadre du Club. · Conflits d’intérêtsChaque membre du CRiP se doit d’éviter toute situation de conflit entre les intérêts du Club et ses intérêts personnels ou ceux de ses proches.Le Club est un club d’utilisateurs.Cependant certains de ses membres peuvent appartenir à des sociétés ad-hérentes qui peuvent avoir dans leurs missions une offre de service pour les autres adhérents. Il est impératif dans ce cas que les représentants membres de ces dites sociétés aient un comportement irréprochable et n’utilisent pas ce cercle de confiance pour promouvoir les offres de services de la société qui les emploie.

Nicolas COURAUDResponsable de la coordination

des travaux du CRiP

Le format choisi permet à l’auditeur :- de se forger une opinion en toute indépendance à travers la restitution

des travaux du CRiP, Club utilisateur des Responsables d’Infrastruc-ture et de Production dont le crédo est l’indépendance vis-à-vis des fournisseurs

- de découvrir à travers des témoignages utilisateurs l’implémentation

opérationnelle des technologies et solutions avec leurs composantes clés, leurs business case, leurs bénéfices: promesses et réalités, leurs écueils et freins

- de bénéficier de l’éclairage sur les grandes tendances et le panorama de l’offre par un cabinet d’analyste de renommée internationale « Forrester Research » qui est le partenaire stratégique du CRiP

- de rencontrer les acteurs majeurs du marché à l’occasion des pauses et du cocktail qui clôture ces sessions

Les CRiP Thématiques programmées en 2010 sont :

z/OS - 16 septembre 2010 Stockage - 13 octobre 2010

Data Center Facilities - 17 novembre 2010

Les CRIP thématiques sont des conférences qui apportent l’éclairage du CRIPsur les grands sujets d’Infrastructure et de Production traités par ses groupes de travail.

Les exposés agnostiques du groupe de travail et des analystes (Forrester par exemple), associés aux retours d’expériences des membres du CRIP permettent de présenter l’état de l’art et les traductions opérationnelles

des services et technologies dans la vraie vie de l’entreprise.

CM

DB

: E

nquê

te e

t Ana

lyse

des

Ten

danc

esPA

GE

61

LiVR

E B

LAN

C

La convention signée avec le CRIP facilite la relation du CRIPavec le reste de l’écosystème. Cette relation étroite entre les deux partenaires apporte les bénéfices suivants aux membres du CRIP : 1) CONFERENCE CRIP/ITIFORUMS Le CRIP bénéficie d’une tribune officielle annuelle. Les membres du CRIP pilotent les comités de programme, animent les tables rondes, présentent les résultats de leurs groupes de travail et témoignent sur leurs retours d’expériences. 2) CERCLE ICes événements permettent aux membres du CRIP de rencontrer les dirigeants des fournisseurs de produits et de services d’infrastructures et de production 3) I-CONNECTUn réseau on line, rapide et efficace, qui permet aux membres du CRIP, d’une part de communiquer entre eux, et d’autre part de communiquer avec les dirigeants de l’écosystème. 4) BASE DOCUMENTAIREwww.itiforums.com permet de rechercher les documents publics produits par le CRIP, les autres clubs utilisateurs (Archivage, Continuité d’Activité, et Data Center Facilities), et les experts dans ces domaines. 5) CRIP THEMATIQUE Des conférences sur les thèmes que traitent les groupes de travail du CRIP. Ces conférences sur l’Etat de l’Art font appel à des CRIP STRATEGIC PARTNER pour un éclairage sur les grandes tendances mondiales.

ITIFORUMSUne relation stratégiqueet privilégiée avec le CRIP

Connect

Connect

PAG

E 62

Plus de 95 grandes entreprises françaisesadhèrent ou sont en coursd’adhésion au CRiP :TOTALMAAFL’OREALGROUPAMA SIDARVASYSTÈME U OUESTADP GSIAEROPORTS DE PARISERDFGIE ALLIANZ INFORMATIQUEEIFFAGEMINISTERE DES FINANCESRENAULTGE MONEY BANK FRANCEAREVA LA FRANCAISE DES JEUX SWISS LIFEAUCHAN INTERNATIONAL TECHNOLOGYAVIVAGDF SUEZSOCIETE GENERALE PAENAXA TECHSOCIETE GENERALE SGCIBBOUYGUES TELECOMCA SILCAINFORMATIQUE CAISSE DES DEPOTSLA BANQUE POSTALECAISSE EPARGNECREDIT AGRICOLE CIBCANAL +CASINOTHALES GROUPVALLOURECMANPOWER FRANCERTE FRANCECHOREGIECNAVGROUPAMA SYSTEMES D’INFORMATION

CNP ASSURANCESMINISTERE DE LA DEFENSE - CPSIATCREDIT FONCIEREDFESSILOR INTERNATIONALFM LOGISTICGENERALII-BPAIR FRANCEMACIFMINISTERE DE L’INTERIEURCARREFOUR GROUPENATIXISOECDORANGE FT GROUPEPMUPSA PEUGEOT-CITROENRATPSCORSTIME POLE EMPLOIBICDARVASAINT GOBAINIMSSNCFSFRLABORATOIRES BIOMERIEUXCCR ASSET MANAGEMENTLAFARGE SERVICEARAMICELOUIS VUITTON MALLETIERNORBERT DENTRESSANGLEDCNS GROUPAIR LIQUIDECREDIT IMMOBILIER DE FRANCEKEOLISEtc…

ContactsClub des Responsables d’Infrastructure et de [email protected]

En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation du CRiP.

Facilitateur de projets

Cabinet de conseil opérationnel,CG2 Conseil aide les entreprises à créerde la valeur ajoutée pour les métiers à travers le SIPositionnées à la croisée des métiers et de la DSI,nos missions s’articulent autour de 2 axes complémentaires :* Préparer l’entreprise du futur pour aligner vos projets de transformation

et votre organisation sur votre stratégie,* Faciliter les projets pour en faire des réussites métier.

Fort d’une équipe de 40 consultants, le cabinet affiche un CA de plus de 5M€ à fin 2009 avec une croissance de 20% depuis 5 ans.

Au sein du cabinet, notre pôle « Performance des services »intervient autour de 2 grands thèmes :• Adapter votre organisation à votre stratégie,• Livrer à vos clients le ’juste‘ service.

L’objectif pour nos consultants est d’accompagner les clients pour répondre aux attentes des métiers en trouvant les bons leviers pour un ’juste‘ équilibre entre qualité de service et maîtrise budgétaire, et notamment :• D’organiser et d’optimiser les ressources et les actifs,• De dégager des gisements de productivité sans nuire à la qualité de service,• D’accompagner la transformation,• De promouvoir la fonction informatique.

La valeur ajoutée du cabinet repose sur cette approche du conseil, engagée dans ses préconisations, tournée vers les résultats.

www.cg2conseil.com

Cré

atio

n : f

red.

lam

eche

- w

ww

.ano

usde

joue

r.fr

www.crip-asso.fr

15 rue vignon

75008 PAriS