Trouble Ticket system Windows

Fehler-Ticket-System Windows

Gehen Sie zu einer Support-Seite oder öffnen Sie ein Ticket per Mail. Vollständiger Überblick über die Helpdesk-Leistung und -Metriken, die unter Windows und Linux ausgeführt werden. Bei Mystic handelt es sich um ein Open Source Trouble Ticket System, das in Ruby on Rails (RoR) geschrieben wurde. Das SupportCenter Plus wandelt Kundenanfragen über verschiedene Kommunikationskanäle in Tickets zur Bearbeitung um. Anwendungsfenster können Sie das Trouble-Ticket-System aufrufen.

mm-it.

Netzwerkmanagement / Trouble Ticket Systeme als Grundlage

User Helpdesk wird zum Kernstück des zentralen Netzwerkmanagements.

Unterstützt werden die Sachbearbeiter durch so genannte User Help Desks. Jürgen Suppan* gibt in seinem Vortrag einen Richtlinienvorschlag für die Konzeption und den Betrieb von technologieübergreifenden User Help Desks und Trouble Ticket Systems. Der in den vergangenen Jahren zunehmend erzwungene Wechsel von zentraler Datenverarbeitungslösung zu dezentralen Lösungen hat für die Nutzer dieser Techniken eine Vielzahl von schwerwiegenden Folgen gehabt.

In der Regel werden von den beteiligten Endverbrauchern heute folgende Anforderungen gestellt: - Hochverfügbarkeit der unterstützten Techniken und Erzeugnisse, - Hochwertigkeit der Leistungen, - schnelle Reaktionsgeschwindigkeit, - wählbarer Leistungsumfang und Qualität auf der Grundlage von schriftlichen und überprüfbaren Absprachen. - Die wirtschaftliche Kontrollierbarkeit und Funktionsfähigkeit von verteilten Datenverarbeitungstechnologien mit der geforderten Servicequalität sicherstellen, - fachgerechtes Fehlermanagement und vollständige Beherrschung des Verarbeitungsprozesses im Fehlerfall, - vorbeugendes Fehlermanagement und zielgerichtete Schwachstellenanalysen, - Verkürzung der Antwortzeiten auf Kundenwünsche und Fehlermeldungen,

Lösung von 80 prozentigen aller gemeldeten Störungen innerhalb von x min im Level 1 Helpdesk, - optimale Nutzung der personellen Ressourcen, Vermeiden von Mehrarbeit an der gleichen Ursache der Störung, - Systematisches Aufklären aller Beteiligten vom Endbenutzer bis zum Manager, - Erfassen der angefallenen anfallenden Mehrkosten und Erstellen eines Abrechnungsvorgangs. Ein LBS ist in dieser Variation beim Endverbraucher vorhanden und leistet in der Regel sehr anwendungsorientierte Supportarbeit (vgl. Bild 1).

Die LBS unterstützt vor allem die Endverbraucher, während der Betrieb des Systems, einschließlich des Netzwerks, an zentraler Stelle liegt. Der Nachteil ist, dass, wenn die LBS zu einem anderen Unternehmen gehört, die Identität und das berufliche Auftreten der Zentraldienste für den Endnutzer kaum zu erkennen sind. Darüber hinaus ergibt sich in großen Unternehmen ein Vervielfachungsfaktor für das Mitarbeiterpotenzial in der LBS, da pro mal Endnutzer ein Vorgesetzter benötigt wird.

Darüber hinaus ist es bei einer Verteilung der betroffenen Einrichtungen auf mehrere Dienststellen oder Hauptdienststellen nicht möglich, ein gemeinsames Vorgehen und Vorgehen zu erwirken. In Variante zwei gibt es jedoch kein LBS mit einer differenzierten zentralen Verarbeitung. Ob erfolgreich oder nicht, hängt von der Etablierung einer stabilen technologischen Basis und der Fähigkeit ab, klare und nicht zu viele Kontaktpunkte für den Endverbraucher zu schaffen (siehe Bild 2).

Nachteilig an diesem Ansatz sind der beträchtliche vorbereitende Aufwand und ggf. die Erfordernis einer vollständigen Umorganisation. Durch den optimalen Einsatz von Tools muss jede Ebene des User Helpdesk Prozess mit den notwendigen Tools ausgestattet werden. Es stehen folgende Werkzeuge zur Verfügung: - Trouble-Ticket-System, - Netzwerk- und Systemmanagement, - Online-Dokumentation, - Informations- und Berichtssysteme. Grundlage jeder Tool-Lösung für einen User Helpdesk ist das Trouble-Ticket-System.

Die Wahl eines Trouble-Ticketing-Systems erfordert eine grundsätzliche Entscheidung anhand von zwei Fragen: - Soll das Trouble-Ticketing-System "nur" die Verarbeitung von Fahrscheinen verwalten? Sie gibt dann nur einen Überblick darüber, welche Problemstellungen im Augenblick akute sind und in welchem Bearbeitungsstatus sie sich befinden sowie welche Problemstellungen in der Historie aufgetreten sind. Oder soll das Trouble-Ticket-System bei der Fehlersuche tatkräftig unterstützen, indem es auf Tastendruck die notwendigen Daten zur Verfügung stellt und den Betreiber während des Fehlersuchprozesses tatkräftig führt?

  • Eine sehr präzise und fachkundige Projekthandhabung und die erforderliche Projekt-Systematik, - Die Einbindung sehr komplizierter Werkzeuge, - Ein effizientes Systemhaus, welches die gesamte Verantwortung übernimmt. Wenn dies nicht gewährleistet ist, bringt die Variante B beträchtliche mit sich. Grundsätzlich besteht die Funktion eines Trouble-Ticket-Systems darin, Fehler zu erfassen und zu klassifizieren sowie die mit der Fehlerbearbeitung verbundenen Tätigkeiten zu koordinieren und zu überwachen und anschließend die aufgetretenen Fehler zu analysieren.

