Entwicklung eines Werkzeugs für die Administration eines Trouble Ticket Systems

Transkript

1 Entwicklung eines Werkzeugs für die Administration eines Trouble Ticket Systems Rainer Kruse 2001 Forschungsberichte des Fachbereichs Elektrotechnik und Informationstechnik ISSN /2001

2 Fachbereich Elektrotechnik und Informationstechnik Lehrgebiete Allgemeine und Theoretische Elektrotechnik Prof. Dr.-Ing. R. Pregla Datenverarbeitungstechnik Prof. Dr.-Ing. B. Krämer Informationstechnik, insbesondere Realzeitsysteme Prof. Dr.-Ing. W.A. Halang Nachrichtentechnik Prof. Dr.-Ing. L. Kittel Prozeßsteuerung und Regelungstechnik Prof. Dr.-Ing. H. Hoyer Bauelemente der Elektrotechnik Prof. Dr.rer.nat. W. Fahrner Elektrische Energietechnik Prof. Dr.-Ing. D. Hackstein Elektronische Schaltungen Prof. Dr.-Ing. H. Wupper Kommunikationssysteme Prof. Dr.-Ing. F. Kaderali Optische Nachrichtentechnik Prof. Dr.-Ing. J. Jahns Herausgeber: Prof. Dr.-Ing. B. Krämer

3 Satz: Vertrieb: FernUniversität Hagen Nur über das Internet unter Forschungsbericht 2/2001 Entwicklung eines Werkzeugs für die Administration eines Trouble-Ticket-Systems Rainer Kruse 2001 Zur Veröffentlichung empfohlen von Prof. Dr.-Ing. Krämer Rainer Kruse 2001

4 EINLEITUNG UND ÜBERSICHT 3 1 GRUNDLAGEN UND AUSGANGSSITUATION Das Fehlermanagement als Kernaufgabe eines Benutzerservice Die Aufgaben eines Trouble-Ticket-Systems Trouble Ticket Management Statistik und Reports Zugriff auf Problemlösungswissen Integration in das Systemmanagement Korrelation von Trouble Tickets Das Fehlermanagement bei der LBS Nord ARS - das Trouble Ticket System bei der LBS Die ARS-Architektur Die ARS-Komponenten Das Trouble-Ticket-System im praktischen Einsatz 14 2 MOTIVATION UND ZIELE Automatisierte Unterstützung bei der Aktualisierung von Auswahlfeldern Automatisierte Unterstützung bei der Erstellung einer Falldatenbank 18 3 AKTUALISIERUNG VON AUSWAHLFELDERN ZUR KLASSIFIZIERUNG VON TROUBLE TICKETS Information Retrieval Dokumenteninhalte beschreiben, darstellen und wiederfinden Freitextsuche Klassifikation und Thesaurus Automatische und computerunterstützte Indexierung IR Modelle Das TTS-Administrations-Werkzeug Berichterstellung im ARS Die Benutzeroberfläche des Administrationswerkzeugs Das Anwendungsmodul Neue Begriffe

5 3.2.4 Der ARS-Datenimport Das Anwendungsmodul Verwendete Klassen 41 4 ERSTELLEN EINER FALLSAMMLUNG Die Lösungssuche im ARS Fallbasiertes Schließen Das Anwendungsmodul Neue Fälle 46 5 ZUSAMMENFASSUNG UND AUSBLICK 50 6 GLOSSAR 52 7 ABKÜRZUNGSVERZEICHNIS 53 8 LITERATUR 54 9 ABBILDUNGSVERZEICHNIS

6 Einleitung und Übersicht Mit der Ausbreitung der Informationstechnologie in nahezu alle Bereiche eines Unternehmens wurde die Bedeutung eines effizienten Fehlermanagements für die EDV-Anwender und für das Unternehmen deutlich. Dabei umfasst das Fehlermanagement das Entdecken, Eingrenzen und Beheben von abnormalem Verhalten der beteiligten DV-Systeme [Hegering u.a. 99]. Aufgrund der steigenden Komplexität der Systeme durch Vernetzung, räumliche Verteilung, oft über mehrere Standorte, sowie die zunehmende Heterogenität der Hard- und Softwarekomponenten ist es für den Anwender oft gar nicht möglich, die Ursache für eine Störung einzugrenzen und den verantwortlichen Systembetreuer zu identifizieren oder die Störung gar selbst zu beheben. Außerdem sind die Mitarbeiter für andere Aufgaben im Unternehmen zuständig, die sie professionell erledigen können. Die Behandlung von Fehlern in den EDV- Systemen muss ihnen von anderen Organisationseinheiten abgenommen werden, die sich auf das Fehlermanagement spezialisiert haben. Hierfür wurde in vielen Unternehmen ein Benutzerservice, oft auch englisch User Help Desk genannt, eingerichtet. Die Aufgabe des Benutzerservice besteht darin, die Verfügbarkeit und Zuverlässigkeit der Systeme und seiner Dienste durch schnelle Entdeckung und Beseitigung von Fehlern möglichst hoch zu halten. Für das Erreichen dieses Zieles benötigt er ein Werkzeug, das ihn bei der professionellen Behandlung und Dokumentation von Problemen in verteilten Netzwerken unterstützt. Für ein solches Fehlerdokumentationssystem oder auch Störungsverfolgungssystem hat sich allgemein die Bezeichnung Trouble-Ticket-System (TTS) durchgesetzt. In diesem Zusammenhang wird ein Datensatz, der alle zu einer Störung gehörenden Daten wie Störungsmelder, betroffene Komponenten, Störungssymptome, Lösung usw. zusammenfasst, Trouble Ticket (TT) genannt. Nachdem zu Beginn des 1. Kapitels eine kurze Einführung in das Fehlermanagement erfolgt, wird anschließend ausführlich auf die Funktionen eines TTS eingegangen. Dabei wird sich zeigen, dass sich die Aufgaben eines TTS von der reinen Verwaltung von Störungsmeldungen bis hin zu komplexen Unterstützungsaufgaben für das Fehlermanagement erstrecken. Das Kapitel schließt mit der Beschreibung des TTS der LBS Nord. Ein wichtiger Aspekt bei der Betrachtung vernetzter Systeme ist, dass sich die IT-Landschaft im Unternehmen ständig verändert. Ein System, dass der Unterstützung des Fehlermanagements dienen soll, muss sich diesen Veränderungen anpassen können. Dabei ist sicherzustellen, dass der Aufwand für die Administration überschaubar bleibt. In Kapitel 2 werden dazu zwei Ansätze erläutert, die Administratoren eines TTS bei ihrer Arbeit zu unterstützen. Beim Erfassen einer Störungsmeldung greifen die Bediener des TTS auf Einträge in Auswahlfeldern zurück. Das dritte Kapitel der Arbeit beschäftigt sich damit, aus Freitextfeldern, die der näheren Beschreibung der Störung dienen, automatisch die Informationen herauszufiltern, die den Bedienern zukünftig als Menüpunkte zur Auswahl angeboten werden sollen. In diesem Zusammenhang werden verschiedene Methoden der Textanalyse und des Information Retrieval (IR) aufgezeigt. Ein Administrationswerkzeug wendet diese Methoden an und liefert die Ergebnisse an das TTS der LBS zurück. In einem TTS sammelt sich das Problemlösungswissen einer IT-Supportorganisation. Ein Bediener kann dieses Wissen bei neuen Problemen zu Rate ziehen. Die Basis für die Interpretation der TT als Fallbeispiele liefert das fallbasierte Schließen, das im vierten Kapitel vorgestellt wird. Die Arbeit endet mit der Beschreibung einer Erweiterung für das Administrationswerkzeug zum Erstellen einer Fallsammlung

