Gestion des changements - Module Octopus

AFFICHER TOUT LE CONTENU

Table des matières

Configurations
Utilisation intermédiaire

Articles reliés

Introduction

Le présent article décrit la configuration et l'utilisation fonctionnelle du module; vous trouverez aussi des éléments explicatifs qui vous aideront à comprendre le lien qui existe entre les fonctionnalités et les bonnes pratiques.

En premier lieu, le module Changements permet d'intégrer et de suivre tous les changements de façon centralisée, premier facteur clé menant à une amélioration de votre gestion des changements. Tel que recommandé par le référentiel ITIL, (voir l'article Gestion des changements - Processus ITIL pour plus d'information), tous les changements sans exception devraient être 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. En effet, tout changement effectué en dehors de ce contexte compromet la stabilité et la fiabilité de l'infrastructure et, par conséquent, la disponibilité des services. Selon le contexte de l'organisation, le périmètre donné à la gestion des changements peut différer, mais certaines activités demeurent des incontournables. 

Le module Changements vous fournit une structure qui vous aide à documenter, construire, approuver, tester et suivre l'ensemble de vos changements. Il convient de définir au préalable comment vous désirez gérer vos changements et d'utiliser l'outil en ce sens. 

Dans l'établissement du processus et la configuration de l'outil, il ne sert à rien de viser la perfection. Il est encore très courant de voir une organisation TI "gérer" ses changements dans des fichiers Excel; sans aucune planification (implantations à toute heure du jour), sans autorisation, sans analyse d'impact, sans solution de retour arrière, sans être enregistrés ou insuffisamment documentés. Pour plusieurs organisations, l'enregistrement et la gestion centralisée de tous ses changements dans un outil constitue parfois une transition majeure qui bouscule les habitudes établies.

Création d'un changement

La création d'un changement s'effectue à partir du Module Changements, en cliquant sur Créer un changement. Cette action ouvre une fenêtre intitulée Nouveau changement.

Un numéro de requête unique sera attribué une fois le changement sauvegardé. Noter que trois champs sont obligatoires à la saisie :

  • Catégorie
  • Soumis par
  • Sujet

Les sections ci-dessous vous expliquent le contenu du formulaire de création de changements.

Partie supérieure du formulaire

Le formulaire Nouveau changement est séparé en deux parties. Voici une illustration ainsi que la description complète des champs.

