Finalmente dopo anni siamo riusciti a cestinare quell’obrobrio che usavamo per gestire i ticket di assistenza del reparto IT (ok chiamarlo così è un eufemismo).
Cercando sul web anni fa trovai RT che sembrava fare al caso nostro perché:
- è open source
- è altamente personalizzabile
- non è molto specializzato e quindi utilizzabile anche per altri reparti
Il software è scritto in Perl , ma tranne per il file di configurazione non c’è bisogno di mettere mano ai sorgenti.
L’iterazione può avvenire sia via interfaccia web che tramite , ad esempio il ticket può essere aperto via mail e ogni risposta alla mail ricevuta come notifica verrà aggiunta in automatico al ticket.
La parte più complicata , non tanto tecnicamente , ma per quanto riguarda l’organizzazione è la configurazione dei ruoli e delle code.
Il concetto di coda è molto valido in quanto ad ogni coda può corrispondere un indirizzo mail diverso ad esempio una mail di richiesta inviata a supportoit@azienda.com aprirà un ticket nella coda IT mentre una richiesta inviata a portamiunabirra@azienda.com creerà un ticket nella coda Oktoberfest e ben presto una procace bionda vi servirà un birra (se trovate un azienda che fa questo servizio fatemelo sapere! 
).
Oltre ai permessi per gruppo , si possono anche creare permessi per ruolo (tipo incaricato del ticket, richiedente ed osservatore), che possono essere impostati a livello globale o diversificati per singola coda. Potente vero?
Per i ticket e per gli utenti è possibile aggiungere dei campi personalizzati sui quali è possibile impostare permessi anche a livello di coda. Ad esempio un ticket che deve essere seguito dal reparto reti avrà bisogno di informazioni che non interessano al reparto sviluppo e viceversa.
RT fornisce anche un ottimo strumento di ricerca e reportistica per i ticket , queste ricerche possono diventare grafici, feed RSS oppure salvate ed inserite nelle dashboard.
L’ultima grande funzionalità è quella degli scrip (si chiamano così) , che intercettano vari eventi (ad esempio apertura di un ticket, risposta , presa in carico , ecc. ecc.) e che possono eseguire varie azioni come l’invio di notifiche o modifiche al ticket stesso. Se ne trovano già di pronti , ma nulla vieta di aggiungerne altri.
Il vantaggio di questo software è quindi l’estrema duttilità , che ovviamente si paga con una maggiore complicazione in fase di installazione e configurazione e leggermente nell’utilizzo specialmente quando avete colleghi che dovrebbero essere esperti informatici, ma non sono in grado di leggere quello che c’è scritto a schermo o di cercare di capire qualcosa.
Ps. Chi legge questo blog sa che non faccio il sistemista e si chiederà se ho venduto l’anima al cacciavite, in realtà per questa volta ho fatto uno strappo alla regola, visto che tra le ciofeche scelte come successore del ticket c’era anche l’idea di svilupparlo con ScialaquaPoint (aka sharepoint) , ovviamente dal nostro caro sistemista terrorista. Per fortuna che io ed un mio collega abbiamo evitato il peggio, installando un server Linux ed RT rispettando , per la prima volta nel nostro ufficio, i tempi che c’eravamo dati. Ovviamente questo era il secondo tentativo, il primo era stato abortito per il solito “progetto inutile e mal gestito”.
