RT est en effet un outil très pratique et bien pensé pour tout pôle de support d'une entreprise.
Pour préciser un peu son fonctionnement, le ticket, qui matérialise la demande et son processus de traitement/résolution, est déclenché soit par la création d'une telle demande via l'interface web, soit directement par un interlocuteur envoyant un mail à une adresse spécifique : RT contient un module de passerelle mail qui ouvre le ticket lors de la réception du mail.
A partir du tikcet créé, on peut lui assigner un statut pour suivre son état (nouveau, ouvert/en cours de traitement, résolu, bloqué), un intervenant unique, ainsi que des champs personnalisés (nom du client, plateforme par exemple) définissables à volonté. Lorsque le demandeur envoie le mail à l'adresse qu'on lui a indiquée, RT lui envoie un accusé de réception, certifiant que la demande est en cours de traitement, avec un login/mot de passe permettant de suivre l'évolution de tous ses tickets.
Il est possible de gérer plusieurs types de support, ou de classer les demandes en queues, ayant chacune leur adresse mail (ainsi on peut séparer les demandes, par exemple, de support, d'incident, de renseignement etc...).
Contrairement à ce que tu dis dans ton pdf, je ne trouve pas l'interface de recherche difficle à appendre même pour un non informaticien, puisque cette recherche se fait en fonction de critères du ticket (demandeur, date d'ouverture, statut, intervenant, sujet... , et il n'y a pas à maîtriser la moindre notion informatique ou de sql.
On est d'accord sur ce qui concerne l'interface web : assez colossalement laide, elle paraît vieillote. La css a elle seule ne permet pas de tout modifier, j'ai du pour ma part ajouter des styles dans le code là ou certaines choses étaient codées en dur.
Quelques scripts et modules permettent de compléter RT : entre autre le modules Statistics, qui permet de voir sur une période de temps le nombre de demandes reçues, traitées, le temps de résolution, avec des graphiques ; le module RTFM, qui permet d'écrire et gérer une base documentaire d'articles.
Un autre bon point : la migration d'une version de RT vers une nouvelle est simple grace aux scripts SQL fournis, qui permettent de garder l'ancienne base de données en l'adaptant comme il faut.
L'installation de l'outil n'est pas difficile à mon avis perso, elle est surtout un peu longue, il y a une tonne de modules perl à installer, mais RT propose un script qui tente de le faire tout seul. Dans tous les cas, les modules manquants sont présents sur le CPAN Perl. A noter : l'installation est bien plus smple et rapide sur une Debian (il existe même des paquets) que sur une redhat 9.0....
Voilà, si il y a des questions je tenterai d'y répondre avec plaisir (tout comme l'auteur de ce journal je pense!).
Et ton interface Ajax, c'est juste un projet ou c'est en cours? Ca sera dispo un jour en GPL? ;-)
# mon avis
Posté par Matthieu . En réponse au journal Retour d'expérience sur la personnalisation du logiciel libre de gestion d'incident « Request Tracker ». Évalué à 4.
Pour préciser un peu son fonctionnement, le ticket, qui matérialise la demande et son processus de traitement/résolution, est déclenché soit par la création d'une telle demande via l'interface web, soit directement par un interlocuteur envoyant un mail à une adresse spécifique : RT contient un module de passerelle mail qui ouvre le ticket lors de la réception du mail.
A partir du tikcet créé, on peut lui assigner un statut pour suivre son état (nouveau, ouvert/en cours de traitement, résolu, bloqué), un intervenant unique, ainsi que des champs personnalisés (nom du client, plateforme par exemple) définissables à volonté. Lorsque le demandeur envoie le mail à l'adresse qu'on lui a indiquée, RT lui envoie un accusé de réception, certifiant que la demande est en cours de traitement, avec un login/mot de passe permettant de suivre l'évolution de tous ses tickets.
Il est possible de gérer plusieurs types de support, ou de classer les demandes en queues, ayant chacune leur adresse mail (ainsi on peut séparer les demandes, par exemple, de support, d'incident, de renseignement etc...).
Contrairement à ce que tu dis dans ton pdf, je ne trouve pas l'interface de recherche difficle à appendre même pour un non informaticien, puisque cette recherche se fait en fonction de critères du ticket (demandeur, date d'ouverture, statut, intervenant, sujet... , et il n'y a pas à maîtriser la moindre notion informatique ou de sql.
On est d'accord sur ce qui concerne l'interface web : assez colossalement laide, elle paraît vieillote. La css a elle seule ne permet pas de tout modifier, j'ai du pour ma part ajouter des styles dans le code là ou certaines choses étaient codées en dur.
Quelques scripts et modules permettent de compléter RT : entre autre le modules Statistics, qui permet de voir sur une période de temps le nombre de demandes reçues, traitées, le temps de résolution, avec des graphiques ; le module RTFM, qui permet d'écrire et gérer une base documentaire d'articles.
Un autre bon point : la migration d'une version de RT vers une nouvelle est simple grace aux scripts SQL fournis, qui permettent de garder l'ancienne base de données en l'adaptant comme il faut.
L'installation de l'outil n'est pas difficile à mon avis perso, elle est surtout un peu longue, il y a une tonne de modules perl à installer, mais RT propose un script qui tente de le faire tout seul. Dans tous les cas, les modules manquants sont présents sur le CPAN Perl. A noter : l'installation est bien plus smple et rapide sur une Debian (il existe même des paquets) que sur une redhat 9.0....
Voilà, si il y a des questions je tenterai d'y répondre avec plaisir (tout comme l'auteur de ce journal je pense!).
Et ton interface Ajax, c'est juste un projet ou c'est en cours? Ca sera dispo un jour en GPL? ;-)