Description des champs

  • Gabarit de changement : permet de sélectionner un gabarit de changement parmi ceux configurés dans Outils > Gestion des données de référence > Changement > Gabarits. Pour plus d'information, consulter la section Gabarit de changement
  • État : représente où est rendu le changement dans son cycle de vie. Par défaut, en début de processus, l'état est à Nouveau. Les items de liste du champ État sont configurés dans Outils > Gestion des données de référence > Changement > États. Pour plus d'information, consulter la section Gestion des états.
  • Priorité : la priorité d'un changement est dérivée de l'impact et de l'urgence. Pour accéder à ces champs, cliquer sur le lien Priorité du formulaire.
    • La priorité est suggérée au départ par l'initiateur du changement mais pourrait être modifiée lors du processus d'évaluation et d'approbation du changement. L'évaluation du risque est un facteur additionnel à considérer. L'instance d'approbation du changement aura besoin d'information sur les conséquences sur les affaires afin d'évaluer correctement le risque d'implantation. Les critères d'établissement de la priorité d'un changement sont différents de ceux appliqués à un incident. L'impact repose sur les bénéfices sur les affaires une fois le changement implanté ou sur la réduction des impacts négatifs ou des coûts lorsque le changement corrige une erreur. L'urgence, quant à elle, est basée sur le délai que l'on peut se permettre jusqu'à sa mise en oeuvre. Quels qu'ils soient, la documentation des critères - nombre d'utilisateurs affectés, criticité d'une application pour les affaires, étendue des dommages si le changement tourne mal (risques), etc. contribuent tous à une évaluation juste du changement et permet d'augmenter son succès.
      • Valeurs du champ priorité :
        • Élevée : le changement affecte sévèrement des utilisateurs clés, un grand nombre d'utilisateurs ou les affaires
        • Moyenne : pas d'impact sévère, mais le changement ne peut pas être différé jusqu'au prochain déploiement - il doit être planifié dans un avenir relativement court
        • Basse : le changement est nécessaire et justifié, mais on peut attendre qu'une occasion se présente (par exemple, une interruption de service pour un autre changement planifié)
  • Début : un changement peut être enregistré à l'avance, dans le cadre d'une gestion de projet par exemple; cependant, on peut vouloir indiquer la date de début du changement. On pourrait aussi l'utiliser pour d'autres fins, par exemple, la date où le changement a été assigné à une ressource
  • Échéance : ce champ peut être utilisé pour inscrire la date d'implantation demandée par l'initiateur du changement
  • En attente : lorsque le changement est reporté à une date ultérieure inconnue, ou pour toute autre raison - à la sélection de la case à cocher, on doit justifier la raison de la mise en attente
  • Catégorie : indique la catégorie de changement. Ce champ détermine le cycle de vie qui sera appliqué. La catégorie est configurée dans Outils > Gestion des données de référence > Changement > Catégories. Pour plus d'information, consulter la section Gestion des catégories
  • Financement : désigne la source de financement du changement, tel que le service de l'informatique, le client, ou toute autre source. Les items de la liste sont personnalisables dans Outils > Gestion des données de référence > Général > Sources de financement
  • Urgent : indique un changement normal qui doit être mis en oeuvre dès que possible
  • Projet de développement : ce champ est temporaire et sera éventuellement retiré du formulaire. Il peut être configuré comme catégorie Projet dans la Gestion des données de référence
  • Coût estimé : champ de type monétaire pour indiquer le coût estimé du changement
  • Impact sur l'infrastructure : indique l'étendue du risque sur l'infrastructure, à savoir si des CIs en relation avec le CI ajouté ou modifié peuvent aussi être affectés par le changement. Par exemple, un changement sur un routeur peut affecter plusieurs sites qui dépendent de ce routeur. Les valeurs possibles sont : 
    • Impact majeur
    • Impact significatif
    • Impact mineur
  • Coût réel : cumulatif du total des coûts totaux de l'onglet coûts ainsi que le total des coûts relatifs aux efforts des activités du changement. Le coût estimé -vs- le coût réel permet de suivre l'aspect financier du changement dans le temps
  • Impact sur les ressources : indique ce que le changement exige en termes d'implication des intervenants dans le changement. Les valeurs possibles sont : 
    • Impact majeur
    • Impact significatif
    • Impact mineur
  • Amortissement (mois) : permet d'inscrire un amortissement sur le changement, par exemple, une nouvelle application qui aurait une valeur aux livres et qu'on voudrait amortir sur une période de "x" mois
  • Service : permet de sélectionner un service impacté par le changement, les items de liste proviennent des CIs de type Service du module Configurations
  • Soumis par : identifie l'utilisateur qui crée le changement, qui peut aussi être un intervenant. C'est un champ obligatoire à la saisie lors de la création du changement 
  • Site : indique le site affecté par le changement (restreint à un site)
  • Géré par : identifie l'intervenant qui gère l'intégralité du changement - ne représente pas nécessairement le gestionnaire des changements dans le sens ITIL du terme
  • Sujet : champ de type texte obligatoire à la saisie lors de la création du changement

Partie inférieure du formulaire | Onglets

La partie inférieure du formulaire Nouveau changement comprend huit onglets, que nous détaillons ci-dessous.

Onglet Documentation

L'onglet Documentation permet à l'utilisateur de documenter le changement et de fournir au gestionnaire des changements tous les détails nécessaires à l'acceptation, l'analyse et l'autorisation. On y retrouve les sections suivantes : 

  • Description
  • Impacts
  • Impacts si on ne réalise pas ce changement
  • Sommaire des coûts et ressources
  • Sommaire des risques
  • Plan de secours
  • Temps d'arrêt planifié
  • Plan de communication
  • Autorisations

À mesure que vous les documenterez, les champs se positionneront automatiquement au début jusqu'à reprendre l'ordre établi ci-dessus.

Certains de nos clients ayant une gestion des changements plus mature aiment utiliser l'onglet Documentation pour documenter les petits changements (standards ou mineurs) pour un accès rapide à l'information. Les changements de plus grande envergure, quant à eux, pourraient nécessiter un document formel permettant une documentation plus complète, dont plusieurs livrables. Ces derniers peuvent alors être ajoutés comme fichiers joints à la requête.

 

Voir en image

 

ATTENTION : ll est  possible de modifier le nom des champs ou de retirer un ou plusieurs champs par défaut de l'onglet Documentation du module Changements. 

