Quel indicateur pour la CMDB ?

Cette question a été posé dans un environnement particulier car un processus d'incident relativement bien maîtrisé fonctionnait tandis que nous mettions la gestion de la configuration. Il fallait prouver que la CMDB pouvait participer au traitement des incidents.
Pour cela, j'ai proposé trois niveaux d'indicateurs :
Déploiement de la CMDB : s'assurer que le périmètre prévue des CIs s'intègre convenablement dans la base.
Utilisation de la CMDB : s'assurer qu'elle est mise à jour régulièrement et que ses informations sont utilisées dans le traitement des incidents
Avantages de la CMDB : regarder quelles sont les gains sur le traitement des incidents de la mise en place de la CMDB.
Dans ce dernier cas, il sera très difficile d'isoler l'origine des améliorations constatées si d'autres actions sont en cours. Il faudra alors regarder par comparaison : sur un même type d'incident. Est ce que les incidents dont les CIs sont renseignés ont été traités plus rapidement ?

Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Comment valoriser sa CMDB ?

Il y a peu de temps, un client m'a demandé a quoi pouvait lui servir sa CMDB ?


Ma première réponse fut : A rien. Une CMDB pour une CMDB n'a pas vraiment de valeur ajoutée ajoutée. Cela risque de lui couter cher pour la maintenir sans pouvoir justifier le gain.

C'est pourquoi, il faut voir la CMDB comme un support pour :

Optimiser le traitement de ses incidents : connaitre l'environnement de l'utilisateur dans lequel un dysfonctionnement se passe va faciliter la recherche de la cause et une probable solution dans la base de connaissance

Réduire ses couts : connaitre son infrastructure permet de faciliter la préparation des budgets d'investissement et de renouvellement

Augmenter la stabilité : avoir une infrastructure connue dans lequel les Single Point Of Failure peuvent se trouver facilement va réduire les risques

Réduire les impacts de changements : lors de la préparation de changement et de leur validation, une CMDB peut faciliter le travail CAB (change Advisor Board) pour prévoir les risques et les éléments impactés.

Ce ne sont évidemment pas les raisons uniques mais certainement les plus importantes qui peuvent justifier l'implémentation d'une CMDB. C'est pourquoi si le processus de configuration est souvent nécessaire pour structurer un environnement selon les bonnes pratiques ITIL, il ne peut être implémenter seul car sa seule utilisation ne justifierait les investissements nécessaires.

La télécollecte doit-elle mettre à jour la CMDB ?

Il est courant que la question concernant la connexion entre le CMDB et un outil de télécollecte soit posée. En effet, lorsqu'un tel outil est implémenté, le premier reflexe est toujours de décider que la CDMB serait alors mise à jour automatiquement.


Je propose souvent une autre vue de cette interface. En effet, dans ce processus de configuration, une phase importante correspond à la phase d'audit et de contrôle. C'est pourquoi, je recommande d'utiliser les données de l'outil d'inventaire de deux niveaux suivant le degré de détail des informations.

Pour les CI (Configuration Item) de bas niveaux, je confirme que cette mise à jour peut se faire directement et que leurs valeurs sont directement gérées par les remontées de données : adresse IP, Adresse MAC, RAM, Taille de disque dur). En revanche, je recommade de garder la maîtrise des CIs de haut niveaux manuellement et d'utiliser l'outil d'inventaire comme outil de contrôle : application installé sur un équipement, affectation de matériel sur un utilisateur...

En effet, si toutes les données sont alimentées automatiquement, la gestion de l'infrastructure sera toujours réactives : comment s'assurer si l'installation d'une application sur un équipement est normal ou pas si on ne peut pas comparer la décision (dont la gestion est manuelle ou provenant du Request Management) et la situation réelle (provenant de la télécollecte) ?

Dans ce même exemple, une gestion proactive permettra au contraire de savoir quelle licence est autorisée à être installer, quelle licence ne devrait pas être présente et combien de licence sont donc disponibles. Vous devenez alors maître de votre infrastructure et par conséquent de vos coût.

Le configurateur manager doit-il faire les mises à jour dans la CMDB ?

Très souvent, on traduit : configurateur manager = opérateur de saisie dans la CMDB. C'est souvent une erreur.


En effet, afin que la mise à jour soit efficace, chaque processus doit comporter une action de mise à jour de la CMDB. Cette activitée est donc diffuse sur l'ensemble des opérateurs de l'ensemble des processus. Mais alors quel est le rôle de ce manager ?

Son travail peut se répartir sur trois domaines qui recoupe évidemment les cinq activités décrites dans ce processus :

Organiser et assurer le quotidien : c'est à dire qu'il a une activité de contrôle et d'audit. Il doit s'assurer que les mises à jour sont faites et en plus qu'elles sont fiables. Il doit donc avoir des outils lui permettant d'opérer comme l'outil d'inventaire, des requêtes croisées dans la base...

Développer le périmètre de gestion : c'est à dire l'activité de planification. Il doit s'assurer que le périmètre et la connaissance contenue dans la CMDB progresse. Ainsi, il aura à étudier l'utilité du nouvel attribut pour tel ou tel CI.

Développer la maturité de mise à jour : On retrouve l'activité de suivi du cycle de vie des CIs et de l'historique. En effet, il doit relever les dysfonctionnements rencontrées dans les procédures de mises à jour, par exemple, et proposer des solutions.

Il faut donc bien voir le configurateur manager comme un animateur de processus et un chef de projet que comme un opérateur de saisie dans l'application qui supporter la CMDB.