Sie sind auf der Suche nach einem Ticketsystem für Ihr Unternehmen, um Kundenanfragen zu beantworten? Dann sind Sie hier genau richtig! In unserer Artikelreihe stellen wir Ihnen vier Helpdesk-Systeme vor und zeigen ihre Vor- und Nachteile. Nach Zammad beschäftigen wir uns im zweiten Teil mit Request Tracker.
Request Tracker (gerne als RT abgekürzt) ist ein alter Hase unter den Open Source Helpdesk-Systemen. Seit 1996 wird die in Perl programmierte Lösung von der Firma Best Practical Solutions LLC entwickelt. Große Top-100-Unternehmen wie NASA, Nike oder Merrill Lynch setzen auf das freie Ticketsystem. In Deutschland ist RT besonders im Support-Bereich bei Hostern und Softwareherstellern beliebt.
Aufwendige Installation
Die aktuelle Version 4.4 von 2016 setzt die neuesten Versionen vieler Perl-Module voraus. Weil diese selbst wieder bestimmte Releases anderer Perl-Komponenten benötigen, ist es nötig, alle erforderlichen Module vom CPAN zu laden und zu kompilieren. Aber selbst dann erfasst die Installation nicht alle Abhängigkeiten, obwohl der Installer einen Erfolg meldet. Um die fehlenden Pakete herauszufinden und per Hand einzubinden, ist einiges Wissen über die Konfiguration des Webservers notwendig. Inklusive der Google-Recherchen sind damit mehrere Stunden erforderlich, um Request Tracker zum Laufen zu bringen.
Schlüsselfeature: Verschlüsselung
Im Gegensatz zu anderen Ticketsystemen bietet RT eine nahtlose Integration von PGP. Durch die PGP-Unterstützung können Anwender sowohl eingehende als auch ausgehende E-Mails ver- und entschlüsseln sowie überprüfen und signieren.
Das geht sogar soweit, dass RequestTracker allen RT-Anwendern ebenfalls verschlüsselte Mails schicken kann, d.h. wenn eine verschlüsselte Mail im System eingeht und diese an bestimmte User weitergeleitet werden soll, entschlüsselt RT die Nachricht und schickt sie dann an die entsprechenden Anwender – verschlüsselt mit deren jeweiligen Keys. Und es besteht sogar die Möglichkeit, dass Request Tracker von RT-Usern Antworten und Kommentare per Mail entgegen nimmt, denn bei einer korrekt signierten (und optional verschlüsselten) Mail kann sich das System sicher sein, dass die Mail vom jeweiligen User kommt und nicht von jemand anderem.
Allerdings gibt es bei dem Verschlüsselungsfeature einen kleinen Stolperstein: Request Tracker kann PGP-Inline oder PGP/MIME. Je nachdem, was der Anwender in RT konfiguriert, gibt es Probleme mit dem jeweils anderen Format.
Automatisierung durch Scrips
Ein Feature, das RT besonders interessant macht, sind die so genannten Scrips (kein Tippfehler!). Sie ordnen den Ereignissen im Ticketsystem eine bestimmte Abfolge von Aktionen zu. Das Funktionsspektrum reicht vom automatischen Versenden von Mails bis zur Abbildung von Workflows. Ein neues Scrip klickt sich der RT-Benutzer in der Weboberfläche zusammen. Scrips selbst bestehen aus gewöhnlichem Perl-Code und bieten Zugriff auf die gesamte RT-API.
Differenzierte Rechtevergabe
Request Tracker bietet viele Konfigurationsmöglichkeiten, zum Beispiel eine differenzierte Rechtevergabe für die Benutzer. Der Zugriff lässt sich für Queues und Problemkategorien getrennt regeln. Gruppen fassen mehrere Benutzer zusammen. Auch Benutzergruppen können selbst wieder Mitglieder anderer Gruppen sein, sodass sich eine hierarchische Berechtigungsstruktur darstellen lässt. Das birgt allerdings die Gefahr, dass sich Definitionen widersprechen.
Überblick bei vielen Tickets
Alle ernst zu nehmenden Ticketsysteme enthalten eine Suchfunktion, doch nur wenige bieten dem Anwender so viele Möglichkeiten wie Request Tracker, um unter vielen Tickets den Überblick zu behalten. Nach der Anmeldung gelangt der Benutzer auf die Seite “RT at a glance” und findet dort je nach Einstellung die zehn “Anfragen” (Tickets) mit der höchsten Priorität oder die zehn neuesten Anfragen.
RT bietet auch die Möglichkeit, Tickets zu vereinigen (Merge). Aber Achtung! Dieser Schritt lässt sich über das Webinterface nicht mehr rückgängig machen, sondern nur noch durch direkte Manipulation der SQL-Datenbank.
Bewertung: Solider Oldie, der ein wenig aus der Zeit gefallen ist
Die Bedienung von Request Tracker ist zwar nicht schwierig, aber auch nicht ausgesprochen intuitiv. In vielen Fällen liegt dies nur an der deutschen Übersetzung: Manchmal wurden gängige Fachausdrücke unnötigerweise verdeutscht, andere Elemente hingegen schlicht übersehen.
Viele der früher innovativen Features von RT sind heute eine Selbstverständlichkeit, z.B. die Zuweisung an unterschiedliche Bearbeiter, die Identifikation eingehender E-Mails oder das Berichten über Ereignisse per Mail, etwa das Abschließen einer Anfrage. Request Tracker bietet solide Funktionalitäten, aber keine innovative Konzepte wie z.B. die Einbindung von Social Media-Kanälen bei Zammad.
Wenn der Anwender Tickets als gelöscht markiert (bzw. auf den Status »gelöscht« setzt), bleiben sie trotzdem in der Datenbank, sie sind nur über die normalen Suchfunktionen nicht mehr auffindbar. Der Grund dafür ist in erster Linie, dass die Datenbankstruktur von RT kein einfaches Löschen von Tickets aus der Datenbank erlaubt. Damit wächst die Größe der Datenbank kontinuierlich und bestimmte Operationen (z.B. Volltextsuche) werden immer schwerfälliger.
Einige Benutzer mögen Open Source-Programmen solche Schönheitsfehler vielleicht verzeihen, im Fall von Request Tracker stellt sich aber dann doch die Frage, ob die Software noch als „Enterprise Grade“ bezeichnet werden kann.
Die Vorteile von RT auf einen Blick:
- Enterprise-ready (z.B. Kuehne & Nagel Logistik, 20.000-70.000 Tickets/Tag)
- Weitgehend übersichtlich gestaltete Oberfläche
- PGP-Unterstützung
- Mehrere hundert verfügbare Erweiterungen
Die Nachteile:
- Hürdenreiche und zeitaufwändige Installation
- Stark US-fokussiert, z.B. nur ein Training außerhalb der USA
- Lange Entwicklungszyklen
Alle Artikel der Serie:
