Attribution de plusieurs catégories à un ticket/article/...

chtonk · 2008-06-02 12:37:06

Bonjour,

je me heurte souvent, dans la gestion des tickets, au fait de ne pouvoir choisir qu'une seule catégorie de rattachement.

est-ce qu'il serait possible de gérer plusieurs catégorie pour un même ticket ? Je m'explique :
Avoir une sorte de liste (non déroulante) dans laquelle on rajoute une ou plusieurs catégories (sans rien changer à la gestion des catégories avec leurs hiérarchies).

Par exemple, un utilisateur se plaint de ne pouvoir imprimer sur l'imprimante partagée. Après analyse, c'est un domaine windows 2003 sur laquelle l'imprimante a été dé-partagée, ou bien on a retiré le droit d'accès à cet utilisateur pour cette imprimante. Les catégories sont à la fois l'impression, mais réseau et administration réseau.

C'est un exemple qui vaut ce qu'il vaut, mais qu'il donne clairement une idée du multi-catégorie qui serait utilisable.

Cordialement,

Guillaume

JMD · 2008-06-02 22:43:49

Je sais plus s'il y a un ticket d'ouvert à ce sujet.

chtonk · 2008-11-03 20:33:15

Bonsoir,

JMD wrote:

Je sais plus s'il y a un ticket d'ouvert à ce sujet.

désolé pour ce délai de réponse, mais je ne pense pas qu'il y ait de ticket ouvert pour ça.

Cordialement,

Guillaume

MoYo · 2008-11-03 20:37:58

il y a celui là mais qui ne correspond pas aux catégories :
https://dev.indepnet.net/glpi/ticket/839

Personnellement je ne suis pas convaincu de l'intérêt mais surtout de la pertinence de la multi-catégories.

chtonk · 2008-11-03 20:52:31

Bonsoir,

MoYo wrote:

il y a celui là mais qui ne correspond pas aux catégories :
https://dev.indepnet.net/glpi/ticket/839
Personnellement je ne suis pas convaincu de l'intérêt mais surtout de la pertinence de la multi-catégories.

En fait, en regardant de plus près avec un autre post, la question posée serait la suivante :

Un ticket est souvent ouvert par un utilisateur. Afin de déterminer le genre d'action à mener, il lui est demandé de catégoriser son problème.

Par la suite, le problème étant résolu, si sa résolution s'est située dans des domaines variés (cf exemple sur l'impression réseau qui a correspondu à des problèmes d'impression, d'administration réseau), il serait bien de pouvoir préciser tous ces domaines impactés par le problème.

Il s'agit donc bien de catégoriser de manière multiple un ticket. Peut être moins dans la demande par l'utilisateur que lors de sa fermeture et/ou de sa résolution par un technicien.

