Wenn in einem Team Probleme auftauchen, ist es wichtig, die Vorgänge zu protokollieren und Lösungsschritte zu planen. Ticket-Systeme helfen den Überblick zu behalten und die Ressourcen effizient einzuteilen.

Ticket-Systeme kommen heute in vielen Szenarien zum Einsatz ? vom Kundensupport bis hin zur Entwicklung von Software. Entsprechend groß ist die Vielfalt der zur Verfügung stehenden Anwendungen. Sie lassen sich in zwei Kategorien einteilen: Bugtracker und Trouble-Ticket-Systeme. Bugtracker koordinieren die Software-Entwicklung, Trouble-Ticket-Systeme sind für den Einsatz im Kundensupport optimiert.

Quer gedacht

Allerdings ist es auch hier manchmal sinnvoll, quer zu denken: Der Autor dieses Artikels hat einmal für eine Firma gearbeitet, die angepasste Softwarelösungen für eine Handvoll Großkunden entwickelte. Die Supportabteilung setzte eine Trouble-Ticket-Lösung ein. Die hier aufgelaufenen Bugs übertrug ein Mitarbeiter per Hand in ein Bugtracking-System, obwohl die Software der Supportabteilung diese ebenso gut hätte verwalten können. Zum Aufwand des manuellen Übertragens kam noch der Nachteil, dass sich die Einträge im Bugtracker nicht mehr bis zu ihrem Ursprung zurückverfolgen ließen.

Dieser Artikel bietet eine Übersicht über bewährte Trouble-Ticket-Systeme und hilft Kompromisse zu finden und damit Administrationsaufwand und Datenmigrationsprobleme zu vermeiden.Alle vorgestellten Produkte sind Open-Source-Software und zum kostenlosen Download verfügbar. Alle besitzen ein Webfrontend, arbeiten mit einem Apache-Webserver zusammen und benutzen überwiegend MySQL als Datenbank. Als Testsystem kam Suse Linux Professional 10.0 zum Einsatz.

Request Tracker

Der in Perl programmierte Request Tracker (RT) von Best Practical [1] ist eines der führenden freien Trouble-Ticket-Systeme. Die aktuelle Fassung setzt die neuesten Versionen vieler Perl-Module vorraus. Weil diese selbst wieder bestimmte Releases anderer Perl-Komponenten benötigen, ist es lästig, diese von Hand einzubinden. Abhilfe schafft das Installationsskript, das alle erforderlichen Module vom CPAN lädt und kompiliert.

Im Test ergab sich allerdings, dass die automatische Installation nicht alle Abhängigkeiten erfasst, obwohl der Installer einen Erfolg meldet. Eine wichtige Voraussetzung, um die fehlenden Pakete herauszufinden und per Hand einzubinden, ist einiges Wissen über die Konfiguration des Apache-Webservers. Inklusive der Google-Recherche waren im Test mehrere Stunden erforderlich, um RT zum Laufen zu bringen.

Die Bedienung ist zwar nicht schwierig, aber auch nicht ausgesprochen intuitiv (siehe Abbildung 1). In vielen Fällen liegt dies an der deutschen Übersetzung: Machmal wurden gängige Fachausdrücke unnötigerweise verdeutscht, andere Elemente hingegen schlicht übersehen. Einige Benutzer mögen solche Schönheitsfehler bei Open-Source-Programmen vielleicht verzeihen, im Fall von RT stellen sie jedoch zumindest die Selbsteinschätzung der Entwickler in Frage, die die Qualität ihrer Software als ?Enterprise Grade? bezeichnen.

Abbildung 1: Ist die manchmal problematische Installation überstanden, bietet Request Tracker von Best Practical eine leistungsfähige und weitgehend übersichtlich gestaltete Hotline-Software.

Das System 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. Doch ergibt sich hier die Gefahr wiedersprechender Definitionen.

Alle ernst zu nehmenden Ticketsysteme enthalten eine Suchfunktion, doch nur wenige bieten dem Anwender so viele Möglichkeiten, um unter vielen Tickets den Überblick zu behalten. Nach der Anmeldung gelangt der Benutzer auf die Seite »RT auf einen Blick« und findet dort je nach Einstellung die zehn »Anfragen« (Tickets) mit der höchsten Priorität oder die zehn neuesten Anfragen.

RT unterstützt dabei auch Beziehungen: Anfragen können in einer Eltern-Kind-Beziehung oder in einer unhierarchischen Relation zueinander stehen. Außerdem lassen sich mehrere Anfragen nachträglich zusammenfügen.

