Comment valide le CAB ?

Le nombre d'intervenant au CAB ne doit pas être limité pour des raisons d'organisation. En effet, il est important que tous les collaborateurs qui peuvent être impactés par le change puissent participer au CAB.

Mais pour cela, il ne faut pas imaginer le CAB uniquement sous forme de réunion répétitive dans lequel les intervenants vont patienter que le sujet qui les intéresse soit abordé. cela couterait bien trop cher.

C'est pourquoi, il est conseillé d'organiser le moyen de valider par le CAB en fonction du niveau de chaque changement.

En effet, pour rappel, il existe au moins trois types de changement et pour chacun d'eux, je propose une validation différente :

Change mineur : le change manager a procuration pour valider, il informe simplement les membres du CAB de la décision et leur permet la possibilité de réagir dans un certain délai. Dans le cas d'une objection, le CAB peut être requalifié pour alors changer de type.

Change significatif : une validation type Doodle peut être organisé. Pour cela, les participants recoive un mail avec un lien URL permettant d'accéder à une page. Celle-ci doit contenir au moins :

• Le nom du valideur
• Le rôle tenu par le valideur
• L'avis position ou négatif
• L'explication de son avis
• Une vue des autres avis du membre du CAB

Si une discution s'engage entre deux participants, il est, là aussi, toujours possible de requalifier le change

Change majeur : une réunion doit alors s'effectuer pour que chaque avis puisse s'exprimer et se confronter.

Dans cette approche, seul les changements majeurs nécessitent une réunion. Cela fluidifie grandement le processus et réduit d'autant l'effet d’entonnoir que la validation CAB génère souvent.

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

Qui compose le CAB ?

Le CAB, pour rappelle (Change Advisor Board) est le bureau en charge de valider les demandes de change.

Sa composition ne peut pas être figée et dépend nécessairement du contenu et des probables impactes des changes à valider.

Ainsi, autour d'un noyau systématique :

• Change manager pour coordonner, suivre les délibérations et s'assurer que le processus est respecté ;
• Le responsable technique impacté pour étudier quel impact et quel risque sont encourus ;
• Le responsable du Service Desk pour se préparer à recevoir les incidents en cas de dysfonctionnement et organiser les risques de charge
• Le représentant du client (le SLM, par exemple) pour représenter le client et faire valoir son avis

on peut aussi retrouver des invités. En effet, afin que le CAB soit le plus efficace possible, il doit être nécessaire de convier toutes personnes pouvant apporter sa compétence pour que la décision soit prise en connaissance de tous les risques.

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

Existe-t-il un mode opératoire pour concevoir un Catalogue de service ?

Pour ma part, je ne pense pas, cela va dépendre du niveau de maturiré de l'entreprise et des objectifs de la mise en place.

En effet, mettre un catalogue de service peut servir à :
- Améliorer la relation entre l'IT et le métier en mettant plus de transparence
- Mieux connaitre ses processus de travail IT et les responsabilités des différentes équipes
- Préparer un plan de sourcing pour externaliser certains services ou simplement les faire supporter par des compétences externes.

Voici deux méthodes que j'ai déjà testé et qui marche :

Méthode A

1. présenter le projet aux différents manager de l'IT et leur demander les demandes utilisateurs auxquelles ils font face quotidiennement
2. compiler et organiser les résultats

Cette solution est faisable si la structure de l'entreprise est limitée car elle reste assez empirique.

Méthode B

1. Partir sur les OLA, si existant, afin de partir sur la base des services fournis par les différentes équipes.
2. Développer le OLa et son périmètre pour ensuite détailler le service.


Beaucoup plus pratique pour une grande structure car cela peut se faire périmètre par périmètre

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

A quoi correspond une demande d'information ?

J'entends par demande d'information des questions tel que "Comment imprimer dans cette application ?" ou "Qui dois-je contacter pour obtenir les informations suivantes ?"... Il ne s'agit pas d'incident car il n'y a pas de perte d'information.

Pour ma part, je recommande de pouvoir les traiter au niveau du Service Desk. En effet, en plus de pouvoir catégoriser les contacts entrants comme incident, demande, erreur... il doit exister une type information. Et la base de connaissance doit être suffisamment complète pour que l'opérateur puisse répondre directement.

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

Comment justifier le processus de problème ?

On vient de voir à quoi peut servir ce processus.

Pour justifier son implémentation, il est possible de commencer par regarder les incidents dont la date d'échéance est passée depuis plusieurs jours, voir souvent plusieurs semaines. Lorsqu'on creuse ces cas, on se rend compte qu'ils sont restés ouvert car on attend une migration, on n'est pas sûr de la résolution apportée... Il s'agit de toute évidence de problème géré dans le processus d'incident. Démarrer par ses cas le processus de problème permet de présenter l'avantage de ce processus : supprimer ces incidents dont l'impact sur les niveaux sont effroyables.

Par cette démarche, les opérateurs vont alors commencer à comprendre l'utilité du processus de problème pour sa part réactive.

Traiter les problèmes pro-actifs devra se faire dans une seconde étape. La maturité du processus aide alors et la mise en place est naturelle.

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

A quoi sert le processus de problème ?

Si les processus d'incident  et de change sont devenus naturels dans les entreprises, le lien entre les deux est souvent flou. En effet, le processus de problème est souvent difficile dans son appréhension. Et pourtant lorsqu'on creuse le sujet, il apparait qu'entre un incident déclaré par un utilisateur dont l'origine est inconnue et la mise en place du changement pour corriger, une étape est évidente : la recherche de l'origine et la définition des modifications nécessaires à apporter.

Et bien le processus de problème permet justement de traiter cette phase.

Le processus d'incident a des exigences fortes en terme de délai de traitement pour remettre à niveau le service, le temps imparti ne permet donc pas de prendre le temps pour rechercher la cause.
Le processus de changement se concentre sur l'opportunité ou non de réaliser cette modification. Le détail du changement est donc déjà connu.

Le processus de problème a donc un objectif de mettre en place une Task Force qui va rechercher les origines techniques (ou fonctionnelles suivant le cas) pour présenter les bons changements à mettre en place.

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

Que valide-t-on dans le CAB ?

Pour rappel, le CAB est le Comité de Consultation des Changes. Un client m'a présenté un double processus de change afin de valider dans un premier l'acceptation ou non du point de vue fonctionnel ; ensuite pour valider la planification.


Cela génère un double change et donc une surcharge du processus. Dans le processus de change, on valide le change durant le CAB. Celui-ci est d'ailleurs constitué d'un représentant du Business et de technicien afin de pouvoir juger l'importance fonctionnelle des risques à prendre. La planification est simplement en avant de la réalisation et permet de traiter la file d'attente et de trouver un créneau sur les plages de maintenance pour positionner le change. En aucun cas, la planification n'a la possibilité de refuser un change, elle va au pire le planification pour une date très lointaine.

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

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.