 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : Logiciel de Ticket Incident | |
| smael op | Bonjour Merci beaucoup pour les propositions. J'ai choisi GLPI mais le problème c'est que je n'ai pas pu personnaliser le formulaire des tickets. Merci |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| smael op | Bonjour Merci beaucoup pour les propositions. J'ai choisi GLPI mais le problème c'est que je n'ai pas pu personnaliser le formulaire des tickets. Merci |
| rufo | Ce que tu décrits, je le réalise par des plugins dans mon outil Astres. Ces plugins sont développés pour répondre à des besoins très spécifiques qui n'ont aucun intérêt à être implémentés dans le coeur du logiciel (ex : corrélation des infos relatives à des matériels entre une BD de GMAO et une BD d'un autre industriel).
J'ai aussi implémenté un système de champs personnalisés qui peuvent s'ajouter par configuration en fonction du type de demande (différent types de tickets), du projet concerné (ex: des logiciels, des plates-formes, des systèmes...) et du niveau de la demande (N0, N1, N2...). Ces champs peuvent apparaître dès la création du ticket ou uniquement à partir du moment où le ticket existe. On peut aussi paramétrer certains champs personnalisés pour qu'ils apparaissent dans le moteur de recherche et servir à filtrer les tickets. Ces champs peuvent être de type texte 1 ligne ou bloc de texte, un entier, un nb à virgule, une date, une liste à sélection unique ou à sélection multiple avec la liste de valeurs fixe ou provenant d'une table de la BD : dans ce cas, on indique la table (une de l'appli ou une nouvelle table), le champ servant à prendre la valeur, le champ à afficher dans la liste et le champ servant à ordonner les valeurs. Je me suis inspiré du système de l'outil Mantis et l'ai amélioré. :) C'est très pratique pour gérer des champs métier, trop spécifiques pour être implémentés nativement (oui, je travaille dans un contexte de helpdesk très particulier qui va de la gestion de fréquence ou de leur protection en passant par du suivi de métrologie ou d'incidents de systèmes de communication, donc rien à voir avec de l'IT). |
| akizan | Pendant qu'on y est, une fonctionnalité que j'aimerai bien voir, c'est que pour chaque catégorie d'incident, il y' ai une liste complète des informations à remplir car pertinent. Chaque catégorie aurait ainsi ces propres données liées au type d'incident. Nous n'avons pas ça non plus dans EasyVista mais ça me parait hyper important afin de "ne pas omettre" une information ou le résultat d'un test à effectuer. |
| akizan | La fonctionnalité que décrit Rufo est également très intéressante. Dans EasyVista, la recherche d'incidents similaires est orientée sur 2 principes : les mots clés (donc de la merde) ou l'attachement des incidents à un même problème (mais qu'on utilise pas car incapable en interne de se coordonner). Du coup, un outil "intelligent" qui arrive à donner des résultats pertinents, c'est effectivement une fonctionnalité très chouette. |
| rufo | Petite question : j'ai l'impression que peu d'outils de helpdesk possèdent un outil d'analyse sémantique qui propose au résolveur des tickets similaires, identiques ou corrélés permettant ainsi de faire soit des liens entre des tickets non identifiés jusqu'à présent, soit de récupérer la solution déjà mise en place dans un ticket déjà traité.
Attention, je parle pas d'une fonction qui se base juste sur des mots-clés de la description du ticket... Perso, je l'ai implémenté dans mon outil Astres (peu connu malheureusement). Plusieurs fois, ça m'a permis de fournir à nos industriels des pistes d'analyse parce que mon outil avait ressorti une référence d'un ancien ticket (souvent, une régression suite au déploiement d'une nouvelle version). En plus, quand des logiciels partagent des même briques logicielles, ça peut être pas mal d'avoir des liens entre des tickets concernant des logiciels différents. ;) |
| nebulios |
|
| akizan | Merci pour les explications bien complètes. Ca semble très chouette (après si on devait trouver un défaut, peut être qu'au niveau écologie, c'est pas parfait si tout est par email...) mais je suis quand même content de voir le principe du bouzin !! Merci Merci !
C'est en effet et j'en suis persuadé, une des fonctionnalités les plus importantes d'un outil de ticketing que tu décris la. |
| cotorep | zendesk |
| HPIR40 | Peut être https://glpi-project.org/DOC/FR/glp [...] ector.html Mais dans le serveur GLPI que j'avais récupéré (c'était le précedent admin qui l'avait configuré), ce n'était pas présent l'époque. Donc je n'ai jamais testé les collecteurs dans GLPI. |
| Saguu | Dans GLPI les collecteurs ne font pas le même job ? |
| HPIR40 | De base il n'y a rien, sauf un mail, que tu peux personnaliser , pour dire que le ticket a bien été reçu et créé. Le formatage est 100% ouvert et libre. Au sein de la boite j'ai mis à dispo un mail pré rempli type avec les differentes infos à donner et qui sont indispensables L'utilisateur fait un copier coller du mail, donne les infos demandées, joint une capture d'écran si besoin est et hop envoi le mail. L'utilisateur ne respecte pas le pré formatage? pas de soucis, tu lui envoi une reponse préformatée que tu a enregistré dans le système (ca prend 5 secondes), et il reçoit son mail, mais surtout c'est enregistré en dur dans l'appli. Comme cela tu garde une trace des emmerdeurs qui ne font pas les choses comme il faut (et surtout qui sont les premiers à raler car tu ne va pas assez vite pour résoudre leur problème). Le système m'informe par mail de l'arrivé du ticket avec le contenu, donc je suis au courant, je regle le soucis ou je vais sur la plateforme pour demander un complement d'info etc... et tout ce régle par mail. Tu peux toi même catégoriser les tickets à volonté (donc fini le user qui se trompe de rubrique). Tout est paramétrable, comme une reponse automatique pour dire que le soucis est résolu, on peut même créer des consultants des tickets mais qui ne pourront pas agir dessus (lecture seule) pour un service qualité par exemple. Tu peux même sortir des statistiques (intégré dans le systéme) sur la durée de resolution des tickets, sur le nombre de tickets par catégorie, sur les #!@! dont j'ai parlé avant car tu aura créé une catégorie qui leur est dédiée, etc... (Un vrai mouchard !!) Bref, avant on utilisait GLPI mais: il fallait se connecter à la plateforme Là maintenant tout passe par les mails; c'est 1000 fois plus facile à utiliser, moins contraignant, c'est plus rapide tout compte fait et tout le monde en est content. Je suis certain qu'il y a pleins de fonctionnalités semi cachées ou que je n'exploite pas, mais franchement, à mon avis, c'est le système parfait pour gérer des tickets sans prise de tête. Seul inconvenient: il faut une adresse email 100% dédiée. |
| akizan | j'avoue HPIR40 que cette fonctionnalité fait rêver.
Par curiosité, comment fonctionne elle ? est-ce que l'email en lui même est construit comme un formulaire afin d"avoir un squelette des champs insérable dans l'outil de ticketing ou bien il y'a une IA ou un truc un peu plus intelligent on va dire qui fait son découpage par rapport au contenu du mail ? (en espérant avoir été compréhensible :p ) |
| HPIR40 | J'utilise OTRS (en opensource bien sur) depuis 4 ans et franchement je ne reviendrais pas en arrière.
Gros avantage, ce qui m'a fait choisir ce logiciel à l'époque, un simple mail à une boite email dédiée suffit à créer un ticket. |
| Je@nb | vachement dur de faire une recherche google ...
https://fr.wikipedia.org/wiki/Logic [...] assistance |
| smael op | Bonjour, Je voudrais savoir si quelqu'un connait un logiciel de gestion de Ticket d'Incident (opensource)? Merci |