7 1 Grundlagen und Ausgangssituation 1.1 Das Fehlermanagement als Kernaufgabe eines Benutzerservice Eine Kernaufgabe des Benutzerservices ist das Fehlermanagement, das sich in die Phasen Fehlererkennung, Fehlerdiagnose und Fehlerbehebung gliedert [Probst 95]. Während der Fehlererkennung werden Störungen und Probleme frühzeitig erkannt und erfasst. Dabei kann die Störungsmeldung an den Benutzerservice durch den Anwender, einen Systemadministrator oder auch durch eine Managementplattform erfolgen. Bei der Erfassung sollen alle wesentlichen Daten zu der Störung, zum Störungsmelder und zur betroffenen Systemkomponente aufgenommen werden. Anschließend erfolgt die Klassifizierung der Störung. Hierbei wird die Störung einem Sachgebiet zugeordnet. Als Sachgebiete können z.b. Netzwerk, Hardware oder Software dienen, wobei eine Klassifizierung auch in wesentlich feinere, mehrstufige Unterteilungen erfolgen kann. Die Fehlererkennung endet mit der Zuweisung und Benachrichtigung (Notifikation) des zuständigen Fachbereiches bzw. des zuständigen Sachbearbeiters. Während der Fehlerdiagnose findet die Identifikation der Störungsursache mit Hilfe der bei der Fehlererkennung erfassten Daten statt. Hierfür benötigt der Bearbeiter ein fundiertes Problemlösungswissen. Dabei greift er auf die technischen Unterlagen der Hersteller, Informationsforen im Internet zu bestimmten Sachgebieten, FAQs usw. zurück. Wesentliche Voraussetzung für eine erfolgreiche Fehlerdiagnose bleibt jedoch das persönliche Problemlösungswissen, die Erfahrung des Bearbeiters. Zur Steigerung der Effizienz im Benutzerservice muss es daher Ziel sein, das Problemlösungswissen der einzelnen Mitarbeiter in der Supportorganisation des Unternehmens allen am Fehlermanagement beteiligten Mitarbeitern zugänglich zu machen. Auf diese Weise wird einem Flaschenhalseffekt - die Problemlösung in einem konkreten Fall kann nur durch einen bestimmten Bearbeiter erfolgen - entgegengewirkt. Wenn einem Mitarbeiter die Diagnose der Störung nicht gelingt, muss die Störungsmeldung an einen qualifizierteren Experten weitergegeben werden (Eskalation/Routing). Wenn der Fehler diagnostiziert ist, beginnt die Fehlerbehebung. Die Behebungsmaßnahme mündet in die Wiederherstellung der Funktion der betroffenen Komponente. Abschließend wird der Störungsmelder über die Behebung der Störung informiert und die Störungsmeldung wird geschlossen. Abbildung 1-1 Die Phasen des Fehlermanagement - 4 -

8 An jeder Phase des Fehlermanagements können mehrere Bearbeiter beteiligt sein, die für ihre Aufgabe im Fehlermanagement die aktuellen Daten zur Störung benötigen und sich über die schon erfolgten Diagnosemaßnahmen informieren müssen. Eine Mehrfachbearbeitung sollte ebenso vermieden werden wie ein ständiges Weitergeben der Störungsmeldung von einem Mitarbeiter zum nächsten aufgrund von Zuständigkeitstreitereien (Ping-Pong-Effekt). Weiterhin erwartet der Störungsmelder vom Benutzerservice eine gleichbleibend hohe Servicequalität, unabhängig vom aktuell zuständigen Bearbeiter. Insbesondere falsche Diagnosen von in früheren Fällen bereits richtig analysierten Störungen durch weniger erfahrene Mitarbeiter müssen ausgeschlossen werden. Falls es zu Nachfragen oder Beschwerden durch den Störungsmelder kommt, muss es jederzeit möglich sein, den aktuellen Sachstand zur Störungsmeldung nachzuweisen. Hierzu ist es erforderlich, einen ständigen Überblick über den eindeutigen Bearbeitungszustand zu haben. Aus diesen Gründen ist es notwendig, alle Teilschritte im Fehlermanagement zu dokumentieren. Darüber hinaus stellt eine sorgfältig strukturierte Dokumentation der Störungen die Basis für eine Vielzahl von erweiterten Funktionen für das Fehlermanagement dar, auf die im Weiteren näher eingegangen wird. Im nächsten Abschnitt wird gezeigt, wie ein Trouble-Ticket-System das Fehlermanagement sinnvoll unterstützen kann. 1.2 Die Aufgaben eines Trouble-Ticket-Systems Die grundsätzliche Idee eines Trouble-Ticket-Systems (TTS) ist das Speichern und Verwalten von Störungsmeldungen, den sogenannten Trouble Tickets (TT), in einer Datenbank. Alle ausgeführten Tätigkeiten während der Störungsbearbeitung werden im TT dokumentiert [Dreo 95]. Bei einer Gliederung des Systems in Funktionsblöcke wird diese Aufgabe als Trouble Ticket Management bezeichnet. Aus dieser Kernaufgabe des Systems ergibt sich eine Vielzahl von Erweiterungen, die die Leistungsfähigkeit des Netzwerkbetriebes erheblich verbessern können [RFC1297]. Dabei dienen die Erweiterungen sowohl der Verbesserung des Trouble Ticket Managements als auch der Schaffung neuer Funktionsblöcke wie Statistiken und Reports, Zugriff auf Problemlösungswissen, Integration in das Systemmanagement und Korrelation von Trouble Tickets. Abbildung 1-2 Die Funktionsblöcke eines TTS - 5 -

