Saisie des tickets dans GLPI 0.80

remi · 2009-12-17 20:32:00

Bonjour,

Dans le prochaine version, en cours de développement, le formulaire de saisie des tickets va être fortement remanié pour gérer des nouvelles données (Urgence, Impact, Suivis, Tâches, Solution, ...)

Quelles sont à votre avis les données essentielles lors de la création d'un ticket par un technicien, le but est de ne pas encombrer le formulaire et d'avoir une utilisation efficace de GLPI (utilisable dans 90% des cas, les autres pourront se faire en 2 temps)

- Date : par défaut, heure système
- Statut : sachant qu'il sera nouveau par défaut, ou attribué si un technicien est désigné, ou résolu si une solution est saisie
- Urgence : expression du client
- Impact
- Priorité : résultat d'un calcul des 2 précédents
- Catégorie
- Source de la demande => disponible dans les préfs.
- Matériel concerné
- Demandeur
- Groupe demandeur
- Technicien
- Groupe
- Fournisseur
- Durée
- Suivi par email
- Email
- Titre
- Description
- Document joint
- Suivi => dans la description, c'est le reflet des échanges avec l'utilisateur ?
- Tâche => uniquement en modification ? (surtout pour la planification)
- Solution => à la place du suivi autorisé en 0.72, permettant de résoudre le ticket dès la création

Évidemment tous ces champs seront ensuite disponibles en visualisation / modification.

Votre avis...
Remi.

tsmr · 2009-12-17 20:38:02

Pour ma part, la plupart du temps :

- Date
- Statut
- Urgence
- Impact
- Priorité
- Catégorie
- Matériel concerné
- Demandeur
- Technicien
- Groupe
- Fournisseur
- Suivi par email
- Email
- Titre
- Description
- Document joint
- Tâche => en création - modification avec planification
- Solution (si un mail contenant la solution est envoyée au demandeur)

Last edited by tsmr (2009-12-17 20:38:39)

doum · 2009-12-17 21:07:39

Chez nous :

- Date (pouvoir la changer directement est pratique pour la saisie des incidents d'astreinte le lundi matin par ex)
- Urgence
- Impact
- Priorité : résultat d'un calcul des 2 précédents
- Catégorie
- Matériel concerné
- Demandeur
- Groupe demandeur
- Technicien
- Groupe
- Titre
- Description
- Document joint
- Suivi => dans la description, c'est le reflet des échanges avec l'utilisateur ? J'ai pas compris ? Pour moi le premier suivi c'est la description du probleme, a voir mais me semble sans grand interet
- Solution

J'ai volontairement enlevé suivi par mail (tjs a oui chez nous), et le mail (récupéré automatiquement via le ldap donc non nécessaire a la saisie du ticket), la source de la demande (95% des incidents ont pour source la source par defaut), le fournisseur (ca passe forcement dans un premier temps par un technicien interne a la boite avant d'eventuellement etre dispatché), la durée (pas utilisé chez nous), le statut (vu le fonctionnement auto que tu donnes, pas nécessaire pour nous, quitte a le changer dans un 2eme temps une fois de temps en temps)

Last edited by doum (2009-12-17 21:10:46)

ricky_ds · 2009-12-17 23:37:18

Si je pense au 90% des tickets