RT enthält eine in beiden Richtungen wirksame E-Mail-Funktion: Einerseits lassen sich über eingehende Mails neue Anfragen erstellen. Andererseits berichtet das System über Ereignisse, etwa das Abschließen einer Anfrage oder einen Wechsel zum Status »mehr Infos erforderlich« per Mail. Unter den vielen verfügbaren Erweiterungen finden sich auch solche, die es erlauben, bestehende Tickets per Mail zu verändern.

Ein Feature, das RT besonders interessant macht, sind die so genannten Scrips (Coupons). Sie ordnen den Ereignissen im Ticket-System eine bestimmte Abfolge von Aktionen zu. Das Funktionsspektrum reicht vom Versenden einer oder mehrerer Mails bis hin zu komplexen Abfragen in der Datenbank des Systems. Scrips bestehen aus gewöhnlichem Perl-Code und bieten Zugriff auf das gesamte RT-API.

Open Ticket RequestSystem

Wie RT basiert auch OTRS [2], das zweite, ähnlich weit verbreitete Hotline-Ticket-System, auf Perl. Es stehen Pakete für Suse, Red Hat, Debian und Gentoo sowie für Windows bereit. Obwohl einige Abhängigkeiten per Hand aufzulösen sind, dauerte die Installation von OTRS weniger als 20 Minuten. Nach der eigentlichen Installation lässt sich das System inklusive Datenbank vollständig im Webbrowser einrichten.

Abbildung 2: OTRS lenkt den Benutzer nicht mit einem unübersichtlichen Wirrwarr von Bedienelementen ab. Alle relevanten Funktionen sind über die Menüleiste dennoch schnell zu erreichen.

OTRS unterstützt alle gängigen Datenbanken wie MySQL, PostgreSQL, Max DB, Oracle, DB 2 und MS SQL. Die Oberfläche von OTRS wirkt sehr professionell und ist intuitiv zu bedienen. Neue Tickets lassen sich schnell und bequem erstellen (Abbildung 2).

OTRS unterscheidet zwischen normalen Benutzern und Kunden. Diese Trennung erleichtert es, externen Benutzern einen eingeschränkten Zugang zu gewähren. Wie in RT existieren in OTRS Benutzergruppen und Ticketqueues. Mit deren Hilfe lässt sich ein einziges OTRS-System so organisieren, dass die Kunden mehrerer Firmen nur auf die für sie relevanten Tickets Zugriff erhalten.

Neben Gruppen kennt OTRS so genannte Rollen. Sie bündeln unterschiedliche Zugriffsrechte und erleichtern es, an mehreren Benutzeraccounts die gleichen Veränderungen vorzunehmen. Rollen lassen sich einzelnen Benutzern, aber auch Benutzergruppen zuweisen. Verglichen mit RT ist die Rechtevergabe weniger flexibel, dafür einfacher und schneller.

Für die meisten Firmen reicht der Funktionsumfang aus. Alle Einstellungen sind über das Webfrontend erreichbar. Wie RT besitzt OTRS ebenfalls ein ereignisgesteuertes Benachrichtigungssystem, dessen Leistungsumfang allerdings etwas geringer ausfällt.

Auch für OTRS stehen Erweiterungen bereit: Unter dem Menüpunkt »Paket Verwaltung« lassen sie sich direkt vom Server des Anbieters installieren. Neben dem auch in der Online-Demo [3] integrierten FAQ-Modul stehen noch ein Kalender, ein Umfrage- und ein Dateimanager-Modul zur Verfügung.

Trac

Trac [4] ist ein Bugtracker und hat damit eine andere Zielgruppe als die bisher vorgestellen Systeme. Da Trac auf der in der Webentwicklung weniger verbreiteten Sprache Python basiert, müssen die benötigten Komponenten oft selbst aus den Quellen gebaut werden.

Der Bugtracker beschränkt sich auf die Grundfunktionen: Die Tickets enthalten nur die nötigsten Felder wie Priorität, Schweregrad, Bearbeiter, Status und Kommentar. Relationen oder ein ausgefeiltes System zur Kategorisierung der Tickets kennt Trac nicht. Änderungen lassen sich in der History nachvollziehen. Das System kann Projekte in Komponenten untergliedern und enthält eine einfache E-Mail-Benachrichtigung sowie eine Suchfunktion.