Champs par défaut :

  • Description
  • Impacts
  • Impacts si on ne réaliste pas ce changement
  • Sommaire des coûts et ressources

  • Sommaire des risques
  • Plan de secours
  • Temps d'arrêt planifié
  • Plan de communication
  • Autorisations

Pour plus d'informations ou pour faire modifier ces sections dans votre environnement, télécharger et remplir le fichier Excel et le transmettre votre demande de Changement de configuration / données à notre Centre de services. 

Onglet Tâches

L'onglet Tâches peut inclure les tâches d'approbation, standard et de notification relatives à l'exécution d'un changement ("workflow"). Ces tâches peuvent être assignées à un groupe / intervenant pour exécution. Un intervenant peut documenter ses actions en ajoutant une activité à la tâche sans nécessairement y être assigné.

Noter que la revue post-implantation, considérée comme une bonne pratique dans la gestion des changements, peut être représentée comme une tâche à exécuter avant la fermeture du changement.

Les tâches peuvent être visualisées en mode liste ou en mode graphique. Voir l'article Gestion des tâches pour plus de détails au sujet de l'exploitation des tâches dans Octopus. 

Voir en image

Tâche de déploiement

Une tâche de déploiement est une tâche standard qui est destinée au déploiement du changement. Toutes les tâches de déploiement sont consignées dans le Calendrier des déploiements, qui s'avère un outil de planification et de communication très utile. On le consulte afin de planifier des changements qui ne sont pas conflictuels et qui peuvent être déployés ensemble, d'identifier ceux qui nécessitent une interruption de service, qui provoquent une dégradation de service ou qui n'ont aucun impact. Le Calendrier des déploiements peut être consulté par tous les intervenants Octopus.

Déployer plusieurs changements minimise les interruptions de service. Il est de bonne pratique de définir une plage de maintenance connue des utilisateurs où se tiendront les déploiements afin de minimiser les impacts sur les affaires. Il est important de considérer la nature et la criticité des services qui seront interrompus ou dégradés ainsi que la fréquence des déploiements.

Consulter le wiki Calendrier des déploiements pour plus de détails.

Onglet Activités

Nous retrouvons dans l'onglet Activités le journal des activités du changement. Toutes les activités, qu'elles soient ajoutées à partir d'une tâche ou à partir de la requête, se retrouvent consolidées dans cet onglet. 

Voir en image

Onglet Requêtes

L'onglet Requêtes permet d'établir des relations entre le changement et d'autres types de requêtes (incident, SR, événement, problème, changement).

Pour plus d'information consulter l'article Les relations interrequêtes.

Voir en image

Onglet CI

L'onglet CI regroupe les CIs qui doivent faire partie du changement. 

Voir en image

Onglet Coûts

L'onglet Coûts contient les coûts autres que ceux inclus dans les activités du changement ou des tâches (efforts). Les coûts entrés dans l'onglet sont liés dynamiquement avec le champ Coût réel​.

Voir en image

Onglet Fichiers joints

À partir de l'onglet Fichiers joints, il est possible d'ajouter des fichiers à la requête de changement : un formulaire, une autorisation par courriel, des résultats de tests, une procédure de retour arrière, des comptes-rendus de réunion, une revue post-implantation, bref tout livrable obligatoire ou non qui contribue à la documentation du changement, qui facilitera sa consultation avant, pendant et après son implantation. 

Voir en image

Onglet Historique

L'onglet Historique garde la liste des changements faits à la requête de type changement. On peut voir la Valeur initiale, la Nouvelle valeur, la date et l'heure du changement et l'intervenant Octopus responsable.

Voir en image

Configuration du module Changements

Les items de catégorie, d'état et les gabarits de changement peuvent être configurés à partir de Outils ­> Gestion des données de référence > Changement.

Gestion des catégories

Ajout d'une catégorie

  1. Aller dans Outils > Gestion des données de référence > Changement > Catégories
  2. Clic droit de la souris et sélectionner Ajouter
  3. Entrer le nom de la catégorie en français
  4. Entrer le nom de la catégorie en anglais
  5. Entrer sa position d'affichage dans la liste déroulante de la catégorie
  6. Sauvegarder
Voir en image

Suppression d'une catégorie

Cliquer le bouton droit de la souris sur la catégorie et sélectionner Supprimer.

Ce qu'il faut savoir : 

Il est impossible de supprimer une catégorie qui a déjà été utilisée dans un changement. Un choix s'offre alors : Fusionner la catégorie avec une autre.

