Articles reliés

• Gestiondes problèmes - Processus ITIL®
• Gestiondes incidents - Processus ITIL®
• Lesrelations interrequêtes

​ Voir le webinaire sur la Gestion des problèmes du 8 Mars 2017

Introduction

Normalement, après avoir mis en place le module Incidents/SR, un des prochains modules à implanter est la gestion des Problèmes. Le présent article traite de l'application du processus de gestion des problèmes dans Octopus. Pour en apprendre davantage sur les concepts ITIL® de base de ce processus, consulter l'article Gestiondes problèmes - Processus ITIL®.

Concepts généraux

Il existe une distinction fondamentale entre un incident et un problème. Très simplement, l'incident est une situation non planifiée et il doit être résolu le plus rapidement possible, car il impacte directement la capacité de travailler des utilisateurs. Le problème, quant à lui, présente une vue différente d'un incident par la compréhension de sa cause fondamentale, qui pourrait être aussi la cause d'autres incidents. Pendant que les intervenants affectés à la gestion des incidents s'occupent de résoudre les incidents, ceux affectés à la gestion des problèmes cherchent avant tout des façons de prévenir l'occurrence des incidents ou d'en réduire les impacts afin que les utilisateurs soient affectés le moins possible par des interruptions. Pour vous aider à mettre ces concepts en contexte, nous allons nous servir d'un scénario.

« Depuis quelque temps, quelques agents du Centre de services rapportent un nombre plus élevé d'appels pour des postes de travail qui ne répondent plus (gelés). Une cliente en particulier mentionne qu'elle n'avait pas ce problème dans le passé, mais que depuis quelque temps, la situation se répète régulièrement. Les employés du Centre de services font les validations d'usage pour ce genre d'incident et pour l'instant, un redémarrage du poste rétablit la situation. On procède ainsi pour les utilisateurs qui rapportent ce même symptôme. À chaque fois, un incident est créé et résolu par le redémarrage du poste. »

On comprend le bénéfice qu'apporterait une réduction ou une élimination de ces incidents qui se répètent continuellement, autant pour le groupe TI que pour les utilisateurs qui subissent ces interruptions.

Voici trois règles importantes :

• On ne garde pas ouvert un incident « résolu » pour ne pas l'oublier (dans le but d'analyser la situation plus tard), on procède quand même à sa résolution. Cependant, c'est alors qu'on crée une requête de type problème et qu'on relie tous les incidents qui s'y rapportent.
• On ne ferme pas un incident, sans le résoudre, parce qu'un problème existe à ce sujet. L'incident doit quand même être résolu. S'il n'y a pas de solution disponible, l'incident doit être escaladé à un groupe spécialisé ou un niveau plus élevé, on peut parfois faire appel à un fournisseur de service si l'expertise n'est pas disponible à l'interne. Mais on continue de rechercher une manière d'éliminer l'incident, même si elle est temporaire. C'est pour cette raison que le Centre de services continuera de créer et de résoudre les incidents qui surviennent, et ce, aussi longtemps qu'une solution permanente ne sera pas déployée (habituellement par la mise en place d'un changement).
• Lorsqu'un changement est requis pour résoudre un incident, la création d'un problème n'est pas systématique. Si l'analyse de l'incident a été suffisante pour trouver la cause de la situation et sa solution, on peut appliquer un changement directement... Ne vous encombrez pas d'un problème qui n'aurait pas de valeur ajoutée. Une relation entre l'incident et le changement expliquera la situation.

Quoiqu'il est plus courant qu'un problème soit créé après l'occurrence de plusieurs incidents de même nature, ITIL® mentionne qu'un seul incident est suffisant pour justifier la création d'un problème, dans la mesure où l'on suspecte l'existence d'une cause sous-jacente. Les critères d'observation pour identifier un problème potentiel sont multiples et pourraient être : symptômes identiques, récurrence dans une période de la journée (de la semaine, du mois), nouveaux incidents suite à un changement ou à un déploiement, etc. Voici une illustration qui montre les interrelations qui existent entre incident, problème et changement.

Création d'un problème dans Octopus

Créer un problème manuellement

1. À partir du module Problèmes, cliquer sur l'action Créer un problème
2. Documenter le problème en saisissant l'information pertinente, identifier le CI et relier les incidents pertinents. Noter que les champs Groupe et Sujet sont obligatoires à la création
3. Enregistrer le problème en cliquant OK. Un numéro de référence unique est automatiquement attribué par le système

Description des champs

Créer un problème à partir d'un incident

1. Ouvrir le formulaire d'incident à partir duquel un problème doit être créé
2. Choisir l'action Créer un problème à partir de cet incident - la catégorie, l'assignation, le sujet, la description et le CI en cause sont automatiquement reportés dans le problème
3. Compléter le formulaire de création de problème selon les informations connues, relier d'autres incidents le cas échéant
4. Enregistrer le problème en cliquant OK
5. L'incident de départ se relie automatiquement au problème en utilisant la relation À pour occurence

 

Créer un problème à partir d'un problème

L'action Créer un problème à partir de... dans le module Problèmes fait partie d'un module d'extension (plug-in:
ESI.Octopus.PlugIns.PinkCertification) qui peut être ajouté à votre base de données. Pour l'obtenir, vous n'avez qu'à en faire la demande au Centrede services Octopus.

