© Roman Milert, 123RF.com

So genannte Trouble-Ticket-Systeme helfen dabei, die Anfragen von Kunden schnell und effizient zu beantworten. Die ausgereiften Open-Source-Lösungen Request Tracker und OTRS unterstützen beim professionellen Service und sind bei großen und kleinen Unternehmen im Einsatz.

Quillt das Postfach im Unternehmen vor Kundenbeschwerden und Anfragen über, wird es Zeit für ein Trouble-Ticket-System, auch als Help-Desk- oder Issue-Tracking-System bezeichnet. Es nimmt E-Mails entgegen, leitet sie an einen passenden Support-Mitarbeiter beziehungsweise (Service-)Techniker weiter, sorgt für eine fristgerechte Abwicklung und stellt obendrein sicher, dass keine Kundenanfrage verloren geht.

Kostenlose Trouble-Ticket-Systeme haben in den letzten Jahren eine erstaunlich hohe Qualität und Stabilität erreicht. Nicht zuletzt, weil viele Open-Source-Projekte solche Software selbst einsetzen. Daneben gibt es Anwender in namhaften Unternehmen und Organisationen.

Für den Mittelstand besonders interessant sind Request Tracker (RT, [1]) und OTRS [2]. Sie sind für den Einsatz beim Kundensupport optimiert, haben sich in der Praxis bereits tausendfach bewährt, fühlen sich in fast allen Branchen wohl und lassen sich recht einfach in bestehende Unternehmensstrukturen integrieren. Die Bedienung erfolgt komfortabel über eine fast selbsterklärende Weboberfläche, die jeder (Support-)Mitarbeiter schnell über seinen Browser erreicht. Wem der Funktionsumfang nicht ausreicht, der rüstet die Systeme über Erweiterungen auf.

Von der Mail zum Ticket

Request Tracker und OTRS arbeiten ähnlich: Zunächst verschnüren sie jede eingehende E-Mail mit ein paar Meta-Informationen und einer Vorgangsnummer zu einem Ticket, das anschließend in einer Queue (Warteschlange) auf seine Beantwortung wartet. Jedes Ticket besitzt einen eindeutigen Bearbeitungsstatus, beispielsweise gelten noch nicht bearbeitete Tickets als “offen”, erledigte als “geschlossen”.

Sobald eine neue Anfrage beziehungsweise E-Mail eingeht, verschickt das System automatisch eine Bestätigungs-E-Mail, die auf vorgefertigten Textbausteinen (Templates) basiert. Ein- und ausgehende E-Mails lassen sich mit PGP verschlüsseln und signieren. Einem Ticket darf der Bearbeiter Kommentare anheften, die nur für seine Support-Kollegen sichtbar sind, etwa “Der Kunde spricht nur von Entsafter, meint aber unseren Multientsafter 3000”.

Servicelevel sicherstellen

Jedes Ticket besitzt eine Priorität, die seine Dringlichkeit widerspiegelt. Zusätzlich kann der Anwender die maximal für die Bearbeitung erlaubte Zeit sowie ein Fälligkeitsdatum vorgeben. Auf diese Weise stellt er mit dem Kunden vereinbarte Reaktionszeiten (Service Level Agreements) sicher. Ergänzend bieten sowohl Request Tracker als auch OTRS automatisierte Eskalationsmechanismen, die in der Regel auf einer Art Zeitschaltuhr basieren: Liegt ein Ticket zu lange unbearbeitet herum oder erreicht es sein festgelegtes Fälligkeitsdatum, leitet das System für diesen Fall festgelegte Maßnahmen ein – in Regel alarmiert es einen Vorgesetzten.

In beiden Systemen kann ein Ticket in Beziehung zu anderen Tickets stehen. Ein solches Ticket lässt sich nur dann lösen, wenn auch das beziehungsweise die anderen gelöst sind. Darüber hinaus kann man ähnliche Tickets zu einem einzigen zusammenführen, beispielsweise wenn der Kunde gleich mehrere Anfragen gestellt hat. OTRS erlaubt andererseits sogar das Aufspalten von Tickets.

Die Benutzeroberflächen von RT und OTRS sprechen mehrere Sprachen, darunter durchwachsen bis fließend Deutsch. Ein Wechsel zwischen den Systemen ist für das Personal dennoch nicht ganz einfach, da die Übersetzer die englischen Begriffe unterschiedlich und teilweise sogar inkonsistent ins Deutsche übertragen. So heißen die Queues beim Request Tracker »Bereiche« , die Tickets teilweise »Anfragen« .