Pour en savoir davantage sur les catégories

La catégorisation des changements permet de les classifier afin d'appliquer un niveau de gestion adéquat basé sur l'envergure d'un changement. Nous nous sommes rattachés au cadre de référence ITIL pour identifier les différentes catégories de changement. Pour comprendre la structure de catégorisation, voici une illustration :

  • Standard : le changement standard est un changement préautorisé, relativement commun, exécuté selon une procédure préétablie (« workflow ») et dont le risque est contrôlé. On prendra soin de créer des modèles de changements standards prédéfinis à l'avance, et tout autre changement n'en faisant pas partie sera considéré comme un changement mineur.
  • Mineur : le changement mineur est un changement normal dont l'impact est bas et qui comporte peu de risques. Il doit être approuvé localement (par le gestionnaire des changements, par exemple) et n'a pas de procédures préétablies. Ce sont les "petits" changements, qui ne passeront pas au CAB.
  • Significatif / Majeur : le changement significatif ou majeur est un changement normal de plus grande envergure, qui exige une plus grande attention. On considère son coût plus important, son niveau d'impact et de risques plus élevé, un besoin d'approbation formelle d'une ou plusieurs instances, selon le cas (CAB, haute direction). On devra prévoir une procédure de retour arrière en cas de problèmes, l'élaboration de tests, etc.
  • Proposition : la proposition de changement est souvent associée a un changement majeur. Utilisée à très haut niveau, elle sert à présenter une description du futur changement; elle inclut un document d'analyse d'affaires qui évalue les risques, les problèmes et alternatives, les évaluations budgétaires et financières, ainsi qu'un aperçu de la construction et de l'implantation du changement. Une fois approuvée par la gestion des changements, on modifie la catégorie de la requête, et le cycle réel du changement débute.
  • Projet : la catégorie projet a été ajoutée pour distinguer les changements des projets.
Ce qu'il faut savoir :

On cochera la case Urgent dans un changement normal (catégorie mineur, significatif ou majeur) s'il doit être implanté rapidement (pour résoudre un incident urgent, par exemple)

Gestion des états

Ajout d'un état

  1. Aller dans Outils > Gestion des données de référence > Changement > États
  2. Clic droit de la souris et sélectionner Ajouter
  3. Entrer le nom de l'état en français 
  4. Entrer le nom de l'état en anglais
  5. Entrer sa position d'affichage dans la liste déroulante de l'état
  6. Sauvegarder l'état
Voir en image

Suppression d'un état

Faites un clic droit sur l'état et sélectionner Supprimer.

Ce qu'il faut savoir :
  • Il est impossible de supprimer un état qui a déjà été utilisé dans un changement. Un choix s'offre alors : Fusionner l'état avec un autre
  • Limitez au minimum le nombre d'états, juste assez pour bien gérer les différents cycles des changements. Vous pouvez exploiter les tâches; par exemple, ajouter une tâche de revue post-implantation aux gabarits de changement qui le requièrent au lieu de créer un état Changement en revue. Cela facilitera la compréhension et l'application des états par les intervenants
  • Le changement de catégorie d'un changement existant, l'état sera remis réinitialisé à Nouveau. 

 

Description des états

La plupart des états présentés ici proviennent de la littérature ITIL et les descriptions sont à titre indicatif seulement et ne représentent pas la réalité de toutes les organisations informatiques.

  • Nouveau : état du changement à la création
  • En analyse : selon l'information fournie pour le changement, on prend connaissance des risques, des bénéfices pour les affaires, des coûts, des impacts et on valide s'il est dans la bonne catégorie, le niveau d'approbation à appliquer, qui devrait être inclus dans le CAB s'il y a lieu, les tâches nécessaires, etc. S'il manque des informations ou des documents, on retourne auprès de l'initiateur du changement
  • En construction : une fois le changement validé, le responsable du changement peut commencer les travaux qui vont mener au déploiement du changement. Selon l'envergure, il verra à établir une procédure de retour arrière et à documenter les tests afin que le CAB soit en mesure d'évaluer si le changement peut passer en production
  • En approbation : c'est la période où le CAB évalue le changement afin d'approuver ou de refuser le déploiement en production. Dans tel cas, il sera reconduit à une date ultérieure
  • En déploiement : déploiement du changement en environnement de production. Le déploiement peut se faire en plusieurs phases; ce sont les tâches de déploiement qui contrôleront cet aspect
  • Implanté : le changement a été implanté en environnement de production. On surveille pendant quelque temps que le changement implanté n'est pas la cause de nouveaux incidents, dans tel cas, on devra décider si on crée un nouveau changement
  • Fermé : le changement a été implanté avec succès. On pourrait utiliser un type d'activité qui précise le résultat du changement : succès, succès partiel, retour arrière appliqué, ou autre. Ceci contribue à identifier les éléments à améliorer dans l'application du processus de gestion des changements et à augmenter le taux de succès 
  • Refusé : état appliqué lorsque l'approbation d'un changement est refusée 
  • Annulé : état appliqué si un changement a été créé par erreur

 

