Ab einer gewissen Zahl von Supportanfragen sind Trouble-Ticket-Systeme unverzichtbar, um effizient zu bleiben. Das OTRS ist ein quelloffenes System, das die Arbeit am Helpdesk enorm erleichtert. Es hat sich bereits bei Firmen bewährt, bei denen täglich Zehntausende Fragen eintreffen.

Unternehmen mit komplexen, erklärungsbedürftigen Produkten und Dienstleistungen werden nicht zuletzt an der Qualität ihres Supports gemessen. Damit dieser nicht unendliche Ressourcen verschlingt, brauchen die Anbieter automatisierte Systeme, die den Fluss von Supportanfragen und deren Antworten strukturieren, also so genannte Trouble-Ticket-Systeme.

Deren Einsatz kann einen enormen Wettbewerbsvorteil bringen, den sich die Hersteller dieser Systeme oft sehr teuer bezahlen lassen. Nicht so beim OTRS[1]: Es ist freie Software unter der GPL und kostet genau null Euro Lizenzgebühren. Es entstand ursprünglich als internes Supportsystem bei der SuSE Linux AG[2] und wird seit einiger Zeit als freies Projekt weitergeführt.

Das GPL Open Ticket Request System (OTRS) ist eine Art Sammelbecken für alle ankommenden E-Mails, Telefonate und Faxe an eine Sammeladresse, ein Team von Mitarbeitern kümmert sich anschließend darum. Eine wichtige Herausforderung besteht darin, Anfragen über verschiedene Medien wie Telefon, E-Mail, Fax oder sogar Briefpost gleich zu behandeln und ihnen allen ein Ticket zuzuteilen.

Ein Ticket enthält alle Daten, die zu einer bestimmten Supportanfrage gehören. Tickets für Telefonate kann der Helpdesk-Mitarbeiter im OTRS entweder manuell anlegen oder sie werden über eine Telefonanlagenschnittstelle (LTAPI) halbautomatisch erzeugt. Faxe werden als Gif-Grafik an eine E-Mail angehängt. Briefe als Faxe bearbeitet (also sich selber zugefaxt). Am Ende ist im OTRS jedes Ticket eine E-Mail.

Im Februar gaben die Entwickler die erste als final erklärte Version des Systems frei, wir nutzen diese Gelegenheit, einen detaillierten Blick auf dieses Softwareprojekt zu werfen.

Ziehen Sie eine Nummer!

Eine Trouble-Ticket-Nummer (TTN) ist der eindeutige Identifikator für jedes Ticket. Schreibt ein Kunde eine E-Mail an »hotline@company.com«, bekommt er vom OTRS eine Antwort mit einer im Subjekt enthaltenen TTN. Antwortet der Kunde auf diese E-Mail, erkennt das OTRS an dieser TTN das Ticket und ordnet es entsprechend direkt zu.

Eine TTN kann aus Buchstaben und Ziffern bestehen. Ratsam ist es aber, ausschließlich Ziffern zu benutzen. Dann kann der Kunde seine TTN auch bei einer Telefonhotline über ein Sprach- oder Touchtone-Interface direkt eingeben. Die Schnittstelle der Telefonanlage (LTAPI) stellt ihn dann gleich zum richtigen Mitarbeiter durch. Der hat das Ticket dann bereits direkt auf den Bildschirm, wenn er den Anruf bekommt. Wichtig bei der TTN ist, das sie nie wieder geändert werden kann.

Das OTRS bietet standardmäßig eine Auswahl an verschiedenen Algorithmen an, um TTNs zu erzeugen. Die gängigste Methode ist sicherlich »$ Jahr$ Monat$ Tag$ Ticketzähler$ Prüfziffer« (also beispielsweise 20020323000109). Allerdings hat diese Methode auch einen Nachteil: Der Kunde kann anhand der TTN die Anzahl der bisherigen Anfragen (an dem entsprechenden Tag) ersehen. Wer dies nicht will, hat aber die Möglichkeit, sich recht einfach ein TTN-Modul selber zu schreiben und es im modular aufgebauten OTRS einzubinden.

Webbasierter Client

Viele kommerzielle Trouble-Ticket-Systeme benutzen spezielle Clients, die meist nur auf Windows laufen. Beim OTRS hingegen braucht der Benutzer (im Helpdesk-Jargon als Agent bezeichnet) neben einem Account auf dem System nur einen beliebigen Browser. Selbst mit Lynx und W3m ist das System sehr gut bedienbar. Nach dem Anmelden bekommt der Agent die für ihn freigeschalteten Queues angezeigt.