9 Die Unterscheidung zwischen Basis- und Erweiterungsfunktionen in einem TTS wird in der Literatur durchaus unterschiedlich interpretiert. Funktionen, die vor einigen Jahren noch als Erweiterung eines TTS galten, gehören heute selbstverständlich zum Funktionsumfang Trouble Ticket Management Das Trouble Ticket Management unterstützt alle Phasen des Fehlermanagements, indem es den Mitarbeitern des Benutzerservices die Möglichkeit gibt, die während der einzelnen Schritte gesammelten Informationen strukturiert und für alle am Fehlermanagement Beteiligten verfügbar abzuspeichern. Darüber hinaus stellt es Funktionalitäten zur Verfügung, welche die Arbeitsabläufe aller für den Betrieb zuständigen Organisationen unterstützen. Der erste Schritt im Trouble Ticket Management ist das Erstellen eines TT. Dabei kann die Störung auf unterschiedlichen Wegen in das TTS gelangen. Im klassischen und wohl auch heute noch häufigsten Fall wird die Störung von einem Anwender bemerkt und dann telefonisch an den Benutzerservice gemeldet. Ein Mitarbeiter des Benutzerservice nimmt die Daten vom Störungsmelder entgegen und gibt diese in das TTS ein. Hierzu wird den Anwendern vom Benutzerservice eine zentrale Rufnummer angeboten, die innerhalb der Servicezeiten ständig besetzt sein muss. Eine Entlastung des Benutzerservice kann erreicht werden, wenn die Erfassung der Daten dem Anwender überlassen wird, indem man ihm Zugang zu den Erfassungsformularen über TTS-Clients oder über Web verschafft oder strukturierte s in das TTS übernimmt. Dabei ist jedoch davon auszugehen, dass eine zusätzliche Fehlerqualifizierung erforderlich wird. Die Datenerfassung durch die Mitarbeiter des Benutzerservice, die mit der Bedienung des TTS und der Beschreibung von Störungen vertraut sind, erreicht selbstverständlich eine wesentlich höhere Qualität. Eine weitere Möglichkeit zur Entlastung ist die automatische Generierung von TT aus Systemmanagementwerkzeugen heraus. In jedem Fall hängt die Effizienz eines TTS zu einem Großteil von der Exaktheit und Vollständigkeit der zu einem TT verfügbaren Informationen ab [Hegering u.a. 99]. Einmal ermittelte Daten sollen allen Mitarbeitern, die das TT zu einem späteren Zeitpunkt weiterbearbeiten, ohne wiederholte Recherche zur Verfügung stehen. Bei allen Möglichkeiten der TT-Erstellung muss eine bestimmte Grundmenge von Daten erfasst werden, die sogenannten Grunddaten eines TT [Valta&Dreo 93], die in vorgegebene Felder der TT-Datenbank abgelegt werden. Tabelle 1-1 zeigt die Grunddaten eines TT: Ticket-ID Ticket-Zustand Benutzerdaten Komponenten-/Dienstdaten Zeitstempel Fehlerdaten Organisationsdaten Tabelle 1-1: Grunddaten eines TT Die Ticket-ID ist eine eindeutige Identifikationsnummer für ein TT. In vielen produktiven Systemen wird dem Anwender bei der Erfassung seines Tickets diese Nummer mitgeteilt, um bei Nachfragen schnell auf das TT - 6 -

10 zugreifen zu können. Der Ticket-Zustand gibt den Bearbeitungsstand des TT an. Typische Werte für den Ticket- Zustand sind offen, weitergeleitet, in Bearbeitung, wartend und gelöst. Die Benutzerdaten enthalten die persönlichen Daten des Störungsmelders, die Komponenten- oder Dienstdaten die Einzelheiten zu den betroffenen Geräten oder Diensten. Alle wichtigen Aktionen der Störungsbearbeitung werden in einem TTS mit Zeitstempeln gespeichert. Der erste Zeitstempel hält fest, wann der Fehler aufgetreten oder gemeldet worden ist. Es folgen Fehlerdaten, die die Störung beschreiben. Die Organisationsdaten enthalten Angaben zur organisatorischen Abwicklung der Fehlerbearbeitung, z.b. wer das TT erfasst hat, wer es bearbeitet usw. Eine weitere, wichtige Angabe zu einem TT, die in den Organisationsdaten hinterlegt wird, ist die Festlegung einer Dringlichkeit oder Priorität. Anhand der Priorität kann ein Mitarbeiter schnell erkennen, ob bei einer Störungsmeldung sofort reagiert werden muss oder in welchem zeitlichen Rahmen die Fehlerbehebung möglich ist. Dabei kann die Auffassung darüber, ob ein TT eine bestimmte Dringlichkeit erhält, von Anwendern und Bearbeitern durchaus unterschiedlich sein. Einige Systeme versuchen dies zu berücksichtigen, indem sie der Bewertung des Anwenders eine entsprechende Bewertung des zuständigen Bearbeiters gegenüberstellen. Wenn die Grunddaten des TTS erfasst sind, wird das TT auf Grund der beschriebenen Störungssymptome klassifiziert. Eine sorgfältige Klassifizierung der Störungsmeldungen liefert die Grundlage für eine Analyse des Systemverhaltens. Weiter kann der Bearbeiter zu einer bestimmten Problemklasse bekannte Problemlösungen einsehen und letztlich könnten bei eindeutig zugeordneten Fehlern automatische Fehlerbehebungsmaßnahmen wie z.b. der Neustart einer Komponente eingeleitet werden. Die beschriebenen Maßnahmen sind nur durchführbar, wenn alle Bearbeiter des TTS bei der Fehlerbeschreibung die gleichen Begriffe verwenden. Dies ist nur möglich, wenn die Klassifizierung über vorgegebene Auswahlfelder erfolgt. Dazu wird in der Regel vor Einführung des TTS eine Untersuchung durchgeführt, um die häufigsten Fehlersituationen für das Einsatzgebiet des TTS zu ermitteln. Daraus resultiert eine Begriffsmenge, mit der eine Domäne hinsichtlich ihrer IT-Struktur, insbesondere der möglichen Störungen, beschrieben werden kann. Unter einer Domäne versteht man dabei eine Menge von Objekten mit gleichen technischen oder administrativen Eigenschaften und einer gemeinsamen Verwaltungsautorität [Hegering u.a. 99]. Das Wörterverzeichnis aller die Domäne charakterisierenden Begriffe wird als Domänenvokabular bezeichnet. In einem gut konfigurierten TTS finden sich die wichtigsten Ausdrücke des Domänenvokabulars in den Auswahlfeldern wieder. Allerdings muss den Benutzern des TTS neben den Auswahlfeldern auch immer die Möglichkeit gegeben werden, Freitext einzugeben. Sie wären sonst bei bestimmten Störungssituationen, die bei der Konfiguration des Systems nicht berücksichtigt wurden, gezwungen, ungenaue (oder gar falsche) vorgegebene Begriffe zu verwenden. Alle bisher beschriebenen Funktionen im Trouble Ticket Management werden idealerweise bei der Ersterfassung des TT durchgeführt. Dabei bietet es sich an vielen Punkten an, die Datenerfassung durch Verknüpfung mit weiteren Datenbanken zu vereinfachen und dadurch zu beschleunigen. Ein Störungsmelder möchte möglichst schnell sein Problem anzeigen und nicht vorher lange Auskunft zu seiner Person und seiner DV-Ausstattung geben. So kann z.b. auf eine Personendatenbank zurückgegriffen werden, um die Daten zum Störungsmelder in das TT zu übernehmen. Bei modernen Verfahren wie CTI (Computer Telefon Integration) wird die Rufnummer des Störungsmelders beim Anruf aus der Telefonanlage in das TT übergeben und gleichzeitig werden aus einer Personendatenbank alle weiteren Information ins TT übertragen. Des Weiteren bietet sich die Ankopplung an eine Inventardatenbank für die Komponenten des verteilten Systems an, aus der die Gerätedaten zu einer gestörten Komponente ausgelesen werden können

