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