Qu'est-ce que la gestion du changement ?

La gestion des changements ITIL 4 fait référence à un ensemble de lignes directrices établies par la fondation ITIL. Ces lignes directrices aident les organisations à gérer les changements apportés aux produits numériques. friction ou risques minimaux.

ITIL 4 est la quatrième révision de ces recommandations, la première version ayant été publiée en 1989 ! Contrairement à ITIL 3, qui définissait un ensemble de processus précis à suivre pour les organisations, ITIL 4 vise à fournir des recommandations flexibles. Il est important de noter que les organisations peuvent adopter les processus spécifiques décrits par ITIL 3 tout en restant pleinement compatibles avec les recommandations d'ITIL 4.

Les recommandations de gestion du changement d'ITIL 4 fournissent principalement des définitions précises des concepts et rôles clés intervenant dans les opérations informatiques. Ces concepts sont généralisés afin d'être applicables à tous, quelle que soit la structure de l'entreprise. L'objectif est d'aider les organisations à développer leurs propres processus et pratiques en tenant compte du cadre de gestion du changement établi par ITIL 4.

Utiliser les recommandations d'ITIL 4 de concert avec Analyse de prédiction des risques de changement peut considérablement accélérer le rythme des mises en production tout en incitant les équipes produit à privilégier les changements à moindre risque. Anticipez les risques grâce à Digital.ai Intelligence.

Pourquoi utiliser ITIL 4 pour la gestion du changement ?

Les modifications font partie intégrante des opérations informatiques quotidiennes, quelle que soit leur catégorie. Il y a quelques décennies, elles se limitaient à de rares correctifs ou mises à jour de configuration, intervenus quelques fois par an, voire moins. Aujourd'hui, certaines des applications, services et plateformes les plus populaires au monde reçoivent des milliers de mises à jour chaque année. Google a notamment annoncé en 2018 que… Cette année-là seulement, l'entreprise a apporté plus de 3 000 modifications à ses algorithmes de recherche., soit en moyenne environ 9 par jour.

Face à l'évolution rapide et constante de la situation, les organisations informatiques ont besoin d'une méthode structurée pour intégrer et déployer les changements afin de minimiser les risques d'interruptions de service. Parallèlement, les responsables des opérations informatiques doivent lever tous les obstacles qui freinent la rapidité du changement. Tout retard ou contrôle inutile nuit à la chaîne de valeur.

Cela présente un paradoxe : nous devons mettre en œuvre des changements dans un safe et à une vitesse plus rapide que jamais auparavant.

La mise à jour récente du processus de gestion des changements ITIL vise à résoudre ce problème. L'objectif principal de la gestion des changements ITIL 4 est de lever tous les obstacles au déploiement des changements tout en conservant un contrôle efficace des indicateurs opérationnels et des autres objectifs de gestion des risques liés aux changements. Dans cette optique, ITIL 4 propose un cadre d'accompagnement des changements plutôt que de définir rigidement un ensemble de processus de gestion des changements prescriptifs.

En adoptant les idéaux d'ITIL 4 et en les personnalisant pour qu'ils correspondent au mieux à l'environnement organisationnel en question, les équipes d'exploitation informatique peuvent accélérer le rythme du changement tout en minimisant les inefficacités et les menaces perturbatrices en cours de route.

ITIL 4 vise à rendre la gestion du changement moins complexe.

Les premières versions d'ITIL, dont la première a été publiée à la fin des années 1980, décrivaient rigoureusement les processus afin d'apporter prévisibilité et structure aux activités informatiques d'une organisation. Ces directives étaient essentielles pour les entreprises dont les exigences informatiques étaient soit méconnues, soit sources d'imprévisibilité. Elles étaient nées dans un contexte technologique encore peu familier avec l'émergence de nouvelles technologies, et les entreprises comme les organismes gouvernementaux étaient avides de ce niveau de précision.

Cependant, un changement majeur dans les méthodologies de développement logiciel est apparu au début des années 2000 : l’approche Agile. Avec l’approche Agile, les méthodes rigides « … »CascadesLes processus de développement traditionnels ont été supprimés. Cela a permis aux équipes de développement de bénéficier d'une plus grande autonomie et d'un meilleur contrôle sur leurs résultats finaux, qui pouvaient être atteints dans un délai considérablement plus court.

La méthode Agile a popularisé l'idée que les applications et les plateformes technologiques pouvaient évoluer en continu, à condition que des efforts soient déployés pour s'assurer que chaque nouvelle modification apporte une valeur ajoutée aux utilisateurs finaux.

