Ticket-Handling

Tickets haben eine Vielzahl von Eigenschaften und Felder, die ihrerseits wieder in verschiedene Bereiche untergliedert sind und im Kopfbereich eines Tickets angezeigt werden. Die einzelnen Kategorien sind ein- und ausblendbar und zur leichteren Auffindbarkeit farblich kodiert ( Abbildung 2 ).

Abbildung 2: Kopfbereich eines Tickets inklusive aller Metadaten.

Im Reiter »Basics« finden sich die grundlegenden Eigenschaften der Tickets, etwa die Ticketnummer, der aktuelle Status, die Anfangs- und Endpriorität und die Queue, in die das Ticket einsortiert wurde. Im Bereich »People« stehen die Angaben zu den einzelnen Personen, die mit dem Ticket assoziiert sind. Das sind zum einen der Requester, also die Person oder E-Mail-Adresse, die das Ticket ursprünglich erstellt hat, sowie der aktuelle Ticket Owner, also die Person, die für die Bearbeitung und vor allem Erledigung des Tickets verantwortlich ist.

Daneben gibt es noch die so genannten Watcher, die entweder als »CC« oder als »AdminCC« zu einem Ticket hinzugefügt werden können. Ähnlich zu den CC-Empfängern (Carbon Copy) einer E-Mail erhalten diese Personen Kopien der Ticketkorrespondenz, allerdings in unterschiedlichen Detailebenen. In der Regel wird der Administrator das System so konfigurieren, dass man externe Personen als CC einsetzt und analog zum Requester behandelt, während interne Personen als Admin-CC bei einem Ticket aufgenommen werden. Der große Unterschied liegt in der späteren Konfiguration des Workflow. CCs erhalten nur normale Korrespondenz, während Admin-CCs auch interne Kommentare weitergeleitet bekommen. So kann man innerhalb eines Tickets sowohl mit seinen Kunden als auch mit seinen Kollegen korrespondieren, ohne dass die Kunden interne und vielleicht vertrauliche Kommentare erhalten.

Unter »Dates« befinden sich die verschiedenen Datumsfelder. Während »Created« , »Closed« oder »Updated« automatisch gesetzt werden, kann man »Starts« , »Started« , »Last Contact« und »Due« auch manuell einstellen. Die Datumsfelder dienen vor allem dazu, entsprechende Fristen wie »Created 4 weeks ago« oder im Rahmen des Reporting Daten zu den Reaktionszeiten zu berechnen. Mit diesen Daten lässt sich ebenfalls eine genaue Überwachung und Auswertung von Service-Levels implementieren

Eine weitere Ordnungsfunktion innerhalb des Request Trackers sind Links zwischen verschiedenen Tickets. Dieses Feature eignet sich dazu, Abhängigkeiten zwischen verschiedenen Aufgaben zu modellieren. Dafür gibt es die Beziehungstypen »Depends on« , »Parent/Child« und »Refers to« . Setzt man eine Beziehung in eine Richtung, zum Beispiel "Ticket 9 ist Parent von Ticket 3", wird automatisch auch eine Beziehung in der Gegenrichtung erstellt, also "Ticket 3 ist Child von Ticket 9".

Auf Basis dieser Beziehungen lassen sich auch logische Regeln in das Ticketsystem einbauen. So kann ein Ticket, das noch von anderen Tickets abhängig ist, nicht gelöst werden, bevor die anderen Tickets endgültig erledigt wurden. Dadurch lassen sich beispielsweise mehrere Incidents einem Problem zuordnen, das dann wiederum zu einem Change führt.

Request Tracker kann diese Abhängigkeiten über mehrere Ebenen sogar visuell darstellen und einen Abhängigkeitsgrafen aus den Ticketdaten erstellen ( Abbildung 3 ). Um sich oder andere Benutzer des Systems an wichtige Termine zu erinnern, lassen sich zu Tickets so genannte Reminder erstellen, die später auf der Startseite eingeblendet oder per E-Mail versendet werden.

Abbildung 3: Grafische Darstellung der Abhängigkeiten zwischen mehreren Tickets.

Protokolliert

Neben den Basisdaten zeichnet Request Tracker eine komplette Bearbeitungshistorie inklusive Timestamps und der veränderter Felder auf. Diese History wird nach den Metadaten bei jedem Ticket angezeigt ( Abbildung 4 ). Um die Revisionssicherheit des Systems zu erhalten, gibt es keine Möglichkeit, im Webinterface Transaktionen zu löschen. Natürlich kann der Anwender fast alle Werte eines Tickets verändern, dabei legt RT aber eine Transaktion an, die registriert, wer wann welche Daten verändert hat.

Abbildung 4: Ansicht der Bearbeitungshistorie eines Tickets.

