English

Gestion des changements dans Octopus

Modifié: 2011/12/07 10:12 par cdutremble - Catégorisé en: Configurations, En révision, Implantation

Modifier

Articles reliés



Modifier

Introduction

Il est possible d'intégrer et suivre tous vos changements informatiques d'une façon efficace et centralisée avec le module "Changements" d'Octopus. Le présent article décrit l'utilisation fonctionnelle du module "Changements" d'Octopus.

Selon ITIL (n'hésitez pas à consulter l'article Gestion des changements selon ITIL pour plus d'information), tous les changements sans exception devraient être enregistrés, évalulé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 met à risque la stabilité et la fiabilité de l'infrastructure, et par conséquent, la disponibilité des services informatiques. Selon le contexte de l'organisation, le périmètre donné à la gestion des changements à implanter peut différer, mais certaines activités ne doivent pas être négligés.

Le module "Changements" vous fournit une structure qui permet la documentation et le suivi de vos changements; cependant, comme pour tous les autres modules d'Octopus, une compréhension et une utilisation correcte et harmonisée du module par les intervenants impliqués assureront une qualité d'information qui servira les objectifs de gestion des changements visés par l'organisation informatique. Prenez un peu de temps pour définir la façon dont vous voulez gérer vos changements et comment l'outil doit être utilisé à cette fin. Prévoyez une formation des intervenants et un suivi des enregistrements (contrôle de qualité), surtout au début, pour adresser les écarts d'utilisation et apporter les correctifs nécessaires.

Il ne sert à rien de viser la perfection; aussi surprenant que cela puisse être, il n'est pas rare que dans certaines organisations, les changements soient gérés exclusivement dans des chiffriers Excel - sans compter ceux qui sont implantés à toute heure du jour, sans autorisation, sans analyse d'impact, sans solution de retour arrière, sans être documentés nulle part. Pour ces organisations, l'enregistrement de tous les changements dans un outil de gestion constitue parfois une transition majeure.

Prendre note que le module Changements sera révisé dans son ensemble en 2012 afin de mieux le définir par rapport aux concepts ITIL et d'améliorer son utilisation dans un contexte opérationnel. Nous vous invitons à nous faire part de vos suggestions dans "Vos idées pour améliorer Octopus", accessible dans le menu 'Outils'.

Modifier

La Gestion de projets dans le module "Changements"

Plusieurs de nos clients profitent du module "Changements" pour gérer les projets informatiques; en effet, comme les intervenants impliqués dans les projets sont souvent les mêmes qu'aux opérations, il est avantageux de centraliser une gestion de projets simple dans Octopus. Nous vous recommandons d'utiliser une catégorie "Projet" afin de séparer les changements des projets; cette catégorie doit être ajoutée par nous, n'hésitez pas à nous contacter pour en faire la demande.

Vous référer à l'article Gestion de projets dans Octopus pour de plus amples informations à ce sujet. Modifier

Module "Changements"

Dans sa forme actuelle, le module Changements ne peut être configuré à travers les 'Options' ou les 'Données de référence' d'Octopus, sauf pour certaines listes qui font aussi partie des autres modules.

(rappelez-vous que les gabarits de changement dans les 'Données de référence' ne servent qu'aux tâches planifiées d'Octopus).

Les listes configurables sont Site et Financement; le champ 'Soumis par:' est alimenté par la liste des utilisateurs et le champ 'Géré par:' l'est par la liste des intervenants.

Certaines fonctionnalités du module "Changements" sont exploitées de la même manière que pour les demandes de service (SR) dans le module "Incidents/SR"; en effet, on peut y ajouter:

  • des tâches;
  • des activités;
  • y relier un ou plusieurs CI;
  • insérer des fichiers joints (ces derniers pourraient être des livrables requis dans le cas d'un changement de plus grande envergure, des résultats de tests, une procédure spécifique, des statuts de projets, etc.).

L'illustration ci-dessous vous présente le formulaire de création d'un changement, ainsi qu'une brève description/explication pour chaque champ.


Image

Modifier

1. Champ "État"

Voici une illustration des différents états qui surviennent sur un changement à partir de son enregistrement jusqu'à ce qu'il soit complété. Nous avons appliqué une corresondance entre ces états et les activités du processus tel que défini dans l'article La Gestion des changements selon ITIL :

Image

Les différents états d'un changement dans Octopus peuvent être mis en pratique de la façon suivante (ou selon vos propres critères, pourvu qu'ils soient clairement définis) :

  • Nouveau
État du changement à la création.

Image
Les changements à l'infrastructure peuvent être enregistrés directement par un intervenant TI dans Octopus.

Les demandes de changement applicatif étant généralement initiées par un utilisateur (ou plusieurs) ne faisant pas partie de l'organisation informatique, il est avantageux, dans un premier temps, de les gérer en tant que demande de service dans le module "Incidents/SR". Elles peuvent être soumises directement par l'utilisateur (idéalement via un formulaire sur le portail Web libre-service recueillant les détails nécessaires à leur évaluation) et assignées directement à un groupe d'évaluation qui constituera le contenu des changements applicatifs. Lorsque l'évaluation est complétée, les demandes de service sont fermées, les demandeurs informés, et un changement est créé dans le module "Changements" et documenter le(s) numéro(s) de SR qui y font référence (éventuellement, dans une version ultérieure, une SR pourra être reliée à un changement).

  • En cours d'autorisation par le superviseur
État du changement lorsque le gestionnaire des changements passe en revue les nouveaux enregistrements. Il vérifie s'ils sont logiques, applicables, complets (au niveau de la documentation fournie), ou s'ils ont déjà été soumis; selon le cas, il pourrait 1) communiquer avec l'utilisateur si le changement est incomplet et remettre l'état à "Nouveau" ou 2) rejeter les requêtes qui ne seront pas considérées et mettre l'état à "Rejeté" (avec une explication au demandeur sur la raison du rejet, bien sûr).

  • En analyse