Das System sollte die nachfolgenden Voraussetzungen erfüllen: - Der gemeldete Fehler muss ein Ticket so generieren können, dass der Fehler eingestuft und beschreibbar ist. - Eine Fahrscheinübertragung an Einzelpersonen oder Gruppierungen muss möglich sein, um die Störung zu beheben. - Es muss zwischen einem Agenten und einem Ticketkoordinator unterschieden werden.

  • Eine Problemkarte muss mehrere Zustände haben können. Abhängig davon wird es möglich sein, zulässige und nicht zulässige Prozesse zu steuern. - Möglicherweise ist es so, dass ein System über ein leistungsfähiges System verfügt. Durch die Archivierung eines Tickets muss es möglich sein, zwischen der ursprünglichen Ursache der Störung und der tatsächlichen Ursache der Störung zu unterscheiden. - In dem Ticket müssen die für die Ticketbearbeitung anfallenden Kosten erfasst und einer Cost stelle oder einem Dienstleistungsvertrag zugeordnet werden können.
  • Die Import-Schnittstelle für die automatische Generierung von Eintrittskarten aufgrund von externen Ereignissen muss bereitstehen. - Zu diesem Zwecke müssen Exportschnittstellen zur Weiterleitung von Fahrscheinen oder Teilinformationen über Fahrscheine an die Außenwelt eingerichtet werden. - In Abhängigkeit von Änderungen des Ticketstatus muss es ein beliebig konfigurierbares Maßnahmenschema aufstellen. Viele Trouble Ticket Systeme verfügen über diese Grundfähigkeiten.

Entscheidend für die Wahl ist der Umfang der tatkräftigen Unterstützung durch das System im Umgang mit einem Fehler. Ein Trouble Ticket System sollte heute zumindest die folgenden Angaben enthalten: - Konfiguration der Hard- und Software des fehlerhaften Terminals, - Information über die Integration des Terminals in ein Netz mit detaillierten Angaben über die Anbindung an den nächsten im Netz tätigen Anbieter, - Konfigurationsinformation über das Versorgungsnetz, - Archivinformation über typ. Lösungen für ähnliche Problemstellungen in der Folge.

Mit der Identifizierung des Fehlerdetektors sollen alle weiteren über den Detektor verfügbaren Nutzdaten zum einen so weit wie gewünscht automatisiert in das Ticket eingegeben werden und zum anderen auf Tastendruck vollständig wiederhergestellt werden. Gleiches trifft auf die Endgerätedaten des Detektors und die Konfigurationsinformationen einer defekten Baugruppe zu. Die Einhaltung dieser Mindestvoraussetzungen ist nur durch ein Trouble-Ticket-System in Verbindung mit einem Online-Dokumentationssystem möglich.

Schon bei der Akzeptanz von mündlichen Nachrichten kann es passieren, dass mehrere Fahrscheine zu einer Störungsursache werden. Beispielsweise hat ein und dieselbe Störung mehrere Störungsbilder. Es ist auch möglich, dass eine Unterbrechung eine größere Anzahl von Anwendern trifft, die getrennt berichten, oder dass mehrere Berichte an unterschiedlichen Helpdesk-Arbeitsplätzen parallel erfasst werden.

Es besteht ein Zusammenhang zwischen Trouble Ticktes, wenn sie sich auf die gleiche Störungsursache berufen können, auch wenn dies aus den Informationen im Trouble Ticket nicht ersichtlich ist. Verschärft wird diese Problematik, wenn das Trouble-Ticket-System auch automatisiert erzeugte Anfragen aus Managementsystemen übernimmt. Es kann dann mehrere mündliche und verschiedene automatisierte Berichte über eine einzige Störungsursache geben.

Dieser Umstand ist charakteristisch für eine größere Client-Server-Architektur. Dies muss zwangsläufig zu der Anforderung führen, ein Trouble-Ticket-System so einstellen zu können, dass es eine so genannte Ticketgruppe formt, in der alle potenziell korrelierenden Lose zusammengeführt werden. Die meisten Trouble-Ticket-Systeme haben hier große Schwierigkeiten, da sie nur über Keywords und Description-Texte miteinander auskommen.

Eine große Ausnahmen bilden Trouble-Ticket-Systeme mit eingebauter Online-Dokumentation, da sie über die kompletten Zusammenschaltungsinformationen der Bauteile verfügen und damit Korrelationszusammenhänge aus der Schaltungstopologie ableiten können. Das Trouble Ticket System bietet nur in Kombination mit anderen Werkzeugen aktiven Support bei der Fehlersuche und vollständige Information für alle Agenten. Daten, die in ein Trouble Ticket einfließen sollen, stammen in der Praxis meist aus Netzwerk- und Systemmanagementlösungen.

Beim Koppeln dieser Anlagen muss die Kopplungsschnittstelle oder das Managementsystem über beträchtliche Vorfiltermöglichkeiten verfügen, wenn man nicht eine Totalflutung des Trouble-Ticket-Systems befürchten will. Durch die Exportmöglichkeiten eines Trouble-Ticket-Systems eignet es sich als Informationszentrale. Daher muss die Ausgabe- oder Exportschnittstelle eines Trouble-Ticket-Systems an Emailsysteme und an nicht netzverbundene Rufanlagen angeschlossen sein.

Grundlage jeder gelungenen Lösung ist ein Fehlerdiagramm.

Mehr zum Thema