L'ITSM pour les équipes haute vélocité
L'évolution de la gestion des changements informatiques
La gestion des changements, également appelée « habilitation des changements », est une pratique informatique visant à réduire les interruptions des services informatiques, tout en apportant des changements aux systèmes et services essentiels.
Un changement consiste à ajouter, modifier ou supprimer tout ce qui pourrait avoir un effet direct ou indirect sur les services.
Les pratiques de gestion des changements sont conçues pour réduire les incidents et respecter les normes réglementaires. Ces pratiques garantissent une gestion efficace et rapide des changements apportés à l'infrastructure informatique et au code. Qu'il s'agisse de déployer de nouveaux services, de gérer des services existants ou de résoudre des problèmes dans le code, les approches modernes de gestion des changements éliminent les silos, fournissent du contexte et de la transparence, évitent les goulots d'étranglement et limitent les risques.
La gestion des risques est une pratique ITIL 4 connexe adoptée « pour s'assurer que l'organisation comprend et gère efficacement les risques. » La gestion des risques et des changements exige un suivi et un lien entre les changements afin de fournir un enregistrement auditable. En tirant parti des données sur les changements antérieurs et leurs taux de réussite, les organisations peuvent adapter leurs pratiques de manière à équilibrer intelligemment les risques et la rapidité.
Les pratiques adaptatives axées sur les données visent l'efficacité, contrairement à la gestion traditionnelle des changements, qui s'avère souvent inutilement lente, procédurale et lourde. Étant donné que la gestion des changements traite des défis liés aux risques et à la conformité, à l'auditabilité et à la coordination entre les équipes, elle devient trop souvent complexe, bureaucratique et pénible.
Mais ce n'est pourtant pas une fatalité. La gestion des changements, c'est un peu comme « manger ses légumes » : pas toujours appétissant, mais d'une importance cruciale. Grâce aux bonnes pratiques et à la culture adéquates, la gestion des changements permet de limiter les incidents, de réduire le stress pour vos équipes et de consacrer plus de temps à la valeur apportée aux clients.
Définition de la gestion des changements
Quand il est question de gestion des changements, certains d'entre nous incluent tous les aspects du changement dans la définition : de la technologie, des personnes et des processus à l'impact sur les clients et les systèmes. Afin d'apporter une clarté dans le contexte de l'ITSM, ITIL 4 a établi une distinction entre les pratiques de gestion des changements informatiques et de gestion des changements organisationnels.
- La gestion des changements organisationnels est la « pratique qui consiste à s'assurer que les changements au sein d'une organisation sont implémentés de façon fluide et efficacement, et que la gestion des aspects humains des changements procure des avantages durables. »
ITIL 4 a ensuite redéfini son ancien processus de gestion des changements en tant que pratique de « contrôle des changements ».
- La pratique de contrôle des changements garantit « que les risques sont correctement évalués, autorisant les changements à se poursuivre et gérant un planning correspondant afin de maximiser le nombre de changements fructueux au niveau des services et des produits ».
Le choix de ce nouveau nom a suscité la controverse, de nombreuses équipes informatiques rejetant l'association avec le « contrôle ». Pour certains, c'est un mot toxique qui évoque la bureaucratie, les goulots d'étranglement et les mesures inutiles que la gestion traditionnelle des changements a créés (en conséquence de quoi, elle est d'ailleurs devenue tristement célèbre).
Axelos a écouté les commentaires et répondu. « Suite à la sortie d'ITIL 4 Foundation, plusieurs personnes à travers le monde nous ont dit que la pratique était mal interprétée ou mal comprise, puisqu'elle était vue comme le "contrôle des changements" ou le "contrôle des équipes", plutôt que le "contrôle du rythme des changements". »
ITIL a finalement décidé d'appeler la pratique « habilitation des changements ». Le nouveau nom évoque une pratique qui aide les équipes en leur donnant la possibilité (et la liberté) de faire avancer les changements.
En fin de compte, nous ne pensons pas que le terme que vous utilisez soit particulièrement important. (Dans cet article, et chez Atlassian, nous utilisons « gestion des changements ».) Ce qui compte, c'est votre approche. Si vous vous reposez sur des équipes performantes et une culture adaptée, votre organisation est sur la bonne voie pour créer une pratique efficace de gestion des changements.
Relation entre la gestion des changements et la gestion des livraisons
La gestion des livraisons constitue une autre pratique importante entourant la gestion des changements. Selon ITIL 4, le but de la « gestion des livraisons… est de rendre disponibles des fonctions et des services inédits et modifiés. » Les livraisons peuvent tout inclure : modifications apportées aux fonctionnalités logicielles, ou encore mises à jour de la documentation et des formations.
Historiquement, la gestion des livraisons regroupait les changements, les présentant aux clients sous la forme de package. La gestion traditionnelle des livraisons respecte les normes strictes en matière de gestion de projets. Elle peut donc créer des frictions lors de la livraison de mises à jour précieuses aux clients et entraîner une certaine frustration parmi les équipes qui adhèrent aux principes Agile.
Nous pouvons repenser la gestion des livraisons pour le contexte DevOps. S'éloignant de sa fonction traditionnelle de gestion de projets, la gestion des livraisons devrait toucher à l'intégration et l'automatisation. Elle apporte des pipelines de code dans un système sécurisé qui intègre (dans la mesure du possible) une revue automatisée, et assure le suivi et la surveillance. Elle brise ainsi les anciennes approches cloisonnées et garantit la transparence des étapes vers la production. La gestion des livraisons pourrait viser à faciliter plus que jamais la fourniture continue de valeur et à appliquer le principe « you build it, you own it » (Vous le développez, vous en êtes responsable).
Pourquoi la gestion des changements informatiques est-elle importante ?
Les organisations modernes expriment des attentes critiques et contradictoires à l'égard de leur équipe informatique. Tout d'abord, elles attendent des services stables et fiables qui garantissent la productivité de l'organisation et répondent aux attentes des utilisateurs finaux. Ensuite, l'équipe informatique doit implémenter des mises à jour régulières des services afin de permettre à l'organisation de s'adapter à l'évolution constante des exigences métier, de sécurité et de coût.
Ne pas tenir compte de l'une ou de l'autre peut avoir des conséquences désastreuses. L'incapacité à maintenir un service fiable peut considérablement affecter la productivité et les coûts. Selon Gartner, de nombreuses organisations signalent que les temps d'arrêt coûtent plus de 300 000 dollars par heure. Pour certains services web, ce chiffre peut être encore bien plus élevé.
Dans le même temps, les organisations qui ne se préparent pas à l'avenir ne pourront plus suivre la vitesse du business et seront distancées par la concurrence. Si vous déployez les changements trop lentement, les employés risquent de rejoindre des entreprises qui utilisent des systèmes moins instables, ou vos clients risquent d'apporter leur soutien et leur argent à d'autres organisations qui leur apportent davantage de valeur.
Comment comptez-vous gérer ces besoins contradictoires ? Une pratique de gestion des changements permet à votre organisation de livrer des mises à jour, tout en assurant la stabilité et en limitant les risques. La gestion des changements permet de réaliser ces derniers de différentes manières :
- Établir un framework pour gérer le processus de changement
- Prioriser les changements nécessaires pour allouer correctement les ressources
- Intégrer les informations pertinentes pour une prise de décision plus intelligente
- Impliquer les parties prenantes nécessaires des domaines du développement et de l'informatique dans les approbations
- Intégrer le test des changements pour éviter les incidents
- Simplifier et améliorer le flux des changements pour générer de la valeur plus rapidement
Types de changements
ITIL définit trois types de changements.
Changements standard
Les changements standard sont à faible risque, souvent répétés et approuvés au préalable. Ils sont exécutés fréquemment et suivent un processus documenté et approuvé.
Par exemple, l'ajout de mémoire ou de stockage est un changement standard. Le remplacement d'un routeur défaillant par un routeur fonctionnel identique est un changement standard. La création d'une instance d'une base de données est un changement standard.
Tous ces changements sont courants et suivent un processus bien défini. Et parce que ce processus a probablement déjà fait l'objet d'un processus d'évaluation des risques et d'approbation de la gestion des changements, il n'est pas nécessaire de le répéter chaque fois qu'un routeur doit être remplacé.
Pour de nombreuses entreprises, les changements standard constituent une opportunité privilégiée pour l'automatisation. Certaines entreprises indiquent que jusqu'à 70 % des changements standard peuvent être automatisés, ce qui permet à leurs équipes de se concentrer sur les changements normaux et urgents.
Changements normaux
Les changements normaux sont des changements non urgents qui n'ont pas de processus défini et pré-approuvé.
Par exemple, la mise à niveau vers un nouveau système de gestion de contenu est un changement normal. La migration vers un nouveau data center est un changement normal. Les améliorations des performances sont des changements normaux. Elles ne sont ni standard, ni reproductibles. Elles présentent des risques. Mais ce ne sont pas non plus des urgences. Ce qui signifie qu'elles peuvent entrer dans la file d'attente habituelle de gestion des changements pour l'évaluation et l'approbation des risques.
Certains changements normaux, comme un remplacement de data center, présentent un risque élevé et peuvent nécessiter une évaluation des risques et une approbation d'un comité consultatif sur les changements (CAB). D'autres, comme un changement de site web, peuvent présenter un risque faible et peuvent être approuvés selon un calendrier plus rapide par une autorité de changement désignée ou au moyen de vérifications automatisées et d'examen par les pairs.
Changements urgents
Ces changements découlent d'une erreur ou d'une menace inattendue et doivent être résolus immédiatement, généralement pour restaurer le service pour les clients ou les employés ou sécuriser les systèmes contre une menace.
Par exemple, l'implémentation d'un correctif de sécurité est un changement urgent. Résoudre une panne de serveur est un changement urgent. La résolution d'un incident majeur est un changement urgent.
De par leur nature, les changements urgents doivent être traités beaucoup plus rapidement, car un processus de revue long est plus risqué que la résolution rapide du ticket.
La façon dont vous catégorisez vos changements dépend de facteurs, tels que vos processus, votre organisation et votre tolérance au risque. Nous préconisons l'abandon de l'approche « universelle » et le traitement différent de chaque changement en fonction de l'évaluation des risques. Au fur et à mesure que votre organisation en apprend davantage sur les incidents antérieurs et les systèmes spécifiques, et intègre d'autres données pertinentes, vous devriez pouvoir définir un plus grand nombre de changements comme standard et de les pré-approuver. La gestion moderne des changements devrait simplifier les demandes de changement autant que possible.
Qu'est-ce qu'un comité consultatif sur les changements (CAB) ?
Dans la plupart des organisations informatiques traditionnelles, un comité consultatif sur les changements (CAB) est chargé d'évaluer les risques liés à l'approbation (ou la non-approbation) de chaque changement. En règle générale, le CAB organise régulièrement des réunions pour examiner tous les changements proposés et, si nécessaire, fait appel à des experts pour expliquer, défendre ou évaluer ces changements.
D'une part, les CAB peuvent aider à réduire les risques et à donner l'alerte lorsqu'un changement ne fonctionne tout simplement pas pour l'entreprise. D'autre part, ils peuvent également créer un goulot d'étranglement, surtout lorsqu'ils sont composés de personnes qui ne sont pas familiarisées avec les changements déployés. Dans de nombreuses entreprises, le processus d'approbation du CAB est complexe et chronophage, ce qui ralentit le processus de changement.
De nombreuses équipes informatiques délaissent les réunions traditionnelles du CAB ou limitent le périmètre aux changements les plus risqués et aux préoccupations organisationnelles importantes. Dans ce paradigme, les CAB deviennent des conseillers de confiance chargés de surveiller les tendances, de conseiller sur la façon dont les pratiques peuvent y répondre, et d'assurer la coordination entre les équipes et leurs besoins.
ITIL 4 encourage également la décentralisation de votre autorité de changement au niveau des parties prenantes métier ou des pairs. Au lieu d'avoir recours à un comité distinct, intégrez la gestion des changements dans les workflows normaux avec les parties prenantes concernées. Pour éviter les situations de goulot d'étranglement, envisagez l'automatisation, les checklists virtuelles et la revue par les pairs comme alternative plus agile et plus collaborative.
Processus de gestion des changements
Pour les équipes agiles haute vélocité, le processus de gestion des changements s'éloigne des longues revues et des approbations non techniques des parties prenantes pour se rapprocher des processus automatisés et collaboratifs entre les équipes informatiques et de développement. Ces processus augmentent l'agilité, tout en tenant compte des risques.
Voici un aperçu sommaire d'un processus de gestion des changements, ainsi que quelques recommandations pour accélérer votre génération de valeur.
| Phase | Bonnes pratiques |
| Demande de changement : quelqu'un demande un changement et inclut des notes sur les risques possibles, l'implémentation prévue et les systèmes affectés. | Configurez un portail en libre-service intuitif pour les parties prenantes et le personnel informatique afin de créer facilement une demande de changement standard. Assurez-vous que vos équipes de développement et informatiques peuvent collaborer sur la même plateforme pour obtenir tout le contexte complet et garantir la transparence tout au long du workflow des demandes de changement. |
| Examen des demandes de changement : un responsable des changements ou un pair évaluateur passe en revue la demande de changement initiale. Quelle est la probabilité de réussite ? Les risques et les récompenses sont-ils exacts ? Le jeu en vaut-il la chandelle ? | Utilisez l'automatisation pour approuver automatiquement le changement ou lancer un bref processus d'approbation avant l'implémentation du changement. |
| Plan de changement : l'équipe crée un plan d'attaque pour le changement. Elle documente les résultats attendus, les ressources, le calendrier, les exigences en matière de tests et les moyens d'annuler le changement si nécessaire. | Alignez rapidement les parties prenantes grâce à une réunion de lancement sur la gestion des changements. Assurez-vous que vos équipes restent sur la même longueur d'onde grâce à des modèles de base de connaissances pour documenter vos plans de changement. |
| Approbation des changements : le responsable des changements, le réviseur pair ou le CAB approprié passe en revue le plan et approuve le changement. | Simplifiez les approbations grâce à des revues par les pairs. Décloisonnez grâce au suivi et à la documentation partagés, afin que les gens puissent collaborer facilement et de manière asynchrone. |
| Implémentation des changements : l'équipe livre le changement ; elle documente les procédures et les résultats en cours de route. | Utilisez l'automatisation pour exécuter vos processus et vos standards. L'automatisation du workflow peut acheminer et assigner des demandes à la prochaine personne autorisée en fonction de vos règles métier. |
| Clôture des changements : le cas échéant, le responsable des changements passe en revue et clôture le changement. Son rapport doit indiquer si le changement a été couronné de succès, en temps opportun, avec précision, dans les limites du budget, etc. | Conservez des articles de base de connaissances et des tickets accessibles afin que les équipes puissent tirer des enseignements des tâches antérieures. Peut-être est-il possible d'automatiser des demandes de changement similaires à l'avenir. |
Bonnes pratiques en matière de gestion des changements
Comme déjà mentionné, pour certains, la crainte liée à la gestion des changements est la même que celle ressentie à propos des légumes verts à feuilles. Nous ne sommes pas toujours impatients d'en manger, mais nous connaissons leurs bienfaits. De plus, nous pouvons faire en sorte de rendre le tout plus attrayant.
Voici quelques bonnes pratiques pour une gestion moderne des changements :
- Déterminez la tolérance au risque et les obligations réglementaires de votre organisation
- Simplifiez et automatisez les processus de gestion des changements dès que possible
- Donnez aux CAB une orientation plus stratégique
- Adoptez des pratiques pour faire des changements standard la nouvelle norme
- Consultez divers frameworks, comme ITIL et DevOps, pour trouver des directives qui conviennent le mieux à votre organisation
- Donnez la priorité à la collaboration
- Exploitez l'ingénierie du chaos pour réduire vos risques
- Simplifiez la réception des demandes de changement pour les équipes informatiques et de développement
- Libérez le potentiel d'apprentissage grâce aux métriques de changement et aux indicateurs de performance clés (KPI)
- Adoptez une approche DevOps de la gestion des livraisons
Relever les défis posés par la gestion des changements
Les développeurs veulent déployer le code rapidement et sans consacrer du temps et des efforts supplémentaires à la documentation manuelle. Les équipes dédiées aux opérations informatiques cherchent à réduire les risques, à tenir des registres détaillés pour les audits et à éviter les incidents. Si vous demandez aux développeurs d'ajouter une étape supplémentaire à leurs processus, de tout consigner, du matin au soir, ils se sentiront sûrement détournés du but ultime de leur travail. Demander à l'équipe opérationnelle de repenser les processus existants, d'abandonner les contrôles d'approbation et de se reposer davantage sur l'automatisation n'est pas chose aisée et pourrait entraîner des risques supplémentaires.
Pendant ce temps, les enjeux sont plus élevés que jamais. L'essor des services basés sur les logiciels a élevé les attentes des clients et augmenté la demande en services ultra performants disponibles en continu. Dans un environnement toujours plus dynamique, le travail nécessaire à la gestion des services ne cesse de s'intensifier.
Alors, comment surmonter ces défis ? Eh bien, tout d'abord, en dissipant le mythe selon lequel un processus complexe réduit les risques. Ensuite, en adoptant une culture, des pratiques correspondantes et des outils qui aident les équipes à collaborer et à livrer. Enfin, en intégrant continuellement des informations pour démontrer la valeur des étapes précédentes et s'efforcer de s'améliorer encore.
Vous souhaitez découvrir comment Jira Service Management peut transformer votre processus de gestion des changements ?
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Lire le livre blancBase de connaissances : votre solution pour améliorer la collaboration
Découvrez la puissance d'une base de connaissances pour votre entreprise. Augmentez la productivité, améliorez le service client et rationalisez efficacement la gestion des informations.
Lire l'article