En réponse à l'essor de la méthodologie Agile (et DevOps Suite à cela, ITIL a dû s'adapter. ITIL v3 s'est appuyé sur les processus de changement ITIL existants et a développé un modèle de mise en œuvre du changement continu que de nombreuses organisations ont suivi en suivant les étapes suivantes :

1. Créer une demande de changement (RFC)
2. Examiner la RFC
3. Le comité consultatif Have a Change (CAB) évalue et analyse le RFC
4. Autoriser les modifications en fonction de la RFC
5. Planifier les mises à jour
6. Mise en œuvre coordonnée
7. Deploy/intégrer les nouvelles modifications
8. Examinez les modifications et fermez l'enregistrement des modifications.

Cette version du processus de gestion des changements ITIL était fiable, reproductible et permettait un contrôle important sur le résultat des propositions de changement. Cependant, pour certaines organisations, elle restait encore assez lourde à mettre en œuvre.

L'exigence d'un examen constant par le comité consultatif des modifications (CAB) retarde les changements et peut engendrer d'importantes inefficacités. De ce fait, la valeur ajoutée de chaque modification s'en trouve compromise.

Face à ces lacunes, le nouveau référentiel ITIL 4 suggère de réserver le modèle rigide de gestion des changements « proposition > approbation > implémentation > clôture » ​​à certains changements considérés comme non standard. Ainsi, tout en conservant un processus de gestion des changements « classique » similaire à celui des versions précédentes, ITIL 4 encourage les responsables des opérations informatiques à faire migrer autant de changements que possible vers une autre catégorie : les changements standard.

Accélérer le rythme du changement grâce aux modèles de changement standard d'ITIL

ITIL v3 comportait une catégorie de changements proposés décrits comme des « changements standard ». Ceux-ci étaient considérés comme présentant un faible risque et étaient susceptibles de se produire fréquemment dans l'environnement informatique donné. Exemples proposés Cela comprenait les changements de mots de passe, les procédures d'embauche de nouveaux employés et le déménagement du matériel physique.

Avec ITIL 4, les responsables ITSM reconnaissent que les organisations peuvent viser à ce que les changements standard deviennent la norme, et non une exception aux « changements normaux ». ITIL 4 propose qu'en modélisant des catégories de changements ou des types de changements spécifiques, le contrôle d'accès formalisé et l'approbation du CAB ne soient plus nécessaires dans de nombreux contextes.

Déterminer quelles modifications sont réellement « normales » (c’est-à-dire « à faible risque ») permet ainsi de lever la plupart des obstacles à l’agilité. Lorsque des modifications plus risquées sont intégrées au processus formel de demande de changement (RFC), les responsables des opérations informatiques peuvent également commencer à évaluer, à atténuer ou à refuser le risque.

Le processus de mise en œuvre d'une modification normale peut désormais être largement automatisé, ce qui signifie que dès que la modification est proposée par le développement (souvent en réponse aux retours d'information des opérations informatiques), elle peut être testée, intégrée et déployée dans l'environnement de production, puis clôturée avec peu ou pas d'intervention humaine.

Ainsi, bien que les modifications standard reflètent le processus de modification normal, la RFC est examinée et autorisée par un processus à faible latence au lieu d'un examen formalisé par le CAB.

Adapter le processus de gestion des changements ITIL pour accélérer les changements tout en maîtrisant les risques

Chaque étape du processus original de gestion des changements ITIL 3 peut être préservée, dans son essence, sans sacrifier la rapidité ni la flexibilité.

Propositions suggérées par le cadre ITIL 4 mis à jour L'adaptation du processus de gestion du changement d'une organisation comprend notamment :

• Création de modèles de changement pour les changements récurrents
• Décentralisation de l'approbation des modifications standard
• Décomposer les changements importants en petites étapes comportant moins de risques
• Utilisation de contrôles, de tests et de déploiement automatisés

Voici comment les adaptations pourraient se refléter dans chaque étape d'un processus de gestion des changements ITIL plus formel :

Demande de modification

Les modifications « normales » proposées doivent d’abord être évaluées par rapport à un modèle de modification standard afin de déterminer si elles peuvent effectivement être exemptées du processus d’approbation. Les modifications à « faible risque » présentant certaines caractéristiques de modifications pré-modélisées peuvent être scindées de manière à ce que seule la proposition novatrice soit formellement examinée, tandis que les composantes standard sont pré-autorisées.