Zur Bearbeitung von Tickets dienen die verschiedenen Queues, die normalerweise nach Themen, Abteilungen oder Prozessen strukturiert sind. Queues können eigene E-Mail-Adressen, Prioritäten und Deadlines besitzen. Auch alle Berechtigungen sind Queue-spezifisch konfiguriert. So lässt sich genau festlegen, welche Abteilungen Zugriff auf eine Queue haben und wer Tickets ansehen, bearbeiten oder sogar löschen darf. Diese Einstellungen lassen sich für User, Usergruppen und Rollen festlegen.

Für jede Queue kann der Admin einzelne Watcher konfigurieren, die automatisch als CC-Benutzer Kopien der Korrespondenz erhalten, ohne dass er sie für jedes Ticket einzeln einrichten muss. So lässt sich beispielsweise ein Teamleiter über alle Vorgänge innerhalb seiner Abteilung informieren. Auch die nachfolgend beschriebenen Workflows und Custom-Felder werden immer Queue-spezifisch konfiguriert.

Sämtliche automatisierten Aktionen innerhalb von Request Tracker werden über eine eingebaute Skripting Engine gesteuert. Die entsprechenden Regeln nennen sich Scrips, ein Wortspiel zusammengesetzt aus Script und Subscription [2] . Eine solche Regel besteht immer aus den drei Teilen: Condition, Action und Template. Zuerst gibt man als Condition an, bei welchem Ereignis eine Aktion ablaufen soll. Beispiele für solche Ereignisse sind »On Create« , »On Resolve« , »On Owner Change« , »On Priority Change« , »On Status Change« , »On Comment« und viele weitere.

Die zweite Einstellung »Action« gibt an, welche Aktion bei Eintritt des Ereignisses abläuft. Beispiele dafür sind E-Mail-Benachrichtigungen wie »Autoreply to Requestor« , »Notify Owner« , »Notify AdminCs as Comment« oder verschiedene Ticket-Aktionen wie »Open Ticket« , »Resolve Ticket« oder »Create Ticket« .

Die dritte Einstellung »Template« legt dann fest, welches Template beim Ausführen der Aktion zur Verwendung kommt. Das Template kann ein E-Mail-Template, aber auch ein Template für ein neues Ticket sein. Innerhalb dieser Templates lassen sich alle Eigenschaften der Tickets als Variablen verwenden. Request Tracker ersetzt diese dann später bei der Ausführung des Scrip durch die echten Daten des jeweiligen Tickets, wie in Listing 1 zu sehen ist.

Wie beschrieben sollte ein Anwender auf eine E-Mail-Anfrage an den Helpdesk eine automatische Antwort bekommen. Diese Autoreply hat mehrere Funktionen. Zum einen informiert sie den User, dass seine Anfrage eingegangen ist, zum anderen erhält er damit alle wichtigen Informationen zum neu erstellten Ticket und gegebenenfalls zu den weiteren Bearbeitungsschritten. Dieses Verhalten lässt sich über das folgende Scrip konfigurieren:

Condition: On Create
Action: Autoreply to Requestor
Template: Autoreply Template

Der Scrip-Mechanismus erlaubt es, den Request Tracker und vor allem die darin abgebildeten Prozesse sehr individuell zu konfigurieren und zu automatisieren. So lässt sich damit die komplette Korrespondenzlogik feinjustieren, beispielsweise was bei eingehenden E-Mails genau passiert, wie die ausgehenden E-Mails aussehen und welche Aktionen überhaupt durch E-Mail getriggert werden. Außerdem können Scrips auch das Verhalten innerhalb von RT steuern. So kann beispielsweise beim Schließen eines Tickets in einer Queue automatisch ein Ticket in einer anderen Queue erzeugt werden, etwa um nach Abschluss eines Projekts ein neues Ticket für die Qualitätssicherung zu erstellen.

Neben den vordefinierten Events und Aktionen lassen sich auch komplett benutzerdefinierte erstellen. Damit ist es möglich, auch sehr spezielle Anforderungen mit Request Tracker abzubilden. Da Request Tracker in Perl programmiert ist, werden auch diese selbst definierten Scrips in Perl-Syntax erstellt. Das Beispiel in Listing 2 zeigt eine benutzerdefinierte Action, die immer beim Erstellen neuer Tickets abläuft. Das Scrip prüft dabei die Absenderadresse auf das Pattern »@kunde.de« . Kommt dieser Domainname in der Adresse vor, wird eine zusätzliche E-Mail-Adresse »helpdesk@kunde.de« als CC-Empfänger dem Ticket hinzugefügt. So bekommt der Helpdesk des Kunden immer eine Kopie aller E-Mails. Gerade diese Funktionen erlauben es, viele manuelle Aufgaben innerhalb des Ticketsystems zu automatisieren.