Transition des états

La transition des états est un mécanisme que nous avons intégré afin de contrôler le cycle d'un changement, de sa création jusqu'à sa fermeture. Dans Octopus, cette transition est basée sur la catégorie de changement. Par exemple, un changement standard est par définition préautorisé avec des étapes définies à l'avance; il n'aura pas besoin de passer par les états "En approbation" et "En analyse" pour être exécuté. En revanche, un changement majeur possède un cycle d'exécution beaucoup plus complexe; parce qu'il représente des risques et des impacts accrus, il doit passer par un cycle plus contrôlé.

 

Afin d'appliquer une transition contrôlée des états dans Octopus, il s'agit d'importer les transitions possibles avec le programme DataImporter pour chaque catégorie de changement. C'est à vous de décider ce que vous permettez ou non comme transitions, selon le niveau de contrôle que vous désirez imposer dans le cycle du changement. Dans l'exemple ci-dessous, nous avons représenté les transitions d'un changement de catégorie standard et significatif, et nous avons laissé la possibilité à un intervenant de revenir à l'état précédent afin que ce ne soit pas trop rigide. 

Ce qu'il faut savoir :
  • Les états ou permissions absents d'Octopus seront ajoutés automatiquement lors de l'importation
  • Vous devez vous assurer d'inclure les permissions aux rôles pour qu'elles soient appliquées
  • À chaque réimportation, le système ne prend en considération que les états/transitions/permissions importés à partir du dernier fichier d'importation
  • Tester les transitions pour chaque catégorie afin de vous assurer du résultat 

Nous vous proposons un modèle de transition par défaut pour les catégories standard, mineur, significatif et majeur, à partir duquel vous pourrez travailler. Ce modèle est disponible sur l'article DataImporter- Importation des Transitions d'états des Changements.

Gestion des gabarits de changement

Les gabarits de changement permettent de créer des modèles réutilisables pour des catégories de changement. Ils sont largement utilisés pour définir les changements standards. Ils permettent de prédéfinir quelques champs par défaut ainsi qu'un workflow de base, qui pourra par la suite être ajusté selon les besoins du changement. De plus, ils rendent la création d'un changement plus facile et uniforme pour les intervenants.

Les gabarits de changements définis dans les données de référence sont accessibles à partir de la fenêtre de création d'un changement : 

Création d'un gabarit de changement

On peut créer un gabarit de changement ou une catégorie (dossier). La catégorie permet d'établir une structure qui regroupe logiquement des gabarits de changement, ce qui rend la sélection des gabarits plus intuitive lors de la création d'un changement.

  1. Accéder aux gabarits de changement via Outils > Gestion des données de référence > Changement > Gabarits
  2. Clic droit de la souris et sélectionner Ajouter. Le système vous demandera s'il s'agit d'un gabarit ou d'une catégorie (dossier)

  3. Catégorie ou gabarit

Créer une catégorie

  • Inscrire une description en français et en anglais et sauvegarder​

Créer un gabarit

Pour créer un gabarit, vous pouvez vous positionner sur Gabarits ou sur une catégorie (dossier); faites un clic droit, Ajouter, et sélectionner Gabarit de changement.

  • Section Identification : 
    • Inscrire un sujet (français/anglais) 
  • Onglet Général :
    • Sélectionner la personne qui gère le changement
    • Identifier la Catégorie* du changement
    • Indiquer si ce gabarit sera utilisé pour les changements Urgents
    • Sélectionner la Priorité, le Service, l'Impact sur l'infrastructure et l'Impact sur les ressources

