Faut il une cmdb pour un processus de change ?

Et bien aussi surprenant que cela puisse paraitre, j'ai decouvert chez un client un processus de change très mature qui tourne régulirement sur des CI générique. En effet, ce processus a un fort pouvoir de standardisation dans la planification et la réalisation de l'infrastructure.
Mais j'ai fait remarqué qu'une part importante de la plus value de ce processus était perdue : l'historique. En effet, faire un changement sur un serveur ou une application permet de garder un historique des modifications. Ne pas lier le change sur un CI précis ne permet donc d'avoir ce suivi dans le temp.

Comment mettre en place le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Revivew. A chaque début de CAB, il doit être pris 10 minutes afin d'étudier les changes réalisés 3 ou 4 semaines plutôt. Il suffit alors de répondre à quelques questions dessus tel que :

• Réalisé dans les délais annoncés ?
• Utilisateurs impactés ?
• Incident généré depuis le change ?
• Dysfonctionnement résolu ?
• Autres remarques ?

Des statistiques issues de ces résultats servent alors au pilotage de ce processus et de s'assurer qu'il répond au besoin premier : permettre de modifier l'infrastructure en maîtrisant les impacts aussi bien techniques que des utilisateurs.

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

Pourquoi plusieurs processus suivant le type de changement ?

Dans la mise en place du processus de changement, il arrive qu'on ne mette en place qu'un processus de changement quelque soit son type. Pour rappel, un changement peut être majeur, significatif, normal ou urgent.
Dans de nombreux cas, le change urgent reste relativement indépendant des autres car il est souvent traité hors outil, pour son caractère urgent,

Pour les autres types, il est conseillé de mettre en place des processus différents, notamment pour la validation du CAB (change Advisory Board). En effet, mettre en place un processus qui répond au processus majeur sera lourd et cher pour les changes normaux. De l'autre, un procesuss simple risque de décider des changes significatifs sans avoir pris en considération tous les paramètres.

C'est pourquoi, un unique processus peut faciliter la mise en place de ce processus, mais il est nécessaire rapidement de déployer tous les cas adaptés à chaque type.

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

A quoi sert le PIR du processus de change ?

Pour rappel, le PIR correspond au Post Implementation Review. Il s'agit après chaque change de faire un bilan. Cela doit se faire , que le change est réussi ou non.

En effet, si le change a bien fonctionné, il est nécessaire de savoir si le dysfonctionnement a bien été résolu. Un change qui se passe bien ne corrige malheureusement pas toujours un dysfonctionnement ! Simplement parce qu'un change qui se passe bien correspond au fait que l'infrastructure fonctionne toujours après mais peut-être que cela n'a servit à rien.

Si le change s'est mal passé, il est plus courant de mettre en place ce bilan. Il s'agit de comprendre l'origine des difficultés rencontrés. Il ne s'agit pas évidemment de trouver le coupable mais de trouver ou le processus a failli : CMDB pas à jour (et donc impact sur l'infrastructure non prévu), représentant du CAB absent (revoir la sélection des opérateurs du CAB).

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

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

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