- Urgence : expression du client
- Impact
- Priorité : résultat d'un calcul des 2 précédents
- Catégorie
- Source de la demande => disponible dans les préfs.
- Matériel concerné (nous avons surtout des tickets niveau logiciel et non niveau matériel, donc on pourrait s'en passer dans bcp de cas. Mais certainement pas 90%, donc il faut que ça reste)
- Demandeur
- Groupe demandeur (on pourrait s'en passer si le groupe demandeur, lorsqu'il n'y a pas de matériel, était le groupe principal de l'utilisateur -- et encore, il faudrait pouvoir définir ce groupe principal)
- Technicien
- Durée
- Suivi par email
- Email
- Titre
- Description
- Document joint
- Suivi => dans la description, c'est le reflet des échanges avec l'utilisateur ?
- Tâche => uniquement en modification ? (surtout pour la planification)
- Solution => à la place du suivi autorisé en 0.72, permettant de résoudre le ticket dès la création

Les champs dont nous n'avons pas besoin, ou au maximum dans 10% des cas:
- Date (nous ne la changeons jamais)
- Statut (les seules modifications actuellement sont si le ticket est résolu lors de la saisie. Dans ce cas nous avions à changer le statut, mais si c'est automatique en 0.8, alors plus besoin). Il y a peut-etre 10% des cas ou nous mettons un ticket directement en attente lors de la saisie.
- Groupe (rarement utilisé, car toujours assigné à un technicien)
- Fournisseur (très, très, très rare)

infooo · 2009-12-30 15:19:23

Bonjour,

Concernant la listes des informations que vous avez établie, je n'ai pas de remarque particulière.
J'avais lu dans ce forum qu'il était question dans la 0.80 de revoir les catégories de tickets, avec d'une part la catégorie sélectionnée par le demandeur et d'autre part une "2ème" catégorie renseigné par le technicien. Est-ce que vous pensez prendre en compte cet élément ? (ou bien je n'ai peut-être pas tout compris sur ce point).

J'en profite pour vous demander si quelque chose est prévu au niveau de la saisie par les demandeurs. Je m'intéresse notamment à la question d'une formulation précise du besoin par les demandeurs, pour éviter aux techniciens d'avoir fréquemment recours à des demandes de complément d'informations.
J'avais évoqué la question ici : http://www.glpi-project.org/forum/viewt … 90#p97290.

Dans ce genre de problématique, la difficulté est que chacun a des besoins différents, c'est pourquoi je pense a une solution qui donnerait la possibilité au demandeur de choisir éventuellement dans une liste de "formulaires" (paramétrables par les admins) qu'il n'aurait plus qu'à remplir et qui seraient intégrés en pièce jointe au ticket.
Cela pourrait permettre de cadrer la formulation de certaines demandes, par exemple demande d'installation d'une prise réseau avec dans mon cas : nom du bâtiment, étage, numéro de la pièce, etc.

Merci de votre aide

remi · 2009-12-30 17:02:46

> revoir les catégories de tickets,
Oui : catégorie de ticket (besoin) + catégorie des tâches (opération réalisées par le tech)

Les gabarits de ticket ne sont pas encore à l'ordre du jour.

+

J-n-s · 2010-02-15 17:33:30

2 suggestions :
La première j'ai déjà posté le problème dans ce post : http://www.glpi-project.org/forum/viewt … p?id=16722
>pouvoir assigner un ticket à un groupe et que ce ticket garde le statut "nouveau" lorsqu'il n'est pas affecter à un technicien

et celle-ci (moins important) :
>que le groupe du demandeur soit rempli automatiquement, dans le cas ou le demandeur appartient à un seul groupe.
Que le demandeur ait le choix de déterminer son groupe s'il appartient à plusieurs groupes (j'ai vu que c'était possible lorsque le profil à les droits d'éditions, mais je ne veux pas que le demandeur se fasse passer pour un autre : avec les droits d'éditions, lors de la création d'un ticket, on peut choisir le demandeur...). => en bref, personnalisation plus détaillée de l'interface selon le profil

JMD · 2010-02-15 17:52:53

Bonjour,

Vos deux demandes semblent tout de même spécifiques. A moins que ça soit des options on ne peut pas en faire des comportements par défaut.

Par ailleurs et s'il vous plait. Peut-on rester sur le sujet initial et ne pas partir dans une liste de Noel. Plus il y a de bruit dans un fil de discussion et plus ça devient compliqué de tracer les éléments qui devront être relevés.

turkpipotutunu · 2010-02-19 19:28:52

Je reponds par un resume des 2 Topics que je viens d'ouvrir( ...)

* Standardisation des taches pour saisie plus efficase etmeilleur lisibilite ensuite, a partir d'une table de taches 'standard'
* Acces a une base de donnee exterene (via une vue) pour avvecder a des peices detachees ou prestations fournisseur ou internes.... avec calcul du cout du ticket (devis ou reel)

coolhead · 2010-02-24 09:25:02

Bonjour,

J'ai dernièrement eu un problème d'utilisation à propos des tickets.

Un évènement impact un problème de connexion Internet, j'ouvre un ticket en rapport avec le serveur Proxy.
J'ai le plugin "Liaison" pour gérer les connexion Adsl, Sdsl, ...
Ma connexion utilise le logiciel ISA Server.

Il se trouve que j'aurai voulu indiquer que le ticket "Problème de connexion Internet" était en relation avec un logiciel, un ordinateur et une liaison.

Pourrions nous indiquer plusieurs éléments de l'inventaire en lien avec un ticket ?

Par ailleurs, lorsque nous lançons un ticket tel que "Remettre la nouvelle image disque de la salle informatique", pourrions nous attribuer un ticket à plusieurs "Ordinateur"; pas un groupe, mais plutôt la liste des éléments d'inventaire en lien avec le ticket (peut être avec une dépendance, un priorité , ... je ne sais pas)

Merci @ tous

BenLar · 2010-03-29 21:39:56

Une remarque que je me fais depuis quelques temps.

Concernant l'impact/l'urgence, il me semblerait intéressant qu'il existe une info bulle qui explique ce qui est entendu par le degré d'impact/d'urgence (à définir pour chacun bien sur).

Par exemple :
pour l'impact
très élevé : atteinte à la sécurité des personnes
élevé : atteinte aux personnes sans atteinte à leurs sécurité OU désorganisation l'organisation OU perte financière mettant en péril l'organisation OU....
moyen : désorganisation d'un service OU perte financière....
...

Pour l'urgence
très élevé : missions non réalisée, pas de contournement, crise
élevé : pas de contournement, retard dans les missions
moyen : contournement, missions réalisées avec retard...

Ceci me semble plus parlant et permet de mieux définir les évènements.

Après, effectivement, on pondère là ou il faut dans la configuration de la bébête.

A voir si cela apporte quelque chose.

A+

Ben

slayer722 · 2010-04-06 14:31:50

remi wrote:

- Tâche => uniquement en modification ? (surtout pour la planification)
- Solution => à la place du suivi autorisé en 0.72, permettant de résoudre le ticket dès la création
Évidemment tous ces champs seront ensuite disponibles en visualisation / modification.
Votre avis...
Remi.

Bonjour,

J'ai pas compris cette phrase, est ce que ça veut dire qu'on pourra enfin définir quels champs afficher ?

Cordialement

EmpereurZorg · 2010-04-06 14:47:54

slayer722 wrote:

remi wrote:
Évidemment tous ces champs seront ensuite disponibles en visualisation / modification.
Bonjour,
J'ai pas compris cette phrase, est ce que ça veut dire qu'on pourra enfin définir quels champs afficher ?
Cordialement

Bonjour,
Cela veux avant tout dire qu'il y aura une première vue par défaut, "restreinte" de façon à ce que le premier intervenant (notamment) puisse remplir rapidement tous les champs pertinent, mais que les autres champs resteront bien entendu à disposition.
Je n'ai pas encore testé la beta, mais je ne pense pas qu'il soit encore possible de personnaliser entièrement l'affichage/les champs d'un ticket.

++
Anthony

doum · 2010-04-06 14:56:48

slayer722 wrote:

remi wrote:
- Tâche => uniquement en modification ? (surtout pour la planification)
- Solution => à la place du suivi autorisé en 0.72, permettant de résoudre le ticket dès la création
Évidemment tous ces champs seront ensuite disponibles en visualisation / modification.
Votre avis...
Remi.
Bonjour,
J'ai pas compris cette phrase, est ce que ça veut dire qu'on pourra enfin définir quels champs afficher ?
Cordialement

Je n'aime pas le ton de votre "on pourra enfin définir"
Si pour vous c'est tellement indispensable, contribuez afin que ce soit faisable
Voila ca c'etait juste mon petit coup de gueule de 15h

Sinon non la 0.78 (et les suivantes d'ailleurs) ne permettront pas de definir les champs a afficher ou ne pas afficher

Last edited by doum (2010-04-06 14:57:06)

slayer722 · 2010-04-09 18:52:44

Bonjour,

Je vous trouve plutôt susceptible, je le disais absolument pas sur ce ton.
Je trouve ce projet excellent et si j'avais plus d'expériences et surtout du temps je m'empresserai de contribuer.

Je promets rien mais j'essaierai de faire un ticket avec quelques idées, voir des mockups.

Cordialement.

EmpereurZorg · 2010-04-09 19:38:03

Ne te formalise pas slayer722, c'est la période ou le forum commence à se peupler de stagiaires à qui l'on demande de tester Glpi, alors à force de lire pour la nième fois la même demande du type "édez moi sa marche pas c urgent", même les messages les plus anodins peuvent être mal interprétés. C'est ton 4ème message, donc suspect "par défaut"... même moi après mes 500 messages j'ai pris ce travers, des fois je me retient même de répondre
Bon week-end !

Last edited by EmpereurZorg (2010-04-09 19:40:35)

nicoelo · 2010-04-19 16:35:09

Bonjour,

dans notre cas, il serait intéressant de pouvoir mettre une date prévisionnelle de réalisation lors de la modification du ticket. Elle permettrait ensuite de faire des stats sur l'efficacité du service par exemple.

Merci

dcpc · 2010-06-08 14:37:51

Pour ma part, les éléments en gras seraient utiles régulièrement, les autres pas utiles ou plus rarement

- Date : par défaut, heure système
- Statut : sachant qu'il sera nouveau par défaut, ou attribué si un technicien est désigné, ou résolu si une solution est saisie
- Urgence : expression du client
- Impact
- Priorité : résultat d'un calcul des 2 précédents
- Catégorie
- Matériel concerné
- Demandeur
- Groupe demandeur (s'il pouvait être rempli automatiquement dans le cas d'un demandeur avec 1 seul groupe ...)
- Technicien
- Groupe (très utile .. surtout avec la nouvelle console centrale !)
- Suivi par email
- Email (NON : rempli auto via LDAP)
- Source de la demande
- Fournisseur
- Durée (à la création on ne devrait pas avoir de durée à remplir, la durée doit être liée à une action, ou suivi avec le demandeur)
- Titre
- Description
- Document joint
- Suivi => dans la description, c'est le reflet des échanges avec l'utilisateur ?
- Tâche => uniquement en modification ? (surtout pour la planification)
- Solution => à la place du suivi autorisé en 0.72, permettant de résoudre le ticket dès la création (pas propre comme procédure au niveau ITIL !)

thidess · 2010-09-20 10:52:59

Bonjour,
Pour ceux qui ne pouront pas utiliser ldap, il y aura-t-il des foctions "alertes mails" automatiques pour ce qui est des des délais de prises en charge et dépassements des SLA? Merci de votre réponse

DaBoss · 2010-10-27 23:24:41

Bonjour à tous,

Afin de faire avancer le chimilihimil . . . le chilimihilimi . . . le chilmi . . . enfin le projet GLPI ..! Voici un "premier" retour sur l'ouverture des tickets.

- Date : par défaut, heure système (date actuelle par défaut suffit, pas de raison à priori d'ouvrir un ticket a il y avait 3 jours)
- Date Echéance (pas encore implémenté dans la 0.78 mais je crois en prévision pour la 0.80, super utile pour nous afin de savoir comment planifier nos actions.)
- Statut : sachant qu'il sera nouveau par défaut, ou attribué si un technicien est désigné, ou résolu si une solution est saisie
- Urgence : expression du client (lié a la date echance mais pas très révélateur, si je compare a un hopital, je suis le chirurgien urgentise, tout est toujours urgent, et "ma demande" est plus urgente que les autres.)
- Impact
- Priorité : résultat d'un calcul des 2 précédents
- Catégorie (indispensable)
- Source de la demande => disponible dans les préfs. (automatique dans 90% des cas)
- Matériel concerné
- Demandeur (indispensable, je n'ai pas encore mis en prod ni importé tout mes users depuis LDAP mais la liste des users sera longue, un champ de saisie du user avec un petit coup d'ajax pour mettre a jour la liste et la restreindre serait bien pratique)
- Groupe demandeur
- Technicien (indispensable, un petit bouton 'assign to me' serait plus que pratique pour s'assigné un ticket.)
- Groupe
- Fournisseur
- Durée
- Suivi par email (pratique si l'utilisateur ne veut plus d'alerte mail)
- Email (avec ldap c'est recup auto alors c'est même plutot mal venu que l'utilisateur puisse la changer)
- Titre (indispensable)
- Description (indispensable)
- Document joint (bien utile)
- Suivi => dans la description, c'est le reflet des échanges avec l'utilisateur ?
- Tâche => uniquement en modification ? (surtout pour la planification)
- Solution => à la place du suivi autorisé en 0.72, permettant de résoudre le ticket dès la création

Voilà sinon globalement cela répond bien a mon besoin pour le moment, après quelques mois d'utilisation j'aurais surement d'autre remarque.

Une approche importante également si l'affichage des tickets est revu est que pour moi les informations primordiales d'un ticket sont le titre et la description. Ils sont un peu noyer dans le reste, je pense qu'une bonne chose serait de les faire mieux resortir.

;-)

coolhead · 2010-10-28 08:41:52

Un truc me pause problème (v0.78)

Nous ne pouvons pas ajouter un suivi et modifier des données du ticket en même temps (ticket clos par exemple, changemetn d'urgence, ...).

didilice · 2010-11-02 04:29:49

Bonjour,

Pour ma part j'utilise l'ensemble des champs.

Petite idée d'ajout : un nouveau champs pour saisir la référence ticket du fournisseur pourrait etre vraiment tres pratique.

Qu'en pensez vous?

SphynXz · 2010-11-18 10:27:06

Je me permet de copier/coller une idée que j'avais partagé sur la ML concernant un sujet sur l'interface de traitement d'un ticket.

==> Personnellement et en m'appuyant sur pas mal de demande client, le formulaire de création de ticket est celui que je refond le plus souvent. Très souvent parce qu'il est "trop compliqué/complet".

Et ce genre de remarque apparaît souvent dans le cadre d'une hotline qui n'est chargée que de transformer rapidement les appels en tickets.

A l'inverse d'autres demandes s'axent vers un formulaire a la mode itil...

Il faudrait peut-être envisager un formulaire sur deux étapes. Un peu comme les règles: un premier formulaire simple qui une fois renseigné laisse apparaitre tout le formulaire complet( ou non selon les droits).

Godiche · 2010-12-24 11:00:27

Bonjour,

je reviens sur ces deux points concernant l'ouverture de ticket

DaBoss wrote:

- Date : par défaut, heure système (date actuelle par défaut suffit, pas de raison à priori d'ouvrir un ticket a il y avait 3 jours)
- Date Echéance (pas encore implémenté dans la 0.78 mais je crois en prévision pour la 0.80, super utile pour nous afin de savoir comment planifier nos actions.)

Pour ma part la date d'échéance est une fonctionnalité que je recherche.
Par contre concernant la date (de début), il serait interessant de pouvoir la modifier dans le cas où une intervention ne pourrait se faire avant telle date.

coolhead · 2010-12-24 12:20:32

Autre grand problème pour la saisie des tickets.

Aujourd'hui lorsque nous voulons apporter un suivi mais aussi mettre à jour une donnée sur le ticket (Catégorie, Priorité, Intervenant, ... ) il nous faut faire deux étapes. Actualiser la fiche du ticket puis ajouter le suivi; ou inversement.

Pourquoi le bouton valider ne validerait pas tous les champs à l'écran en 1 seule fois ?

Forum GLPI-Project

Announcement

#1 2009-12-17 20:32:00

Saisie des tickets dans GLPI 0.80

#2 2009-12-17 20:38:02

Re: Saisie des tickets dans GLPI 0.80

#3 2009-12-17 21:07:39

Re: Saisie des tickets dans GLPI 0.80

#4 2009-12-17 23:37:18

Re: Saisie des tickets dans GLPI 0.80

#5 2009-12-30 15:19:23

Re: Saisie des tickets dans GLPI 0.80

#6 2009-12-30 17:02:46

Re: Saisie des tickets dans GLPI 0.80

#7 2010-02-15 17:33:30

Re: Saisie des tickets dans GLPI 0.80

#8 2010-02-15 17:52:53

Re: Saisie des tickets dans GLPI 0.80

#9 2010-02-19 19:28:52

Re: Saisie des tickets dans GLPI 0.80

#10 2010-02-24 09:25:02

Re: Saisie des tickets dans GLPI 0.80

#11 2010-03-29 21:39:56

Re: Saisie des tickets dans GLPI 0.80

#12 2010-04-06 14:31:50

Re: Saisie des tickets dans GLPI 0.80

#13 2010-04-06 14:47:54

Re: Saisie des tickets dans GLPI 0.80

#14 2010-04-06 14:56:48

Re: Saisie des tickets dans GLPI 0.80

#15 2010-04-09 18:52:44

Re: Saisie des tickets dans GLPI 0.80

#16 2010-04-09 19:38:03

Re: Saisie des tickets dans GLPI 0.80

#17 2010-04-19 16:35:09

Re: Saisie des tickets dans GLPI 0.80

#18 2010-06-08 14:37:51

Re: Saisie des tickets dans GLPI 0.80

#19 2010-09-20 10:52:59

Re: Saisie des tickets dans GLPI 0.80

#20 2010-10-27 23:24:41

Re: Saisie des tickets dans GLPI 0.80

#21 2010-10-28 08:41:52

Re: Saisie des tickets dans GLPI 0.80

#22 2010-11-02 04:29:49

Re: Saisie des tickets dans GLPI 0.80

#23 2010-11-18 10:27:06

Re: Saisie des tickets dans GLPI 0.80

#24 2010-12-24 11:00:27

Re: Saisie des tickets dans GLPI 0.80

#25 2010-12-24 12:20:32

Re: Saisie des tickets dans GLPI 0.80

Board footer