11 Anschließend folgt ein erster Versuch, das TT sofort zu lösen. Sollte die sofortige Behebung des Fehlers nicht möglich sein, wird das TT der nächsten Supportebene zugewiesen. Oft wird die Supportorganisation mehrstufig aufgeteilt, wobei man bei den internen Abteilungen von 1 st -Levelund 2 nd -Level-Support spricht [Jagodic u.a. 98]. Der 1 st -Level-Support erfolgt in der Hotline während der 2 nd - Level-Support durch eine spezialisierte Abteilung, z.b. die Netzwerkabteilung, durchgeführt wird. Auf der höchsten Stufe ist ein externer Dienstleister eingebunden, der häufig eine bestimmte Gerätegruppe, wie z.b. PCs oder Drucker, betreut. Mit jeder Stufe steigt die Qualifikation, aber auch die Spezialisierung der Bearbeiter. Grundsätzlich gilt, dass in der Störungsannahme Mitarbeiter beschäftigt sind, die als Generalisten alle Aspekte des verteilten Netzes kennen, jedoch auf relativ niedrigem Niveau, während in der nachgeordneten zweiten Supportebenen Experten für bestimmte Teilgebiete eingesetzt werden, die sich jedoch hauptsächlich mit der Pflege und Weiterentwicklung der Systeme beschäftigen und nicht mit dem Fehlermanagement. Je länger das TT bearbeitet wird, desto länger kann der Störungsmelder seine Arbeit nicht fortsetzen. Darüber hinaus steigen mit jedem weiteren Mitarbeiter, der das TT bearbeiten muss, die Kosten der Supportorganisation. Erklärtes Ziel vieler Benutzerdienste ist es daher, eine möglichst hohe Sofortlösungsquote zu erreichen. Die Zuweisung an eine höhere Supportebene erfolgt aufgrund der Klassifizierung des TT häufig automatisch. Anschließend wird die Bearbeitungsgruppe über die Zuweisung benachrichtigt. Die Benachrichtigung (Notifikation) über das zugewiesene TT wird durch das TTS ausgelöst und der Bearbeitungsgruppe per oder auch über spezielle Notifizierungswerkzeuge zugestellt. Wie schon erwähnt sind alle Einträge in das TT mit einem Zeitstempel versehen. Mit Hilfe des Zeitstempels können alle Maßnahmen während der Störungsbearbeitung in ihrer zeitlichen Reihenfolge nachvollzogen werden. Darüber hinaus ist ein Zeitstempel die Grundlage für erweiterte Zeitüberwachungsmechanismen. Abbildung 1-3 Das TT-Management In vielen Unternehmen werden für das Fehlermanagement bestimmte Zeiten definiert, die unter Berücksichtigung der Priorität die Reaktions- und Wiederherstellungszeiten festschreiben. Im Umfeld eines Benutzerservice spricht man von Dienstleistungsvereinbarungen (DLV) oder Service Level Agreements (SLA) [Hegering u.a. 99] zwischen Kunden und Betreuungsorganisation, aber auch zwischen dem Benutzerservice und den nachfolgenden Supportabteilungen. Neben den Zeitvorgaben enthält die DLV auch eine exakte Definition der zu erbringenden Dienstleistung. In Abhängigkeit von den DLV wird die Zeit seit Erstellung des TT überwacht. Wenn die Bearbeitung und Lösung des TT nicht in der vorgegebenen Zeit erfolgt, erzeugt das System eine entsprechende Erinnerung, die sogenannte Eskalation. Neben dieser zeitlichen Eskalation spricht man auch von Eskalation, wenn die nächst höhere Supportebene eingeschaltet werden muss. Ob die zeitliche Eskalation auch gleichzeitig das Weiterleiten des TT an die nächst höhere Supportebene auslöst, unterscheidet sich je nach Konfiguration des TTS