Für jeden Benutzer lassen sich kleinteilig die Zugriffsrechte auf Tickets und Queues festlegen, mehrere Benutzer mit ähnlichen Rechten bündelt man in Gruppen. Die Bedienoberflächen fassen für jeden Benutzer die wichtigsten Informationen, etwa die dringlichsten offenen Tickets, übersichtlich auf einer einzigen Seite zusammen. Welche Informationen auf diesem so genannten Dashboard zu sehen sind, muss der Anwender beim Request Tracker mühsam aus Listen zusammenklicken, OTRS arbeitet hier etwas komfortabler per Drag&Drop.

Viele Augen

An einem Ticket sind mitunter verschiedene Personen interessiert. Neben dem ursprünglich anfragenden Kunden und dem zuständigen Mitarbeiter kann man noch weitere Personen und Administratoren als Beobachter festlegen. Sie erhalten dann lesenden Zugriff auf das Ticket oder bekommen automatisch eine Kopie der Korrespondenz zugestellt.

Suchanfragen kann der Benutzer in beiden Systemen bequem zusammenklicken und speichern (Abbildung 1). Über Massen-Updates (in RT »Bulk Updates« , bei OTRS »Bulk Features« genannt) lassen sich rasch mehrere Tickets auf einmal beantworten. Gibt es beispielsweise einen Serienfehler im Produkt Multientsafter, kann der Hersteller alle Betroffenen mit zwei Mausklicks informieren.

Abbildung 1: Suchanfragen lassen sich in Request Tracker bequem zusammenklicken und als Vorlage speichern. OTRS bietet zu diesem Zweck sogar eine Oberfläche mit Drag&Drop.

Um die Konsistenz zu wahren, lassen sich Änderungen in beiden Systemen nicht mehr rückgängig machen, was mit einem Ticket passiert, geschieht unwiderruflich. Einmal angelegte Nutzer lassen sich wie Queues nur noch deaktivieren, Tickets als »gelöscht« markieren.

Zu den beliebtesten Erweiterungen zählen die FAQ-Manager, die häufige Fragen und ihre Lösung in einer Datenbank sammeln und den Supportmitarbeitern bereitstellen. Beim Request Tracker heißt das entsprechende Modul RT FAQ Manager, kurz RTFM, beim Konkurrenten OTRS FAQ. Beide Erweiterungen stammen zwar direkt von den Entwicklern der Trouble-Ticket-Systeme, gehören aber erstaunlicherweise nicht zu deren Standard-Lieferumfang.

Request Tracker

Request Tracker, meist mit RT abgekürzt, gehört zu den ältesten freien Trouble-Ticket-Systemen auf dem Markt. Der Systementwickler Jesse Vincent veröffentlichte die erste Version bereits in den 90er Jahren, heute betreut sein Unternehmen Best Practical Solutions die Weiterentwicklung. Dort erhält man auch kostenpflichtigen Support und Schulungen. Darüber hinaus programmiert Best Practical Solutions im Auftrag maßgeschneiderte Software und hostet RT-Installationen für Kunden. Zu den Nutzern der unter GPLv2 lizenzierten Software gehören unter anderem Nike, Nasa, Verisign und zahlreiche Universitäten.

Request Tracker ist in Perl geschrieben, seine Daten landen wahlweise in einer MySQL-, PostgreSQL- oder Oracle-Datenbank (siehe Kasten “Systemvoraussetzungen für RT”). Daneben sind ein Webserver sowie viele weitere Perl-Module erforderlich, die wiederum von anderen Perl-Modulen abhängen. Diese einzelnen Komponenten muss der Admin durchweg per Hand installieren und für den Einsatz mit Request Tracker vorbereiten. Am einfachsten geht es noch unter Ubuntu Linux: Dort installiert er das RT-Paket über den Paketmanager, nickt ein paar Fragen ab und kopiert eine Apache-Konfigurationsdatei an die richtige Stelle.

Angestaubte Doku

