Page principale | Pages par catégorie | Index des pages Recherche rapide

Modifier

Articles reliés

• Gestion des changements dans Octopus

Modifier

1. Introduction

Cet article présente les concepts clés du processus de Gestion des changements selon le cadre de référence ITIL; nous l'avons simplifié afin de rendre sa compréhension et son opérationnalisation accessible, surtout pour les organisations informatiques qui débutent dans la formalisation d'une gestion des changements au sein de leur organisation.

Le module "Changements" d'Octopus permet la mise en application des activités du processus de Gestion des changements et vise concrètement l'établissement d'un meilleur contrôle des changements informatiques. Nous vous invitons à consulter l'article Gestion des changements dans Octopus pour mieux comprendre l'utilisation de ce module.

L'objectif du processus de Gestion des changements est de garantir que les changements soient enregistrés, évalués, autorisés, priorisés, planifiés, testés, mis en oeuvre, documentés et revus de manière contrôlée.

Pour qu'il soit exécuté de façon satisfaisante, le processus de Gestion des changements doit:

• utiliser des méthodes et des procédures standardisées (qui peuvent être réutilisées)
• assurer l'enregistrement de tous les changements
• tenir compte des risques et des impacts pour l'entreprise

Quels sont les symptômes d'une gestion des changements inexistante ou déficiente? des arrêts de service non planifiés à cause de changements non enregistrés, non autorisés ou insuffisamment évalués & testés des changements déployés avec peu de succès - des incidents surviennent après l'implantation du changement (plutôt que d'être enrayés définitivement) un nombre élevé de changements d'urgence etc.

Chaque organisation TI doit bien définir le périmètre de ce qu'est un changement. Par exemple, une organisation informatique pourrait identifier le remplacement d'un disque dur d'un ordinateur comme étant une demande de service et le traiter comme tel dans le processus d'Exécution des demandes, en-dehors de la gestion d'un changement standard. On pourrait simplement définir que tout ce qui ne constitue pas une demande de service est traité comme un changement dans le cadre du processus de Gestion des changements.

Modifier

2. Quelques définitions

Terme	Définition
Demande de changement (RFC)	Demande formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. Le terme RFC est souvent utilisé à contresens pour signifier Enregistrement de changement ou le changement lui-même.
Changement	Ajout, modification ou suppression de quoique ce soit pouvant avoir un effet sur les services TI. Le "quoique ce soit" est généralement les éléments physiques ou logiciels de l'infrastructure, mais cela inclut aussi les changements à des documentations, des processus, un catalogue de service, etc.
Comité consultatif sur les changements (CAB)	"Change Advisory Board" - Groupe de personnes qui conseille le Gestionnaire des changements dans l'évaluation, la définition des priorités et le calendrier des changements. Ce comité peut être composé de représentants de toutes les branches au sein de l'organisation TI, de l'entreprise ainsi que des sous-traitants.
Calendrier des changements	Document qui établit la liste de tous les changements approuvés et leur date d'implantation prévue.

Modifier

3. Catégorisation du changement

Il existe 3 types de changements:

• Changement standard

• Changement normal

• Changement urgent

Modifier

4. Diagramme de processus de Gestion des changements

Le processus de Gestion des changements comprend une série d'activités dont le déroulement peut différer selon la nature d'un changement. Par exemple:

• les changements standards, qui sont en fait des demandes de services, sont gérés dans le processus d'Exécution des demandes, mais les étapes d'exécution sont définies et validées par la Gestion des changements;

• les changements urgents ont une procédure spécifique définissant comment ils seront évalués, autorisés, testés, et implantés dans un contexte urgent.

L'illustration ci-dessous vous présente un exemple de diagramme de Gestion des changements pour un type Normal, montrant les rôles des différents intervenants durant le processus. Pour télécharger le fichier en format Visio 2007, cliquer ici.





Modifier

5. Activités du processus

Afin de mieux expliquer comment le processus se déroule, voici une brève description de chacune des activités. Modifier

a) Enregistrer la RFC

La création et l'enregistrement du changement (ou RFC) peut se faire par un individu ou un département qui demande le changement; il peut provenir du côté de l'entreprise ou de l'organisation TI (par exemple, un changement à une application, un changement à un élément de l'infrastructure, etc.). Tous les changements sont enregistrés et identifiés d'un numéro unique. Le périmètre et l'impact du changement déterminent la quantité d'information exigée pour son évaluation, et cet aspect doit être défini dans le processus soit par des modèles de documents à remplir, soit par une procédure précise à suivre.

Modifier

b) Valider la RFC

