<chapter id="Troubel-Ticket-Systeme">
<title>Trouble Ticket Systeme</title>

<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.
</para>

<sect1 id="Kurzbeispiel-fuer-ein-TTS">
<title>Ein einfaches Beispiel für ein kleines Trouble Ticket System</title>

<para>
Wie könnte ein typisches Einsatzszenario für OTRS aussehen?
</para>
<para>
	Beispiel: Max Mustermann ist Fabrikant und produziert
      Videorekorder. Da die Programmierung der Videorecorder sehr schwierig
      ist, wenden sich die Kunden von Herrn Mustermann gerne und häufig an ihn
      und schreiben eine E-Mail. An manchen Tagen kann Herr Mustermann der
      E-Mail Flut 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. Dem ein oder anderen Kunden dauert dies jedoch zu
      lange und so schickt er einfach eine weitere E-Mail an Herrn Mustermann.
      Diese E-Mails laufen alle einer INBOX, wie sie von fast allen
      Email-Programmen verwendet wird, auf. Wenn die Anfragewelle besonders
      groß ist und Herr Mustermann sich außerstande sieht, alle E-Mails noch
      am gleichen Tag zu beantworten, kommandiert er seine Entwickler Meier
      und Schulze zur Kundenhotline ab. Sie benutzen dann alle das gleiche
      System und greifen auf die gleiche INBOX zu. Natürlich haben Meier und
      Schulze kein Ahnung, dass manch ein Kunde in seiner Not gleich zwei
      E-Mail verfasst hat. So kommt es vor, das Meier die erste E-Mail mit
      einem anderen Ratschlag beantwortet als Schulze der sich im selben
      Moment der zweiten E-Mail annimmt. Das Ergebnis ist, dass der Kunde
      unterschiedliche Antworten bekommt! Darüber hinaus hat Herr Mustermann
      keinen Einblick darüber, wer wann was welchem Kunden gesagt hat, welche
      Probleme besonders häufig auftreten und wie groß sein gesamter Aufwand
      für Kundensupport ist!
</para>
<para>
	Aber dann erfährt Herr Mustermann, dass es OTRS gibt und
      installiert dies um zukünftig Unterstützung im Kundensupport zu haben.
      Von nun an werden die Hilferufe der Kunden nicht mehr länger an seine
      private INBOX, sondern direkt an den OTRS Account weitergeleitet. Das
      System hat eine Schnittstelle zum OTRS Account, so dass alle ankommenden
      E-Mails automatisch ins System eingespeist werden. Unabhängig ob Herr
      Mustermann nun gerade zu Tisch 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 erhört wurde und wartet gespannt auf eine Antwort.
      Sowohl Herr Mustermann als auch die Entwickler Meier und Schluze können
      sich über einen beliebigen Internetbrowser und die URL von OTRS auf die
      Anfragen zugreifen und diese einzeln beantworten. Stellen wir uns vor,
      dass Herr Schmidt eine Anfrage ans System gestellt hat und Herr Meier
      diese kurz und knapp beantwortet. Herrn Schmidt reicht dies Antwort
      jedoch nicht aus und so antwortet er auf die Lösungsmail am folgenden
      Tag. Herr Meier ist jedoch gerade mit der Entwicklung des Nachfolgers
      beschäftigt, so dass sich Herr Mustermann der Sache annimmt. Über die
      Histroy Funktion kann er jetzt auf alle vergangenen E-Mails zugreifen
      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 OTRS. Da Herr Mustermann eine kleine Firma führt
      erhält er vielleicht nur um die 100 E-Mails am Tag, die er vielleicht
      noch ganz überschaulich mit seiner INBOX handhaben kann und somit kein
      OTRS braucht. Wenn aber der neue DVD-Rekorder in die Regale kommt,
      werden es vielleicht schon 500 oder in ein paar Jahren schon 10.000
      E-Mails am Tag sein! - Glücklich, wer ein OTRS hat!
</para>
</sect1>

<sect1 id="Was-ist-ein-Trouble-Ticket">
<title>Was soll ich mir unter Trouble Ticket vorstellen?</title>
<para>
	Ein Trouble Ticket lässt sich im Wesentlichen mit einem
      Krankenblatt eines Patienten vergleichen. Bei der erstmaligen
      Einlieferung im Krankenhaus wird dieses 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 eine Mehrfachdosierung. Ist die
      Krankheit besiegt und der Patient entlassen, wird das Krankenblatt
      archiviert.
</para>
<graphic align="center" fileref="images/LebenszyklusTT.PNG" scale="60"></graphic>
<para>
	Im OTRS werden solche Trouble Tickets als normale E-Mails
      behandelt und gespeichert. So ist es möglich, dass Trouble Tickets auch
      Anhänge enthalten, die dann als normale E-Mailanhänge gespeichert werden
      können. Die Tickets selbst werden auf der Festplatte gespeichert. Eine
      Sortierung erfolgt über die deren Meta-Informationen welche zusätzlich
      in der Datenbank gehalten werden. (Nähere Informationen findet man im
      Quelltext!)
</para>
</sect1>

<sect1 id="Was-ist-eine-Queue">
<title>Was muss ich mir unter einer Queue vorstellen?</title>
<para>
	Wer verhandlungssicheres Englisch spricht, für den mag es etwas
      komisch erscheinen, dass OTRS.de sich die Mühe macht, einen englischen
      Begriff zu erläutern. Queues sind jedoch für den produktiven Einsatz von
      OTRS sehr wichtig, da sie quasi als Grundkonzept hinter allem stehen!
</para>
<para>
	Normalerweise werden E-Mails (und wie oben schon erwähnt auch
      Trouble Tickets die üblicherweise als solche ankommen) in einer INBOX
      verwaltet. Eine INBOX ist im Prinzip nur eine große Datei, in der
      einfach nur alle E-Mails aneinandergereit werden und der neue E-Mails
      einfach am Ende angefügt werden. Das E-Mail Programm strukturiert diese
      Datei und bereitet den Inhalt für den Anwender auf.
</para>
<para>
	Eine Queue ist ein Mechanismus mit dessen Hilfe viele Tickets
      gespeichert und verwaltet werden können. Als Anwender ist es völlig
      unwichtig zu wissen, wo oder wie das Ticket gesichert ist. Wichtig ist
      nur zu wissen, welcher Queue das Ticket zugeordnet wurde. Anwender sog.
      Agents können nun Tickets zwischen den Queues verschieben! Warum aber
      sollte sie das tun? Weil durch das Sortieren der Tickets in
      unterschiedliche Queues Ordnung geschaffen und somit ein besserer
      Überblick entsteht. Nehmen wir mal an, das unser Unternehmen täglich 200
      E-Mail zu den unterschiedlichsten Themenbereichen erhält. Hier um
      kümmern sich 3 Teams von Spezialisten. Es wäre nicht besonders sinnvoll
      oder gar effizient, wenn jeder Spezialist jede E-Mail lesen muss.
      Zeitverschwendung! Sinnvoller wäre es, einen Agent (den sog. Dispatcher)
      abzustellen, der die Tickets aus einer Eingangsqueue in die
      entsprechenden Queues verteilt! Das spart Zeit und somit Geld!
</para>
</sect1>
</chapter>

