De quelles composantes technologiques dépendent nos services TI? Voilà une question qu’un nombre croissant d’organisations se pose depuis un an ou deux. Qu’il s’agisse de cybersécurité, conformité, continuité des affaires, gestion des pannes et de leurs impacts, évolution applicative accélérée (agile, DevOps), prise de décision éclairée selon le contexte et l’impact d’affaires… un référentiel reliant les services TI aux composantes technologiques devient vite incontournable.
Dans le quotidien, un tel référentiel peut porter plusieurs noms : système d’inventaire, Configuration Management Database (CMDB), Configuration Management System (CMS), etc. Cependant, le besoin auquel il répond demeure le même : mieux comprendre l’environnement pour mieux agir.
Souhaiter se doter d’un tel référentiel est une chose. Le déployer avec succès en est une autre. Voici ce que nous avons appris en l’implantant chez nos clients récents :
Même avec ces considérations, la mise en place de la gestion des configurations demeure un travail complexe, de longue haleine et pavé de risques. Voici 8 pièges à éviter pour améliorer vos chances de succès.
1— Lancer l’initiative de mise en place d’une CMDB sans objectifs précis
Souvent, les organisations se lancent dans la mise en place d’une CMDB sans avoir au préalable clarifié leurs objectifs. Comprendre la contribution générale d’un tel référentiel au gain de maturité de processus telle la gestion des incidents ou des changements est une chose. Posséder des objectifs précis en est une autre.
Pour obtenir des bénéfices tangibles, il est nécessaire de clairement énoncer ce que l’on souhaite atteindre au moment de l’implantation. Par exemple, « nous devons être en mesure d’améliorer l’analyse de risque d’un changement », ou « nous avons besoin de comprendre le niveau de criticité d’un service afin de bien gérer la panne majeure » sont bien plus spécifiques et conditionneront la manière dont le déploiement de la CMDB sera abordé. En particulier, pendant l’implantation, ces objectifs aideront à trancher toute question concernant la portée ou l’inclusion de types d’éléments particuliers. On préviendra ainsi l’éparpillement qui est souvent le pire ennemi des projets de CMDB.
2— Croire qu’une CMDB est un projet principalement technologique
Le mythe est très fort : une CMDB serait uniquement un projet technologique. Certes, gérer les configurations requiert beaucoup de technologie : un système où se loge la CMDB, de l’automatisation (c.-à-d. de la découverte). Cette technologie rend la CMDB possible, mais n’est qu’un de ses aspects.
En effet, gérer des configurations requiert aussi une implication humaine importante. Pour que votre CMDB apporte les bénéfices escomptés, il vous faudra :
Ces tâches et responsabilités ne peuvent être assumées par des machines. Au-delà de la technologie, votre — plus grand défi -- sera de responsabiliser vos équipes et de les rendre imputables de la qualité et de la maintenance des données. Pour cela, vous aurez besoin de gouvernance (voir aussi le point 8).
Pour résumer, la mise en place de la gestion des configurations est avant tout un projet qui implique des humains et des responsabilités. Une gouvernance active sera une des clés du succès.
3— Concevoir la solution CMDB en vase clos
La gestion des configurations (SACM) est au cœur de la gestion des services TI : la majorité des autres processus TI consomment l’information qu’encadre le processus SACM. Ainsi, c’est l’information-clé fournie par le processus SACM qui permet à l’organisation de s’assurer qu’elle livre bien les services conformément aux ententes
Parce que le processus SACM est essentiel à tant de processus qui en dépendent, le nombre de parties prenantes est important. Deux de ces parties prenantes doivent impérativement être impliquées dans le design de la solution :
Élaborer une CMDB en vase clos n’est donc pas recommandé. En particulier, les deux groupes mentionnés ci-dessus doivent être activement impliqués pour la durée du projet.
4— Croire en une super-CMDB monolithique
L’expérience de terrain démontre qu’une super CMDB unique centralisant toute l’information de l’entreprise n’est ni viable, ni souhaitable. Dans les faits, plusieurs systèmes contiennent déjà les informations en question. Pourquoi ne pas plutôt mettre en relation toutes ces sources autoritaires ?
En fait, la meilleure approche est de mettre en place une CMDB intégratrice (et non pas centralisatrice) qui :
5— Mettre en place une pyramide coupée : oublier les services et applications
Le modèle d’une CMDB ressemble à une pyramide dont chaque couche a son importance et ses spécialistes. Il est aujourd’hui assez simple de découvrir via des automatismes le contenu des couches du centre (infrastructure et infrastructure applicative). Plusieurs projets tombent donc dans le piège de s’y limiter et négligent les deux couches du haut (applications et services). Pourtant, c’est vraiment là que la valeur de la CMDB se concrétise !
Dans le quotidien, un tel référentiel peut porter plusieurs noms : système d’inventaire, Configuration Management Database (CMDB), Configuration Management System (CMS), etc. Cependant, le besoin auquel il répond demeure le même : mieux comprendre l’environnement pour mieux agir.
Souhaiter se doter d’un tel référentiel est une chose. Le déployer avec succès en est une autre. Voici ce que nous avons appris en l’implantant chez nos clients récents :
- L’implication et le support de la gestion sont cruciaux, comme pour toute transformation majeure
- L’amélioration continue est un ingrédient incontournable une fois le projet livré
- L’aspect humain est une composante essentielle au succès, et ce, à plusieurs niveaux : design de la solution, changement des comportements, transfert de connaissances, compréhension des concepts et des outils, prise en charge des responsabilités et engagement, etc.
- Il faut clairement distinguer gestion des configurations, gestion des actifs TI et gestion de l’inventaire :
- Gérer un inventaire c’est gérer une liste simple d’éléments, sans contexte ni liens.
- Gérer des actifs TI implique l’ajout d’un cycle de vie, de contrôles et d’un volet financier (coût, amortissement, contrats, etc.).
- Gérer des configurations requiert l’ajout des liens entre les éléments pour démontrer comment ils contribuent à livrer un service TI à une ligne d’affaires. Ce faisant, la gestion des configurations établit une réelle cartographie orientée affaires de vos environnements.
Même avec ces considérations, la mise en place de la gestion des configurations demeure un travail complexe, de longue haleine et pavé de risques. Voici 8 pièges à éviter pour améliorer vos chances de succès.
1— Lancer l’initiative de mise en place d’une CMDB sans objectifs précis
Souvent, les organisations se lancent dans la mise en place d’une CMDB sans avoir au préalable clarifié leurs objectifs. Comprendre la contribution générale d’un tel référentiel au gain de maturité de processus telle la gestion des incidents ou des changements est une chose. Posséder des objectifs précis en est une autre.
Pour obtenir des bénéfices tangibles, il est nécessaire de clairement énoncer ce que l’on souhaite atteindre au moment de l’implantation. Par exemple, « nous devons être en mesure d’améliorer l’analyse de risque d’un changement », ou « nous avons besoin de comprendre le niveau de criticité d’un service afin de bien gérer la panne majeure » sont bien plus spécifiques et conditionneront la manière dont le déploiement de la CMDB sera abordé. En particulier, pendant l’implantation, ces objectifs aideront à trancher toute question concernant la portée ou l’inclusion de types d’éléments particuliers. On préviendra ainsi l’éparpillement qui est souvent le pire ennemi des projets de CMDB.
2— Croire qu’une CMDB est un projet principalement technologique
Le mythe est très fort : une CMDB serait uniquement un projet technologique. Certes, gérer les configurations requiert beaucoup de technologie : un système où se loge la CMDB, de l’automatisation (c.-à-d. de la découverte). Cette technologie rend la CMDB possible, mais n’est qu’un de ses aspects.
En effet, gérer des configurations requiert aussi une implication humaine importante. Pour que votre CMDB apporte les bénéfices escomptés, il vous faudra :
- Définir et maintenir un catalogue de service TI
- Comprendre et représenter les liens entre les services, les applications et les groupes qui les supportent
- Créer certains des éléments de configuration (tout ne peut être découvert automatiquement)
- Maintenir certains attributs
- Assurer la qualité des données de la CMDB
- Assurer la pérennité de la solution (évolution, gouvernance)
Ces tâches et responsabilités ne peuvent être assumées par des machines. Au-delà de la technologie, votre — plus grand défi -- sera de responsabiliser vos équipes et de les rendre imputables de la qualité et de la maintenance des données. Pour cela, vous aurez besoin de gouvernance (voir aussi le point 8).
Pour résumer, la mise en place de la gestion des configurations est avant tout un projet qui implique des humains et des responsabilités. Une gouvernance active sera une des clés du succès.
3— Concevoir la solution CMDB en vase clos
La gestion des configurations (SACM) est au cœur de la gestion des services TI : la majorité des autres processus TI consomment l’information qu’encadre le processus SACM. Ainsi, c’est l’information-clé fournie par le processus SACM qui permet à l’organisation de s’assurer qu’elle livre bien les services conformément aux ententes
Parce que le processus SACM est essentiel à tant de processus qui en dépendent, le nombre de parties prenantes est important. Deux de ces parties prenantes doivent impérativement être impliquées dans le design de la solution :
- Les propriétaires de processus:
- Pour eux, la CMDB est une source d’information incontournable. Par exemple, pour évaluer le risque qu’implique un changement sur un élément du service, il faut de l’information de qualité concernant l’élément et son rôle dans la chaîne de livraison du service. Les propriétaires de processus exprimeront donc des besoins spécifiques importants dont il sera essentiel tenir compte.
- Les propriétaires d’éléments de configuration (CI):
- Les propriétaires de CI sont des équipes opérationnelles qui répondent de la qualité de l’information et en assurent la maintenance. Par exemple, l’équipe des serveurs Windows s’assure que tous ses serveurs sont représentés dans la CMDB au niveau de qualité d’information et de précision entendu. Les exigences des propriétaires de CI s’exprimeront donc à selon deux axes :
- livraison (données requises pour livrer le service),
- faisabilité opérationnelle (capacité de l’équipe à maintenir l’information au niveau de qualité exigé).
- Les propriétaires de CI sont des équipes opérationnelles qui répondent de la qualité de l’information et en assurent la maintenance. Par exemple, l’équipe des serveurs Windows s’assure que tous ses serveurs sont représentés dans la CMDB au niveau de qualité d’information et de précision entendu. Les exigences des propriétaires de CI s’exprimeront donc à selon deux axes :
Élaborer une CMDB en vase clos n’est donc pas recommandé. En particulier, les deux groupes mentionnés ci-dessus doivent être activement impliqués pour la durée du projet.
4— Croire en une super-CMDB monolithique
L’expérience de terrain démontre qu’une super CMDB unique centralisant toute l’information de l’entreprise n’est ni viable, ni souhaitable. Dans les faits, plusieurs systèmes contiennent déjà les informations en question. Pourquoi ne pas plutôt mettre en relation toutes ces sources autoritaires ?
En fait, la meilleure approche est de mettre en place une CMDB intégratrice (et non pas centralisatrice) qui :
- faire idéalement partie de votre système de gestion des services TI (ITSM)
- contient le minimum d’informations requis pour opérer les processus
- permet d’accéder si nécessaire au contenu détaillé des sources autoritaires externes
5— Mettre en place une pyramide coupée : oublier les services et applications
Le modèle d’une CMDB ressemble à une pyramide dont chaque couche a son importance et ses spécialistes. Il est aujourd’hui assez simple de découvrir via des automatismes le contenu des couches du centre (infrastructure et infrastructure applicative). Plusieurs projets tombent donc dans le piège de s’y limiter et négligent les deux couches du haut (applications et services). Pourtant, c’est vraiment là que la valeur de la CMDB se concrétise !
Dans la grande majorité de cas, il est difficile ou impossible de peupler de manière automatique le contenu de ces deux couches. Les applications sont souvent développées à l’interne et des règles doivent être configurées pour les découvrir correctement. Quant aux services, ils sont souvent connus d’une poignée d’experts. Résultat : le projet se concentre sur les couches plus faciles à découvrir et on obtient une CMDB qui ressemble à une pyramide tronquée C’est dommage, car après tous ces efforts, l’organisation connait bien ses serveurs et outils de gestions d’infrastructure (ce qui était déjà le cas avant), mais ne peut toujours pas savoir quelle application est affectée par une panne matérielle ou quel département sera touché par un changement. C’est donc aussi une occasion manquée de rapprocher les TI des affaires.
Pour bien débuter un projet de CMDB, concentrez-vous sur le haut de la pyramide. Travaillez avec les architectes d’entreprise et les représentants des lignes d’affaires — ce sont les personnes qui normalement détiennent l’information-clé du haut de la pyramide. Consolidez l’information de manière simple, servez-vous de chiffriers s’il le faut. Ensuite, adoptez une approche « top-down », et connectez ces éléments (applications et services) aux données d’infrastructure (les couches du bas). Dans le cas où votre organisation n’a pas encore intégré le concept de service (et compris les bénéfices qu’on en retire), commencez au moins avec la couche applicative et préparez en parallèle une initiative de mise en place d’un catalogue de service et du processus qui l’encadre.
6— Mettre en place une solution inopérable
Souvent, les projets CMDB sont conçus par ceux qui consommeront l’information et non par ceux qui devront opérer la solution au quotidien. On s’emballe devant les capacités (théoriques) de l’outil et on rêve. Le « tu as vu, l’outil peut faire ça ! » est souvent le pire ennemi. Le résultat est une dérive de complexité et détail sans égard pour la maintenance au quotidien. Ainsi, très vite (quelques mois), les équipes se trouveront incapables de maintenir la qualité des informations de la CMDB. Ceux qui consomment les données s’en rendront vite compte. C’est ainsi que la CMDB, censée être la pierre angulaire des processus TI, sera décriée, évitée, contournée, par manque de réalisme lors de la conception.
Impliquer, dès la phase de conception, ceux qui devront opérer la solution permettra d’éviter ce scénario. La portée de la CMDB devra être approuvée par ces personnes. De plus, des politiques et mécanismes de gouvernance encadreront l’évolution future du contenu de la CMDB — le principe d’opérabilité facile demeurera central.
Un exemple ? On pourrait se laisser rêver à gérer dans la CMDB tous les ports des commutateurs réseau ainsi que les liens sur chaque port. La valeur en serait incroyable ! Mais les efforts de maintenance de telles informations seraient titanesques ! C’est ce que les équipes de réseau feront valoir aux demandeurs (les équipes de sécurité et d’architecture). Un compromis viable sera possiblement l’automatisation de la mise à jour de ces informations. Ou encore, l’exclusion de ces éléments de la portée de la CMDB.
N’oubliez donc pas de tester vos rêves à l’aune de l’opérabilité au quotidien !
7— La perfection ou rien
Les systèmes TI modernes sont complexes, fluides, en constante évolution. Quoi que vous fassiez, votre CMDB n’atteindra jamais 100 % de précision ! Alors, n’attendez pas qu’elle soit parfaite avant de la déployer !
Rob England, blogueur ITSM connu qui administre le IT Skeptic, a écrit plusieurs articles sur la mise en place d’une CMDB. Dans son article « ITIL’s CMDB can’t be done, no-how », il parle spécifiquement de l’impossibilité d’atteindre la perfection telle que décrite dans ITIL, ce qui est aussi un thème présent dans des autres publications.
En fait, Rob England est beaucoup plus pessimiste que nous. Nous pensons qu’une CMDB de qualité peut quand même être mise en place et maintenue. La clé est de commencer petit, d’encadrer serré, de s’améliorer de façon continue et de fermer la boucle de vos processus TI (« closed loop processes »). Parlons un peu plus de ce dernier concept.
De tous les processus qui gravitent autour de la gestion des configurations, c’est surtout la gestion des changements qui amène des changements de configuration. Si votre processus des changements est solide ET qu’il contient une boucle de rétroaction vers la gestion des configurations (mise à jour des données correspondantes), les données de la CMDB seront de bien meilleure qualité ! Ces connexions avec les autres processus sont primordiales : il faut les contrôler et s’assurer qu’elles sont respectées.
8— La gouvernance c’est pour les autres
Tous les processus ont besoin de gouvernance, mais jamais autant que la gestion des configurations. Pensez seulement aux questions suivantes, qui sont le quotidien de la gestion des configurations :
- Quelle portée donne-t-on à la CMDB ?
- Comme fait-on évoluer son contenu selon les besoins d’affaires ?
- Quels attributs maintient-on ? À quel coût ?
- Quelles politiques encadrent le travail des acteurs de la CMDB ? Ces derniers s’y conforment-ils ?
- Quelle est la qualité des données ?
- En quoi devons-nous nous améliorer ?
- Etc.
Le processus de gestion des configurations gère des données essentielles au bon fonctionnement des TI (et des affaires qui en dépendent). Étant donné le nombre d’acteurs impliqués, il est impératif de travailler — ensemble — pour garder le cap, assurer l’amélioration continue, au bénéfice de tous. Cette gouvernance prendra deux formes :
- opérationnelle pour suivre la qualité des données, maintenir le cap au quotidien
- de gestion, pour maintenir l’alignement aux besoins d’entreprise
Sans gouvernance, nous l’avons vu souvent, le chaos ne tardera pas à ressurgir.
Conclusion
Pour réussir votre projet de CMDB, il vous faudra :
- Accepter d’être minimaliste -- dans sa première mouture, le niveau de détail de la CMDB sera plus limité et axé sur des objectifs concrets à atteindre (plutôt qu’un rêve idéaliste).
- Concevoir et modéliser en concertation -- les parties prenantes exprimeront leurs besoins et aideront à valider que la CMDB pourra vivre au quotidien
- Promouvoir engagement et imputabilité -- les équipes responsables de maintenir l’information devront activement s’impliquer et t’accepter leur imputabilité. La gouvernance surveillera le tout
- Accepter les petits pas — l’amélioration continue sera la clé du succès.
À propos des auteurs
 | Jean-Francois Cyr Associé Principal, Groupe Uni-TI conseil Jean-François est un architecte de solution spécialisé dans les aspects processus et fonctionnels de la gestion des services TI (ITSM). Il a dirigé plusieurs projets et initiatives ITSM pour des moyennes et grandes entreprises au cours des 15 dernières années. |
 | Louis-André Morin Architecte technique ITSM Louis-André est un expert multidisciplinaire qui a travaillé dans plusieurs sphères du monde des TI : développement applicatif, gestion de bases de données, architecture de systèmes, ingénierie des processus et gestion de projet. Dans les dernières années, il s’est particulièrement spécialisé dans l’implantation de solutions CMDB et l’intégration avec les solutions de surveillance de systèmes TI |
 | Arkady Kunysz Associé principal, Groupe Uni-TI conseil Arkady est un spécialiste de la gestion du changement dans le cadre du déploiement de modèles de livraison, processus TI et outils ITSM. Il définit la stratégie, anime des ateliers, encadre des ressources et donne des formations en 3 langues. |
Flux RSS