Bien sûr, cela est décorrelé des actions de résolution qui ont été menées (cf l'autre message référencé ci-dessus).

En fait, ces propositions sont des moyens de faire un peu d'analytique sur les tickets, en eux-même, comme sur leurs résolutions. C'est pour pouvoir, par la suite, faire des études et des rapports qualitatifs sur les interventions.

Cordialement,

Guillaume

Last edited by chtonk (2008-11-03 20:52:47)

wawa · 2008-11-04 10:05:18

ça ressemblerait pas à une notion de tags multiples qu'on voit dans certains logiciels ou je suis complètement à côté ?

chtonk · 2008-11-04 10:49:03

Bonjour,

wawa wrote:

ça ressemblerait pas à une notion de tags multiples qu'on voit dans certains logiciels ou je suis complètement à côté ?

eh bien, techniquement, ce sont deux tables de liens :
1. une table de liens reliant la table des tickets et la table des catégories
2. une table de liens reliant la table des tickets et la table des résolutions (qui devrait être créée)

Le seul hic, c'est que garantir l'intégrité de ce genre de table de lien est très lourd en développement. De même les interfaces les plus optimisées pour ce genre de tables de liens sont des listes et ce qui alourdit en plus l'interface...

Mais d'un autre côté, cela permet d'affiner les informations sur les tickets et suivis pour mieux étudier les interventions, les problèmes, la qualité des interventions, la qualité du travail des techniciens, etc...

Cordialement,

Guillaume

JMD · 2008-11-04 13:34:48

Ok on est bien daccord.

L'ajout d'un dropdown pour le typage des suivis est à l'étude.

chtonk · 2008-11-04 14:49:49

Bonjour,

JMD wrote:

Ok on est bien daccord.
L'ajout d'un dropdown pour le typage des suivis est à l'étude.

Nous sommes bien d'accord qu'un dropdown est l'équivalent d'une combo box ? Le souci que je vois avec ce type d'interface est l'unicité de sélection d'un type de suivi. Alors que dans la discussion, j'émets l'idée d'avoir d'un côté les domaines du problèmes(impression, droits utilisateurs, réseau, câblage, panne matérielle ordinateur, ...) , qui peuvent être multiples, que les actions menées, qui peuvent être multiples également (Suivi téléphoniques, interventions sur site, intervention à distance, appel hotline tiers, ...).

Ou alors, ce genre d'informations, peut être faut-il l'envisager sous l'angle d'un plugin ? Mais l'avoir dans l'écran principal d'un ticket me semblerait un plus. Surtout que fonctionnellement, dans le principe de base de connaissance liée aux tickets, cela a un sens.

Cordialement,

Guillaume

PS : désolé d'être si insistant, mais dans mon cas, c'est vrai que ce serait un plus énôôôôrme

JMD · 2008-11-04 15:13:12

Il doit y avoir une unicité de catégorie pour un ticket d'ouverture d'incident ou une demande de service.
C'est la catégorie de classement du ticket par du ou des problèmes sous jacents.

Lorsque GLPI integrera la gestion des problèmes et changement, il sera possible de lier un ou plusieurs tickets d'incidents à un problème ou une RFC. (cf chantier ITIL)

Ce qui manque actuellement c'est typage des suivis. Afin que chaque suivi puisse être rélié à un type d'action et donc obtenir des statistiques.

Enfin la résolution de l'incident devrait comprendre un lien possible avec la base de connaissance mais pas de façon obligatoire.

chtonk · 2008-11-04 15:44:30

Bonjour,

JMD wrote:

Il doit y avoir une unicité de catégorie pour un ticket d'ouverture d'incident ou une demande de service.
C'est la catégorie de classement du ticket par du ou des problèmes sous jacents.

Oui. Je pense que l'utilisateur qui a accès à l'interface du helpdesk pour ouvrir un ticket incident ne doit qualifier l'incident qu'à partir d'une seule catégorie (qui a du sens pour lui).

JMD wrote:

Lorsque GLPI integrera la gestion des problèmes et changement, il sera possible de lier un ou plusieurs tickets d'incidents à un problème ou une RFC. (cf chantier ITIL)

Ce qui répond à la multi-catégorisation des tickets.

JMD wrote:

Ce qui manque actuellement c'est typage des suivis. Afin que chaque suivi puisse être rélié à un type d'action et donc obtenir des statistiques.

C'est là que, à mon sens, doit se faire un choix, tout dépendant de la manière avec laquelle glpi et plus précisément les suivis sont utilisés.

Prenons l'exemple d'une société disposant de 2 sites distants, reliés par un VPN. Sur le site A, un nouvel utilisateur entré le jour même veut imprimer un document sur une imprimante du site B. Seulement, 1° l'utilisateur n'a pas les droits pour utiliser cette imprimante, 2° le lien VPN est coupé.
A l'ouverture du ticket, l'utilisateur va préciser une unique catégorie : Problème d'impression. A la suite de quoi, un technicien intervient sur son poste. Le technicien va identifier que le problème ne vient pas du poste. Il va "pinger" l'imprimante et voir que ça ne passe pas parce que le lien VPN est tombé. Il appelle une hotline pour faire remonter le VPN, qui est remonté super rapidement (c'est pour de faux, mais temporellement ça va plus vite ). Il arrive donc à "pinger" l'imprimante. A la suite de ça, toujours dans la même intervention, il se rend compte que l'utilisateur n'a pas le droit d'imprimer sur cette imprimante. Il modifie donc les droits de l'utilisateur pour cette imprimante et tout fonctionne, l'utilisateur est super content et le technicien est le sauveur ( )

L'exemple posé, il y a plusieurs manières d'historiser cette intervention :
1° : le technicien ne crée qu'un seul suivi dans lequel il met tout ce qu'il a fait.
2° : le technicien crée autant de suivis qu'il y a eu d'actions différentes (analyse poste client, analyse lien réseau, appel hotline, gestion des droits utilisateurs).

(en ce qui me concerne, je fonctionne plus selon la méthode 1° avec un seul suivi. Toutefois, je peux appliquer la méthode 2° si le cas nécessite une identification plus fine. Mais cela demande plus de travail de saisie).

Dans le 1°, il faut pouvoir rattacher plusieurs actions (indépendamment de leur séquentialité) à un seul suivi - et là, une dropdown n'est pas pertinente mais plutôt une liste à multi-sélection. Dans le 2°, oui, là une dropdown est pertinente, car cela revient à créer autant de suivi que d'actions. Mais c'est plus long en termes de saisie.

JMD wrote:

Enfin la résolution de l'incident devrait comprendre un lien possible avec la base de connaissance mais pas de façon obligatoire.

Je pense qu'un ou plusieurs liens sont nécessaires, cf. l'exemple ci-dessus, pouvant faire appel à des données multiples d'une base de connaissance (gestion des droits utilisateurs, utilitaires réseaux, imprimantes, procédure d'appel à la hotline du VPN, ...)

Cordialement,

Guillaume

JMD · 2008-11-04 16:13:42

2° : le technicien crée autant de suivis qu'il y a eu d'actions différentes (analyse poste client, analyse lien réseau, appel hotline, gestion des droits utilisateurs).

C'est nécessaire car il peut y avoir (et c'est meme souvent le cas dans le helpdesk de taille moyenne et +) plusieurs intervenants.

