KEDB

Tel que le préconise ITIL :
Un changement se lance à partir d'une erreur connue :

Multiples incidents (avec solution de contournement) -> Création d'un problème -> Si solution de contournement -> Ajout d'une erreur connue -> Lancement d'un changement

La KEDB permet de recenser les problèmes "non résolus" (Avec une solution de type Erreur Connue) et de centraliser tous les incidents / problèmes liés à cette erreur connue afin de déclencher la création d'un changement.

Coté GLPI

La KEDB pourrait être assimilée à une catégorie de la KB GLPI.
Ainsi on peut créer un article dans la KB GLPI taggé erreur connue, grâce à la catégorie et cibler les articles vers les gestionnaires de changement uniquement.
Cependant il est impératif de lier les objets ITIL (Incident, Problème) à cet article afin de pouvoir créer un changement depuis celui-ci et directement lié aux problèmes (voire Tickets) initiaux.

Actuellement :

  • Ouverture et Solution de contournement de ticket : OK
  • Création d'un problème (lié à ces tickets) : OK
  • Solution de contournement de problème : OK
  • Typage d'une solution en erreur connue : OK
  • Enregistrement dans la KB de l'erreur connue : OK

Manquant :

  • Configurer un type de solution comme étant une erreur connue et définir la catégorie de KB liée (erreurs connues).
  • A l'ajout de la solution (ayant un type de solution taggé erreur connue) à un problème (ou incident) , création d'un article dans la catégorie de KB (erreurs connues) obligatoire.
  • Liaison de l'article (taggé erreur connue) avec le ou les problèmes (ou incidents) (pas de table de liaison de type glpi_itilobjects_knowbaseitems)
  • Lien de création d'un changement depuis un article de la KB (taggé erreur connue)
  • Système de clôture (ou de dé-publication) des erreurs connues après résolution du changement

Web

http://www.theitsmreview.com/2012/04/7-benefits-of-using-a-kedb/

  • Is the KEDB the same as the Knowledge Base?

This is a common question. There are a lot of similarities between Known Errors and Knowledge articles.

I would argue that although your implementation of the KEDB might store its data in the Knowledgebase they are separate entities.

Consider the lifecycle of a Problem, and therefore the Known Error which is, after all, just an attribute of that Problem record.

The Problem should be closed when it has been removed from the system and can no longer affect users or be the cause of Incidents. At this stage we could retire the Known Error and Workaround as they are no longer useful – although we would want to keep them for reporting so perhaps we wouldn’t delete them.

Knowledgebase articles have a more permanent use. Although they too might be retired, if they refer to an application due to be decommissioned, they don’t have the same lifecycle as a Known Error record.

Knowledge articles refer to how systems should work or provide training for users of the system. Known Errors document conditions that are unexpected.

There is benefit in using the Knowledgebase as a repository for Known Error articles however. Giving Incident owners a single place to search for both Knowledge and Known Errors is a nice feature of your implementation and typically your Knowledge tools will have nice authoring, linking and commenting capabilities.