Der Administrator kann, nachdem das System installiert ist, alle Konfigurationen per Webclient vornehmen. Der Client ist intuitiv bedienbar und lässt sich gut an Userwünsche anpassen. Jede Seite liegt im System als Template (»dtl«) vor und ist schnell an das jeweilige Cooperate Design anpassbar. So bleibt selbst bei einem Update der Software die Arbeitsumgebung der Agents gleich.

Einzelne Tickets werden in Queues gesammelt. Ob ein Agent Zugriff auf eine Queue hat, bestimmt der Administrator. So ist sichergestellt, dass Buchhaltungsanfragen auch wirklich nur von der Buchhaltung und nicht vom technischen Support beantwortet und trotzdem in einem System verwaltet werden. Bei großen Installationen wird oft eine Dispatchereinheit auf eine so genannte Raw Queue angesetzt.

Ticket Queues

In diese Raw Queue laufen alle neuen einkommenden Kundenanfragen ein. Der Dispatcher kann die E-Mails dann in Spezialqueues verteilen. Wenn ein Dispatcher dabei einen Fehler gemacht hat und eine Kundenanfrage in die 2nd- Level-Support-Queue verschoben hat, die aber eigentlich eine 3rd-Level-Support-Anfrage ist, können die Agents der 2nd-Level-Queue dieses Ticket mit einem Kommentar versehen.

Natürlich wird auch dieser Kommentar im entsprechenden E-Mail-Folder abgespeichert. Das Ticket geht dann entweder zurück an den Dispatcher oder an den 3rd-Level-Support. Wer welches Ticket auf welche Queue bewegen darf, wird über ein ausgeklügeltes Rechtesystem für jede Queue einzeln bestimmt.

Der Standardfall

Die meisten Anfragen sind mit einer FAQ-Antwort geklärt. Gerade hier spielt das OTRS seine Trümpfe aus. Für jede Queue lassen sich beliebig viele Standardantworten definieren. In der Praxis sollte man aber der Übersichtlichkeit halber nicht mehr als acht Antworten pro Queue definieren. Wer eine E-Mail mit einer solchen Standardantwort beantworten will, klickt einfach auf den entsprechenden Link und bekommt einen webbasierten E-Mail Client, der bereits die Frage des Kunden, die Standardantwort und eine persönliche Begrüßung an den Kunden enthält.

Im Idealfall genügt es dann, direkt auf »Absenden« zu klicken. Ansonsten kann man die Antwort noch einmal anpassen. So lassen sich in vielen Systemen bis zu 70 Prozent aller Anfragen schnell und einfach beantworten. Allerdings lebt dieses System von der Pflege. Wenn sich die Standardantworten ändern, ist auch im OTRS ein Update fällig.

Queue-Robots

Ein besonderer Leckerbissen für Supportmitarbeiter ist die Möglichkeit, Robots auf Queues loszulassen. In der Version 1.0.1 (Codename Sunset Beach) gibt es einen Generic Agent, der Tickets in einer Queue selbstständig schließen, verschieben und mit Notizen versehen kann. In Zukunft werden laut OTRS-Wishlist auch Queue-Robots den Inhalt eines Tickets durch eine externe Applikation pipen und damit Filterfunktionen durchführen können.

So lässt sich automatisch in einer Raw Queue nach bestimmten Schlüsselwörtern suchen und das Ticket dann in eine entsprechende Queue verschieben. Eine weitere Anwendung liegt im automatischen Schließen von Spam-Tickets, die vom Dispatcher in eine Spam-Queue verschoben wurden.

Auch hier liegt das Augenmerk der Entwickler auf einem hohen Automationsgrad. Ein Dispatch-Agent verschiebt ein Ticket mit einem Klick in eine Spam-Queue, der Robot verfasst einen entsprechenden Kommentar und schließt das Ticket. Viele OTRS-Installationen benutzen auch Software wie Spam Assasin, um Spam vollautomatisch in eine solche Queue zu verschieben (das geht über einen speziellen X-Header, den das OTRS ausliest).

Praxisprobleme und ihre Lösung auf OTRS-Art

Um zu vermeiden, dass ein Ticket zu lange in einer Queue liegt, ist für sie eine Eskalationszeit einstellbar. Wenn sie abgelaufen ist, kann der Agent in dieser Queue nur noch dieses Ticket und kein anderes mehr bearbeiten. Auf diese Weise ist gewährleistet, dass Tickets nicht zu alt werden.

Je nach Einsatzgebiet mag es sinnvoll sein, ein Ticket nach einer bestimmten Zeit wieder zu bearbeiten, um es dann endgültig zu schließen oder den Kunden noch einmal anzurufen. Im System kann man pro Ticket eine eigene Wiedervorlagezeit definieren oder auch einen Vorgabewert benutzen.