Dennoch zeichnet sich Trac gegenüber anderen Systemen durch ein sehr nützliches Feature aus: Es integriert ein Wiki, das Befehle für den direkten Verweis auf Tickets oder Patches im integrierten Repository-Browser enthält. So lassen sich Vorgänge im Projekt zusammenhängend dokumentieren. Meist ergibt sich damit eine bessere Übersicht als bei über viele Tickets verteilten Kommentaren. Wegen der schlichten Programmarchitektur lässt sich Trac relativ einfach durch selbst geschriebene Plugins erweitern [5].

Bugzilla

Bugzilla [6] ist der bekannteste und am weitesten verbreitete Open-Source-Bugtracker (Abbildung 3). Er ist in Perl programmiert. Die Installation von Version 2.22.1 verlief schnell und problemlos: Ein Skript prüft, ob alle nötigen Perl-Module vorhanden sind, installiert sie aber nicht automatisch. Da dies »cpan Kategorie::Modul« jedoch komfortabel erledigt, entsteht kein großer Nachteil.

Abbildung 3: Bugzilla ist die verbreitetste und leistungsstärkste Bugtracking-Software. Bei kleineren Projekten erweist sich der Featurereichtum jedoch leicht als Effizienzbremse.

Die Bugzilla-Oberfläche wirkt leicht angestaubt, ist jedoch übersichtlich gestaltet und integriert alle administrativen Funktionen. Bei kleinen Projekten erweist sich allerdings die Zahl der eingebauten Funktionen und Bedienelemente eher als störend, auch wenn die umfassende Dokumentation beim Verständnis hilft: Besonders praktisch ist, dass viele Bedienelemente einen direkten Link zum entsprechenden Kapitel im Handbuch enthalten. Der Bugzilla Guide auf der Homepage bietet viele weiterführende Informationen.

Bugzilla erlaubt es, Projekte (Produkte) hierarchisch in Komponenten zu untergliedern. Die Produkte lassen sich ihrerseits über Klassifizierungen genauer gruppieren. Die Anwendung ordnet die Tickets innerhalb der Produkte außerdem nach Plattform und Betriebssystem sowie nach Priorität und Dringlichkeit. Innerhalb von Produkten sorgen Meilensteine und Produktversionen für eine bessere Übersicht. Zusätzlich können die Benutzer über die Wichtigkeit abstimmen. Innerhalb eines Produkts lässt sich eine Schwelle für die Stimmenanzahl festlegen, ab der Tickets automatisch als bestätigt gelten.

Der Bugtracker erlaubt vielfältige Beziehungen zwischen den Tickets: Ein Bug lässt sich als Duplikat eines anderen kennzeichnen und wird damit automatisch geschlossen. Der Administrator kann außerdem festlegen, dass erst ein bestimmter Bug korrigiert werden muss, bevor sich ein davon abhängiger schließen lässt. Ein Abhängigkeitsbaum stellt die Relationen grafisch dar.

Besonders für Open-Source-Projekte nützlich ist das so genannte Whining (Jammern): Die Entwickler arbeiten hier meist über weite Distanzen verstreut und oft nur sporadisch an einem Projekt. Die Funktion hilft zu verhindern, dass Probleme in Vergessenheit geraten, indem es in regelmäßigen Abständen Erinnerungsmails verschickt.

Zwei weitere Features runden das umfangreiche Leistungsspektrum ab: Der Patch Viewer vergleicht vorhandene Patches und hebt Änderungen farblich hervor. Eine vollständig über die Webschnittstelle zu bedienende Reportfunktion zeigt einen grafischen oder tabellarischen Überblick über den Entwicklungsstand der Produkte. Ausgangsbasis für Reports ist eine Suche mit der recht leistungsstarken Suchfunktion. Die so entstandenen Kriterien-Sets lassen sich dauerhaft speichern.

Mantis

Das Bugtracking-System Mantis [7] basiert auf PHP. Die Installation des ausgereiften Systems ist einfach: Nach dem Entpacken des Archivs in das Webserver-Verzeichnis erfolgt bereits das Setup der Datenbank über die Weboberfläche. Die ist wegen ihrer grellen Farben etwas gewöhnungsbedürftig (Abbildung 4), aber übersichtlich und intuitiv zu bedienen. Die Sprache lässt sich ohne weitere Installation zur Laufzeit wählen.

Abbildung 4: Das PHP-basierte Mantis ist schnell installiert. Die oft recht oberflächliche Dokumentation erschwert es jedoch, das System den eingenen Vorstellungen anzupassen.