​* Le champ Catégorie est obligatoire.

  • Onglet Tâches : 
    • On peut définir les étapes d'exécution d'un changement en configurant à l'avance une ou plusieurs tâches. Elles peuvent être exécutées séquentiellement ou en parallèle, selon le processus d'exécution du gabarit. Il est possible de configurer des tâches Standard, d'Approbation ou de Notification

      Pour plus d'information sur la configuration des tâches, veuillez consulter l'article wiki sur la Gestion des tâches​.

  • ​Onglet Fichiers joints :

    • Ajouter des fichiers joints, si requis

Voir en image

Suppression d'un gabarit de changement

Faites un clic droit sur le gabarit et sélectionner Supprimer.

Ce qu'il faut savoir : 
  • Il est impossible de supprimer un gabarit de changement qui a déjà été utilisé dans la création d'un changement. Deux choix s'offrent alors : décocher la case Actif pour désactiver le gabarit, ou Fusionner le gabarit avec un autre.
  • La fusion enlève le lien entre les changements créés du type source et crée un nouveau lien au type de destination. Par la suite, le type source est automatiquement supprimé.
  • Vous devez supprimer ou déplacer le(s) gabarit(s) de changement avant de pouvoir supprimer une catégorie.

Les tâches dans les gabarits de changements

Tous comme avec les types de SR, on peut ajouter des tâches à des gabarits de changement. Même des tâches de déploiement. Pour savoir comment, voir l'article sur le Calendrierde déploiements.

Modèles proposés pour la gestion des changements

Voici les modèles proposés pour la gestion du changement dans Octopus.

Il existe 3 types de changements - Standard, Normal, qui comprennent les changements mineurs, significatifs et majeurs, et Urgent. Chaque type contiendrait des modèles conçus pour gérer le flow du processus. Un flow de travail plus complet pourrait être créé pour les changements qui ont plus d'impact ou de risques.

  • Changement Standard : Comme ils sont préapprouvés, aucune tâche d’approbation n’est requise
  • Changement Normal : Selon qu’ils soient mineurs, significatifs ou majeurs, une ou plusieurs approbations peuvent être requises.
  • Changement Urgent : Le ECAB est impliqué et le flow de travail peut être différent afin de prendre en compte la situation urgente.

Permissions

Par défaut, il existe quatre (4) permissions associées au module Changements :

  • Accéder au module de gestion des changements
  • Créer un changement
  • Modifier un changement
  • Supprimer une tâche de changement

D'autres permissions peuvent être ajoutées et appliquées aux rôles. Pour plus d'information à ce sujet, nous vous invitons à lire l'article Gestiondes rôles.

Métriques

Changements par mois

Dans le module Statistiques, il existe un rapport intitulé Changements par mois; on obtient des résultats variables selon les paramètres ou les filtres suivants :

  • Changements par mois : Nouveaux et/ou Fermés et/ou Ouverts
  • Efforts par mois
  • On peut désigner une période
  • On peut désigner une priorité
  • Faites un clic droit sur le graphique pour afficher les valeurs ou les lignes horizontales
  • Faites un clic droit sur une barre pour afficher :
    • ​les détails de cette barre sur un autre graphique ou
    •  pour afficher les données sous forme de liste
  • Le rapport peut être imprimé ou sauvegardé comme fichier .pdf
Voir en images

Listes de suivi

Les listes de suivi permettent d'obtenir d'autres métriques extrêmement utiles dans le suivi des changements. On peut penser à des listes du genre :

  • Changements par état
  • Changements fermés
  • Changements par catégorie
  • Changements par CI impacté
  • Changements approuvés
  • Changements implantés (pour une période x)
  • Tâches de changement par groupe
  • Changements fermés avec revue post-implantation
  • Propositions de changement
  • Arrêts de service projetés (PSO - "Projected Service Outages")
  • Autres

Menu des Actions

Créer un incident / SR à partir de ce changement

Dans le contexte d'un changement ou d'un projet, il arrive souvent qu'on ait des requêtes internes à créer. Pour faciliter l'ouverture de telles requêtes, utiliser l'action Créer un incident / SR à partir de ce changement. Au moment de la création de la requête, le nom de la personne qui gère le changement sera mis comme Demandeur et Utilisateur de la requête et un lien sera fait entre le changement et la nouvelle requête.

Voir en image

Calendrier de déploiements

Le calendrier de déploiements, que l'on peut afficher en cliquant sur l'action Calendrier de déploiements, affiche les tâches de déploiements configurés dans l'onglet Tâches des changements. Voir l'article Calendrierde déploiements pour plus d'information.

 

X
Aidez-nous à améliorer l’article