12 1.2.2 Statistik und Reports Durch die strukturierte Ablage der Informationen in einer TT-Datenbank bildet sich während des Betriebes ein Abbild des verteilten Systems im Hinblick auf seine Schwachstellen. Die Abfrage dieser Daten kann mit unterschiedlichen Zielsetzungen erfolgen, die sich von der aktuellen Zustandsabfrage bis hin zu langfristigen Trendanalysen erstrecken. Es werden Statistiken und Reports erstellt, die dazu dienen: - den Betrieb des TTS zu unterstützen. - das Fehlermanagement zu verbessern. - das Management im Unternehmen mit Daten zu versorgen. Im laufenden Betrieb ergibt sich oft die Notwendigkeit, das TTS nach dem aktuellen Betriebszustand des verteilten Systems abzufragen. Dazu gibt es eine Vielzahl von Abfragen, die den Betrieb des TTS unterstützen. So überprüft ein Mitarbeiter im Benutzerservice regelmäßig die Anzahl der offenen TT für die Einteilung seiner täglichen Arbeit. Eine Führungskraft lässt sich die TT anzeigen, die seiner Supportgruppe zugewiesen wurden oder ein Koordinator für das Fehlermanagement prüft den Bearbeitungszustand der nicht gelösten TT und ergreift gegebenenfalls weitergehende Maßnahmen. Zusätzlich zu diesen Funktionalitäten, die das Trouble Ticket Management direkt unterstützen, gibt es eine Vielzahl von Möglichkeiten, durch Auswertung des TTS das Fehlermanagement im Unternehmen zu verbessern. Eine Abfrage nach häufig auftretenden Fehlern kann gezielt in vorbeugende Maßnahmen münden, die diese Fehler in Zukunft vermeiden helfen. Die Bandbreite der möglichen Maßnahmen erstreckt sich hier von einfachen Änderungen der Konfiguration oder gezielten Hinweisen zur Bedienung der Komponenten bis hin zum kompletten Austausch von Gerätegruppen oder dem Update einer Software. Wiederholte Anfragen zu gleichen Themen deuten auf eine mangelhafte Einweisung der Anwender in die benutze Software hin. Hier können Schulungsmaßnahmen eingeleitet werden, die sich gegenüber dem Management durch die Zahlen aus dem TTS begründen lassen. Die Auswertung des TTS ergibt auch einen guten Überblick über den Zustand des vernetzten Systems und des Fehlermanagements. Hier werden oft die Zeiten, die ein System fehlerfrei läuft (engl.: mean time between failure) oder auch die Zeit, die bis zur Reparatur einer gestörten Komponente vergehen (engl.: mean time to repair), betrachtet. Wenn zwischen den Abteilungen in der Supportorganisation und insbesondere zu externen Dienstleistern hin DLV bestehen, können diese aufgrund der Daten bewertet werden. Des Weiteren liefert das TTS auch Hinweise auf latente Problemquellen. Wenn die Anwender in einer Abteilung wiederholt über lange Antwortzeiten im Netz klagen, kann das Netzwerkmangement davon ausgehen, dass das Netzwerksegment bis an die Grenze ausgelastet ist. Sollen nun noch weitere Mitarbeiter in diesem Bereich in das Netzwerk integriert werden, ist das nur durch einen Ausbau der Netzwerkinfrastruktur möglich. Die Entscheidung kann entsprechend mit den Daten aus dem TTS untermauert werden. Schließlich können die Daten aus dem TTS zur Unterstützung des Managements herangezogen werden. Es liefert einen Überblick über den Aufwand, der im Fehlermanagement betrieben wird. Dadurch lässt sich möglicherweise ein erhöhter Personalbedarf begründen. Erkannte Schwachstellen im Fehlermanagement können dazu führen, Ausbildungsmaßnahmen für die Supportmitarbeiter durchzuführen. Wenn der interne Aufwand für das Fehlermanagement zu hoch wird, lassen sich auch Teilgebiete an externe Dienstleister ausgliedern (Outsourcing)

13 1.2.3 Zugriff auf Problemlösungswissen Beim Erstellen eines TT erfolgt die Aufnahme der in eingeführten Grunddaten des TT. Im Laufe der Bearbeitung werden diese Grunddaten um weitere Daten ergänzt, die die Fehlerdiagnose und Fehlerbehebung dokumentieren. So wird das Wissen aller an der Problemlösung Beteiligten im TT zusammengefasst und gespeichert. Damit stehen die Erfahrungen aus bereits gelösten TT allen Mitarbeitern der Supportorganisation zur Verfügung. Bei neu eingehenden Störungsmeldungen kann jeder Mitarbeiter, der das TT bearbeitet, auf ähnliche, bereits gelöste Fälle aus der TT-Datenbank zurückgreifen. So können auch weniger erfahrene Mitarbeiter die Fehlerdiagnose und Fehlerbehebung durchführen und somit für ein effizienteres Fehlermanagement sorgen. Darüber hinaus ist auch das Einbinden externer Wissensdatenbanken in den Diagnoseprozess möglich. Dabei stößt man jedoch auf Grenzen, da die unternehmensspezifischen Abläufe, Konfigurationen und Anwendungen nicht berücksichtigt sein können. Der Zugriff auf Problemlösungswissen kann auch durch intelligente Assistenten unterstützt werden, welche die Bediener bei der Fehlerdiagnose führen. Da sich die Unterstützung aber als Durchlaufen eines Ereignisbaumes mit den jeweiligen Ja/Nein-Entscheidungen darstellt, ist ein positiver Effekt nur für häufig wechselndes Personal in Hotlines oder auch direkt für Endanwender zu erwarten. Erfahrene Mitarbeiter im Benutzerservice verfügen in der Regel über dieses Wissen und bedürfen hier keiner Unterstützung Integration in das Systemmanagement Eine vielfach geforderte Anforderung an ein TTS ist die Einbindung in ein Systemmanagement, welches das gesamte verteilte System überwacht und steuert. Aus dem TTS heraus soll direkt auf die Netzwerkmanagementwerkzeuge zugegriffen werden können. Dabei erfolgt die Übergabe der im TT erfassten Gerätedaten an das Managementwerkzeug, das sofort mit der gewünschten Maske erscheint und die benötigten Daten anzeigt oder die gewünschten Aktionen ausführt. Des Weiteren werden im Systemmanagement erkannte Störungen an das TTS gemeldet und dort automatisch als TT erfasst. Somit können auch diese Störungen bei einer Auswertung mit in die Bewertung des verteilten Systems einfließen. Das Systemmanagement und das TTS sollten auf die gleiche Datenbasis zurückgreifen, um Redundanzen zu vermeiden und die Pflege der Daten zu vereinheitlichen Korrelation von Trouble Tickets Bei der Störung einer Netzwerkkomponente wird zunächst aus dem Systemmanagement heraus automatisch ein TT erzeugt. Aufgrund der gleichen Störung kann es aber auch zu Störungsmeldungen durch betroffene Anwender oder zu weiteren automatisch generierten TT kommen. Ziel der Korrelation ist es nun, zu erkennen, dass die ursächlich zusammengehörenden TT auch als Folgestörungen bearbeitet werden können und dadurch eine Mehrfachbearbeitung zu vermeiden. Bei Behebung der Störungsursache sollten dann auch alle mit dem bearbeiteten TT zusammenhängenden Folgetickets automatisch auf gelöst gesetzt werden. 1.3 Das Fehlermanagement bei der LBS Nord Die LBS Norddeutsche Landesbausparkasse Berlin-Hannover (im folgenden kurz LBS genannt) ist ein mittelständisches Unternehmen auf dem Finanzdienstleistungssektor. Um ihre Kunden zu erreichen, hat die LBS