Die Dokumentation beschränkt sich auf das englischsprachige und leicht veraltete Buch “RT Essentials” aus dem O’Reilly-Verlag [3] sowie ein kostenlos nutzbares Wiki. Letzteres ist ziemlich unübersichtlich aufgebaut, lückenhaft und ebenfalls teilweise veraltet. Best Practical Solutions setzt hier vollständig auf das Engagement der Nutzergemeinschaft, weitere Hilfen gibt es nur gegen Geld.

Die hürdenreiche Installation steht im krassen Gegensatz zu der einfach bedienbaren, aufgeräumten Oberfläche, die derzeit in 15 Sprachen übersetzt ist (Abbildung  2). Abhängig von der am linken Rand ausgewählten Hauptrubrik erscheinen in der kleinen und unscheinbaren waagerechten Leiste am oberen Rand weitere Optionen.

Abbildung 2: Die RT-Startseite fasst alle für den Support-Mitarbeiter wichtigen Informationen zusammen.

Zusätzlich zur Startseite »RT auf einen Blick« darf jeder Benutzer weitere Übersichtsseiten anlegen, die so genannten Anzeigetafeln. Administratoren können solche Seiten auch für alle Nutzer oder eine Gruppe erstellen beziehungsweise vorgeben. Auf diese Weise lässt sich etwa eine maßgeschneiderte Übersicht für die Entwicklungsabteilung des Multientsafters zimmern. Als weitere Hilfe kann ein (Support-)Mitarbeiter Lesezeichen auf Tickets anlegen. Wie bei den Lesezeichen in einem Browser hat er so raschen Zugriff auf die aus seiner Sicht wichtigsten Tickets aus der Vergangenheit.

Berechtigungen

Request Tracker behandelt Kunden und Support-Mitarbeiter gleich, Kunden besitzen im System lediglich weniger Rechte. Immer dann, wenn eine neue E-Mail von einem unbekannten Fragesteller eingeht, legt RT automatisch einen unprivilegierten neuen Benutzer an. Gibt man einem solchen Kunden in RT ein Passwort, kann er sich an dem System anmelden und so seine laufenden und vergangenen Tickets einsehen – mehr aber auch nicht. Da sie im System normale Nutzer sind, dürfen Kunden auch noch weiter gehende Rechte erhalten.

Benutzergruppen lassen sich wieder in andere Gruppen stecken und verschachteln. Eine untergeordnete Gruppe erbt dabei automatisch alle Rechte der übergeordneten. Damit bildet der Systemverwalter auch komplizierte Rechtebeziehungen ab, muss aber aufpassen, dass er sich dabei nicht verheddert.

Geht ein Support-Mitarbeiter in Urlaub, kann er eine eigene persönliche Nutzergruppe erstellen und seine Rechte an die darin aufgenommenen Kollegen delegieren. Wer Berechtigungen festlegen möchte, trifft allerdings schnell auf ziemlich kryptische Einstellungen, deren Wirkung nur ein ausgiebiges Studium des Wiki erklärt. Darüber hinaus muss der Admin die Rechte an unterschiedlichen Stellen in der Benutzeroberfläche zuweisen und dabei auch noch spezielle, vom System vorgegebene Gruppen wie etwa die “privilegierten” (Mitarbeiter) und die “unprivilegierten” (Kunden) berücksichtigen.

Tickets erhalten eine Priorität zwischen 0 und 99. RT erhöht die Priorität auf Wunsch, je länger das Ticket herumliegt oder ein wichtiges Fälligkeitsdatum näher rückt. Die in einem Ticket gespeicherten (Meta-)Informationen darf der Anwender auch um eigene Datenfelder erweitern. Gespeicherte Suchanfragen kann jeder Benutzer für sich selbst behalten oder den Nutzern einer Queue beziehungsweise allen anderen Benutzern im System zur Verfügung stellen.

Kein Tippfehler: Scrips

Request Tracker kann beim Eintreten eines Ereignisses, etwa dem Eintreffen einer neuen E-Mail, automatisch mehrere andere Aktionen durchführen. Was genau wann passieren soll, legen so genannte Scrips fest (übrigens kein Tippfehler). Ein neues Scrip klickt sich der RT-Benutzer bequem in der Weboberfläche zusammen und erweitert es bei Bedarf mit handelsüblichem Perl-Code.

