You are not logged in.
Bonjour,
La liste me semble très bien.
Si GLPI va vers ITIL, il serait bien de créer une "table/base des erreurs connues" et donc permettre de relier un ticket vers une erreur connue et un peu dans le même esprit gérer une "base/table des problèmes" et de relier un ticket à un problème.
Sinon c'est bien.
Une question qui parfois revient, c'est de pouvoir dupliquer un ticket, notamment quand on a une multitudes d'appels concernant un incident particulier.
De plus, la possibilité d'afficher ou non les champs pour l'utilisateur post-only afin de customiser la saisie des non techniciens.
J'ai helpé i
Offline
Une question qui parfois revient, c'est de pouvoir dupliquer un ticket, notamment quand on a une multitudes d'appels concernant un incident particulier.
Quel intérêt vois tu à dupliquer les tickets si plusieurs appel pour un même incident...?
Habituellement on cherche surtout à fusionner les tickets relevant d'un incident commun.
Mieux vaut se taire et passer pour un impécile, que de l'ouvrir et ne laisser aucun doute à ce sujet.
Offline
Créer un ticket par appel sert tout simplement à comptabiliser. Comptabiliser sert à évaluer l'ampleur de l'incident.
Pour revenir aux champs que l'on pourrait rajouter à la saisie d'un ticket, il y a un notion que j'utilise qui est de savoir si le ticket a été résolu sur site (déplacement d'un technicien) ou bien à distance (par prise en main du poste).
J'ai helpé i
Offline
Bonjour à tous, et merci pour votre excellent travail.
Voici ce qui me parait essentiel pour la saisie d'un ticket :
En gras le nom du champ a renseigner
En gras italique le champ qui se rempli de façon implicite
- 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
- Technicien
- Groupe : affecté en fonction du technicien
- Durée
- Suivi par email => Oui par défaut
- Email
- Titre
- Description
- Document joint
GLPI 0.78.1 / PHP 5 / MYSQL 5.0.51
Linux version 2.6.24-24-server UBUNTU 8.04.3 LTS
Offline
Juste un mot pour revenir au statut résolu sur site ou à distance.
C'est un notion importante, pour un service support qui est amené à se déplacer, car moins on déplace plus on est efficace.
On résout les appels plus vites, et souvent en premier niveau, c'est un indicateur (KPI) très intéressant en terme de stats.
Je pense que ce statut peut être intégré aux statuts existants sans créer de champs supplémentaires.
Par contre il faut en tenir compte dans le statut Fermés qui doit reprendre la somme des 2 statuts.
J'ai helpé i
Offline
Je reporte mon message ici comme suggéré par MoYo:
Hello,
Je trouve qu'il y a deux éléments qui ne sert à rien lors de l'ouverture d'un ticket:
- Statut: "Clos" et "Résolu"
- Durée totaleSi l'on suit une démarche ITIL comme vous le souhaitez depuis la version 0.78, ces éléments cassent tout.
En fait, on ne peut clore ou résoudre un ticket directement depuis la 0.78.
Si l'on veut clore un ticket, il y a au moins un suivi, une action ou une solution à indiquer. On ne peut clore un ticket avec seulement une description. Ce n'est pas une démarche propre. Avec la 0.72 on pouvait rajouter un suivi donc c'était légitime. Mais là...Concernant la durée totale, je ne vois pas ce qu'elle fait à l'ouverture du ticket. Je ne suis pas sûr mais il me semble qu'avec les versions antérieures à 0.78, c'est le temps estimé que l'on pouvait mettre (je crois... vous me direz si je me trompe). Dans ce cas, d'accord.
Mais dans la version actuelle, le fait de mettre un temps, ajoute une action avec le temps donné et une description vide.
Donc à moins d'être devin et de ne pas avoir besoin d'une description dans le ticket...
Offline
Bonjour,
Je remonte le point ci-dessous que j'avais évoqué il y a fort longtemps concernant la "Matrice de calcul de la priorité".
Est-il envisagé quelque chose de ce genre ?
Merci
Ben
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
Offline
Le topic ne doit plus être suivi... jamais de réponse...
Offline
Désolé du déterrage de topic mais j'ai une question.
Je cherchais un peu partout sur le net une sorte de guide qui expliquerait les différents champs dans la saisie des tickets car nous utilisons GLPI mais lors de la saisie d'un ticket on a l'impression d'avoir une redondance par exemple avec Urgence/Impact/Priorité.
Pouvez vous svp me donner une description de chaque champs pour une meilleur saisie d'un ticket ?
Bonne journée à vous
Offline
Lire la doc !
https://forge.indepnet.net/attachments/ … 0.80.1.pdf
Prod. : CentOS 6.5 - PHP 5.3.3 - Apache 2.2.15 - MySQL 5.1.73 - OCS 2.1.2 - GLPI 0.84.6
Dev. : CentOS 7 - PHP 5.4.16 - Apache 2.4.6 - MariaDB 5.5.50 - OCS 2.3 - GLPI 9.1.2 + OPcache 7.0.5FE + APCu 4.0.11
Offline
Bonjour,
Nous utilisons GLPI au quotidien pour la gestion de plusieurs entités. Les évolutions qu'apportent la version 0.80.3 et celles annoncées pour la 0.83 sont très intéressantes.
Nous avons cependant une interrogation concernant les taches des tickets.
Est il envisageable de pouvoir, à l'avenir, déplacer une tâche d'un ticket à un autre ?
Pourquoi ? : Pour permettre de clôturer une demande comportant des taches reportées et de les déplacer sur une autre demande. Ou encore en fin d'exercice de façon à arrêter les comptes et les compteurs sur un contrat, ou encore, dans le cadre de certains plugins (manageentities par exemple) pouvoir attribuer une tache à une autre demande et donc à un autre contrat.
Merci de votre réponse.
Bien à vous et bonne continuation à cet outils
Cordialement
Centos 6.3 - Apache 2.2.15 Php 5.3.3 Mysql 5.1.61 - OCS 2.0.2 - GLPI 75 entités
Prod GLPI 0.83.7 Plugins : Comptes, domaines, Portail entité, Architecture réseau
Recette centos 6.3 GLPI 0.83.7 Plugins : Portail Entités, Comptes, Domaines, Architecture reseau
Test CentOS 6.4 - Apache 2.2.15 Php 5.5.1 Mysql 5.5.31 (En attente disponibilite des plugins pour test > 0.84)
Offline