Nous allons voir dans ce chapitre comment créer dans GLPI un ticket de changement, et comment le qualifier pour optimiser son traitement.
Identifiez un changement et une demande de changement
Mais tout d’abord, qu’est-ce qu’un changement ?
Encore et toujours, référons-nous au référentiel ITIL pour mieux cerner ce qu’est un changement.
Ça peut être par exemple :
une nouvelle version d’une application (mise à jour applicative) ;
une modification de l’infrastructure (mise à jour technique logicielle ou hardware) ou la modification d'une procédure ;
un remplacement d’un composant de l’infrastructure (ex : remplacement d’une carte réseau, d’un switch, d’une baie…) ;
l’installation/désinstallation d’une application ou d'un service ;
l’externalisation d’un service vers un fournisseur externe ;
l’installation de matériel, de logiciels.
Afin de réaliser ces changements en maîtrisant les risques de dégradation ou de rupture de services SI, tout changement doit être introduit par une RFC – Request For Change : une demande de changement qui permettra de décrire, suivre et contrôler le changement.
Une demande de changement ne concerne pas uniquement des services techniques liés à l’infrastructure, mais aussi :
des services applicatifs ;
des procédures ;
des méthodes de travail ou d’organisation.
GLPI nous offre la possibilité de gérer et suivre une demande de changement en gardant le contrôle sur le SI : autorisation, priorisation et planification des actions nécessaires. C’est ce que vous allez découvrir dans la suite de ce cours.
Qualifiez une demande de changement et définissez sa priorité
L’objectif maintenant est de rassembler tous les éléments pour qualifier sereinement la demande de changement, et établir la priorité de son traitement.
Afin de cerner le périmètre du changement, vous définissez sa catégorie qui permet d’informer sur quel composant du SI (technique, infrastructure ou applicatif) se situe le changement.
Mais le plus important est de responsabiliser les acteurs contribuant au changement, sur la priorité du traitement de ce changement.
Comme pour les incidents et les problèmes, la priorité se déduit de :
l’impact qui représente l’ampleur du périmètre et/ou le nombre d’utilisateurs concernés par ce changement ;
l’urgence qui va mesurer le niveau de criticité sur l’activité, l’urgence à mettre en place le changement (ou l’incident, ou le problème).
La matrice de priorités se configure dans GLPI via le menu Configuration > Générale > Assistance. À l’intersection ligne (urgence)/colonne (impact), se situe la priorité :
Il faut donc interpréter comme suit :
Impact | Urgence | Priorité indiquée dans GLPI | Priorité dans le vocabulaire de gestion des changements |
Haut | Haute | Très haute | Urgent/Critique |
Moyen | Basse | Basse | Normal |
Bas | Moyenne | Basse | Normal |
Bas | Basse | Très Basse | Standard/Planifié |
Créez dans GLPI la demande de changement
Avec les éléments cités plus haut, vous allez pouvoir créer votre première demande de changement dans GLPI.
Prenons l’exemple de l’arrivée dans quelques jours d’un nouveau collaborateur et de la mise à disposition de son poste de travail : masterisation d’un PC et installation sur le bureau du collaborateur.
C’est parti, lancez GLPI, cliquez sur le menu Assistance > Changements
Et cliquez sur l’icône « + » (Ajouter) :
Renseignez les champs de base
Date d’ouverture : laissez la date et l’heure renseignées par défaut.
Par : en général vous-même ou le nom du demandeur (ce champ est renseigné par défaut avec votre nom) : Courgey Guy.
Statut : Nouveau (ce champ est renseigné par défaut avec Nouveau).
Demandeur : champ renseigné par défaut avec votre nom. Préciser la personne qui est à l’origine de la demande de changement, ici c’est Suisurre Jean.
Attribué à : pour un changement « planifié », c’est-à-dire de priorité très basse, renseigner ce champ avec le groupe de techniciens ou avec le nom du technicien qui va réaliser la préparation et l’installation du poste de travail. Ici : Itekniciun Paul (Pour un changement de priorité plus élevée, saisir dans ce champ le nom du Change Manager).
Décrivez la demande de changement : soyez précis
Plus la description est précise, plus vous facilitez le traitement de la demande.
Titre : résumez la demande de changement en quelques mots (soyez clair et succinct) : Mise à disposition d'un poste de travail à M. Fassaule.
Description : décrivez la demande de changement, de façon précise et détaillée : Suite à l'embauche de Monsieur Rémi Fassaule, préparer et installer un poste de travail (profil contrôleur de gestion) dans le bureau E1028, en face de Madame Sarah Vigote.
Catégorie : permet de comprendre immédiatement sur quel composant du SI se situe la demande : Matériel.
Saisissez les champs de classification du changement
Validation : dans cet exemple, la demande de changement est « standard », c’est-à-dire qu’il s’agit d’un changement commun, sans risque de dégradation du SI et qui est préautorisé. Ainsi, choisir « non soumis à validation ».
Urgence : je rappelle que l’urgence indique le niveau de criticité sur l’activité. Plus l’urgence est élevée, plus il faut mettre en place rapidement le changement. Ici l’urgence est basse, car il s’agit d’un changement standard.
Impact : à titre de rappel, l’impact représente l’ampleur du périmètre du changement et/ou le nombre d’utilisateurs concernés par ce changement. Ici l’impact est bas, car il s’agit d’un changement standard qui ne concerne qu’une seule personne.
Priorité : laissez GLPI calculer la priorité, selon la combinaison de l’urgence et de l’impact. Dans notre exemple : Urgence basse et Impact Bas à Priorité calculée par GLPI selon la matrice des priorités définie = Basse (NB : cf. les éléments indiqués plus haut, il faut interpréter la priorité dite « basse » comme « Planifiée »).
Après avoir cliqué sur le bouton Ajouter, le ticket apparaît en tête de la file des demandes de changements :
En résumé
Dans ce chapitre, nous avons :
découvert ce qu’est un changement dans le référentiel ITIL ;
compris la nécessité de créer une demande de changement (RFC) pour assurer le suivi du changement et garantir la maîtrise des risques de dégradation ou de rupture de service(s) SI ;
caractérisé et priorisé la demande de changement en fonction de la combinaison de l’impact et de l’urgence ;
et enfin créé notre premier ticket de demande de changement.
Dans le prochain chapitre, nous verrons comment suivre l'avancement du changement dans GLPI.