Einer der Hauptvorteile eines in sich geschlossenen Trouble-Ticket-Systems ist die Möglichkeit, alle Transaktionen genau zu loggen und so die Einhaltung der mit dem Kunden vereinbarten Service-Level-Agreements zu überwachen. Es ist jederzeit nachweisbar, wann welche Aktion vollzogen wurde.

Ein typisches Problem von großen Trouble-Ticket-Systemen ist das Kranker-Agent-Szenario. Ein Agent sichert (lockt) ein Ticket und hat damit alleiniges Zugriffsrecht. Wenn dieser Agent einen Tag später krank wird und das Ticket immer noch von ihm gelockt ist, hat kein anderer Agent Schreibzugriff auf das Ticket und kann es nicht beantworten. Dieser Fall ist ausgeschlossen, wenn nach einer definierten Zeit ein gelocktes Ticket automatisch entsperrt (unlockt) wird und damit wieder für alle Agents zur Verfügung steht.

Abbildung 1: Standardansicht einer Anfrage. Alle Tools sind einen Klick entfernt.

Abbildung 2: Standardantworten sind in den meisten Fällen ausreichend.

Konfigurationsmarathon

Wer das OTRS optimal einsetzen will, sollte sich schon mal auf einen Konfigurationsmarathon einstellen – alles ist anpassbar. So lässt sich für jeden Agent eine eigene Sprache für die Menüs und ein eigenes Codeset für die Anzeige einstellen. In dem OTRS-Demosystem auf [http://www.otrs.org/] wird dies anhand einiger russischer E-Mails sehr schön gezeigt.

Zur Zeit unterstützt das OTRS die beiden freien Datenbanken MySQL und PostgreSQL. Wer die OTRS-Mailingliste mitliest, findet dort beide Lager. Die derzeit größte Installation betreibt ein britischer ISP mit MySQL. Dieses System verarbeitet pro Tag 20000 Tickets. Die Installation mit den meisten Agenten betreibt eine große deutsche Bank. Dort sitzen gleichzeitig bis zu 2000 Servicemitarbeiter an den Schreibtischen und arbeiten mit OTRS, wieder dient MySQL als Datenbank. Natürlich sind die meisten Installationen sehr viel kleiner (in der Regel zwischen zehn und 500 E-Mails am Tag), aber es ist schon ein gutes Gefühl zu wissen, dass das System auch sehr viel mehr verkraftet.

Für Statistikfans hält das OTRS eine ganze Reihe von sinnvoll aufbereiteten Statistiken bereit. Allerdings wird dies in den meisten Firmen vom Betriebsrat nicht sehr gerne gesehen und sollte daher mit ihm besprochen werden.

Die Mühen der Installation

Nicht trivial ist die Installation. Wer keine Zeit hat, sollte lieber die Finger davon lassen! Das OTRS braucht als Voraussetzungen einen Webserver (normalerweise Apache), eine Datenbank und Perl (ab Version 5.5). Am einfachsten lässt sich das OTRS zur Zeit auf einem SuSE Linux installieren. Hierfür stellt das Entwicklerteam fertige RPMs zum Download bereit. Damit ist die Software innerhalb von zwei bis drei Minuten zu installieren.

Bei allen anderen Linux- und Unix-Varianten muss man mit dem »tar.gz«-File Vorlieb nehmen und die Software von Hand auf das System bringen. Es ist zudem sehr wahrscheinlich, dass hierzu über CPAN erst noch ein halbes Dutzend Perl-Module zu installieren sind. Danach ist die »httpd.conf« anzupassen, der Apache neu zu starten (wichtig!) und die Datenbank des OTRS zu installieren. Es gibt aber eine sehr gute Installationsanleitung im Dokumentationsbereich der OTRS-Homepage.

Niemand sollte sich übrigens von den niedrigen Versionsnummern abschrecken lassen, sie zeugen eher von einem etwas schrägen Humor der Entwickler. Versionen, die im OTRS-Tree als Beta bezeichnet werden, würde so manche Firma als stabile Final Release rausgeben. Wer sich nicht sicher ist, ob das OTRS das richtige System für die eigenen Bedürfnisse ist, kann auf der Homepage des Projekts ein Demosystem zum hemmungslosen Experimentieren benutzen. Dort sind auch viele weitere Informationen zu dem Trouble-Ticket-System zu finden. (uwo)

Abbildung 3: Die History eines Tickets ist nötig, um alle Informationen zu einem Supportvorgang sofort griffbereit zu haben.

Abbildung 4: Das OTRS bietet ausgefeilte Statistikfunktionen an, die weniger fleißige Mitarbeiter schnell enttarnen.