Ecaldima

Modules · Gestion des problèmes

Les incidents qui reviennent ont une cause. Ecaldima vous aide à la trouver.

La gestion des problèmes regroupe les incidents qui se répètent, structure la recherche de la cause racine et met le contournement à la disposition du support, en attendant la correction.

Demander une démonstration Télécharger la fiche

  • Alerte de tendance au-delà d’un seuil
  • 5 pourquoi et diagramme d’Ishikawa
  • Erreurs connues proposées sur les tickets

01Avant que l’impact grandisse

Une tendance se signale d’elle-même.

Au-delà d’un seuil, cinq incidents en sept jours par défaut, par catégorie ou par élément de la CMDB, une alerte propose d’ouvrir un problème proactif. La courbe montre la période glissante et le seuil franchi.

Une tendance se signale d’elle-même.

02Pendant l’analyse

La cause racine se cherche avec méthode.

Les 5 pourquoi et le diagramme d’Ishikawa en six familles structurent la recherche ; une cause racine est exigée avant de déclarer une erreur connue ou de résoudre le problème.

La cause racine se cherche avec méthode.

03Pour le support

Le contournement arrive sur le ticket.

L’erreur connue publie un article avec le symptôme, la cause et le contournement ; la fiche d’un incident propose les erreurs connues les plus proches. La correction passe par un changement, et sa réussite propose de résoudre le problème.

Le contournement arrive sur le ticket.

Une crise laisse ses enseignements.

La revue post-incident d’un incident majeur 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.

La vérification reste humaine.

La clôture est proposée au succès du changement correctif, jamais imposée : c’est l’équipe qui confirme que le problème est résolu.

Je suis scotché !

Un client, utilisateur d’Ecaldima depuis ses débuts, après la démonstration de la nouvelle version

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 Tout le détail du module
  • 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 fiche

Vous voulez voir ce module sur vos propres processus ?

Nous construirons la démonstration autour de votre réalité opérationnelle.

Demander une démonstration