Eigene Scrips sind grundsätzlich immer dann notwendig, wenn irgendetwas automatisiert ablaufen soll, wenn beispielsweise Tickets bei Ablauf ihres Fälligkeitsdatums automatisch eskalieren sollen. Von sich aus reagiert RT nicht auf länger herumliegende Tickets. Darüber hinaus lassen sich mit Scrips auch Workflows abbilden und so beispielsweise Tickets von einer höheren Stelle bestätigen beziehungsweise freigeben [4].

Die insbesondere für Manager interessanten Statistiken und Reports beschränken sich im Wesentlichen auf die gelösten Anfragen eines Benutzers sowie auf die gelösten und neu eingegangenen Anfragen in einem bestimmten Zeitraum. Für tiefer gehende Analysen benötigt man entsprechende Erweiterungen.

Neben der Weboberfläche lässt sich Request Tracker auch über E-Mails, einen Kommandozeilen-Client und eine REST-Schnittstelle steuern. Auf diesem Weg dockt RT auch andere Systeme an, fertige Schnittstellen existieren unter anderem zu Nagios, Mediawiki und Subversion.

OTRS

Treibende Kraft hinter dem Open-Source Ticket Request System (OTRS) ist die deutsche OTRS AG. Ihr Ticketsystem steht unter der freien Affero General Public License (AGPL) in Version 3. Ursprünglich ins Leben gerufen hat es 2001 Martin Edenhofer, der damals für die Lufthansa arbeitete. Neben der Fluglinie gehört heute unter anderem Nokia zu den großen Anwendern. Darüber hinaus bildet OTRS die ITSM-Komponente im Stack der Lisog (siehe Artikel über Software-Stacks in diesem Magazin).

Auch OTRS ist in Perl umgesetzt, die Daten lagern wahlweise in einer MySQL-, PostgreSQL-, Oracle-, DB2- oder MSSQL-Datenbank (siehe Kasten “Systemvoraussetzungen für OTRS”). Genau wie beim Kollegen RT setzt die Installation beim Admin einiges Wissen über Webserver, Datenbank und Perl voraus. Einfacher hat er es auf RPM-basierten Distributionen, allen voran Open Suse und SLES, für die auf der Projekt-Homepage fertig geschnürte Pakete bereitstehen.

PDF-Handbuch

Die OTRS AG bietet ein komplett ins Deutsche übersetztes, über 500 Seiten dickes PDF-Handbuch kostenlos zum Download an [5]. Entwickler erhalten weitere 140 Seiten. Da sieht man gerne über die vielen Rechtschreibfehler und kleinere inhaltliche Lücken hinweg. Für offene Fragen stehen Mailinglisten und ein Forum bereit. Wer mehr möchte, muss in die Tasche greifen: Die OTRS AG bietet kostenpflichtigen Support an, schreibt auf Basis ihres Produkts maßgeschneiderte Softwarelösungen und tritt auf Wunsch auch als Hoster für vorkonfigurierte OTRS-Installationen auf.

Die Benutzeroberfläche von OTRS hat mit der im November 2010 veröffentlichen Version 3.0 ein radikales Facelifting erfahren (Abbildung 3). Die neue Ausgabe nutzt seither ausgiebig Javascript, ist dabei aber barrierefrei und spricht 22 Sprachen. Einander ähnliche Funktionen sind übersichtlich zusammengefasst, insgesamt wirkt die Oberfläche klar und aufgeräumt.

Abbildung 3: Das Dashboard von OTRS wirkt etwas aufgeräumter als die Einstiegsseite des Konkurrenten.

Die Authentifizierung gegenüber dem System geschieht wahlweise über die Weboberfläche, LDAP, HTTP-Auth oder Radius. Templates dienen dazu, das Aussehen der Benutzeroberfläche an die eigene Corporate Identity anzupassen. Dazu muss der Admin allerdings die eigens entwickelte Dynamic Template Language (DTL) lernen.

Mail-Anbindung

Während der Administrator dem Request Tracker alle eingehenden E-Mails immer über ein spezielles Skript eintrichtern muss, kann OTRS die E-Mails auch aus POP3-, POP3S-, IMAP- und IMAPS-Postfächern abholen. Analog lassen sich ausgehende Nachrichten per Sendmail oder über SMTP-Server verschicken. Rasch formulierte Filterregeln sortieren die eingehenden E-Mails in die passenden Queues, HTML-E-Mails wandelt das System auf Wunsch in reine Textnachrichten um.