Basé sur la documentation fournie, le gestionnaire des changements valide le type de changement (mineur, significatif, majeur, selon des critères définis par l'organisation TI); il désigne /confirme l'intervenant qui s'occupera du changement ("géré par:"); en consultant les ressources spécialisées impliquées, il analyse les informations fournies pour comprendre le changement, son impact, ses risques, et ses coûts.

  • En cours d'autorisation par le CAB
État du changement lorsque l'analyse est complétée et qu'il est planifié à la prochaine réunion du CAB. Tous les types de changement ne passent pas obligatoirement par le CAB; voir l'article Gestion des changements selon ITIL, section 5 d) pour plus d'informations sur le CAB).

  • Rejeté
État utilisé si un changement est rejeté par le gestionnaire de changements ou par le CAB.

  • Approuvé
Cet état indique que le changement est approuvé par le gestionnaire des changements (après l'analyse) ou le CAB (après la réunion du CAB).

  • En cours d'implémentation
État du changement pendant l'exécution des tâches assignées aux ressources par le gestionnaire du changement pour la mise en oeuvre. Cet état inclut aussi le transfert en environnement production.

Image
Les tâches associées au changement ne sont pas nécessairement reliées à son implémentation; par exemple, des tâches telles que "Analyse", "Approbation", "Acquisition", "Installation / Configuration", "Test", "Documentation", "Revue post-implantation", etc. peuvent être créées afin de suivre non seulement des tâches technologiques, mais aussi des tâches de gestion et d'administration du changement, assurant ainsi un standard d'exécution plus complet. Les intervenants assignés utiliseront les activités pour confirmer les actions de leur tâche, pour communiquer à l'interne ou à l'externe (par exemple avec un fournisseur). Le tout sera consigné dans le journal des activités.

Les tâches de suivi sont des tâches plus administratives, qui n'ont pas d'incidence dans le déroulement du changement mais qui contribue à sa gestion (par exemple, une revue post-implantation).

Voir l'article Création de tâches pour plus d'informations.

  • Complété
État du changement après son implantation dans l'environnement production.

  • Annulé
Utilisé pour toute requête de changement qui doit être interrompue en cours de route (parce qu'elle a été créée en double, pour des raisons de coupure de budget, etc.). Les tâches associées seront aussi annulées.

Modifier

2. Champ "Priorité"

La priorité d'un changement n'est pas basée sur les mêmes critères que la priorité d'un incident. Elle désigne l'ordre dans lequel les changements doivent être mis en oeuvre. L'impact et l'urgence servent de base.

L'impact repose sur les bénéfices liés au changement sur l'activité ou sur l'étendue des dommages si le changement tourne mal. L'urgence indique le temps de mise en oeuvre.

Il n'y a pas de dérivation de priorité automatisée comme c'est le cas dans le module "Incidents". On pourrait interpréter les priorités d'un changement de la façon suivante:

  • Basse
le changement est souhaité mais peut attendre qu'une occasion se présente

  • Moyenne
il n'y a pas d'urgence ou d'impact élevé, mais le changement ne doit pas être reporté à plus tard.

  • Urgente
le changement présente un risque sérieux ou gênant pour un certain nombre d'utilisateurs, ou il est lié à d'autres problèmes urgents.

Modifier

3. Champ "Début" et "Échéance"

La date "Début" est utilisée davantage lorsque le module "Changements" est utilisé dans le cadre de la Gestion de projets. Il représente la date de début de projet.

La date "Échance" correspond à la date ciblée d'implantation du Changement.

Modifier

4. Champ "Catégorie"

Quatre (4) catégories sont accessibles:

  • Changement standard
Un changement standard, dans le module "Changements" est considéré comme un changement pré autorisé, avec un faible risque sur l'infrastructure et des étapes connues, et qui ne représente pas une demande de service.

Les trois(3) autres catégories réfèrent à un changement "normal", qui doit suivre le processus de Gestion des changements défini dans l'organisation informatique.
  • Impact mineur
  • Impact significatif
  • Impact majeur

Vous devrez définir ce qui constitue un changement standard, un changement mineur, significatif ou majeur pour votre organisation, ainsi que le niveau d'autorisation requis.

Vous trouverez des explications complémentaires et des exemples dans l'article Gestion des changements selon ITIL section 5 c).

Modifier

5. Champs "Impact sur l'infrastructure" et "Impact sur les ressources"

Ces champs vous servirons à identifier séparément l'impact sur l'infrastructure et l'impact sur les ressources. Les choix sont 'Majeur', 'Significatif' et 'Mineur'.

L'impact sur l'infrastructure indique l'étendue du risque, à savoir si des CI en relation avec le CI affecté par le changement peuvent être affectés aussi par le changement. Par exemple, un changement sur un routeur peut affecter plusieurs sites qui dépendent de ce routeur.

L'impact sur les ressources indique ce que le changement exige en termes d'implication des intervenants dans le changement.

Modifier

6. Champ "Site"

Indique le site affecté par le changement (restreint à un site).

Modifier

7. Champ "Financement"

Le champ "Financement" permet de désigner si le budget du changement provient de l'informatique, du client, ou de toute autre source. La liste est personnalisable dans Outils \ Gestion des données de référence... \ Général \ Sources de financement.

Modifier

8. Champ "Coût"

Champ de type texte comme indicatif du coût estimé du changement. Ce champ n'a aucune interaction avec l'onglet "Coûts additionnels" de la partie inférieure du changement.

Modifier

9. Champ "Amortissement"

Dans certains cas, permet d'indiquer un amortissement sur le changement, par exemple, une application qui aurait une valeur aux livres et qu'on voudrait amortir sur une période de "x" mois.

Modifier

10. Champ "Soumis par :" et "Géré par :

Le champ "Soumis par :" identifie l'utilisateur 1) qui crée le changement (dans le cas d'un intervenant TI ou 2) de qui le changement origine (si l'utilisateur n'est pas un intervenant TI). Il est un champ requis lors de la création du changement.

Le champ "Géré par :" identifie l'intervenant responsable de l'exécution du changement (qui n'est pas nécessairement le Gestionnaire des changements dans le sens ITIL du terme).

Modifier

11. Champ "Sujet"

Le champ "Sujet" est un champ de type texte qui est un champ requis lors de la création du changement.

Modifier

12. Onglet "Documentation"

Cet onglet 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

Image

Certains de nos clients ayant une gestion des changements plus mature aiment utiliser l'onglet "Documentation" pour documenter les changements plus modestes (standards ou mineurs) et utiliser un document formel plus complet pour documenter les changements plus complexes. Ils l'ajoutent alors comme fichier joint à la requête.

Modifier

13. Onglet "Tâches"

Toutes les tâches d'exécution relatives aux changements peuvent être créées. Ces tâches peuvent être assignées à un groupe / intervenant pour assurer l'exécution. Chaque intervenant peut alors documenter ses actions en ajoutant une activité à la tâche (cette fonctionnalité est disponible seulement à partir de la version Été 2011).

Voir l'article Création de tâches pour plus de détails au sujet de l'exploitation des tâches dans Octopus.

Modifier

14. Onglet "Activités"

Nous retrouvons ici 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 retrouveront journalisées ici.

Modifier

15. Onglet "CI"

Il est possible d'ajouter un ou plusieurs CI à un changement.

Modifier

16. Onglet "Coûts additionnels"

Il y a plusieurs façon d'utiliser l'onglet "Coûts additionnels":

  • Le gestionnaire du changement pourrait vouloir faire un certain suivi de coûts à mesure que se déroule le changement.
  • Le gestionnaire du changement pourrait vouloir noter que les coûts imprévus au changement, ceux qui ne font pas partie du budget.

Noter que les coûts additionnels ne sont pas automatiquement reportés au champ "Coût" désigné dans la section 8.

Modifier

17. Onglet "Fichiers joints"

Il est possible d'ajouter un ou plusieurs fichiers à la requête, une requête de changement, une autorisation par courriel, des résultats de tests, des compte-rendus de réunion, les revues post-implantations, bref tout livrable obligatoire ou non qui nécessite d'être enregistré avec la requête.

Modifier

18. EXEMPLE CONCRET

À venir.

Administration | Ce wiki est conçu avec ScrewTurn.