Gestion des changements : on ne vous dit pas tout...

Petits rappels de départ, je vais donner quelques définitions.

Non pas que je veuille insulter le lecteur en lui jetant des banalités au visage, mais plutôt que dans notre quotidien et au bout d'un temps suffisamment long (2 jours pour certains, 2 ans pour d'autres...) on finit par faire des "à peu près" ou à perdre de vue le point de départ.

 C'est quoi un(e) :

• Changement : Ajout, modification ou suppression de tout ce qui peut avoir un effet sur les services informatiques. Le périmètre doit inclure les changements aux architectures, aux processus, aux outils, aux métriques et à la documentation aussi bien que les changements aux services informatiques et aux autres, éléments de configuration.

NDLR : ça veut dire plusieurs choses... Un changement c'est un événement, un processus ce n'est pas un ticket dans un outil (heu bah oui...). Ça veut aussi dire qu'un changement ce n'est pas la plupart du temps une "modif" de type "changer le routeur. Et ça veut aussi dire que tout ce qui sert au Service est éligible à subir un changement qui pourra être instruit pas ce processus. Mais j'y reviens plus loin...

• Demande de Changement : Demande formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. 

NDLR : une demande n'est pas en soit le changement, c'est simplement l'enregistremen. J'ai l'air d'enfoncer une porte ouverte, là comme ça... Mais pensez-y est-ce que là où vous êtes on ne mélange pas les deux ? Est-ce qu'on dit "Tiens Bernard (ou Cécile ou autre...) j'ai fait une demande de changement ? Ou pluôt "Je t'ai envoyé un changement" "T'as saisi un changement?".
J'aime la précision de la définition : papier ou électronique... ou encore : vous n'êtes pas obligé dans un premier temps d'acheter un outil à 300k€ pour gérer vos changements (voir un prochain billet sur la mise en œuvre).

•  Enregistrement de changement : Enregistrement contenant tous les détails d’un changement. Chaque enregistrement de changement documente le cycle de vie d’un seul changement. Un enregistrement d’un changement est créé pour chaque demande de changement ayant été reçue, même pour celles qui seront rejetées par la suite. Les enregistrements de changement doivent référencer les éléments de configuration affectés par le changement. Ils sont stockés dans le système de gestion des configurations, ou quelque part dans le système de gestion des connaissances des services. 

NDLR : ça c'est un notion rarement utilisée... Le plus souvent on a Changement = Demande de changement = Enregistrement de changement.
On devrait donc dire : j'ai soumis une demande de changement, tu trouveras toutes les informations utiles dans l'enregistrement pour te permettre d'évaluer le changement.

•  Changement Normal (Normal change) : Changement qui n'est ni un changement urgent, ni un changement standard. Un changement normal suit les étapes prédéfinies du processus de Gestion des Changements. Changement Urgent (standard change)

NDLR : là ça se corse... en Français on aurait tendance à dire que le "normal" c'est celui qu'on fait tous les jours et donc à penser à celui qu'ITIL appelle le "standard". Bref un changement normal c'est en fait le changement de base, moyen, basique... et concrètement c'est celui qu'on va devoir étudier car on ne sait pas à l'avance le sort qu'on lui réserve ni qui va pouvoir le valider etc...
Au démarrage du processus, théoriquement on ne devrait avoir que des changements normaux (sauf si on a fait un inventaire des changements récurrents avant...)

•  Changement Standard (Standard Change): Changement pré-autorisé présentant peu de risque, relativement commun et qui sera exécuté selon une procédure ou une instruction de travail. Par exemple, la réinitialisation d’un mot de passe ou la fourniture d’un équipement standard à un nouvel employé. Des demandes de changement (RFC) ne sont pas requises pour implanter un changement standard, car ceux-ci sont journalisées et suivies selon un mécanisme différent, tel qu’une demande de service.

NDLR : le changement standard c'est le changement qui s'est institutionnalisé, banalisé, qu'on fait "tous les jours" sans y penser. ITIL étant pragmatique (sisi je vous assure) il propose donc de ne pas se poser la question de son évaluation à chaque fois et perdre du temps dessus. On devrait avoir pour objectif de balancer les changements qui représentent "80%" de l'activité dans des standards à moyen / long terme et ne se donner la peine d'évaluer que les "20%" restants (notamment en CAB). Mine de rien là je vous donne une cote mal taillée mais qui devrait désengorger les CABs et mettre au chômage quelques Gestionnaires de Changements qui n'ont pas cette ambition...