En cliquant sur l'action, le système ouvre un formulaire de création d'un problème et transfère les informations suivantes :

• Impact, urgence, priorité
• Catégorie / sous-catégorie
• Assignation
• Sujet
• Contenu du champ Description de l'onglet Documentation

Vous pouvez créer un nouveau problème à partir d'un problème existant, mais vous pourriez aussi créer des modèles de problèmes en inscrivant Modèle dans le sujet. En excluant ces modèles de vos listes de problèmes courants, vous pourriez créer une nouvelle liste répertoriant les modèles de problèmes. Ces modèles pourraient représenter, par exemple :

• Problème majeur - priorité élevée, assignation au groupe d'administrateurs de système, procédure dans la description
• Problème réseau - assignation au groupe d'administrateurs réseau, procédure dans la description
• Autre

Créer un changement à partir d'un problème

L'action Créer un changement à partir d'un problème dans le module Problèmes fait partie d'un module d'extension (plug-in) qui peut être ajouté à votre base de données. Pour l'obtenir, vous n'avez qu'à en faire la demande au Centrede services Octopus.

En cliquant sur l'action, le système ouvre un formulaire de création d'un changement et une fois que le changement est enregistré, le problème duquel il est issu est automatiquement relié au changement dans l'onglet Requêtes.

Résoudre les occurrences reliées

L'action Résoudre les occurrences reliées permet de résoudre ou fermer les incidents reliés à un problème qui utilisent la relation À pour occurrence. 

Lorsque l'action est sélectionnée, une fenêtre apparaît à l'écran pour permettre l'ajout de l'activité de résolution/fermeture.

L'activité de résolution/fermeture va s'ajouter à chacune des requêtes liées.

Dans le cas où une solution de contournement est documentée dans le problème, le message Cette occurrence a été résolue par la solution de contournement du problème #xxx est affichée dans l'activité de résolution /fermeture. 

Ce qu'il faut savoir :
Un message d'erreur apparaît lorsqu'il n'est pas possible de résoudre/fermer l'incident lié.

Contribution de la gestion des incidents

Les intervenants impliqués dans la gestion des incidents peuvent apporter une contribution sous plusieurs formes à la gestion des problèmes. La première et la plus importante est sans contredit la rigueur dans la gestion de chaque incident, ceci incluant :

• Une documentation juste, claire et suffisante du sujet, de la description, des vérifications effectuées, des actions posées et de la résolution appliquée, et ce, pour chaque incident
• La confirmation du CI en cause et de la catégorisation au moment de la résolution
• L'utilisation, lorsqu'approprié, de la case Problème potentiel pour un incident pouvant représenter un problème potentiel

Incident marqué comme Problème potentiel

Dans Octopus, n'importe quel intervenant peut signaler un incident comme étant un problème potentiel en cochant la case Problème potentiel et en justifiant la raison de cette action. Il n'existe pas de permission Octopus à ce propos, alors il est recommandé d'établir la procédure d'utilisation de cette case pour assurer l'efficacité de l'analyse des incidents par un intervenant. Il convient bien sûr de bien documenter dans les activités les symptômes constatés, les étapes de dépannage effectuées et les escalades fonctionnelles aux autres niveaux, le cas échéant. Si une solution fait temporairement disparaître les symptômes, on la consigne dans l'activité de résolution de l'incident. Si d'autres incidents de même nature ont été enregistrés, ils pourront être reliés au problème. Toutes ces actions et documentations fournissent des éléments d'analyse et des pistes importantes pour identifier la cause fondamentale et éventuellement les actions à prendre pour résoudre le problème.

Pour signaler un problème potentiel à partir d'un incident :