Parmi toutes les demandes de changement soumises, certaines peuvent être illogiques, inapplicables ou incomplètes, ou ont déjà été soumises par quelqu'un d'autre. Si c'est le cas, on les refuse et on transmet la raison au demandeur.

Modifier

c) Évaluer la RFC

En premier lieu, valider le type de changement (catégorie), en prenant en considération le risque et l'impact du changement.

La catégorisation des changements est faite pour identifier le niveau d'autorisation requis pour le changement. Basé sur l'impact et l'urgence, nous pouvons établir une matrice indicatrice du type de changement et de son niveau d'autorisation. Par exemple:





Ce tableau n'est qu'un exemple, chaque organisation TI peut définir le sien selon sa réalité; il peut différer selon le domaine d'affaires de l'entreprise, les applications / matériel critiques ou à risque, etc.

Changements majeurs :

Les changement majeurs impliquent une quantité importante de préparation et de travail, des situations complexes ou des dépenses importantes.

Exemples :

• Implantation / mise à niveau d'une application d'affaires corporative
• Déplacement d'une salle informatique

Changements significatifs :

Les changements significatifs impliquent de la préparation et du travail, ainsi que l'évaluation, l'autorisation et la planification du changement.

Exemples :

• L'acquisition et l'installation d'un nouveau serveur
• La re-segmentation d'une partie du réseau
• L'introduction d'une nouvelle application à un petit groupe d'utilisateurs

Changements mineurs

Les changements mineurs peuvent être évalués et autorisés en-dehors de l'autorité du CAB (par exemple par un coordonnateur).

Exemples :

• L'application d'une "patch"
• L'installation d'un nouveau modèle d'imprimante

Modifier

d) Autoriser le changement

Basé sur l'impact, l'appréciation du risque, les avantages potentiels et les coûts du changement, l'autorité du changement doit donner son accord pour chaque changement. Dans le modèle que nous vous suggérons, on considère:

• le Gestionnaire des changements dans l'autorisation des changements mineurs;
• le CAB pour les changements significatifs, majeurs et urgents (un "Emergency Change Advisory Board (ECAB) sera invoqué alors, selon la procédure spécifique aux changements urgents).

Le CAB se compose de toute personne ayant une implication dans le changement, qu'elle soit technique ou opérationnelle (ceci inclut les clients et les fournisseurs externes). Il se réunit ou se consulte à des intervalles réguliers pour prioriser les changements, faire une revue des changements présentés, faire une revue des changements non réussis et/ou non autorisés, discuter des changements en cours, etc. En principe, il constitue une entité consultative seulement, mais notre modèle considère que si tous les membres sont d'accord, le CAB est l'autorité du changement. Dans le cas contraire, le directeur TI pourra intervenir et décider du sort du changement.

Le CAB sera adapté au contexte et à la taille d'une organisation informatique, l'important est d'avoir une autorité qui voit à ce que les changements soient contrôlés, les risques et les interruptions de services soient minimisés, afin de viser un déploiement réussi à la première tentative. Les documents pertinents doivent être distribués à l'avance pour permettre aux membres du CAB d'évaluer les changements et de se préparer aux réunions.

Il va sans dire qu'un changement majeur ou urgent pourrait nécessiter une autorisation hiérarchique plus élevée, et parfois même une autorisation du côté du client, surtout lorsque les risques sur les affaires et les coûts sont élevés. C'est à l'organisation informatique de définir son propre processus d'autorisation. Modifier

e) Coordonner la mise en oeuvre

Les étapes de réalisation des changements approuvés doivent être transmises aux équipes techniques concernées pour la mise en oeuvre. Il faut tester minutieusement les changement, déterminer une procédure de retour arrière, documenter les solutions aux incidents connus qui surviendront, etc. Modifier

f) Revue et clôture

Les changements normaux et urgents mis en oeuvre sont évalués après un certain temps; le CAB détermine si c'est nécessaire. Les questions suivantes peuvent être abordées:

• Est-ce que le changement a atteint le but souhaité?
• Est-ce que les parties prenantes sont satisfaites du résultat?
• Y a-t-il eu des effets secondaires imprévus?
• Y a-t-il eu des dépassements de coûts et d'efforts par rapport à l'évaluation initiale?
• Pouvons-nous faire mieux?

Si le changement est réussi, il peut être clôturé. Sinon, la gestion des changements ou le CAB décidera de ce qu'il faut faire: un nouveau changement ou une modification au changement enregistré.

Au moment de la clôture, le gestionnaire des changements vérifie que la documentation du changement est complète, et s'assure d'inclure le résultat de la revue du changement. Toute cette information pourra servir de base de connaissance pour un nouveau changement de nature similaire, ou encore comme contribution à l'amélioration continue du processus.