• Changement Urgent (Emergency Change): changement qui doit être mis en oeuvre dès que possible. Par exemple, pour résoudre un incident majeur ou implémenter un correctif de sécurité. Le processus de Gestion des Changements aura normalement une procédure spécifique pour traiter les changements urgents.

NDLR : Alors là je les vois venir les petits malins : tiens, en voilà un bon moyen d'éviter de passer en CAB... Un changement urgent n'est pas seulement la solution pour résoudre un incident (ça c'est le cas d'un grand nombre de changements...) mais surtout c'est un risque qu'on accepte de prendre car il est plus faible que le risque qu'on fait porter au service si on ne corrige pas.
Autrement dit, on convient à l'avance de cas où on accepte de contourner le processus (et oui ITIL est bien pragmatique ;) ) et pour lesquels le "cas de force majeure" peut être invoqué.
Attention ceci n'est pas un changement urgent :

• remplacement du PC du patron / VIP par un Ipad
• changement "de dernière minute" juste parce que son initiateur se réveille un peu tard, par exemple vers 17H00 pour un déploiement à 17H30. (Celui-là devrait être refusé / reporté histoire qu'on ne l'y reprenne pas). Ça c'est un changement à l'arrache, pas un changement urgent.
• changement "qu'il faut que je fasse avant de partir en vacances", le vendredi en fin d'après midi.

 Bref, le lecteur aura compris : un changement urgent c'est le cas hyper particulier. Et il y a un comité prévu pour ça : le CAB d'urgence (eCAB), souvent avec un ou plusieurs membres de l'encadrement, des clients, capables d'assumer la décision du "bon bah on y va quand même car on n'a pas le temps de tout tester".

Existe-t-il d'autres types de changements ? NON : ça ne sert à rien
Est-ce que je peux "inventer" mes propres types de changements ? NON ça ne sert à rien (bien que je crois l'avoir vu partout !)
Je vous propose de bien relire à chaque fois que vous vous posez ces questions les définitions, vous verrez que tout est prévu et que ce n'est pas parce que votre contexte vous semble différent sur ce point, qu'il l'est vraiment.
Vous voulez que ça marche ? Vous voulez faire efficace ? Contentez-vous de ces types de changements et focalisez-vous sur ce qui compte.

Si on vous demande un nouveau type de changement pour gérer le cas où le changement n'est pas passé au CAB mais doit être fait quand même, vous avez deux réponses possibles :

• Vous émettez un avis négatif sur le changement et vous dites que la prochaine fois il devrait le planifier suffisamment tôt... Mais ça ça n'est pas pragmatique : dans la vraie vie les changements arrivent n'importe quand... et ne peuvent pas forcément attendre un CAB que vous aurez arbitrairement (qui a dit bêtement au fond de la salle ?) fixé un jour de la semaine
• Vous émettez un avis négatif le changement et vous vous dites que vous allez améliorer votre processus en
• arrêtant ce principe stupide auquel tout le monde semble tenir :
• tout changement devrait passer au CAB (c'est anti-ITIL et contre productif). Il faut déléguer l'approbation et utiliser au maximum les changements standards.
• le CAB est une grand messe hebdomadaire dont le principal but est de faire perdre un maximum de temps à un maximum de personnes (ça aussi c'est l'inverse de ce que propose ITIL). Il peut y avoir plusieurs CAB, chacun à un moment différent, avec un périmètre différent, un casting différent. Et surtout on vient en CAB pour entériner (ou pas) une évaluation déjà faite d'un changement : on ne découvre pas le changement en séance en ouvrant le débat, sans avoir les éléments qui permettent de prendre une décision.
  Le CAB ce n'est pas "tiens au fait on changerait bien le serveur  de messagerie ce week end vous en dites quoi ?". Ça devrait être : nous avons étudié le changement qui propose le remplacement du serveur de messagerie. Le dossier est complet mais nous recommandons son report car il intervient à un moment critique pour nous. Le CAB confirme-t-il cette préconisation ?
• prévoyant un circuit d'approbation via voie hiérarchique pour ces cas particuliers qui font partie de la réalité.

Alors pour finir :

CAB ou comité consultatif des changement (Change Advisory Board): Groupe de personnes qui apporte un support à l’évaluation, la définition des priorités, les autorisations et la planification des changements. Le comité consultatif sur les changements est habituellement composé de représentants de tous les domaines au sein du fournisseur de service informatique, du business et des tierces parties tels que les fournisseurs externes.

Voilà tout pour aujourd'hui !
Ça me fait penser qu'un laïus sur le CAB pourra être utile, tant on se désespère en voyant ce qui est fait de ce concept.