RZ-Mitteilungen
Nr. 23
Mai 2002
Service
Metadaten
Hinweise
Weitere Artikel aus dem cms-Journal Nr. 23 finden Sie auf dem edoc-Server der Humboldt-Universität zu Berlin unter http://edoc.hu-berlin.de/cmsj/23
Copyright
Dieser Artikel ist ein Open Access Artikel und steht unter der Creative Commons Lizenz BY (siehe...).

Vorhaben Trouble-Ticket-System

Uwe Kirchner
uwe.kirchner@rz.hu-berlin.de
Velislav Petrov
velislav=petrov@rz.hu-berlin.de

Abstract

Für den effizienten Betrieb eines Benutzerservice, wie der Hotline der Abteilung „DV in der Verwaltung", ist der Einsatz adäquater elektronischer Systeme zur Unterstützung der bestehenden Abläufe von großem Vorteil. So können für die Erfassung, Klärung, Bearbeitung und Lösung von Problemen so genannte Help-Desk-Systeme eingesetzt werden. Das Trouble-Ticket-System ist so eine Help-Desk-Lösung, die demnächst in die Arbeit der Hotline-Betreuung integriert werden soll. Der nachfolgende Artikel geht auf die wesentlichen Inhalte dieses Systems ein.


Die gegenwärtige Situation in der Hotline

Eine der wichtigen Aufgaben in der Abteilung „DV in der Verwaltung" ist die kontinuierliche DV-technische Betreuung der ca. 450 Angestellten und Mitarbeiter der Universitätsverwaltung. Um aufgetretene Probleme an Hard- und Software aufzunehmen, Lösungsvorschläge anzubieten oder auch den Nutzern Informationen bezüglich der PC-Nutzung zu erteilen, sind Hotline-Nummern eingerichtet worden, die von mehreren RZ-Mitarbeitern betreut werden.

Der jetzige Ablauf der Nutzerbetreuung in der Abteilung DV in der Verwaltung sieht folgendermaßen aus: Bei Auftreten eines Problems kontaktiert der Nutzer einen der Hotline-Betreuer. Dieser versucht zunächst, die Beschaffenheit der Störung zu klären und möglichst bereits am Telefon Abhilfe zu leisten, oder er kümmert sich persönlich vor Ort um die Fehlerbeseitigung. Wenn die Zuständigkeit nicht beim Hotline-Betreuer liegt, wird der Auftrag entsprechend weitergeleitet (an Techniker, Account-Verwalter usw.).

In diesem Ablauf könnten einige Punkte effizienter gestaltet werden. Zum einen steigt nach einer eventuellen Weiterleitung eines Auftrags seitens des Hotline-Betreuers der Zeitaufwand (z. B. wegen der Zuständigkeitsklärung) für die Problemlösung, und der Betreuer verliert den weiteren Verfahrensverlauf aus den Augen. Zum anderen könnten typische und häufig auftretende Problemmeldungen in einer Datenbank erfasst und klassifiziert werden sowie bereits angewendete erfolgreiche Lösungsansätze zwecks einer späteren Anwendung gespeichert und abgerufen werden. Dadurch wird eine Beschleunigung der Problembehebung sowie die sinnvolle Nutzung bereits gesammelter Erfahrungen des RZ-Personals erzielt.

Diese Überlegungen haben zu der Entscheidung geführt, im Rechenzentrum ein Trouble-Ticket-Systems (TTS) zu implementieren und zu testen. Dieses System bietet die Möglichkeit einer automatisierten Bearbeitung von Störungsmeldungen auf der Basis des freiverfügbaren Produktes GNATS. Es wird bereits erfolgreich an anderen Universitäts- und Hochschulrechenzentren eingesetzt. Das Interface wird mit Hilfe von HTML-Seiten und Perl-Skripten realisiert, so dass ein weitgehend systemunabhängiges und einfaches Bearbeiten möglich wird. Die potentiellen Anwender werden dabei sowohl unter den Nutzern in der Universitätsverwaltung als auch unter den Mitarbeitern innerhalb der zuständigen Abteilungen des Rechenzentrums gesehen.

Inhaltsverzeichnis

Die gegenwärtige Situatio...

Anwendung des Systems aus...

Anwendung des Systems aus...


Anwendung des Systems aus der Sicht des Nutzers

Beim Auftreten eines Problems startet der Nutzer über eine auf dem Desktop eingerichtete Verknüpfung das webbasierte Formular des TTS. Als erstes wird versucht, das Problem einer vorgegeben Kategorie (Hardware, Software, Netz, ...) zuzuordnen – hierfür werden die Erfahrungen aus der Verwaltungs-Hotline verwendet (siehe Abb. 1).

image

Abb. 1: Fehlerkategorien

image

Abb. 2: Häufig auftretende Fehlersituationen