14 in Niedersachsen und Berlin 80 Beratungszentren eingerichtet, über die das Geschäft abgewickelt wird. Die Verwaltung ist über 4 Standorte verteilt. Die wichtigsten Anwendungen der LBS sind ein hostbasiertes Datenbanksystem zur Führung der Vertragsdaten sowie ein Marktbearbeitungs- und Beratungssystem, das regelmäßig in beide Richtungen mit Daten aus der Zentrale und den Beratungszentren aktualisiert wird. Dazu kommt eine Vielzahl kleinerer Anwendungen zur Unterstützung bestimmter Teilprozesse. Um den Anwendern den Zugriff auf die Anwendungen und Daten zu ermöglichen, wurde ein Unternehmensnetzwerk eingerichtet, das die Standorte und die Beratungszentren über WAN-Verbindungen mit dem zentralen Rechenzentrum verbindet. Als Betriebssystem im Server- und Endgerätebereich ist vorwiegend WindowsNT 4.0 im Einsatz. Dazu kommt an den 4 Standorten ein reines SNA-Netzwerk, das den Zugriff auf die Hostanwendung ermöglicht und an das 3270-Terminals und PCs mit 3270-Emulationskarten angeschlossen sind. Der Hostzugriff für die vernetzten PCs erfolgt über SNA-Gateways. Insgesamt besteht das Netzwerk der LBS aus ca. 500 Netzwerk-PCs, 300 mobilen Arbeitsplätzen mit Netzanschluss, 400 Terminals, 250 PCs mit 3270-Emulationskarte und mehr als 120 Servern. Das IT-Management der LBS erfolgt in der ORGA/EDV, die in 4 Organisationseinheiten mit den Schwerpunkten Organisation und Prozessbeschreibung, Anwendungsbetreuung, Netzwerke und Datenbanken sowie Benutzerservice aufgeteilt ist. In der ORGA/EDV sind ca. 50 Personen beschäftigt. Hinzu kommen externe Dienstleister für die Betreuung ausgewählter Anwendungen. Abbildung 1-4 Das Fehlermanagement der LBS Im Störungsfall wendet sich der Anwender an den Benutzerservice, der dazu eine Hotline eingerichtet hat. Neben der Störungsannahme werden auch Anfragen zu den Themen der ORGA/EDV von der Benutzerservice- Hotline bearbeitet. Wenn die Störung nicht sofort behoben bzw. die Anfrage nicht sofort geklärt werden kann, wird die Störungsmeldung bzw. Anfrage an die zuständige Gruppe der ORGA/EDV oder an einen externen Dienstleister weitergeleitet. Nach Beseitigung der Störung bzw. Klärung der Anfrage wird der Anwender entweder direkt oder über die Hotline informiert. Diese Darstellung berücksichtigt nur den einfachsten Fall des

15 Fehlermanagements. Selbstverständlich kann es zu jedem Zeitpunkt zu Rückfragen, Weiterleitungen und Eskalationen kommen, wodurch sich noch weitere Querverbindungen zwischen den beteiligten Supportorganisationen ergeben. Um den Prozess des Fehlermanagements zu unterstützen, hat sich die LBS für den Einsatz eines Trouble-Ticket- Systems entschieden, das die in 1.2 beschriebenen Aufgaben eines TTS weitgehend abbilden kann. Die Wahl fiel auf das Action Request System (ARS) der Firma Remedy. 1.4 ARS - das Trouble Ticket System bei der LBS ARS wurde von Remedy als anpassungsfähige Plattform für Unternehmenslösungen entwickelt, die eine benutzerangepasste Gestaltung der Geschäftsabläufe erlaubt. Durch eine Art Baukastensystem [Dreo 98] ist es möglich, aus kleinen Bausteinen komplette Anwendungen zusammenzustellen und somit eine Vielzahl von Prozessen, nicht nur auf dem IT-Sektor, zu automatisieren und zu optimieren. Als Basisausstattung gibt Remedy dem ARS auch fertige Anwendungen mit, die so voll funktionsfähig sind, aber auch individuell angepasst werden können. Hierzu gehört eine Anwendung für den Benutzerservice, der Remedy Help Desk, der über Module für Fehlermanagement, Problemlösung und Inventarisierung verfügt. Die LBS verwendet für ihr Fehlermanagement den Materna HelpDesk 3.0 der Dr. Materna GmbH, der im Wesentlichen eine deutsche Version des Remedy HelpDesk darstellt. Die Anwendung wurde in bestimmten Teilprozessen auf die Anforderungen der LBS hin angeglichen Die ARS-Architektur ARS basiert auf einer 3-stufigen Client/Server-Architektur mit Client, Applikationsserver und einem relationalen Datenbankmanagementsystem. Die Clientseite umfasst mehrere Software-Werkzeuge, die dem Anwender mittels einer graphischen Benutzeroberfläche die Funktionalitäten des Systems zur Verfügung stellen. Der Zugriff auf bestehende AR System-Anwendungen erfolgt über das Werkzeug Remedy User. Es dient der strukturierten Eingabe von Informationen sowie dem Suchen und Ändern in bestehenden Daten und ist damit die Standard-Oberfläche für den Anwender von ARS. Um Anwendungen zu ändern oder neue Anwendungen zu erstellen verwenden die AR System-Administratoren den Remedy Administrator. Mit dem Remedy Notifier bietet ARS ein Benachrichtigungswerkzeug, das Benutzer auf Ereignisse, wie z.b. auf das Ablaufen der Reaktions- oder Wiederherstellungszeit für ein TT, hinweisen soll. Zum Laden externer Daten in das ARS wird das Remedy Import-Werkzeug verwendet. Der AR System-Server steuert die Arbeitsabläufe und den Zugriff auf die Datenbank. Er stellt die Anwendungen sowie die Werkzeuge für die Programmierung bereit. Im Datenbankserver sind die Daten, die von den Anwendungen erzeugt wurden, abgelegt und werden hier für Abfragen aufbereitet

