Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

30/05/2022 14:12 Les changements à l'ère de DEVOPS - Blog de la Transformation

30/05/2022 14:12 Les changements à l'ère de DEVOPS - Blog de la Transformation Digitale www.ab-consulting.fr/blog/it-sm/cab-et-changements-vs-devops 1/8 BLOG DE LA TRANSFORMATION DIGITALE COBIT®, VeriSM, ITIL®, RESILIA, ISO 27001, ISO 20000 (http://www.ab-consulting.fr/blog/) LES CHANGEMENTS À L’ÈRE DE DEVOPS  2 N ove m b r e 2 0 1 8 ( H t t p : // W w w. A b - C o n s u l t i n g . Fr / B l o g / I t - S m /C a b - E t - C h a n g e m e n t s -Vs - D evo p s )  A l a i n B o n n e a u d ( H t t p : // W w w. A b - C o n s u l t i n g . Fr / B l o g /A u t h o r /A b o n n e a u d ) ITIL propose un processus de gestion des changements destiné à ne mettre en production que des services éprouvés pour éviter les impacts négatifs sur les utilisateurs. A l’heure où les entreprises sont en recherche permanente d’agilité et où DEVOPS s’impose, l’approche ITIL semble dépassée. Mais est-elle vraiment dépassée où n’est-ce pas plutôt un échec de mise en oeuvre (http://www.ab-consulting.fr/blog/it-sm/itil/itil-5-erreurs-majeures) des meilleurs pratiques qui est en cause? Dans cet article, nous allons faire un gros plan sur ce que devrait être la gestion des changements. Et nous allons nous intéresser tout particulièrement au CAB (Comité Consultatif des Changements), mal utilisé le plus souvent. 30/05/2022 14:12 Les changements à l'ère de DEVOPS - Blog de la Transformation Digitale www.ab-consulting.fr/blog/it-sm/cab-et-changements-vs-devops 2/8 Crédit © rawpixel.com 2018 La seule raison pour laquelle la plupart des personnes et des organisations ont entendu parler du CAB (Change Advisory Board) est qu’il est décrit dans la section sur la gestion du changement des publications ITIL. La plupart des organisations ont alors considéré que si le CAB est décrit dans ITIL, c’est qu’il est obligatoire. Souvent il a donc été mis en œuvre avec enthousiasme comme mécanisme de contrôle de la qualité dans les grandes entreprises. Pour beaucoup de professionnels des opérations non informatiques, le CAB est leur seul contact avec ITIL. Il en est d’ailleurs presque devenu synonyme. Cela signifie également qu’ITIL est lui-même devenu synonyme de douleur récurrente qui revient toutes les deux semaines… Le conte des trois erreurs Il en va de la gestion des changements comme de beaucoup d’autres domaines de l’informatique. Il y a une différence significative entre la théorie et la pratique. Pourtant, il est exact que la théorie (dans l’ITSM) a été (partiellement) construite sur la base des pratiques du monde réel. Cependant, il s’agit en fait d’une version idéalisée d’une tentative de description globale destinée à être adaptée à chaque situation particulière. Ce n’est en aucun cas une prescription de ce qui doit être mis en oeuvre tel quel dans les organisations. Nous allons tenter de mettre tout le monde d’accord pour commencer à travailler à améliorer la pratique de la gestion des changement. A mon sens, c’est une approche à privilégier plutôt que d’essayer de se rassurer dans des initiatives de type «dénigrement» ou «coup de tête». Elles conduisent le plus souvent à des actions de type « paniqué-coupé-renommé-collé » à partir d’une théorie mal comprise.. Il y a trois domaines principaux dans lesquels la confusion à propos du CAB (Change Advisory Board / Comité Consultatif des Changements) et des pratiques de gestion du changement en général ont entraîné des dysfonctionnements importants. Nous allons essayer de les identifier avant de les comprendre dans le détail.. Survol des trois erreurs Tout d’abord, il y a beaucoup d’incompréhension quant à la signification de la lettre «A» dans l’acronyme «CAB». Deuxièmement, il y a également une incompréhension quant aux changements qui devraient «passer par le CAB». Troisièmement, il existe une confusion relative à la séparation des pratiques de gestion des changements et des pratiques de gestion des mises en production. Cela fait beaucoup pour un seul processus, certes majeur, parmi les 25 processus décrits dans les publications ITIL 2011. 30/05/2022 14:12 Les changements à l'ère de DEVOPS - Blog de la Transformation Digitale www.ab-consulting.fr/blog/it-sm/cab-et-changements-vs-devops 3/8 Commençons par rappeler quelques notions issues d’ITIL, mais souvent incomprises : CAB signifie «Change Advisory Board» (Comité Consultatif des Changements) et non pas «Change Approval Board» (Comité d’Autorisation des Changements). Le CAB n’est pas obligatoire dans ITIL, pas plus que l’envoi de toutes les demandes de changement (RFC) au CAB. A chaque fois que les auditeurs exigent des décisions du CAB, ils confondent la fin et les moyens. Lorsque les managers exigent des décisions du CAB, alors c’est qu’il existe probablement un problème de confiance. L’automatisation (pour les modifications logicielles) rend même les auditeurs plus heureux. Le logiciel circulant dans le pipeline CI / CD (intégration continue / livraison continue) n’est pas destiné à passer par le CAB. L’amélioration des pratiques de gestion du changement requiert la réduction du nombre d’intermédiaires intervenant dans le processus pour améliorer son efficacité. 1 – « A » pour « Advisory » (conseiller) Comme son nom l’indique, le CAB (Comité Consultatif sur les Changements) a pour objectif de conseiller sur l’évaluation des changements. Il est utile principalement lorsqu’il s’agit de changements à haut risque ou de changements à grande échelle qui vont au-delà du champ de perception d’une équipe particulière. Dans ce cas de figure, ils nécessitent la coordination et la gestion de situations complexes. Il faut alors faire face à des priorités conflictuelles et faire des choix en raison de coûts ou de délais. Le rôle du CAB, dans de telles situations, est essentiel car il permet de recueillir les avis de toutes les parties prenantes. Pour diverses raisons, le mot «Advisory» (Consultatif) est devenu «Approval» (Approbateur) dans de nombreuses entreprises. Le CAB s’est alors transformé en un mécanisme de création de retard sans valeur ajoutée. Il est censé être là pour des raisons de qualité, mais il atteint rarement son objectif. La différence entre les mots est loin d’être seulement une question pédante de sémantique : Advisory: avoir ou exercer le pouvoir de conseiller Approval: acte ou instance d’approbation de quelque chose Un mode de fonctionnement inefficace qu’il faut absolument améliorer De plus, les CAB, dans les entreprises, ont souvent tendance à être statiques. C’est toujours même groupe de managers qui discute de tous les changements qui leur sont apportés, quels que soient l’équipe / l’application / le service concerné. Ils invitent parfois les auteurs de RFC (Request For Change / Demande de Changement) ternes et volumineuses à y ajouter un peu de couleur. Cette approche introduit un niveau d’intermédiation qui perd beaucoup de détails. Par conséquent le risque est grand de créer un type de pratique, fonctionnel techniquement mais défaillant dans la pratique. L’absence d’avis est une chose, mais l’échec en matière d’approbation en est une toute autre. La pratique consistant à utiliser des RFC dans l’entreprise semble davantage venir d’un livre de recettes que de l’ITSM. La dynamique de la mise en œuvre repose alors sur un examen minutieux afin de s’assurer que tous les champs du formulaire sont remplis. Elle ne repose pas sur des conseils pertinents. En effet, souvent, les RFC contiennent des informations destinées au CAB. Elles ne contiennent pas les questions et les réponses de / à la personne ou l’équipe recherchant un avis. Cela ne veut pas dire que des contrôles de qualité ne doivent pas être mis en place. Cependant un mécanisme intervenant tardivement dans le jeu, de type Potemkin, est plus susceptible de gêner que d’aider l’entreprise à atteindre ses objectifs. La réduction du nombre d’erreurs est alors obtenue en évitant les changements plutôt 30/05/2022 14:12 Les changements à l'ère de DEVOPS - Blog de la Transformation Digitale www.ab-consulting.fr/blog/it-sm/cab-et-changements-vs-devops 4/8 qu’en améliorant la résilience du système. En effet, la dynamique est tellement lourde, coûteuse et chronophage que les « petits » changements seront rejetés. Ceci peut souvent conduire, en retour, à un besoin de changements de grande ampleur. C’est notamment le cas lorsque le système a dépassé sa date de péremption et échoue sur plusieurs fronts simultanément. Pour améliorer les pratiques dans ce domaine, une réduction réfléchie et consciente des intermédiaires est nécessaire. Ainsi l’évaluation de l’impact et la prise de décision seront rapprochées du lieu où le travail est réalisé. L’efficacité, les coûts et les délais n’en seront qu’améliorés. 2 – Pratiques obsolètes et manque de confiance Comme nous venons de le voir, le CAB peut être un élément utile de la gestion des changements pour certains types de changements. Il sera beaucoup moins utile pour d’autres. Notez bien que je dis «peut être», ce qui signifie que le CAB est facultatif et en aucun cas obligatoire. Il ne devrait être introduit que s’il est vraiment utile. Sa conception, sa portée, son rôle et sa valeur doivent être réexaminés de manière continue. Parmi les autres raisons, il y en a deux uploads/Management/ les-changements-cab-a-l-x27-ere-de-devops-blog-de-la-transformation-digitale.pdf