<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
    "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">


<!-- $Id: tts.xml,v 1.32 2012/02/23 13:44:35 mg Exp $ -->
<chapter id="tts">
<title>Trouble-Ticket-Systeme - die Grundlagen</title>

<abstract>
<para>
In diesem Abschnitt soll kurz die grundlegende Idee, die hinter
Trouble-Tickets im Allgemeinen und Trouble-Ticket-Systemen im Speziellen
steht, erläutert werden. An einem kleinen Beispiel wird gezeigt,  wo die
Vorteile dieser Systeme liegen.
</para>
</abstract>

<section id="basic-tts-example">
<title>Was ist ein Trouble-Ticket-System, und warum benötigen Sie eins?</title>

<para>
Das folgende Beispiel soll verdeutlichen, was ein Trouble Ticket System ist
und wie Sie damit in Ihrem Unternehmen Zeit und Geld eingesparen können.
</para>

<para>
Nehmen wir an, dass Max Mustermann Fabrikant ist und Videorekorder
produziert. Da die Programmierung der Videorekorder sehr unübersichtlich und
kompliziert ist, wenden sich die Kunden von Herrn Mustermann gerne und
häufig mit Supportanfragen per Mail an ihn. An manchen Tagen kann Herr
Mustermann der Mailflut kaum Herr werden und so kommt es, dass seine Kunden
sich einige Zeit gedulden müssen, bis die Antwort mit der rettenden Lösung
bei ihnen eintrifft. Manchen Kunden dauert dies jedoch zu lange, eine
weitere E-Mail mit dem gleichen Inhalt wird an Herrn Mustermann
geschickt. Die E-Mails mit den Supportanfragen werden alle in eine INBOX
weitergeleitet, wie sie von fast allen E-Mailprogrammen verwendet wird.
</para>

<para>
An manchen Tagen ist die Anfragewelle besonders groß und Herr Mustermann
sieht sich außerstande, alle Mails noch in einem vertretbaren Zeitrahmen zu
beantworten. Aus diesem Grund kommandiert er seine Entwickler Meier und
Schulze zur Bearbeitung der Supportanfragen ab. Da von allen das gleiche
System benutzt wird, greifen alle auf die gleiche INBOX und daher auch auf
die gleichen Mails zu. Meier und Schulze haben jedoch keine Ahnung, dass
manch ein Kunde in seiner Not gleich zwei E-Mails verfasst und an Herrn
Mustermann geschickt hat. So kommt es vor, dass Meier die erste Mail mit
einem anderen Ratschlag beantwortet als Schulze der sich im selben Moment
der zweiten Nachricht des gleichen Kunden annimmt. Das Ergebnis ist, dass
der Kunde unterschiedliche Antworten bekommt. Darüber hinaus hat Herr
Mustermann keinen Einblick darüber, welcher Mitarbeiter wann was welchem
Kunden gesagt hat, welche Probleme besonders häufig auftreten und wie groß
sein gesamter Aufwand für den Kundensupport ist.
</para>

<para>
Von einem Kollegen erfährt Herr Mustermann schließlich, dass es
Trouble-Ticket-Systeme gibt, die genau die Probleme lösen, die Herr
Mustermann mit dem Support für seine Kunden hat. Herr Mustermann entscheidet
sich für das offene Trouble-Ticket-Request System OTRS und installiert
dieses System auf einem Rechner, der über einen Webserver sowohl für seine
Mitarbeiter als auch über das Internet erreichbar ist. Von nun an werden die
Hilferufe der Kunden nicht mehr länger an seine private INBOX, sondern
direkt an den Mail-Account für OTRS weitergeleitet. OTRS hat eine
Schnittstelle zur INBOX für die Supportanfragen, so dass alle ankommenden
E-Mails automatisch ins Trouble Ticket System eingespeist werden. Unabhängig
ob Herr Mustermann nun gerade anwesend ist oder nicht, generiert OTRS eine
automatische Antwort und teilt dem Kunden mit, dass seine E-Mail angekommen
ist und so schnell wie möglich bearbeitet wird. Dabei wird eine eindeutige
Trouble Ticket Nummer vergeben. Der Kunde ist glücklich, dass sein Flehen
schnell erhört wurde und wartet gespannt auf eine Antwort. Sowohl Herr
Mustermann als auch die Entwickler Meier und Schulze können nun über einen
beliebigen Internetbrowser und die Weboberfläche von OTRS auf die
Supportanfragen zugreifen und diese einzeln beantworten. Da die Tickets bei
Beantwortung gesperrt werden, wird keine Nachricht versehentlich zweimal
erstellt.
</para>

