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...

Quelle logique pour sa base de connaissance ?

Démarrer sa base de connaissance n'est pas chose aisée. En effet, il est rare qu'une entreprise ait déjà ce processus en place. Et les opérateurs ont plutôt tendance à penser que transmettre leur connaissance déstabiliserait leur position dans l'entreprise. Il arrive aussi que la réaction soit de rappeler que les éléments de l'infrastructure sont déjà présenté dans X documents écrits durant le projet.


Mais la question qu'il faut se poser réellement est :  est ce que cette information est disponible rapidement pour le Service desk ?

Une méthode de mise en place de la base de connaissance est de créer, une fois plus, un cercle vertueux dont les protagonistes seraient gagnants et l'entreprise pourraient agréger ses connaissances.

En effet, il est alors présenté au Service Desk que si l'information se trouve dans la base de connaissance, ils ont alors la responsabilité de la rechercher puis de résoudre eux-même l'incident. Et aux équipes des niveaux suivants, il est rappelé que si l'information est facilement disponible dans la base de connaissance, les incidents ne leur seraient plus transmis.
Avantages :

• Création d'une responsabilité partagé entre le Service Desk et les équipes suivantes
• Création d'un référentiel commun de partage d'information entre les différentes équipes
• Réduction du nombre d'incident transféré aux équipes de niveaux 2 et 3
• Réduction des coûts car les incidents sont traités plus rapidement et par moins d'opérateurs.
  Cet article vous a aidé... n'hésitez pas à cliquer sur les annonces publiées...

Qui saisit dans la KB ?

J'ai dit précédemment que la KB devait être remplie par les 2eme et les 3emes niveaux. Mais il est vrai que cette étape est difficile à faire accepter par ces opérateurs. En effet, ils considèrent souvent que la KB ne sert qu'au Service Desk donc ce n'est qu'a eux de la remplir.


Proposition faite pour mettre en place la KB sans que cette question soit un frein. Il a été posé sur la fiche de l'incident un flag permettant de notifier que la solution apportée pourrait être intégrable dans la KB. Ainsi le KB Manager pourra reprendre les informations et la charge demandée aux opérateurs est minime car il s'agit de remplir un champ type liste déroulante ou case à cocher.

Plus tard, lorsque la KB aura fait la preuve de son fonctionnement, si on souhaite réduire la charge du KB manager, présenté cette responsabilité aux niveau 2 et 3.

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.

Qu'attend on de l'opérateur du Service Desk ?

En principe, afin que le Service Desk soit efficace, il faut que l'opérateur prenne le temps de traiter le contact. En effet, trop souvent, on demande des cadences telles aux opérateurs qu'ils sont réduits à faire du call center. C'est à dire à retranscrire le contact reçu et à transférer l'incident.

C'est pourquoi, il est normalement prévu de prendre 15 minutes pour traiter un appel. Cela veut dire que globalement, on peut répartir ce temps en :
5 minutes de compréhension et de saisie dans l'outil
5 minutes de recherche dans la KB
5 minutes de recherche autrement (prise de main à distance, soutien d'un autre collaborateur...)

On voit bien qu'en laissant un minimum de temps, et avec les outils nécessaires (voir la rubrique KB), l'opérateur du Service Desk peut traiter plus d'appel. Et cela veut dire :

Réduction des couts : traitement uniquement sur les premiers niveaux

Augmentation de la satisfaction cliente : il est toujours plus agréable d'avoir une solution directement que d'attendre le rappel d'un autre collaborateur.

Satisfaction des opérateurs du Service Desk : la prise d'appel sans valeur ajouté devient souvent difficile et rébarbatif.

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

Qui doit créer un problème ?

A cette question, il n'existe pas de réponse unique. Cela va dépendre de plusieurs critères :

     • Maturité du processus dans l'entreprise. Si le processus n'a jamais été défini, il sera préférable de le faire accepter par les équipes de niveau 3 des incidents avant de leur présenter l'utilisation de l'outil de support. Sinon, ils risqueraient de faire un rejet du processus simplement parce qu'il aura été identifié à la probable complexité de l'écran à renseigner.

    • Outil utilisé. Si un outil pour supporter ce processus, si l'outil est trop proche ergonomiquement du processus des incidents, il risque d'avoir une confusion et un amalgame de ces deux processus.

    •  Implication du problem manager. Si ce dernier est impliqué et le souhaite, il peut être possible de lui déléguer cette tâche, au moins dans le démarrage du processus. Il pourra ainsi aider les opérateurs à spécifier les cas dans lequel il s'agit bien d'un problème.

Ainsi, il peut facilement être défini plusieurs étapes en fonction de la maturité du processus et cette responsabilité peut, par exemple démarrer au problem manager afin de soutenir les opérateurs. Et lorsque le processus est accepté et intégré, la création du problème peut s'ouvrir à toutes personnes.

Concernant les utilisateurs, ils doivent évidemment passer par le Service Desk et ne devraient pas demander la création d'un problème directement. En effet, un problème est directement un dysfonctionnement de l'infrastructure dont on veut chercher la cause. Or les utilisateurs ne devraient déclarer que des dysfonctionnements dont ils perçoivent la conséquence.

Comment optimiser une équipe d'intervention ?

Une équipe d'intervention, souvent de niveau 2 dans le processus d'intervention doit être capable de traiter un maximum d'incident afin de garantir la tenue des SLAs.

Comment il s'agit aussi de l'équipe en charge du traitement des requests, il est important de pouvoir suivre la charge.
Première élément à prendre compte : la répartition de charge durant les journées de chaque semaine. En effet, avec un indicateur fiable, il est possible de suivre quand sont les pics de charge dans un journée et quelle jour de semaine.
Très souvent, les mercredis et vendredis sont plus calme et dans une journée, après un pic de début de matinée, la charge diminue entre 10h et 12h00. Il s'agit la d'une constatation générale mais la spécificité du métier de l'entreprise peut influer ces courbes.
En tout état de cause, cela permet de savoir aisément quand les équipes peuvent se planifier le traitement des requests et quand il faut s'occuper des incidents.

Pourquoi l'incident manager et le problem manager doivent être deux personnes ?

Un client m'a présenté la matrice de distribution des rôles des différents managers de processus. Le rôle d'incident et de problem manager était tenu par la même personne.
Certains rôles peuvent être tenu par les mêmes collaborateurs. Mais cela ne doit pas être le cas pour ces deux là.
En effet, l'incident manager doit s'assurer que les incidents sont traités dans les plus brefs délais pour l'utilisateur. Il représente donc les intérêts de l'utilisateur et va s'assurer que ce dernier puisse de nouveau obtenir 100% des services fournis. Même si une solution provisoire est trouvée, elle sera alors suffisante. A l'extrême, même si cela fait entorse à la stratégie et à la logique de l'infrastructure, tant que la solution permettra de répondre au dysfonctionnement vécu par l'utilisateur cela lui conviendra.
De son côté, le problem manager doit, lui, prendre le temps pour garantir que le dysfonctionnement ne se reproduise plus. Il va alors investiguer et effectuer les changements nécessaires et en profondeur si cela est nécessaire.
Il apparait aisé qu'à moins de trouver un profil schysophrène, il sera difficile pour un même intervenant d'assurer les deux rôles de garantir le bon fonctionnement des deux processus. Il sera forcément en conflit avec l'un ou l'autre des processus. Une perte de gain d'amélioration apparaît donc dans ce cas la.

Conseil : Superposer des rôles sur un même collaborateur, oui, mais pas le rôle d'incident et de problem manager.