Dans les structures qui ont vécu la mise en place de l’ITIL, nous retrouvons une pratique populaire : le change management. Ce processus souvent lourd est il compatible avec l’agilité ?
Le change management
Le change management est une pratique ITIL qui impose un processus pour sécuriser tout changement mis en production (logiciel, application, équipement, matériel, configuration, documentation, procédure…).
En générale, il existe 3 types de change management :
- standard : procédure standard pour un changement spécifique récurrent
- normal : procédure générale pour tout changement qui n’est ni standard, ni urgent
- urgente : procédure adaptée pour les changements d’urgence absolue
Toute personne ayant besoin de réaliser un changement devra remplir le document du type de change qui comprendra la procédure de mise en production, la procédure de rollback et toute information nécessaire pour tracer ce changement.
Le changement sera validé par le CAB (Change Advisory Board) qui se réunit de façon régulière et rythmée (sauf les cas d’urgence).
N’hésitez pas à aller sur les sites spécialisés sur l’ITIL si vous désirez creuser ce sujet.
Le change management et l’agile ?
Est-ce que ce concept de change management peut-il s’adapter aux univers agile ? Est-il un frein à l’accélération souvent voulue aujourd’hui par les entreprises ?
Ce concept de change management a pour but de sécuriser au maximum les mises en production. Mais dans mes dernières expériences, j’ai pu rapidement apercevoir que des points négatifs s’ajoutent au tableau.
- les équipes n’aiment pas la bureaucratie ce qui amène a beaucoup d’allez/retour avec le CAB
- les équipes n’aiment pas la bureaucratie et remplissent rapidement les documents (avec un manque de qualité des procédures)
- le CAB se réunit que toutes les semaines voire toutes les 2 semaines ce qui allonge le temps de livraison
Si le changement management est une procédure qui se veut apporter une qualité dans les livraisons en production, l’apport final n’est pas si bénéfique. Le CAB parfois valide les changes mais manque de connaissances pour réellement assurer que la procédure décrite est parfaite… Et les personnes qui ont pris le support qui seront là en cas de nécessité de rollback parfois complexes, ne sont que très rarement formés à la complexité de tous les différents métiers qu’ils doivent gérer.
Au final, les résultats que je constate dans les différentes structures où j’interviens sont très mitigés. Oui, ça apporte un plus dans la sécurisation des mises en production ; mais, le coût global d’une telle procédure remet en question son application (par rapport au bénéfice que ça apporterait).
Il est possible d’avoir un concept de change management plus agile avec un CAB qui se réunirait à la demande ; cependant en cas de grosse activité, les délais s’allongeraient.
Merci le devops et le craftsmanship
La réponse à la suppression de cette procédure ITIL se retrouve dans les pratiques d’intégration continue et de livraison/déploiement continue. En diminuant considérablement les risques de regression ou en mettant des stratégies telles que le chaos engineering, le change management devient inutile et obsolète.
Je vous recommande fortement d’investir dans ces techniques d’ingénierie logicielle qui vous permettront après une bonne maturation à faire disparaitre cette procédure de change management.
Attention, le change management n’est pas une mauvaise chose et apporte une sécurité supplémentaire quand nous n’avons pas la maturité de sécuriser nos mises en production. Cependant pour en avoir de réels bénéfices, il faut qu’il soit optimisé (ce qui est très complexe à mettre en place).
En agile, on privilégiera d’aller vers des approches devops et craftsmanship.
Le change management ne se limite pas à sa définition ITIL. A contrario, ITIL propose une solution (lourde et très administrative) pour aider au change management.
Dans un concept plus large, le change management englobe l’accompagnement au changement, que cela soit du coaching, de la formation, ainsi que de l’aide ponctuelle. Le mot clé du change management est l’écoute; en cela un projet Agile est (normalement) très en phase avec le change management.
L’article parle du change management (pratique ITIL) qui s’applique encore dans certaines entreprises. Et pas de l’idéologie change management qui est assez différente comme tu le dis ; et l’accompagnement au changement est une des choses où l’univers agile essaye d’agir 🙂
Bonjour,
Je ne suis pas d’accord avec ce que vous dites l’intégration continue et le change management doivent coexister. Faire disparaître le CAB serait une ineptie et reviendrait a flinguer une prod.
David
Bonjour David,
Le besoin du change management est souvent lié à des soucis en amont. Si votre système est propre et solide avec des systèmes de rollback automatiques, vous n’en avez pas besoin. Si il y a 20 ans ça se justifiait, aujourd’hui avec les technologies que nous avons à disposition, ça n’a plus d’utilité… Le problème c’est que de nombreuses entreprises n’évoluent pas techniquement et doivent combler le manque d’investissement par des pratiques d’antan (finalement tout aussi couteuses).
Je connais énormément d’entreprises qui n’ont plus ces pratiques depuis 10 ans…. et curieusement, elles semblent avoir beaucoup moins de soucis que les entreprises qui ont encore ces pratiques et des technos vieillissantes. Après certaines organisations ne peuvent pas passer ssur ces technos récentes facilement à cause d’un contexte complexe ; mais ce n’est pas une majorité mais quelques cas particuliers.