Identifier
Depuis un incident ou une alerte de tendance, un problème est créé et les incidents liés lui sont rattachés.
Modules · Gestion des problèmes
Traitez la cause, pas seulement le symptôme.
La gestion des problèmes remonte à l’origine des incidents qui reviennent, documente la cause et le contournement, et les met à la disposition des équipes de support.
Les bénéfices
- Moins d’incidents qui reviennentLes incidents récurrents se regroupent sous un problème dont la cause racine est analysée, puis corrigée.
- Un contournement connu de tousUne erreur connue publie un article, et la fiche d’un incident propose les erreurs connues proches.
- Des tendances repérées à tempsUn symptôme qui se répète au-delà d’un seuil déclenche une alerte avant que l’impact ne grandisse.
- Une résolution pilotéeLa correction passe par un changement ; la clôture est suggérée à son succès, la vérification reste humaine.
Le fonctionnement
Analyser
Les 5 pourquoi et le diagramme d’Ishikawa structurent la recherche de la cause racine.
Contourner
La cause et le contournement sont rédigés ; l’erreur connue est publiée dans la base de connaissances.
Corriger
Un changement résout le problème ; la revue après clôture conserve les enseignements.
Modules associés
- Service Desk Les incidents se rattachent au problème depuis sa fiche ou depuis le ticket, plusieurs d’un coup ; au-delà d’un seuil (cinq incidents en sept jours par défaut, par catégorie ou par élément), une alerte propose d’ouvrir le problème.
- Gestion des changements Le changement correctif se crée depuis le problème, avec la cause racine ; quand il réussit, la fiche propose de résoudre le problème.
- Incidents majeurs La revue post-incident crée le problème majeur, avec le ticket rattaché et la cause déjà rédigée ; une crise ne se clôture pas sans revue.
- CMDB La détection de tendance regroupe les incidents par élément du référentiel : un équipement qui revient trop souvent se signale de lui-même.
Périmètre fonctionnel
- Deux modesRéactif, à partir d’incidents (un seul incident significatif suffit) ; proactif, à partir d’une tendance.
- Cycle de vieIdentifié, investigation, erreur connue, changement planifié, résolu, clôturé ; une cause racine est exigée pour une erreur connue ou une résolution.
- Analyse de cause racineLes 5 pourquoi et le diagramme d’Ishikawa en six familles, comme structure de saisie.
- Incidents rattachésRecherche et rattachement de plusieurs incidents d’un coup ; le lien est visible des deux côtés.
- Base des erreurs connuesArticle publié avec symptôme, cause racine et contournement, mis à jour d’un clic, archivé si l’erreur est infirmée.
- Détection de tendanceSeuil réglable d’incidents sur une période, alerte aux responsables des problèmes et vue graphique des tendances.
- PilotageProblèmes ouverts, récurrence, erreurs connues sans contournement, délai de résolution, matrice impact × fréquence et tableau Kanban.
- Revue après clôtureObligatoire pour un problème majeur : écarts constatés et leçons apprises.
Intégrations
- Service Desk, pour rattacher les incidents
- Gestion des changements, pour la correction
- Base de connaissances, pour publier les erreurs connues
- Notifications par e-mail, avec des modèles modifiables
- Fonctions d’assistance par IA pour suggérer la cause et rédiger le contournement, lorsque le module IA est configuré
Prérequis
- Les responsables des problèmes, à désigner
- Une base de connaissances pour les erreurs connues, de préférence interne
L’essentiel de cette page en PDF, à garder ou à transmettre.
Télécharger la ficheVous voulez voir ce module sur vos propres processus ?
Nous construirons la démonstration autour de votre réalité opérationnelle.