16 Abbildung 1-5 Die ARS-Architektur Die ARS Clientanwendungen sind für die aktuellen Microsoft Windows Betriebssysteme und Unix erhältlich; der ARS-Server wird für Windows NT und verschiedene Unix-Versionen angeboten. Es werden alle gängigen Datenbanksysteme unterstützt. Die LBS setzt ARS unter Windows NT 4.0 ein. Als Datenbankmanagementsystem kommt Oracle zum Einsatz Die ARS-Komponenten Grundlage für alle ARS-Anwendungen ist das Formular, eine graphische Benutzerschnittstelle, die eine strukturierte Ein- und Ausgabe von Daten ermöglicht. Das Formular besteht aus Feldern, in denen die Informationseinheiten abgelegt und angezeigt werden. Die Dateneingabe kann durch Menüs unterstützt werden, die alle denkbaren Werte für das jeweilige Feld strukturiert zur Verfügung stellen. Bei der Datenerfassung werden die Felder des Formulars als ein Datensatz in der Datenbank gespeichert. Auf diese Weise werden mit dem selben Formular immer neue Datensätze angelegt. Bei einer Abfrage der Datenbank werden die Datensätze ebenfalls über das Formular angezeigt. Im Umfeld eines Benutzerservice dient ein Formular zur Erfassung und Anzeige der TT. Eine ARS-Anwendung kann aus mehreren Formularen bestehen, die untereinander verknüpft sind. Dabei sind bestimmte Formulare als Erfassungs- und Abfragemasken für die Benutzer des Systems bestimmt, während andere Formulare der Administration und als Hilfsmasken dienen. Für einen kontrollierten Datenzugriff können Berechtigungen (Ändern, Lesen, Kein Zugriff) sowohl auf Formular- als auch auf Feldebene vergeben werden. Für die Automatisierung von Arbeitsabläufen existieren 3 zusätzliche ARS-Komponenten: Active Links, Filter und Eskalationen. Diese Komponenten führen gemäß der für sie festgesetzten Auslösebedingungen bestimmte Aktionen aus, wobei sie direkt auf die Prozesse einwirken, Daten verändern und Folgeaktivitäten einleiten können. Active Links und Filter werden durch Ereignisse ausgelöst. Das kann z.b. eine Änderung in einem bestimmten Feld, das Speichern eines Formulars oder auch das Betätigen einer Schaltfläche sein. Active Links werden auf Clientseite ausgeführt, Filter auf dem Server aktiviert. Ein Active Link hat die Funktion, auf eine Benutzereingabe direkt zu reagieren, während der Filter über die Daten- und Systemintegrität wacht. Eskalationen sind zeitabhängig und werden nach Ablauf einer vorgegebenen Zeit ausgelöst. Daran lassen sich weitere Bedingungen knüpfen; z.b. kann eine Führungskraft eine Benachrichtigung erhalten, wenn ein TT nicht

17 innerhalb einer festgesetzten Zeit bearbeitet wird. Eine Übersicht der Auslösebedingungen und Aktionen enthält Tabelle 1.2.: Active Link Filter Eskalation Auslösebedingung Fenster öffnen/schließen Eingabetaste/Mausklick Menüauswahl Schaltfläche angewählt Fokus erlangen/verlieren Suchabfrage ausführen Daten hinzufügen, ändern Daten hinzufügen und und löschen ändern Datensätze verbinden Eine bestimmte Zeit ist abgelaufen Aktionen Meldung anzeigen Meldung anzeigen Protokollierung Protokollierung Makro ausführen Verbinden zu anderen Anwendungen Werte aus anderen Werte aus anderen Werte aus anderen Formularen übernehmen Formularen übernehmen Formularen übernehmen Werte in andere Formulare übertragen Werte in andere Formulare übertragen Werte in andere Formulare übertragen Programme aufrufen Programme aufrufen Programme aufrufen Dialogfeld öffnen Tabelle 1-2 Die ARS-Komponenten Das Trouble-Ticket-System im praktischen Einsatz Das wichtigste Formular für das TTS der LBS ist das HelpDesk-Formular. Über dieses Formular werden alle Daten zu einem TT erfasst. Dabei unterstützen hinterlegte Menüs in vielen Feldern die Datenerfassung. In Abbildung 1-6 sind diese Felder mit dem schwarzen Dreieck gekennzeichnet. Andere Felder werden durch Auslösen von Active Links und Filtern automatisch gefüllt. So wird z.b. der Name nach Eingabe der ersten Buchstaben des Nachnamens beim Drücken der Entertaste automatisch ergänzt und die zugehörige Telefonnummer wird eingetragen. Falls es mehrere Anwender mit übereinstimmenden Anfangsbuchstaben gibt, wird eine Auswahlliste angezeigt. Die hierfür benötigten Personendaten werden in einem weiteren Formular gepflegt

18 Abbildung 1-6 Das Helpdesk-Formular Im oberen Teil der Problembeschreibung kann der Benutzer die Störung in Freitext beschreiben und muss anschließend eine Klassifizierung vornehmen. Das geschieht über die 3 Stufen Kategorie, Typ und Komponente, mit denen die Störung zunehmend feiner beschrieben wird. Dabei hängen die Auswahlmöglichkeiten der nachfolgenden Felder jeweils von der Auswahl im vorherigen Feld ab. Für die Konfiguration der Klassifizierung existiert das Formular Kategorisierung, in dem die Auswahlfelder für die Problembeschreibung definiert sind. Einige Beispiele zur Kategorisierung: Kategorie Typ Komponente HW-PC IBM 300 PL Netzwerkkarte HW-Notebook Toshiba Portege 660 CDT Dockingstation HW-Drucker HP Laserjet 5P Photoeinheit SW-Bausparkassenanwendungen Marktanalysen (InfraTest) Fachlich SW-Betriebssystem Windows NT Passwort NW-Router Cisco 3640 Port SW-Officeanwendungen Word 97 Formatierung Tabelle 1-3 Beispiele zur Klassifizierung