In einem nächsten Schritt werden dem Nutzer einige in dieser Kategorie besonders oft vorkommende Probleme aufgelistet (Abb. 2) und bei einer eventuellen Übereinstimmung Lösungswege aus der Datenbank angeboten (Abb. 3). Ist das Problem damit gelöst, wird der weitere Vorgang abgebrochen. Wenn der Nutzer sich aber nicht selbst helfen konnte oder wenn die Störung anderer Art als die aufgelisteten ist, wird in einem letzten Schritt vor der Kontaktaufnahme versucht, das Problem bezüglich seiner Auftretenshäufigkeit, der Anzeige einer Fehlermeldung oder sonstiger Besonderheiten weiter zu spezifizieren (Abb. 4).

image

Abb. 3: Lösungsvorschläge

image

Abb. 4: Informationen des Nutzers für die Hotline

Nach Abschicken des Fehlerprotokolls erhält der Nutzer eine Eingangsbestätigung mit einer Auftragsnummer und dem Namen des zuständigen RZ-Mitarbeiters, der die weitere Bearbeitung übernimmt.

Der gerade beschriebene Ablauf einer Störungsmeldung wurde bewusst so strukturiert, um der Benutzerfreundlichkeit bei der Anwendung des TTS Rechnung zu tragen. So werden bei der Problembeschreibung größtenteils bereits abgefasste Formulierungen vorgegeben und durch Anklicken zur Auswahl gestellt. Der Benutzer spart Zeit bei der Beschreibung seines Problems, wodurch auch die gesamte Bearbeitungsdauer des Störungsfalles verkürzt werden soll. Es kann weiterhin von den Nutzern im Allgemeinen nicht erwartet werden, das Problem selbst bis ins Detail zu beschreiben: die bisherige Praxis hat gezeigt, dass viele Nutzer – was verständlich ist – sich mit den Fachbegriffen nicht gut auskennen („Windows startet nicht" bedeutet zu oft „Rechner bootet nicht"). Das Vokabular sollte sich daher auf allgemeinverständliche und geläufige Fachausdrücke beschränken. Außerdem wird bewusst auf die Abfrage von Angaben zu technischen Details, wie Grafikkarte, Prozessor, Arbeitsspeicher usw., verzichtet. Zum einen setzt das eine höhere PC-fachliche Kompetenz voraus, zum anderen sind diese Daten sowieso meistens vom Rechenzentrum bereits erfasst. Dies alles soll zu einer breiteren Akzeptanz des TTS führen – sonst ist der Griff zum Telefonhörer meist einfacher.

Inhaltsverzeichnis

Die gegenwärtige Situatio...

Anwendung des Systems aus...

Anwendung des Systems aus...


Anwendung des Systems aus der Sicht des Bearbeiters

Das TTS GNATS ist so aufgebaut, dass jeder der definierten Kategorien ein oder auch mehrere zuständige RZ-Mitarbeiter zugeordnet sind, so dass die Störungsmeldung automatisch den unmittelbaren Betreuer erreicht. Handelt es sich beispielsweise um einen nicht funktionierenden Drucker, so wird nach Abschicken der entsprechenden Problemmeldung seitens des Nutzers ein Trouble-Ticket erzeugt und mittels E-Mail in die Auftragsliste eines verantwortlichen Technikers eingetragen. Dieser hat jederzeit die Möglichkeit, seine anstehenden Aufgaben über das Internet einzusehen, deren Status (offen, in Bearbeitung, Bearbeitung ausgesetzt, auf Rückmeldung wartend, abgeschlossen) zu aktualisieren bzw. das Trouble-Ticket einem anderen Verantwortlichen zuzuordnen. Weiterhin hat er eine bestimmte Zeit zur Verfügung, sich um das Problem zu kümmern – sollte innerhalb dieser Zeit keine Veränderung des Status erfolgen, so sendet ihm das System automatisch eine Erinnerung. Des Weiteren kann jeder in der Liste der zuständigen Bearbeiter eingetragene Betreuer auch in die anstehenden Aufgaben seiner Kollegen einsehen, jedoch deren Status nicht verändern – dies kann nur durch den Administrator des Systems erfolgen. Bei der Fehlerbeseitigung trägt der Mitarbeiter seinen Lösungsansatz (oder auch die fehlgeschlagenen Versuche) in das Trouble-Ticket ein, das dann in der TTS-Datenbank gespeichert wird. Diese Tatsache bringt einen wichtigen Nutzen mit sich: jeder RZ-Mitarbeiter kann bei seiner Suche nach Lösungswegen diese Datenbank nach bestimmten Kriterien (Kategorie, Bearbeiter, Nutzer oder auch nach beliebigem Text/Stichpunkt in dem Trouble-Ticket) abfragen.

Abschließend soll noch festgehalten werden, dass die Vorzüge des TTS nur dann voll zum Tragen kommen, wenn sowohl die Nutzer als auch die RZ-Mitarbeiter diese elektronische Unterstützung konsequent annehmen. Seitens der Betreuer ist es besonders wichtig, Lösungswege für eine spätere schnelle Problembehebung so detailliert wie möglich in die Trouble-Tickets einzutragen. Denn letztendlich zählt für den Nutzer an erster Stelle das Endergebnis – wie schnell konnte das aufgetretene Problem vom Rechenzentrum gelöst werden.

Inhaltsverzeichnis

Die gegenwärtige Situatio...

Anwendung des Systems aus...

Anwendung des Systems aus...