Diagramme du processus de gestion des changements (ITIL)
Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.
Qu'est-ce que le processus diagramme du processus de gestion des changements (itil) ?
Dans ce modèle, la gestion des changements désigne la gestion des changements des services IT : le processus permanent par lequel passe chaque changement apporté à un service en production, depuis la soumission d'une demande de changement jusqu'à la clôture du dossier. Ce n'est pas la gestion du changement organisationnel, la discipline centrée sur les personnes associée à des modèles comme ADKAR ou les huit étapes de Kotter, même si les deux sont couramment appelées « le processus de gestion des changements ». La version dessinée ici est la version opérationnelle de style ITIL, exécutée en continu par un responsable des changements et un comité consultatif des changements.
L'essentiel de la valeur se trouve dans une seule décision, en amont : quel type de changement est-ce ? Faire passer chaque changement par la même évaluation complète et le même comité hebdomadaire crée une file d'attente, et c'est une file d'attente qui pousse les gens à faire des changements en dehors du processus. Le schéma trie donc une seule fois, tôt. Les changements standard sont préautorisés selon un modèle de changement documenté et vont directement à la planification. Les changements normaux reçoivent une évaluation de risque et d'impact et vont au CAB. Les changements d'urgence obtiennent une autorisation accélérée d'un CAB d'urgence, puis rejoignent le même chemin de planification, de mise en œuvre et de revue, de sorte qu'un correctif urgent n'est jamais un correctif non consigné.
L'autre chose qu'un diagramme tranche, c'est la responsabilité, ce pourquoi celui-ci est dessiné en couloirs : Demandeur, Responsable des changements, CAB, Équipe de mise en œuvre et Propriétaire du service. Le propriétaire du service a son propre couloir car la vérification est l'étape que les équipes sautent le plus souvent. « Ça a été déployé » et « le service fonctionne » sont deux affirmations différentes, et c'est précisément cette différence qui justifie l'existence du chemin de retour arrière. Dans ce schéma, une vérification échouée déclenche le plan de retour arrière, et le changement réussi comme le changement annulé atteignent tous deux la revue post-implémentation et la clôture.
Ce que couvre cet organigramme
Dans ce modèle
- L'accueil à travers les couloirs Demandeur et Responsable des changements : soumettre une demande de changement, consigner la RFC dans le registre, puis un filtre de complétude à « Demande complète et dans le périmètre ? » qui renvoie les demandes insuffisantes au demandeur pour fournir le détail manquant avant de repasser par le même contrôle.
- Le tri à trois voies à « Type de changement ? », qui envoie les changements standard directement au calendrier des changements, les changements normaux vers l'évaluation de risque et d'impact, et les changements d'urgence vers l'autorisation de l'ECAB.
- Évaluation et approbation : évaluer le risque et l'impact sur le service, consigner l'évaluation et le plan de retour arrière dans un seul document plutôt qu'un fil de tickets, puis l'examen du CAB et une décision d'approbation ou de rejet, les changements rejetés se terminant à un terminateur « Changement rejeté et clôturé » dans le couloir du demandeur.
- La planification, où les chemins approuvé, urgence et standard convergent vers le calendrier des changements et rencontrent un contrôle de conflit avec d'autres changements planifiés, qui renvoie les collisions pour être replanifiées.
- Construction et mise en œuvre dans le couloir Équipe de mise en œuvre : construire et tester le changement, puis le mettre en œuvre dans la fenêtre approuvée.
- Vérification et clôture : le propriétaire du service vérifie le service et répond à « Changement réussi ? », un échec déclenche le plan de retour arrière, et les deux issues convergent vers la revue post-implémentation et la clôture du dossier de changement.
Quand utiliser ce modèle
- Rédiger ou actualiser une procédure de gestion des changements de style ITIL pour une équipe de support, de plateforme ou d'infrastructure qui fonctionne actuellement à l'habitude et aux fils de discussion.
- Convenir de ce qui compte comme standard, normal et urgence avant de configurer les types de changement dans ServiceNow, Jira Service Management ou Freshservice, pour que l'outil encode une décision déjà prise plutôt que d'en inventer une.
- Intégrer de nouveaux responsables des changements, membres du CAB ou ingénieurs d'astreinte qui doivent savoir quels changements nécessitent une approbation, qui la donne et ce qui se passe hors horaires.
- Documenter comment les changements sont évalués, autorisés, testés et annulés pour un auditeur ou un client, par exemple au regard du critère SOC 2 CC8.1 ou du contrôle 8.32 de l'annexe A d'ISO/IEC 27001:2022. Le diagramme documente la procédure ; la preuve, ce sont les dossiers de changement qu'elle produit.
- Réduire votre taux de changements échoués après un mauvais trimestre, quand vous devez voir exactement où se situent la vérification et le retour arrière et qui en est responsable.
Comment cela fonctionne
Renommez les couloirs selon les rôles que vous avez réellement
Remplacez Demandeur, Responsable des changements, CAB, Équipe de mise en œuvre et Propriétaire du service par vos fonctions réelles. De nombreuses organisations ont une seule personne qui agit à la fois comme responsable des changements et présidente du CAB, et les équipes plus petites n'ont pas d'équipe de mise en œuvre distincte. Fusionnez ces couloirs plutôt que de dessiner une structure que vous n'avez pas, et limitez-vous à cinq couloirs maximum, sinon le schéma cesse d'être lisible d'un coup d'œil.
Définissez vos trois types de changement au niveau de la décision de tri
Écrivez ce qui qualifie standard, normal et urgence à côté de la décision « Type de changement ? », et fixez les limites selon le risque et le périmètre d'impact plutôt que l'effort ou la taille du ticket. Gardez la liste des changements standard préautorisés assez courte pour que quelqu'un la maintienne réellement, et donnez à chaque changement standard un modèle de changement documenté qu'il doit suivre.
Nommez l'autorité de changement, sa cadence et son équivalent d'urgence
À l'étape d'examen du CAB, consignez qui sont les approbateurs, à quelle fréquence ils se réunissent et la date limite pour figurer à l'ordre du jour. Définissez séparément l'ECAB : la personne qui peut autoriser un correctif hors horaires est rarement l'ensemble du comité. La règle adoptée par la plupart des équipes : autoriser verbalement en quelques minutes, rédiger le dossier le jour même, l'examiner lors du CAB suivant.
Précisez ce que le document d'évaluation doit contenir
Transformez « Consigner l'évaluation et le plan de retour arrière » en une véritable liste de contrôle : services et utilisateurs concernés, niveau de risque, dépendances, fenêtre d'indisponibilité, approche de test, étapes de retour arrière et qui les exécute. La décision du CAB ne vaut que ce que vaut ce document, et c'est celui qu'un auditeur demandera des mois plus tard.
Rendez explicites les règles de planification et de conflit
Précisez vos périodes de gel, vos délais de préavis minimaux et qui possède le calendrier des changements. Le contrôle de conflit dans ce schéma est délibérément une décision plutôt qu'une formalité, car la plupart des collisions sont deux équipes qui touchent une dépendance partagée plutôt que le même système. Décidez à l'avance si un conflit signifie une replanification ou une escalade.
Définissez la réussite, puis publiez et versionnez la procédure
Précisez ce que signifie « Changement réussi ? » pour vous : quels tests de fumée, combien de temps le propriétaire du service surveille, et ce qui déclenche la décision de retour arrière. Partagez ensuite le schéma là où le travail se fait, à côté du formulaire de demande de changement ou dans le runbook, obtenez l'approbation des personnes qui y sont nommées, et conservez les versions antérieures pour pouvoir montrer quand la procédure a changé et pourquoi.
Questions fréquentes
Est-ce la gestion des changements IT ou la gestion du changement organisationnel ?
La gestion des changements IT. Les deux partagent un nom et presque rien d'autre. Ce schéma est le processus opérationnel de style ITIL pour les changements apportés aux services en production : une RFC est soumise, triée, évaluée, autorisée, planifiée, mise en œuvre, vérifiée et clôturée. La gestion du changement organisationnel est la discipline centrée sur les personnes qui aide le personnel à adopter une nouvelle façon de travailler, généralement structurée autour de modèles comme ADKAR ou les huit étapes de Kotter, et elle n'a ni CAB, ni calendrier des changements, ni plan de retour arrière. Si vous cherchez une analyse des parties prenantes et une planification de communication, ce n'est pas le bon diagramme.
Quelle est la différence entre un changement standard, normal et d'urgence ?
Un changement standard est à faible risque, effectué souvent et préautorisé selon un modèle de changement documenté, il ne nécessite donc aucune approbation individuelle et va directement à la planification. Un changement normal est tout ce qui doit être évalué et approuvé selon ses propres mérites, ce qui correspond au chemin passant par l'évaluation de risque et d'impact jusqu'au CAB. Un changement d'urgence est celui pour lequel attendre le prochain CAB causerait plus de dommages que le changement lui-même, il obtient donc une autorisation accélérée d'un CAB d'urgence. Dans ce schéma, les trois convergent vers le même calendrier des changements, la même mise en œuvre et la même revue, car la catégorie change la voie d'approbation, pas le document.
Chaque changement doit-il passer par le CAB ?
Non, et tout y envoyer est le moyen le plus rapide de pousser les gens à contourner le processus. Le CAB existe pour examiner les changements dont le risque n'est pas déjà compris. Une fois qu'un type de changement a été effectué assez de fois pour avoir une procédure fiable et un mode d'échec connu, promouvez-le en changement standard avec un modèle documenté et retirez-le de l'ordre du jour. Un CAB qui passe sa réunion à tamponner du travail routinier n'examine rien, et la file d'attente qu'il crée pousse les changements réellement risqués vers la voie d'urgence.
Que doit-il se passer quand un changement échoue ?
Il suit le même chemin vers la clôture qu'un changement réussi. Dans ce schéma, une vérification échouée à « Changement réussi ? » déclenche le plan de retour arrière dans le couloir de l'équipe de mise en œuvre, et le changement annulé passe ensuite par la revue post-implémentation et la clôture, exactement comme un changement réussi. Deux choses rendent cela efficace en pratique : le plan de retour arrière a été rédigé et approuvé avant l'exécution du changement plutôt qu'improvisé pendant l'incident, et la revue demande si la catégorie de changement était la bonne, pas seulement si le changement a fonctionné. Une seconde tentative est une nouvelle RFC, de sorte que la tentative échouée conserve son propre dossier.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus de reprise après sinistre (systèmes informatiques) et passe le relais à Organigramme du processus de déploiement de logiciels : de la conception à la….
C'est une étape de Gestion des services informatiques.
Étape 1: Organigramme du processus de gestion des incidents
Un organigramme de processus de gestion des incidents interfonctionnels couvrant la journalisation, la priorisation, l'escalade des incidents majeurs, la violation des SLA, la résolution et la clôture.
Étape 2: Diagramme du processus de gestion des changements (ITIL) Vous êtes ici
Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.
Étape 3: Organigramme du processus de publication du logiciel
Un organigramme du processus de publication de logiciels couvrant le gel de la portée, la porte de test automatisée, la préparation et l'UAT, l'approbation go/no-go, le déploiement, la restauration et les correctifs.