Table des matières
Articles reliés
- Gestion des problèmes - Processus ITIL®
- Gestion des incidents - Processus ITIL®
- Les relations 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 Gestion des 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
- À partir du module Problèmes, cliquer sur l'action Créer un problème
- 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
- 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
État
Octopus gère les états de problème et les états de cycle de vie de problème. Les états des problèmes sont ouvert et fermé; chacun inclut un ensemble d'états de cycle de vie de problème :
- Ouvert : inclut les états de Nouveau à Changement en cours de réalisation
- Fermé : inclut les états Fermé et Inactif.
Ces états de problème sont accessibles du module Mon espace, par une recherche avancée sur le champ état. Par exemple, en sélectionnant Problème comme type de requête et l'état Ouvert, vous pourriez obtenir une liste telle que :
Les états de cycle de vie de problème sont spécifiques au problème, durant son cycle de vie. Alors il faut s'assurer que la recherche avancée est effectuée au bon endroit :
Voir ci-dessous une description des états de cycle de vie de problème.
| État | Définition |
|
1. Nouveau (à valider) |
Lors de la détection et de l'enregistrement. C'est la phase de collecte d'information initiale. |
| 2. Planification en cours | Étape de la catégorisation et priorisation du problème. |
| 3. Recherche de la cause en cours | Étape d'analyse et de diagnostic - axée sur la recherche de la cause fondamentale. Les activités reliées à cette étape peuvent être réunies dans une tâche. Plusieurs experts peuvent être sollicités. L'identification de la cause est un élément important dans la compréhension de la source du problème et aide à la recherche d'une solution. |
| 4. Recherche d'une solution de contournement en cours |
Étape d'analyse et de diagnostic - axée sur la recherche d'une solution de contournement, nécessaire à la résolution des incidents qui découlent des problèmes. Dû à l'objectif de la gestion des incidents, qui est de rétablir la situation le plus rapidement possible, la recherche d'une solution de contournement est prioritaire. |
| 5. Recherche d'une solution permanente en cours | Étape d'analyse et de diagnostic - axée sur la recherche d'une solution permanente qui vise l'élimination des incidents récurrents. Cette étape passe souvent par la mise en place d'un changement. |
| 6. Changement proposé (en attente d'autorisation) | L'identification de la cause et de la solution permanente étant faite, un changement est proposé à la gestion des changements pour corriger le problème. |
| 7. Changement en cours de réalisation | Le problème est en attente de la gestion des changements. |
| 8. Fermé (problème résolu) | Une fois le changement déployé, la documentation du problème sera mise à jour, les incidents reliés encore actifs résolus et si nécessaire, une revue effectuée. |
| Inactif |
Un choix doit être fait pour les problèmes inactifs parmi la liste suivante :
|
Priorité / Impact / Urgence
Les problèmes devraient être priorisés de la même façon en utilisant les mêmes raisons que les incidents. Cependant, d'autres facteurs devraient être pris en considération :
- La fréquence et l'impact des incidents reliés
- La disponibilité d'une solution temporaire
- La criticité d'un problème, selon une perspective service, client et infrastructure :
- Est-ce que le système peut être récupéré ou doit-il être remplacé?
- Quels seront les coûts?
- Combien de personnes et quelles expertises seront nécessaires pour résoudre le problème?
- Combien de temps cela prendra-t-il pour résoudre le problème?
- Quelle est l'étendue du problème (combien de CI sont affectés)?
- Quels sont les impacts au niveau business?
Dans Octopus, cliquez sur la flèche bleue 
pour sélectionner l'Impact et l'Urgence. La Priorité est accessible directement.
Les différents niveaux d'impact, d'urgence et de priorité sont détaillés dans le tableau ci-dessous. Prendre note que les items de ces listes ne sont pas configurables dans la Gestion des données de référence.
| Niveaux d'impact | Niveaux d'urgence | Niveaux de priorité |
|---|---|---|
|
1. Majeur 2. Significatif 3. Mineur 4. Réparation CI non critique |
|
|
Catégorisation / Assignation / Sujet
- Catégorisation : La catégorisation est la même que celle qui est appliquée aux incidents
- Assignation : Un problème est habituellement assigné à un groupe ayant l'expertise nécessaire pour trouver la cause fondamentale d'un incident, la solution à appliquer, est familier avec les activités relatives au processus de gestion des problèmes et comprend les interactions nécessaires avec la gestion des incidents, la gestion des changements et la gestion des actifs et des configurations (CMDB)
- Source* : Liste d'éléments pour identifier la source du problème. Les différentes sources proposées sont :
- résultat d'un changement
- analyse du journal d'événements
- historique des incidents
- observation
- analyse des activités opérationnelles
- Contact* : Pour documenter une personne contact
- Détection : Par défaut, la détection est Réactif, ce qui correspond à un problème dont l'analyse est basée sur des données existantes à propos des incidents, des événements ou des CI impactés. Sélectionner Proactif pour un problème créé pour des faiblesses connues de l'infrastructure ou des événements de type Information ou Avertissement, susceptibles de générer des incidents
- Sujet : Inscrire un sujet significatif qui décrit bien le problème
* Les champs source et contact peuvent être disponibles sur demande au Centre de services Octopus.
Onglet Documentation
Plusieurs champs sont disponibles pour documenter le problème tout au long de son cycle de vie. La documentation relève des informations déjà détenues sur les incidents et le problème, à savoir les symptômes, l'occurrence dans le temps, etc., mais aussi les actions et résultats qui surviennent à mesure qu'on travaille sur le problème. Les sections suivantes sont particulièrement importantes :
- Description : décrit de façon plus précise le problème, ses symptômes. Un problème créé à partir d'un incident reporte dans le champ Description du problème les symptômes décrits dans la description de l'incident
- Impacts : les impacts provoqués par ce problème
- Cause fondamentale : identifie la source qui cause ou pourrait causer des incidents
- Scénario de reproduction : scénario étape par étape qui reproduit le comportement, l'erreur
- Solution de contournement : documente la solution temporaire qui permet à la gestion des incidents de résoudre un incident, pendant que la gestion des problèmes continue à chercher une solution permanente. Le problème demeure ouvert, et tant qu'une solution permanente n'est pas appliquée et le problème résolu, on continue de créer les incidents, d'appliquer la solution de contournement et de les relier au problème
- Solution permanente : il s'agit de la solution finale, implantée via un changement, qui vise à ce que les incidents ne se reproduisent plus. Le problème est prêt à être fermé
Certains problèmes pourraient, pour des raisons financières, ne pas être résolus (par exemple, lorsque l'impact est limité et le coût de résolution élevé). Dans ce cas, on pourrait décider de laisser le problème ouvert et d'appliquer la solution temporaire en tout temps.
Une fois le problème résolu, on doit s'assurer que la solution implantée a atteint ses objectifs, à savoir que les incidents ne se reproduiront plus. Si un autre incident de même type survient, il conviendra de créer un nouveau problème et de le relier au problème original.
Onglet Tâches
Comme pour les requêtes de services et les changements, il est possible d'ajouter des tâches d'approbation, d'exécution et de notification à un problème.
Pour plus de détails à propos des tâches, veuillez consulter l'article Gestion des tâches.
Onglet Activités
Représente le journal d'activités du problème, où les activités créées sont consignées par ordre chronologique (date et heure) tout au long des étapes de gestion du problème. Les activités du module Problèmes peuvent représenter, par exemple :
- les activités de diagnostic du problème
- l'activité de résolution, qui est facilement identifiable si on utilise un type d'activité
- les communications, par l'envoi d'activités par courriel à d'autres intervenants, des fournisseurs, des utilisateurs
- autres
Nous recommandons l'inscription de l'effort pour représenter le temps de travail fourni par un intervenant pour chaque activité. Ce temps se convertit en coût et s'additionne au coût total du problème. En cours d'évaluation, il devient possible d'estimer si le temps investi versu à investir vaut la peine de poursuivre les efforts; la saisie des efforts contribue à la prise de décision.
Onglet Requêtes
Il est possible de relier tout type de requête (incident, problème, changement, événement) au problème, et de qualifier la relation qu'on veut établir. Par exemple, si on veut relier un changement à un problème, les relations possibles peuvent être :
- Est la cause de
- Est la solution de
- Est relié à
D'autres relations logiques sont présentées selon le type de requête sélectionné.
Onglet CI
Inscrire le CI à la source du problème. Le CI en cause identifié dans un incident n'est pas nécessairement celui qui cause le problème.
Onglet Fichiers joints
Comme dans tous les autres modules d'Octopus, vous pouvez joindre des fichiers, ajouter des raccourcis à des fichiers, ou ajouter un fichier à partir du contenu du presse-papier. La case à cocher Afficher les fichiers joints des activités permet de consolider toutes les pièces jointes, incluant celles des activités.
Onglet Historique
Octopus conserve une trace de la date et l'heure lorsqu'un problème est créé et modifié dans l'onglet Historique. L'information présentée dans cet onglet indique la donnée ajoutée ou modifiée (la valeur initiale et la nouvelle valeur), la date et l'heure et l'identité de l'intervenant responsable.
Créer un problème à partir d'un incident
- Ouvrir le formulaire d'incident à partir duquel un problème doit être créé
- 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
- Compléter le formulaire de création de problème selon les informations connues, relier d'autres incidents le cas échéant
- Enregistrer le problème en cliquant OK
- 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 Centre de 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 Centre de 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.
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 :
- Cocher la case Problème potentiel située en dessous du journal d'activités
- Ajouter une note pour justifier la raison
- 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 Gestion des 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 Gestion des événements - Module Octopus ou Gestion des é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.
- Sélectionner un ou plusieurs incidents existants
- Cliquer sur l'action Marquer comme non significatif à la GDP
- 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
- 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 :
- Ouvrir la recherche avancée
- Sélectionner Relation interrequêtes dans la fenêtre des types de résultats à retourner
- Saisir le champ Type (Requête 1) égal à Incident
- 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 Gestion des 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 Centre de services Octopus d'ajouter l'état En développement dans le module Problèmes de votre base de données.
Problème majeur
Pour en savoir plus sur les problèmes majeurs
Un problème majeur est un problème dont la sévérité ou l'impact est tel que la direction décide de revoir comment la situation s'est déroulée. Une revue de problème majeur inclut le processus suivi, les actions du personnel posées, les outils utilisés et l'environnement. La revue d'un problème majeur est une activité d'apprentissage et non une activité punitive ou une critique. Elle vise :
- le non-jugement face au succès ou à l'échec
- à découvrir pourquoi les choses sont arrivées
- à se concentrer directement sur les tâches et les buts qui ont été accomplis
- à encourager les employés à identifier les leçons importantes à en tirer
- à faire partager les leçons apprises
La dernière version du cadre de référence ITIL® a introduit une activité de revue de problèmes majeurs afin de prévenir une réoccurrence, de vérifier que le problème marqué comme fermé a effectivement éliminé l'erreur, et d'en tirer des leçons pour l'avenir.
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 Gestion des tâches pour obtenir des détails sur la configuration des tâches dans Octopus.
Merci, votre message a bien été envoyé.