see ItilChanges

Implementation

Characteristics of a problem:
  • Title
  • Description
  • Notes
  • Entity + Recursive ?
  • Category (same category of incidents. See if hiding some categories following an incident or problem?)
  • Status: same as the tickets? Adding status : under observation / accepted ... (Simple addition in the matrix of life cycle?)
  • Urgency, Priority, Impact: identical to tickets
  • Assign (idem incident): assignment to a provider?
  • Requester (idem incident requester)
  • Recipent (as for tickets)
  • Opening date, resolution date, the closing date, due date, modification date (as for tickets)
  • Affected resources (equipment) -> set defined (eg applications) or unique hardware?
  • Analysis (impact, causes, symptoms)
  • Solution (same ticket)
  • Task management (same ticket)
Possible actions:
  • Create a problem from a ticket
  • Link to a ticket to a problem
  • Link a problem with a change
  • Create a change from a problem
Auxiliary elements:
  • History
  • Notifications
  • Documents
  • Related tickets and related changes
Right management :
  • show my
  • show all
  • edit all

Tables to create:

  • glpi_problems:
    • id, name, content, date, solvedate, closedate, due_date, date_mod, entities_id, is_recursive, status,
    • users_id_recipient, suppliers_id_assign
    • urgency, impact, priority, ticketcategories_id
    • impactcontent, causecontent, symptomcontent
    • ticketsolutiontypes_id, solution, actiontime
  • glpi_problems_users: id, problemss_id, users_id, type, use_notification, alternative_email
  • glpi_groups_problems: id, problems_id, groups_id type
  • glpi_items_problems: id, problems_id, itemtype, items_id
  • glpi_problems_tickets, id, problems_id, tickets_id
  • glpi_problemtasks: id, problems_id, taskcategories_id, date, users_id, content, actiontime, users_id_tech, begin, end, state
  • glpi_changes_problems: id, changes_id, problems_id

Résultat du séminaire

Walid : infos et définitions prises dans le livre Itil et la gestion des services de Thierry Chamfrault et Claude Durand aux éditions Dunod.
La gestion des problèmes ¶

Objectifs :

  • elle est destinée à réduire le nombre et l'impact des incidents
  • rendre le service le plus rapidement aux utilisateurs/clients
  • avoir la certitude d'avoir éradiqué définitivement les gênes occasionnées

Un problème ne peut pas ouvrir un autre problème.

Identification et enregistrement d'un pb

Enregistrement d'un pb : naissance d'un ticket de pb analogue au ticket d'incident. Tous les identifiants des tickets d'incident liés au pb sont reportés dans l'enregistrement (association).

Lors de l'apparition d'un nouvel incident, ce dernier est comparé avec la base des pb afin d'identifier s'il n'existe pas un indicent similaire à celui qui vient de se produire. Si tel est le cas, l'indicent n'est pas traité mais associé au pb en cours de traitement.

Séminaire 2009 : la comparaison ne pourra être que manuelle. De même un incident, même lié à un problème, doit être traité par la solution de contournement.

Attributs d'un problème

Un problème possède un certains nombre d'attributs proches de celui d'un incident :

  • Titre
  • Description
  • Catégorie (identique à la catégorie des incidents. Voir si masquage de certaines catégories suivant incident ou problème ?)
  • Statut
  • Urgence, priorité, impact
  • Assignation (idem à incident)
  • Auteur (idem à incident : demandeur)
  • Date d'ouverture, date de fermeture, date d'échéance (comme pour les tickets d'incident)
  • Walid : aussi un attribut pour dire si c'est un problème ou une erreur connue ?
    décision: une erreur connue est une solution d'un problème

Mais possède des attributs particuliers :

  • services concernés -> non retenu
  • ressources concernées (équipement) -> ensemble définis (ex applicatifs)
  • un historique
  • des notes ? -> non retenu
  • des notifications ? -> ok (à définir)
  • un volet d'analyse (impact, cause symptomes)
  • une association à une solution (erreur connue ou solution)
  • gestion de tâches (équivalent au suiv plannifié)
  • des suivis (correspondant à des entrées de temps (tech, description, temps consacré et valorisé)
Séminaire 2009 :
  • l'interface ressemblera à celui des incidents avec toutefois des onglets supplémentaires :
    - volet d'analyse
    - document
    - incident (listant les incidents liés au problème)
    - changement (listant les changements demandés pour le problème)

Relation problème/incident /changement

Un incident peut être lié à un ou plusieurs problème(s) existant(s) ou nécessiter la création d'un nouveau problème.
Un problème peut concerner plusieurs incidents. (relation n/n)

Priorité, impact et urgence d'un problème ¶

  • Impact : mesure de l'influence sur le Business d'un problème ou d'un incident (potentiel selon lequel le Business reste vulnérable)
  • Urgence : mesure de l'influence d'un incident ou d'un problème basé sur l'impact et sur les besoins du client

Ex Valeurs d'un impact :

  • Majeur
  • Significatif
  • Mineur -> création d'un onglet résolution

Ex Valeurs de l'urgence :

  • Critique
  • Forte
  • Faible

Séminaire 2009 : la matrice pourra être la même que celle des incidents (voir chantier ImpactSeverityPriority)

Etats d'un problème

  • Nouveau
  • Accepté : analyse préalable pour s'assurer que toutes les infos descriptives sont suffisantes et vérifier que le pb est bien de la compétence de l'orga en charge de sa résolution
  • Planifié
  • Affecté
  • En cours
  • En attente
  • Résolu
  • En observation : le problème résolu, il est conseillé de mettre sous observation pendant une période de déterminée son correctif. Cette période de post-implémentation évite de fermer et de réouvrir des pb inconsidérément
  • Clos

Remarques

remi le 19/8/2009 : un problème peut être récursif et regrouper des incidents de plusieurs entitiés.