<para>
Stellen wir uns vor, dass Herr Schmidt eine Anfrage ans System gestellt hat
und Herr Meier diese kurz und knapp beantwortet. Herrn Schmidt reicht diese
Antwort jedoch nicht aus und so antwortet er auf die Lösungsmail am
folgenden Tag. Herr Meier ist jedoch gerade mit anderen Dingen beschäftigt,
so dass sich Herr Mustermann der Sache annimmt. Über die History-Funktion
von OTRS kann er jetzt auf alle vergangenen E-Mails von Herrn Schmidt und
Herrn Meier zugreifen, deren Inhalt abfragen und eine ausführlichere Antwort
versenden. Herr Schmidt erhält nun die Lösung für sein Problem, weiß aber
nicht, dass diese von unterschiedlichen Personen stammt.
</para>

<para>
Natürlich ist dies nur ein sehr kleiner Einblick in die Funktionalitäten von
Trouble Ticket Systemen. Da Herr Mustermann eine kleine Firma führt, erhält
er vielleicht nur wenige E-Mails mit Supportanfragen pro Tag, die er
vielleicht noch ganz überschaulich mit seiner normalen Mailsoftware
handhaben kann und somit kein Trouble Ticket System braucht. Wenn aber der
neue DVD-Rekorder in die Regale kommt, werden es vielleicht schon 500 oder
in ein paar Jahren schon 10.000 Nachrichten pro Tag sein. Spätestens dann
rechnet sich der Einsatz von Trouble-Ticket-Systemen wie OTRS.
</para>

</section>

<section id="what-is-a-tt">
<title>Was ist ein Trouble-Ticket?</title>

<para>
Ein Trouble-Ticket lässt sich im Wesentlichen mit einem Krankenblatt eines
Krankenhauspatienten vergleichen. Bei der erstmaligen Einlieferung in das
Krankenhaus wird das Krankenblatt im Zuge der Anamnese neu angelegt. Jeder
Arzt trägt nun seine Diagnose sowie die verordnete Therapie und Medikation
ein und dokumentiert deren Erfolg. Das Krankenblatt gibt nun einen schnellen
Überblick, gewährleistet eine schnelle Einarbeitung und verhindert
eineMehrfachdosierung von Medikamenten. Ist die Krankheit besiegt und der
Patient entlassen, wird das Krankenblatt archiviert.
</para>

<para>
Im OTRS werden Trouble Tickets, also die Krankenblätter aus dem obigen
Beispiel, als normale E-Mails behandelt und gespeichert. Schickt z. B. ein
Kunde eine Anfrage an das Trouble Ticket System, wird das Krankenblatt
eingerichtet, ein neues Ticket wird geöffnet. Die Antwort eines Mitarbeiters
auf die Anfrage kann als Eintrag eines Arztes gesehen werden, eine erneute
Antwort bzw. Anfrage des Kundens auf das selbe Ticket als Veränderung oder
Erweiterung des Krankheitsbildes. Ein Ticket gilt als erledigt
bzw. geschlossen, wenn eine Antwort auf die Anfrage an den Kunden
zurückgesendet wurde oder das Ticket über das System alsgeschlossen markiert
wird. Antwortet ein Kunde auf ein bereits geschlossenes Ticket, so wird es
erneut geöffnet und die neuen Informationen ergänzt. Um die Konsistenz der
Daten sicherzustellen, werden alle Tickets mit all ihren spezifischen
Informationen archiviert und verbleiben im System. Durch die Speicherung der
Tickets als ganznormale E-Mails ist es möglich, dass diese auch
E-Mail-Anhänge enthalten können. Zusätzlich zu den normalen Informationen
einer E-Mail lassen sich beliebige Notizen zu jedem Ticket hinzufügen. Die
Tickets selbst werden auf der Festplatte bzw. in einer Datenbank archiviert,
ebenso zusätzliche Meta-Informationen des Tickets wie Notizen, an der
Beantwortung des Tickets beteiligte Mitarbeiter, Zeit und Datum der
Bearbeitung, Bearbeitungsdauer usw. Eine Sortierung oder eine Suche über den
Datenbestand wird mit Hilfe aller vorhandenen Informationen zu den Tickets
realisiert.
</para>

</section>

</chapter>