Deux catégories distinctes

Florent C. · 2012-03-19 22:04:18

Bonjour à tous,
Et félicitations à la l'équipe pour ce formidable projet.

Présentation rapide pour mon premier message : responsable de projets au sein d’une équipe de 10 hotliners spécialisés dans l’assistance téléphonique autour des systèmes d’encaissement depuis 10 ans.
Nous avons développé 2 logiciels hotline, utilisé une "grosse" solution du commerce, avant de choisir GLPI il y a 2 ans. Il est vraiment mieux que ce que nous avions avant ;)

Je travaille sur la qualité, mes stats doivent amener des plans d’actions sinon cela ne sert à rien.
Après pas mal d’analyse, la seule solution est à mes yeux deux catégories, je m’explique par UN exemple :

1- L'objet du ticket --> le point de vue de l'utilisateur.
Exemple de titre : mon application OO WRITER plante quand j'imprime.
CATEGORIE = OBJET = WRITER
Avec cette catégorie j'obtiens des Stats qualitatives sur la perception de l'outil, des progiciels ... Ce qui intéresse les responsables chez le client.

2- La cause du ticket --> Le point de vue du hotliner, du tech.
Exemple de suivi : utilisation de WRITER en TSE sur un serveur dont la file d'impression est saturée. Changement de serveur TSE : OK
CATEGORIE = CAUSE = Serveur TSE
Avec cette catégorie j'obtiens des Stats orientées analyse technique qui permettent un plan d'action. Ce qui intéresse le service technique du client.

Vos commentaires seront les biens venus.
J'ai bien cherché, il ne me semble pas que ce sujet ait déjà été évoqué.

Je compte étudier cette évolution à partir de la 0.80.7
Y a-t-il une méthode particulière pour que ce développement puisse être réutilisé dans le plan d'édition de GLPI ?

Très cordialement,
Florent.
(pas dubitatif du tout ;)

Last edited by Florent C. (2012-03-19 22:08:53)

remi · 2012-03-20 08:00:38

Avant tout développement, il est préférable que l'évolution soit validée et inscrite sur la roadmap.
Cf https://forge.indepnet.net/projects/glp … rkflowGlpi

Concernant cette évolution.

Il me semble, que pour cet exemple, c'est principalement l'élément attaché au ticket (ici un serveur) qui permettra d'identifier la cause.

Il n'existe pas actuellement de gestion d'élément complexe dans GLPI (groupement d'élément), mais le plugin "applicatifs" permet de corriger ce manque.

D'autres éléments peuvent aussi être utilisés pour analyser une cause
- la catégorie des tâches, décrivant les actions menées pour solutionner l'incident
- la catégorie de solution, même si dans ce cas je préfère une distinction du type solution définitive / de contournement
- le problème (version 0.83) qui permet de regrouper des tickets ayant la même cause afin d'assurer une résolution globale et définitive

Par ailleurs, j'ai récemment fait la proposition d'ajout d'une rubrique "Processus" (orientation ITIL) qui permettrait de regrouper les tickets sur un critère transverse. Cf https://forge.indepnet.net/issues/3385

Pour résumer ma pensée, oui, la notion de "cause" est importante, mais me semble déjà présente.

D'autre avis ?

Florent C. · 2012-03-21 10:40:56

Merci pour ta réponse Rémi et toutes ces précisions.
Je me fais une maquette .83 cette semaine.

Florent C. · 2012-04-20 15:47:24

Bonjour,

La .83 répond en effet parfaitement au besoin décrit plus haut. (notion "problème")
sujet Clôt.

notre analyse des "Problèmes" se fera au travers d'un cube.
Au terme de quelques semaines d'échauffement, la .83 arrive en fanfare en prod !

J'aurai quand même une ou deux petites questions, dans un futur post.

Sur ce , champagne°°°°
A+
Florent

Forum GLPI-Project

Announcement

#1 2012-03-19 22:04:18

Deux catégories distinctes

#2 2012-03-20 08:00:38

Re: Deux catégories distinctes

#3 2012-03-21 10:40:56

Re: Deux catégories distinctes

#4 2012-04-20 15:47:24

Re: Deux catégories distinctes

Board footer