Wem die standardmäßig fünf vorgegebenen Prioritätsstufen von »sehr niedrig« bis »sehr hoch« für Tickets nicht ausreichen, der darf beliebig viele weitere hinzufügen. Tickets lassen sich zudem ins PDF-Format exportieren. OTRS unterscheidet zwischen Agenten, die im Unternehmen Anfragen beantworten, und Kunden, die Anfragen stellen. Agenten und Kunden lassen sich in jeweils eigene Gruppen stecken. Kundengruppen sind nicht nur nützlich, um Organisationsstrukturen zu bilden, man kann einer solchen Gruppe auch den Zugriff auf ganz bestimmte Queues erlauben. Bestehende Kundendaten bindet OTRS aus verschiedenen Quellen wie etwa Open LDAP ein.

Rollen, Gruppen, ACLs

Zusätzlich zu den Gruppen darf der Administrator Zugriffsrechte in so genannten Rollen zusammenfassen und den Agenten überstülpen. Falls das immer noch nicht reicht, schränkt er den Zugriff auf Tickets und Queues noch mittels Access Control Lists (ACLs) ein. Diese zu definieren ist allerdings umständlich und erfordert einen manuellen Eingriff in die Konfigurationsdateien.

OTRS berücksichtigt in allen seinen Berechnungen Arbeitszeiten, Feiertage und die Zeitzonen, in denen sich seine Benutzer befinden. Geht ein Agent in Urlaub, kann er seine Abwesenheitszeit hinterlegen. Die Kollegen sehen dann auf der Weboberfläche, wie lange er noch fehlt. Bei Rückmeldungen oder -fragen von Kunden (Follow-Ups) entsperrt OTRS zudem das betroffene Ticket, sodass die übrigen Queue-Mitglieder es übernehmen können.

Eine direkte Entsprechung zu den Scrips in RT kennt OTRS nicht. Immerhin kann der Anwender so genannte Jobs zusammenklicken, die in bestimmten Zeitintervallen eine Aktion für ausgewählte Tickets ausführen. Erlaubt sind alle Aktionen, die auch ein menschlicher Agent durchführt, etwa Tickets schließen oder Benachrichtigungen verschicken.

Die Statistiken und Reports gehen über das Angebot von Request Tracker hinaus. Mit Hilfe eines kleinen Assistenten erzeugt der OTRS-Anwender individuelle, maßgeschneiderte Diagramme und Berichte (Abbildung 4).

Abbildung 4: Statistiken erstellt der Anwender in OTRS ähnlich wie Diagramme in einer Textverarbeitung: Datenbasis auswählen, Diagrammtyp wählen und die Achsen beschriften.

Wer schon einmal in einer Tabellenkalkulation ein Diagramm angefertigt hat, dürfte mit der OTRS-Variante schnell zurechtkommen. Allerdings kann man sich in den vielen Möglichkeiten auch verlaufen. Immerhin gibt es ein paar vorgefertigte Statistiken, darunter auch die obligatorische Entwicklung der Reaktionszeiten. Ergänzend existiert eine spezielle Eskalationsübersicht. Sie listet alle Tickets auf, sortiert nach der Zeitspanne bis zur Eskalation.

Unter dem Namen OTRS::ITSM bietet der Hersteller außerdem eine ITIL-konforme IT-Servicemanagement-Lösung auf der Basis von OTRS an.

Kopf an Kopf

Request Tracker und OTRS sind sich sehr ähnlich. Das beginnt schon bei der komplexen Installation, die einen versierten Administrator benötigt und mehrere Stunden in Anspruch nimmt. Hinter beiden Systemen stehen ähnliche Benutzerkonzepte und Leistungsmerkmale sowie Unternehmen, die kostenpflichtige Zusatzleistungen anbieten.

Die Unterschiede liegen im Detail: So hat derzeit OTRS die bessere Dokumentation vorzuweisen, RT punktet mit den flexiblen Scrips, wohingegen OTRS übersichtlicher und etwas komfortabler einzurichten ist. Unter dem Strich hängt die Wahl von den Anforderungen und den benötigten Erweiterungen ab.

Beide federführenden Unternehmen stellen fertig installierte Demoversionen zum Ausprobieren und Kennenlernen im Web bereit ([6], [7]). Einer nicht repräsentativen Umfrage der Schwesterzeitschrift “ADMIN-Magazin” zu Folge ist übrigens OTRS das am meisten genutzte Trouble-Ticket-System [8]. (mhu)