19 Sollte sich aus den Auswahlfeldern keine zutreffende Klassifizierung der Störung ergeben, kann der Benutzer eigene Eingaben zu machen. Dadurch reduzieren sich allerdings die Möglichkeiten für eine weitergehende Automatisierung und für die Auswertbarkeit dieser Felder erheblich. Über die Schaltfläche Quickticket kann eine häufig auftretende Störung wie z.b. das Vergessen eines Passworts relativ schnell erfasst werden. Der Benutzer wählt aus einer Liste ein Quickticket aus und alle Felder der Problembeschreibung werden mit Vorgabewerten ausgefüllt. Mit der Klassifizierung erfolgt eine Voreinstellung für die anschließenden Schritte bei der Störungsannahme. So wird entsprechend der Auswahl vom System eine Priorität vergeben, die aber noch vom Benutzer verändert werden kann. Auch die Lösungssuche basiert auf der Klassifizierung. Lösungen werden entsprechend der Auswahl angezeigt und können durch einen Suchbegriff weiter eingeschränkt werden. Die Zuweisung soll im Allgemeinen an eine Gruppe erfolgen. Aufgrund der Klassifizierung wird ein TT standardmäßig der dafür zuständigen Gruppe zugewiesen. Der Mitarbeiter der angesprochenen Gruppe nimmt daraufhin das TT für sich in Bearbeitung. Alle wichtigen Schritte der Fehlerdiagnose und behebung sollen dann im Arbeitslogbuch festgehalten werden. Der untere Teil des HelpDesk-Formulars enthält die Erfassungsdaten, die automatisch beim Speichern des TT eingetragen werden. Aufgrund von Priorität und Kategorie sind Eskalationszeiten (Reaktions- und Wiederherstellungszeit) definiert, die selbsttätig auf dem ARS-Server überwacht werden. Insgesamt sind allein für das HelpDesk-Formular 258 in weiten Teilen versteckte Felder definiert; der Arbeitsablauf wird über 265 Active Links, 154 Filter und 5 Eskalationen gesteuert. Wie aus der Beschreibung des HelpDesk-Formulars hervorgeht, existieren noch weitere Formulare, die der Unterstützung der Datenerfassung und der Verwaltung des Systems dienen. Die wichtigsten Formulare des TTS der LBS enthält die folgende Tabelle: Formularname Aufgabe HelpDesk Zentrale Benutzeroberfläche für das Fehlermanagement User Benutzerverwaltung Group Gruppenverwaltung Person Verwaltung der Personen, die vom System betreut werden (Anwender) Kategorisierung Definition der Auswahlfelder für die Klassifizierung Weiterleitung Zuordnung von Gruppen zu bestimmten Kategorien Eskalationszeiten Definition von Reaktions- und Wiederherstellungszeiten Tabelle 1-4 Die wichtigsten Formulare im TTS der LBS Das TTS ist bei der LBS seit Mitte 1998 im Wirkbetrieb. In 2000 wurden ca TT mit dem TTS bearbeitet. 2 Motivation und Ziele Die Einführung eines TTS in einem Unternehmen erfolgt in der Regel mit hohem personellen und zeitlichen Aufwand und wird oft von spezialisierten externen Beratern begleitet. Dabei werden die Standardvorgaben der Softwarelösung an die individuellen Anforderungen des Unternehmens angepasst, unternehmensspezifische Daten in das System importiert bzw. eine Schnittstelle zu diesen Datenbeständen definiert. Die Inhalte der Auswahlfelder für die Klassifizierung müssen hinterlegt werden, wozu eine intensive Diskussion innerhalb der Supportorganisation notwendig ist, um eine weitgehende Abbildung der vorhandenen Informationstechnologie,

20 insbesondere deren Störungsverhalten, zu ermöglichen und eine Akzeptanz dieser Auswahl bei den Mitarbeitern zu erreichen. Des Weiteren können Lösungen zu bekannten Störungen eingefügt werden. Nachdem die Grundkonfiguration abgeschlossen ist, geht das TTS in den Normalbetrieb über. In einer sich ständig weiterentwickelnden Informationstechnologie-Landschaft mit immer kürzeren Produktlaufzeiten muss das TTS ständig auf dem aktuellen Stand gehalten werden, um die Bearbeiter bei der Störungsbearbeitung effektiv zu unterstützen. Hier beginnt der Aufgabenbereich der Administratoren des TTS. Unter anderem sollen sie die Entwicklung der IT im Unternehmen beobachten und die wichtigen Veränderungen in das TTS übernehmen. Bei der Einführung neuer Produkte sollen möglichst bald signifikante Begriffe, mit denen sich mögliche Fehler beschreiben lassen, in die Menüs der Auswahlfelder zur Qualifizierung von Störungen eingefügt werden. Dabei wird in den meisten Fällen, wie schon bei der Grundkonfiguration des TTS, versucht, diese Begriffe durch eine Analyse des jeweiligen Produktes durch sachkundige Mitarbeiter zu gewinnen. Diese Methode hat den Nachteil, dass nicht vorhersehbar ist, welche Begriffe bei der Klassifizierung einer Störung tatsächlich von den Bearbeitern benötigt und verwendet werden. Bei der LBS wurde 1999 während der Einführung einer unternehmensweit eingesetzten Anwendung eine Klasseneinteilung aller abgebildeten Prozesse unter Einbindung der jeweiligen Prozessverantwortlichen erarbeitet. Dabei wurden 428 neue Klassifizierungen gefunden und zusätzlich zu den bestehenden Klassen im TTS hinterlegt. Schon während der Analyse stellte sich die Frage, ob eine so tiefgehende Detaillierung durch die Hotline überhaupt anwendbar ist. Zur Klärung dieser Fragestellung und darüber hinaus grundsätzlich zur Nutzung der bereitgestellten Klassen habe ich im Rahmen dieser Arbeit ein Analyseprogramm entwickelt, in dem die Häufigkeit aller definierten Klassen in den TT gezählt wird. Das Programm ist in das Administrationswerkzeug integriert und wird in Kapitel 3 vorgestellt. Eine Auswertung der TT vom bis zum zeigt das in Abbildung 2-1 dargestellte Ergebnis. Der jeweils obere Wert besagt, wie oft die im TTS definierten Klassen für die Klassifizierung der TT des Zeitraums ausgewählt wurden, während die untere Zahl prozentual angibt, wie viele der Klassen entsprechend oft Verwendung fanden ,0% ,9% ,9% ,9% ,7% > 500 0,3% ,2% 0 34,7% 2 40,2% 1 5,1% Abbildung 2-1 Die Verwendung der Klassen in den TT (ab 2000 / prozentual)