1. Cocher la case Problème potentiel située en dessous du journal d'activités
2. Ajouter une note pour justifier la raison
3. Voir à relier tout autre incident de même nature, le cas échéant

Notez que cette action ne crée pas de requête de type Problème, elle ne fait qu'identifier le ou les incidents pouvant potentiellement représenter un Problème.

Le champ Problème potentiel est masqué lorsqu'un Incident est :

• Marqué comme non significatif à la GDP et
• Si une requête de type Problème a été reliée à cet Incident avec le type Est une occurrence de.

Contribution de la gestion des problèmes

La documentation du champ Solution de contournement d'un problème fournit à la gestion des incidents une liste de solutions temporaires potentielles pour résoudre des incidents. À partir du module Incidents/SR, l'action Rechercher une solution affiche une liste de problèmes pour lesquels une solution de contournement est documentée. En cliquant l'action, le système cherche une correspondance avec le CI, le manufacturier et le modèle, et/ou la catégorisation et affiche une liste de solutions potentielles.

Comme nous l'avons mentionné ci-haut, vous devez décider quels problèmes valent la peine d'être travaillés et résolus. Si on doit intervenir sur un CI pour résoudre un problème, la bonne pratique est de passer par un changement. Par conséquent, un problème bien documenté au niveau de l'impact, de l'urgence, des incidents ou événements reliés, des CI reliés, des efforts et des coûts contribuera à l'évaluation et la mise en place du changement.

Analyse des données

Il existe des techniques d'analyse de problèmes qui aident les équipes à identifier la cause fondamentale d'un incident et à évaluer les différentes options dans l'approche à prendre pour en réduire l'impact ou les résoudre. Nous vous invitons à consulter l'activité Investigation & Diagnostic décrite dans l'article Gestiondes problèmes - Processus ITIL® qui fournit une liste et une courte description de ces techniques.

Du côté Octopus, les intervenants travaillant en gestion des problèmes s'alimenteront en grande partie des données saisies dans Octopus pour observer ce qui se passe en production, identifier les tendances et créer les problèmes appropriés. Il existe plusieurs sources d'analyse dans Octopus, dont :

• Les incidents marqués comme Problème potentiel
• Le module Statistiques :
  • Problème > CI les plus problématiques
  • Problème > Modèles de CI les plus problématiques
  • Problème > Types de CI les plus problématiques
• Le nombre d'événements (alertes) ayant généré des incidents
• Les types d'activité, qui pourraient être configurés pour identifier la cause d'un incident à la résolution
• Les problèmes existants et les incidents reliés
• Etc.

Selon ses observations et constatations, l'intervenant décidera s'il convient de créer un problème réactif. Mais les données d'Octopus ne seront pas sa seule source dans sa décision de créer un problème. Dans le cas où il suspecte un état instable d'un élément de l'infrastructure, si un CI critique n'a pas de redondance, ou encore si lors d'une analyse des événements de type « information » ou « avertissement » il suspecte une tendance qui pourrait être corrigée, il pourra créer un problème « proactif » afin de suivre les CI susceptibles de générer des incidents à court, moyen ou long terme. D'autres exemples pourraient s'appliquer. Voir Gestiondes événements - Module Octopus ou Gestiondes événements - Processus ITIL® pour plus d'information à propos des types d'événements.

Incidents marqués comme non significatif à la GDP

Lors de son analyse, l'intervenant assigné à la gestion des problèmes identifie les incidents qu'il juge non significatifs à la gestion des problèmes afin d'épurer ses recherches futures. 

1. Sélectionner un ou plusieurs incidents existants
2. Cliquer sur l'action Marquer comme non significatif à la GDP
3. Un message informe que ces incidents seront marqués comme non significatifs à la gestion des problèmes et que cette opération est irréversible
4. La case Problème potentiel de l'incident est remplacée par une note indiquant que l'incident a été marqué comme non significatif à la gestion des problèmes

Recherche avancée

En faisant une recherche avancée à partir du module Incidents/SR, on a accès à l'onglet Problème. À partir de là, on peut filtrer les incidents en sélectionnant les options suivantes:

• Incidents non corrélés à un problème: tous les incidents n'ayant pas été reliés à un problème
• Exclure les incidents non significatifs à la gestion des problèmes
• Incidents marqués comme « problème potentiel »

Ainsi, l'intervenant pourra orienter la recherche d'incidents en fonction de ses besoins. Le résultat de la recherche inclura tous les incidents de l'état « nouveau » à « fermé ».