Mantis kennt nur zwei Objektklassen, nämlich Tickets (hier Probleme genannt) und Projekte. Ein Projekt kann andere Projekte enthalten, sodass sich eine Hierarchie aufbauen lässt. Die Mantis-Übersichtsseite enthält einen Überblick über die wichtigsten Probleme: Hier zeigt die Software Tickets unter den Rubriken »Nicht zugewiesen«, »Von mir bearbeitet« und »Vor kurzem bearbeitet« an. Die Rubriken und Nummern der einzelnen Tickets stellt Mantis als Links dar, die zur Detailansicht führen.

Mantis bietet zwei Einzelansichten für Tickets mit unterschiedlicher Ausführlichkeit. Bei der erweiterten Ansicht passen selbst bei einem 21-Zoll-Bildschirm nicht alle Daten auf eine Bildschirmseite. Allerdings lassen sich die einzelnen Abschnitte bei Bedarf zuklappen.

Das Handbuch von Mantis bietet oft nicht genügend Informationen: In vielen Fällen beschränkt es sich darauf, einzelne Komponenten kurz zu beschreiben oder nur aufzulisten, erläutert aber deren Bedienung nicht. Die Dokumentation auf der Homepage ist als Forum aufgebaut, in dem Benutzer Informationen hinzufügen können. Leider erschweren doppelte Einträge und unbeantwortete Fragen die Übersicht.

Mantis integriert die Benutzerverwaltung in die Weboberfläche, enthält aber keine vollwertige Gruppenfunktion: Es gibt zwar Rollen, aber diese definieren nur allgemein Zugriffsrechte wie zum Beispiel die Berechtigung, Projekte zu erstellen oder Benutzer zu verwalten. Sie regeln nicht den Zugriff auf einzelne Projekte. Um den Zugang der Benutzer auf bestimmte Projekte zu beschränken, lassen sich diese als privat kennzeichnen. Der Zugriff ist dann nur für zugeordnete Benutzter erlaubt. Die Zuordnung muss der Admin jedoch für jeden Benutzer einzeln herstellen.

Mantis versendet bei jeder Statusänderung E-Mails an alle Beteiligten (den Einsender, den Zuständigen sowie alle, die Beschreibungen eingetragen haben). Der E-Mail-Versand lässt sich über den Access-Level, den die Benutzer für das Projekt haben, einschränken. User können auch Bugs gezielt überwachen.

Kein klarer Sieger

Trotz des unterschiedlichen Leistungsumfangs der vorgestellten Anwendungen gibt es im Test keinen eindeutigen Sieger: Jedes der vorgestellten Systeme stellt für bestimmte Szenarien die optimale Lösung dar. Der einfache Bugtracker Trac eignet sich für kleinere Projekte, da die Integration eines Wiki die Dokumentation erleichtert und die vielen Features eines Bugzilla sowieso nicht benötigt werden. Für größere Projekte ist der Leistungsumfang nicht ausreichend. Bugzilla, der verbreitetste und leistungsstärkste Bugtracker setzt beinahe alle erdenklichen Funktionen um. Bei Projekten, in denen viele hundert oder gar tausende Bugs aufschlagen, bewährt sich der Klassiker aus dem Mozilla-Projekt. Mantis hat dafür eine übersichtlichere Oberfläche und ist, da es auf PHP basiert, auf LAMP-Systemen ohne Installation weiterer Komponenten lauffähig.

Bedarfsgerecht

Wer eine klassische Support-Software sucht und großes Gewicht auf eine leistungsstarke Benachrichtigungsfunktion legt, sollte etwas Zeit in die nicht immer reibungslos verlaufenden Installation von RT investieren. Mit der Scrips-Funktion reagiert die Software flexibler auf Ereignisse im Ticketsystem als andere Trouble-Ticket-Systeme. OTRS zeichnet sich dagegen durch seine einfache Installation und intuitive Bedienung aus. Jede der beiden Lösungen bietet Features, die das andere System nicht beinhaltet. Bei der Entscheidung ist es daher nötig, Prioritäten zu setzen. Da alle Systeme im Test kostenlose Open-Source-Software sind, besteht keine Gefahr, unnötig Geld auszugeben.

Wer Bugtracking und Kundensupport unter einen Hut bringen möchte, sollte beide Aufgaben gemeinsam in einem Hotline-Ticket-System abwickeln: Bugtracker eignen sich nicht für die Verwaltung der Kundenanrufe, Hotline-Ticket-System dagegen durchaus für das Verwalten von Bugs. Wegen seiner leistungsfähigen Rollenfunktion schafft OTRS die Voraussetzungen, um den Anforderungen beider Anwendergruppen ohne großen Andministrationsaufwand gerecht zu werden. (pkr)