Par ailleurs si on veut avoir une métrique horaire sur les suivis par type, il est indispensable d'avoir un type par suivi et donc de créer autant de suivi que d'actions.

chtonk · 2008-11-04 16:18:40

Bonjour,

JMD wrote:

2° : le technicien crée autant de suivis qu'il y a eu d'actions différentes (analyse poste client, analyse lien réseau, appel hotline, gestion des droits utilisateurs).
C'est nécessaire car il peut y avoir (et c'est meme souvent le cas dans le helpdesk de taille moyenne et +) plusieurs intervenants.
Par ailleurs si on veut avoir une métrique horaire sur les suivis par type, il est indispensable d'avoir un type par suivi et donc de créer autant de suivi que d'actions.

Effectivement... c'est moi qui ne travaille pas à la hauteur de ce que je demande

Ok pour moi alors et merci pour ces précisions.

Cordialement,

Guillaume

cgrumel · 2009-04-16 11:42:51

Bonjour,

Je suis dans le même cas : besoin de typer les suivis (et d'en extraire des statistiques).

Qu'en est-il du développement de cette fonctionnalité ? Est-ce prévu dans une prochaine version (je suis actuellement en 0.71.5) ?

Cordialement,
cgrumel

remi · 2009-04-16 11:51:12

Oui, c'est en cours d'étude.
Mais pas pour la 0.72 qui est en cours de finalisation...

+

Forum GLPI-Project

Announcement

#1 2008-06-02 12:37:06

Attribution de plusieurs catégories à un ticket/article/...

#2 2008-06-02 22:43:49

Re: Attribution de plusieurs catégories à un ticket/article/...

#3 2008-11-03 20:33:15

Re: Attribution de plusieurs catégories à un ticket/article/...

#4 2008-11-03 20:37:58

Re: Attribution de plusieurs catégories à un ticket/article/...

#5 2008-11-03 20:52:31

Re: Attribution de plusieurs catégories à un ticket/article/...

#6 2008-11-04 10:05:18

Re: Attribution de plusieurs catégories à un ticket/article/...

#7 2008-11-04 10:49:03

Re: Attribution de plusieurs catégories à un ticket/article/...

#8 2008-11-04 13:34:48

Re: Attribution de plusieurs catégories à un ticket/article/...

#9 2008-11-04 14:49:49

Re: Attribution de plusieurs catégories à un ticket/article/...

#10 2008-11-04 15:13:12

Re: Attribution de plusieurs catégories à un ticket/article/...

#11 2008-11-04 15:44:30

Re: Attribution de plusieurs catégories à un ticket/article/...

#12 2008-11-04 16:13:42

Re: Attribution de plusieurs catégories à un ticket/article/...

#13 2008-11-04 16:18:40

Re: Attribution de plusieurs catégories à un ticket/article/...

#14 2009-04-16 11:42:51

Re: Attribution de plusieurs catégories à un ticket/article/...

#15 2009-04-16 11:51:12

Re: Attribution de plusieurs catégories à un ticket/article/...

Board footer