Dans la recherche avancée, il existe une section qui permet d'accéder aux champs de tous les modules - visibles et non visibles - d'Octopus; cette section fournit en plus des critères de recherche plus évolués. C'est par là qu'un intervenant peut extraire les incidents reliés à des problèmes et vice-versa. Pour procéder :

1. Ouvrir la recherche avancée
2. Sélectionner Relation interrequêtes dans la fenêtre des types de résultats à retourner
3. Saisir le champ Type (Requête 1) égal à Incident
4. Saisir le champ Type (Requête 2) égal à Problème

Vous aurez une liste d'incidents en relation avec un problème, liste que vous pouvez sauvegarder.

Permissions

• Accéder au module de gestion des problèmes
• Créer un problème
• Faire la corrélation des incidents et des problèmes
• Modifier l'état d'un problème
• Modifier un problème
• Supprimer une tâche de problème

Pour voir la liste des permissions ainsi qu'une brève description, télécharger le document Référence Permissions Octopus.

Rapports et listes

Dans le module Statistiques, plusieurs rapports relatifs à gestion des problèmes sont disponibles. Certains sont des rapports de gestion, d'autres servent à l'identification des CI, des modèles de CI ou des types de CI ayant été impliqués dans les incidents ou problèmes, ce qui est très utile à la gestion des problèmes.

Les listes de suivi permettent d'extraire d'autres informations utiles à la gestion des problèmes, entre autres :

• Erreurs connues : affiche les problèmes ayant une cause fondamentale et une solution de contournement documentées. Elles contribuent à aider la gestion des incidents à résoudre les incidents plus rapidement en mettant à leur disposition des solutions.
• CI associés aux problèmes : présente une liste de CI ayant été reliés dans les problèmes
• Ouverts : représentent les problèmes actifs; en affichant les colonnes priorité et le nombre d'incidents, elle permet de valider si la priorité doit être modifiée (une augmentation des incidents reliés pourrait le justifier)
• Fermés : représentes les problèmes résolus
• Cause fondamentale à identifier : problème ouvert depuis plus d'un mois pour lequel une cause fondamentale n'est pas documentée; cette liste est un exemple permettant de suivre les problèmes qui n'ont pas été travaillés depuis un certain temps et est basée sur le dépassement d'un seuil

• Catégories incidents fermés : cette liste sert autant à la gestion des incidents qu'à la gestion des problèmes dans l'analyse de la catégorisation appliquée dans les incidents et les problèmes, afin d'ajuster (par la modification ou l'ajout de catégories) la structure de catégorisation. Cette liste peut être exportée en format Excel, comme toutes les listes créées dans Octopus.

Autres applications

Connaissances

Afin de soutenir les équipes qui participent à la gestion des problèmes, il convient de documenter certaines connaissances qui aideront au bon fonctionnement du processus, dont :

• des techniques d'analyse, de diagnostic, d'analyse de cause fondamentale
• des procédures de création / mise à jour de solutions de contournement, de solutions temporaires et de résolution

Ces connaissances peuvent être documentées dans le module Configurations dans un CI de type document. Ainsi, les équipes peuvent s'y référer et même utiliser des documents d'analyse réutilisables dans un problème. Voir l'article Gestiondes procédures qui saura vous guider dans l'établissement de connaissances formalisées pour la gestion des problèmes. 

Développement applicatif

Lorsqu'une organisation fait du développement applicatif à l'interne, il pourrait arriver qu'elle veuille enregistrer une erreur connue (problème avec une cause fondamentale identifiée et une solution de contournement documentée). Si elle se résout lors de la mise en production de l'application, on peut résoudre la requête. Dans le cas contraire, on pourrait transférer l'erreur connue en production, qui servira à la résolution des incidents, en sélectionnant un état de cycle de vie du problème. Afin de bien distinguer les erreurs connues en développement des erreurs connues en production, des listes séparées peuvent être créées pour consultation.

Si vous désirez appliquer ce concept dans votre département de développement, vous devez demander au Centrede services Octopus d'ajouter l'état En développement dans le module Problèmes de votre base de données.

Problème majeur

Dans le contexte d'Octopus, la revue de problème majeur peut être assurée par une tâche standard ajoutée au problème. Elle devrait comprendre :

• ce qui a été bien fait
• ce qui a mal été fait
• ce qui pourrait être mieux fait la prochaine fois
• ce qui pourrait éviter que le problème survienne à nouveau
• quelles leçons on peut en tirer

N'hésitez pas à consulter l'article Gestiondes tâches pour obtenir des détails sur la configuration des tâches dans Octopus.