Lorsque cela est possible, les demandes de changement (RFC) peuvent être générées automatiquement en réponse directe à un besoin de modification identifié grâce aux données issues des opérations informatiques. Ces RFC automatisées peuvent ensuite être intégrées au portefeuille de modifications/fonctionnalités proposé. L'automatisation des RFC réduit le recours aux modifications d'urgence car elle permet d'identifier les risques de manière proactive et de les gérer, de préférence en se conformant au mieux aux modifications standard pré-modélisées.

Évaluation du changement
Conformément à ITIL 4, les réunions du CAB doivent être convoquées pour traiter des circonstances particulières plutôt que d'être planifiées selon une fréquence prédéfinie ou dans le cadre d'une procédure de changement standard. Un seul responsable du changement peut souvent suffire à évaluer le risque ou l'impact d'un changement lorsque son jugement est étayé par… Analyses basées sur l'IALes modifications standard peuvent être évaluées en grande partie ou en totalité par un processus automatisé, ce qui évite l'accumulation de dossiers à examiner et réduit considérablement les délais. Les modifications courantes nécessitant une approbation formelle peuvent servir de base à un nouveau modèle de modification standard ou contribuer à la mise à jour des modèles existants afin de les adapter à un champ d'application plus large.

Autorisation de modifier
L'un des principaux objectifs du cadre de gestion du changement axé sur l'agilité d'ITIL 4 est de réduire autant que possible le nombre d'autorisations de changement. La modélisation des changements permet une autorisation instantanée dans la plupart des cas, et l'utilisation de l'analyse de données permet d'optimiser le processus. évaluer les risques de changement peut rendre l'autorisation de changement normal guidée par l'humain moins lourde et moins exigeante en matière de recherche.

Planifier les changements
L'analyse des modifications permet de rationaliser considérablement la planification des changements et l'autorisation des builds, jusqu'à une automatisation quasi complète. La planification manuelle des modifications et des builds doit être réduite au minimum. Par ailleurs, la modélisation des changements permet de limiter l'incertitude en distinguant ceux qui nécessitent une attention particulière de ceux qui peuvent être rapidement planifiés et intégrés à un déploiement ultérieur.

DeployIntégrer les nouvelles modifications
Grâce au Release Outils de gestionDans de nombreuses entreprises, le déploiement et l'intégration des modifications sont largement automatisés. Les modifications « normales » à faible risque doivent être priorisées, ce qui signifie que la plupart des modifications ne devraient pas nécessiter de déploiement ou d'intégration manuels. Celles qui requièrent une attention particulière peuvent être surveillées après leur déploiement, réduisant ainsi le besoin de supervision humaine directe pour un petit nombre de modifications à risque.

Examinez les modifications et fermez l'enregistrement des modifications.
Il ne faut pas sous-estimer l'importance de la clôture exhaustive des changements. Il a été démontré qu'elle permet de réduire efficacement les problèmes et les perturbations imprévus. Toutefois, cela ne signifie pas que les services informatiques doivent mettre en place des processus de revue manuels complexes pour garantir la stabilité de chaque changement et sa documentation précise.

La clôture des dossiers de changement est l'une des étapes du processus de gestion du changement les plus susceptibles d'être automatisées, même dans les petites organisations. Tests et examens automatisés L’automatisation des mises à jour de la CMDB et autres tâches de clôture des modifications permet de jouer un rôle d’assurance qualité, tout en réduisant le besoin de clôture manuelle. Ces pratiques garantissent des enregistrements plus complets et diminuent le risque que des erreurs organisationnelles n’affectent l’intégrité des données de la CMDB et des autres systèmes d’information critiques.

Accélérez le déploiement du changement grâce à l'analyse informatique à chaque étape du processus.

Les humains sont créatifs et excellents en résolution de problèmes, mais ils ne sont pas aussi performants que les ordinateurs pour analyser rapidement des milliers de lignes de code ou des millions d'entrées de données. L'analyse de données offre cette fonctionnalité et peut considérablement améliorer la productivité informatique tout en optimisant le processus d'analyse et de déploiement des changements.
L'ajout de modèles d'IA et d'apprentissage automatique renforce encore les capacités informatiques en décelant automatiquement dans les données des tendances que l'œil humain ne pourrait pas percevoir, comme les facteurs de risque de changement ou la probabilité qu'un changement donné ait un effet perturbateur sur les performances.

Ces fonctionnalités illustrent le rôle essentiel de la technologie pour nous aider à gérer les technologies que nous créons et modifions au quotidien. Si l'automatisation des changements n'est pas indispensable aux pratiques modernes de gestion du changement, les recommandations ITIL la considèrent comme une bonne pratique, cruciale dans un monde où la vitesse d'exécution se mesure en millisecondes et non en mois.