Kapitel 1. Trouble-Ticket-Systeme - die Grundlagen
From open-support.info
 |
The master document of this page is updated! Master document: Book:OTRS 3.0 - Admin Manual/Chapter 1 Current revision: 1933 This page refers to: 1856 (Show difference) |
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.
Contents |
Was ist ein Trouble-Ticket-System, und warum benötigen Sie eins?
Das folgende Beispiel soll verdeutlichen, was ein Trouble Ticket System ist und wie Sie damit in Ihrem Unternehmen Zeit und Geld eingesparen können.
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.
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.
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.
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.
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.
Was ist ein Trouble-Ticket?
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.
Im OTRS werden Trouble Tickets, also die Krankenblätter aus dem obigen Beispiel, als normale E-Mails behandelt und gespeichert. Schicktz. 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.
