Die Installation von Client-Server-Umgebungen in Unternehmen stellt hohe Anforderungen an das Netzwerk-Management. Den Administratoren koennen dabei sogenannte User-Helpdesks behilflich sein. Juergen Suppan* gibt in seinem Beitrag einen Leitfaden fuer die Planung und den Einsatz von Technologie-uebergreifenden User- Helpdesks und Trouble-Ticket-Systemen.

Die in den letzten Jahren immer staerker forcierte Abkehr von zentralen DV-Loesungen hin zu verteilten Systemen hat fuer den Anwender dieser Technologien eine Reihe schwerwiegender Konsequenzen. Zum Beispiel sind die zu unterstuetzenden Technologien wesentlich heterogener und laesst sich das bestehende Ausmass an Heterogenitaet auch mit straffen Standards kaum reduzieren. Ferner sind verteilte Technologien zum Teil nur eingeschraenkt zentral zu steuern und haben dezentrale DV- Technologien auch zu einer starken Dezentralisierung von Zustaendigkeiten und Arbeitsablaeufen gefuehrt.

Helpdesk-Einrichtung muss gut ueberlegt sein

Typischerweise stellen heute die betroffenen Endanwender folgende Forderungen:

- Hohe Verfuegbarkeit der betreuten Technologien und Produkte,

- hohe inhaltliche Qualitaet der Dienstleistungen,

- kurze Reaktionszeiten,

- transparente und niedrige Kosten sowie

- ein waehlbarer Grad an Serviceumfang und -qualitaet auf Basis schriftlicher und pruefbarer Vereinbarungen.

Die Einrichtung eines zentralen und Technologie-uebergreifenden User- Helpdesks im Rahmen eines umfassenden Benutzerservice hat in dieser Situation die hoechste Prioritaet. Dabei werden in der Regel folgende Ziele angestrebt:

- Sicherstellung der wirtschaftlichen Beherrschbarkeit und Betreibbarkeit verteilter DV-Technologien mit der erforderlichen Servicequalitaet,

- professionelles Stoerungs-Management und komplette Kontrolle ueber den Bearbeitungsprozess bei Stoerungen,

- praeventives Stoerungs-Management und gezielte Schwachstellenanalyse,

- Verkuerzung der Reaktionszeit bei Kundenwuenschen und Stoerungsmeldungen, Loesung von 80 Prozent aller gemeldeten Stoerungen innerhalb von x Minuten im Level-1-Helpdesk,

- optimaler Einsatz von Personalressourcen, Vermeidung von Mehrfacharbeiten an derselben Stoerungsursache,

- systematische Information aller Betroffenen vom Endanwender bis zur Fuehrungskraft,

- Servicedifferenzierung mit einem waehlbaren Umfang an Serviceleistungen (Service-Level) sowie

- Erfassung entstehender Kosten und Schaffung eines Abrechnungsprozesses.

Das Chaos ist nicht steuerbar. Aus diesem Grund macht es wenig Sinn, mit viel Aufwand einen Technologie-uebergreifenden User- Helpdesk einzurichten, wenn nicht folgende Voraussetzungen geschaffen worden sind:

- Ausreichende Qualitaet der zu betreuenden Technologien am Anfang und auf Dauer,

- Reduktion der Heterogenitaet durch straffe, an den Gesamtkosten orientierte Technologiestandards,

- schriftlich fixiertes und ausgereiftes DV-Konzept,

- Trennung von Test- und Operativbetrieb,

- Schulung von Endanwendern und Betreibern vor Inbetriebnahme neuer Produkte,

- praezise und korrekte Dokumentation der zu betreuenden Technologien sowie

- Projekt-Management

Zwei Grundkonzepte der Anwenderversorgung bieten sich an. Alternative eins ist ein lokaler Benutzerservice (LBS) mit zentraler Meldungsannahme. In dieser Variante existiert ein LBS beim Endanwender vor Ort und erbringt normalerweise stark applikatorisch orientierte Betreuungsarbeiten (vgl. Abbildung 1). Der LBS konzentriert sich dabei auf die Betreuung der Endanwender, waehrend der Systembetrieb inklusive Netzwerk zentral erfolgt. Der LBS haelt die meisten Trivialanfragen vom Level 1 fern, kann aber Level 2 auch direkt einschalten.

Nachteilig ist dabei, dass, wenn der LBS zu einer anderen Organisation gehoert, die Identitaet und das professionelle Erscheinungsbild der zentralen Dienste fuer den Endanwender schwer erkennbar werden. Ferner entsteht bei Grossunternehmen ein Multiplikationsfaktor fuer das Personal im LBS, da pro x Endbenutzer ein Betreuer erforderlich ist. Ausserdem ist, wenn die beteiligten Institutionen ueber mehrere Abteilungen beziehungsweise Hauptabteilungen verteilt sind, kein einheitliches Agieren und Handeln zu erreichen.

Das Konzept erfordert die wenigsten Organisationsaenderungen gegenueber einer traditionellen Ausgangssituation und ist leichter einzurichten. Alles in allem ist es aber personalintensiver und beinhaltet viele denkbare Ablaufstoerungen.

Optimaler Tool-Einsatz zielt auf alle Helpdesk-Ebenen

Bei Alternative zwei gibt es dagegen keinen LBS mit differenzierter zentraler Bearbeitung. Diese Variante vermeidet den Multiplikatoreffekt im Bereich der Endbenutzer. Sie hat insbesondere dann starke Vorteile, wenn der gesamte Service aus einer Organisationseinheit erbracht wird, die sich dem End-User gegenueber nur thematisch gliedert, aber mit einer gemeinsamen Identitaet auftritt.

Erfolg oder Misserfolg haengen von der Schaffung eines soliden Technologie-Fundaments und von der Faehigkeit ab, eindeutige und nicht zu viele Ansprechpunkte fuer den Endanwender zu definieren (vgl. Abbildung 2).

Der Nachteil dieses Ansatzes ist der erhebliche Vorbereitungsaufwand und gegebenenfalls die Notwendigkeit einer vollstaendigen Reorganisation. Im Endeffekt ist es jedoch die konsequenteste Variante, da sie bei professioneller Umsetzung Wirtschaftlichkeit mit Qualitaet und Kompetenz verbinden kann.

Der optimale Tool-Einsatz muss jeden Level des User-Helpdesk- Prozesses mit den erforderlichen Hilfsmitteln versorgen. Folgende Hilfsmittel kommen in Frage:

- Trouble-Ticket-System,

- Netzwerk- und System-Management,

- Online-Dokumentation,

- Auftrags-Management und Vorgangssteuerung sowie

- Informations- und Meldesysteme.

Die Basis jeder Tool-Loesung fuer einen User-Helpdesk ist das Trouble-Ticket-System. Da es aber frueher oder spaeter im Verbund mit den anderen Tools laufen muss, darf es nicht vorschnell ausgewaehlt und eingesetzt werden, um einer kostspieligen Fehlinvestition vorzubeugen.

Bei der Auswahl eines Trouble-Tikket-Systems ist eine Grundsatzentscheidung anhand zweier Fragen zu treffen:

-Soll das Trouble-Ticket-System "nur" die Bearbeitung von Tickets managen? Es gibt dann lediglich einen Ueberblick, welche Probleme im Moment akut und in welchem Bearbeitungsstand sie sind sowie welche Probleme in der Vergangenheit bestanden.

-Oder soll das Trouble-Ticket-System aktiv bei der Stoerungsbearbeitung helfen, indem es notwendige Informationen auf Knopfdruck bereitstellt und den Bediener bei der Bearbeitung einer Stoerung aktiv anleitet?

Wenn die Fragen so gestellt sind, werden viele Leser spontan dazu neigen, Alternative B zu waehlen. Natuerlich ist sie klar die bessere, erfordert jedoch

- einen wesentlich hoeheren Arbeits- und Zeitaufwand,

- eine sehr praezise und kompetente Projektabwicklung und die notwendige Projektsystematik,

- die Integration bereits in sich sehr komplexer Tools,

- bei Grossanwendungen in der Regel kundenspezifische Anpassungen sowie

- ein leistungsfaehiges Systemhaus, das die Gesamtverantwortung uebernimmt.

Ist dies nicht gewaehrleistet, birgt Alternative B erhebliche Risiken.

Die Grundfunktion eines Trouble-Ticket-Systems liegt in der Erfassung und Klassifizierung von Stoerungen sowie der Koordination und Ueberwachung der Arbeiten zur Stoerungsbearbeitung und daran anschliessend in der Analyse der aufgetretenen Stoerungen. Folgenden Anforderungen sollte das System gerecht werden:

- Zu einer gemeldeten Stoerung muss ein Ticket so erzeugt werden koennen, dass die Stoerungserscheinung klassifiziert und beschrieben werden kann.

- Ein Ticket muss zur Bearbeitung der Stoerung gezielt an einzelne Personen oder Gruppen weitergegeben werden koennen. Die Moeglichkeiten zur Weitergabe muessen konfigurierbar sein.

- Das System muss zwischen einem Bearbeiter und einem Koordinator eines Tickets unterscheiden.

- Ein Trouble-Ticket muss mehrere Zustaende haben koennen. Abhaengig davon sollen erlaubte und nicht erlaubte Vorgaenge gesteuert werden koennen.

- Ein System muss ueber ein leistungsstarkes Archiv verfuegen. Die Archivierungsfunktion fuer ein geloestes Ticket muss eine Unterscheidung zwischen urspruenglicher Stoerungserscheinung und festgestellter wirklicher Stoerungsursache ermoeglichen.

- Es muss moeglich sein, die fuer eine Ticket-Bearbeitung entstandenen Aufwaende im Ticket zu erfassen und einer Kostenstelle oder einem Servicevertrag zuzuordnen.

- Ein leistungsstarkes Auswertungs- und Analysesystem muss existieren.

- Import-Schnittstellen zur automatischen Erzeugung von Tickets aufgrund externer Ereignisse muessen vorhanden sein.

- Dazu muessen Export-Schnittstellen zur Weitergabe von Tickets beziehungsweise von Teilinformation von Tickets nach aussen existieren.

- Es muss ein frei gestaltbares Aktionsschema geben, nach dem abhaengig von Ticket-Status-Wechseln frei definierbare Aktionen ausgefuehrt werden.

- Ein Eskalationsverfahren muss definiert sein, das nach Ablauf vorbestimmter Bearbeitungszeiten frei definierbare Aktionen startet.

Diese Grundfaehigkeiten haben viele Trouble-Ticket-Systeme. Die fuer die Auswahl entscheidende Frage ist der Grad an aktiver Unterstuetzung bei der Bearbeitung einer Stoerung, den das System bietet. Mindestens folgende Informationen sollte ein Trouble- Ticket-System heute bereitstellen:

- Hardware- und Softwarekonfiguration des gestoerten Endgeraets,

- Informationen ueber die Einbindung des Endgeraets in ein Netzwerk mit detaillierter Angabe der Verbindung bis zum naechsten aktiven Versorger im Netzwerk,

- Konfigurationsinformationen ueber das versorgende Netzwerk,

- Konfigurationsinformationen ueber den versorgenden Server sowie

- Archivinformationen ueber typische Loesungen fuer aehnlich gelagerte Probleme in der Vergangenheit.

Durch Identifikation des Stoerungsmelders sollten automatisch sofort alle weiteren Benutzerdaten, die ueber den Melder vorliegen, einerseits soweit gewuenscht in das Ticket eingetragen werden und andererseits auf Knopfdruck vollstaendig abrufbar sein. Dasselbe gilt fuer die Endgeraetedaten des Melders und die Konfigurationsdaten einer fehlerhaften Komponente. Mit jeder Identifikation einer Komponente sollte ihre topologische Verknuepfung mit anderen Komponenten auf Knopfdruck abrufbar sein.

Diese Mindestanforderungen kann ein Trouble-Ticket-System nur in Kombination mit einem Online-Dokumentationssystem erfuellen. Bereits bei der Annahme muendlicher Meldungen kann es vorkommen, dass mehrere Tickets zu einer Stoerungsursache aufgenommen werden. Zum Beispiel hat ein und dieselbe Stoerung mehrere Stoerungserscheinungen. Diese werden getrennt gemeldet. Denkbar ist auch, dass eine Stoerung eine groessere Zahl von Benutzern betrifft, die sich separat melden, oder dass mehrere Meldungen gleichzeitig an verschiedenen Helpdesk-Arbeitsplaetzen aufgenommen werden.

Eine Korrelation zwischen Trouble-Tickets liegt vor, wenn sie sich auf dieselbe Stoerungsursache beziehen koennen, auch wenn das aufgrund der Information im Trouble-Ticket nicht erkennbar ist. Diese Komplikation kann noch verschaerft werden, wenn das Trouble- Ticket-System auch automatisch generierte Tickets aus Management- Systemen uebernimmt. Dann koennen mehrere muendliche und diverse automatische Meldungen zu einer einzigen Stoerungsursache vorliegen. Diese Situation ist typisch fuer eine groessere Client- Server-Architektur. Das muss zwangslaeufig zu der Forderung fuehren, ein Trouble-Ticket-System so konfigurieren zu koennen, dass es eine sogenannte Ticket-Gruppe bildet, in der alle potentiell korrelierten Tickets zusammengefasst werden.

Trouble-Ticket-System muss mit E-Mail harmonieren

Hier haben die meisten Trouble-Ticket-Systeme erhebliche Probleme, da sie nur ueber Schlagworte und Beschreibungstexte korrelieren koennen. Die grosse Ausnahme sind Trouble-Ticket-Systeme mit integrierter Online-Dokumentation, da ihnen die vollstaendige Verschaltungsinformation der Komponenten vorliegt und somit Korrelations-Zusammenhaenge aus der Schalttopologie abgeleitet werden koennen.

Ein Trouble-Ticket-System wird nur in Verbindung mit anderen Tools aktive Hilfe bei der Stoerungsbearbeitung und vollstaendige Informationen fuer alle Bearbeiter bieten. Informationen, die automatisch in ein Trouble-Ticket fliessen sollten, kommen in der Regel vorwiegend aus Netz- und System-Management-Loesungen. Bei der Kopplung dieser Systeme muss die Koppel-Schnittstelle beziehungsweise das Management-System ueber erhebliche Vorfilterungsmoeglichkeiten verfuegen, will man nicht eine totale Ueberflutung des Trouble-Ticket-Systems riskieren.

Die Exportmoeglichkeiten eines Trouble-Ticket-Systems machen seine Eignung als Informationsdrehscheibe aus. Aus diesem Grund muss von der Ausgabe- beziehungsweise Export-Schnittstelle eines Trouble- Ticket-Systems die Anbindung an E-Mail-Systeme sowie an nicht netzgebundene Rufsysteme gefordert werden.

Fazit: Ein professioneller, Technologie-uebergreifender User- Helpdesk ist der Dreh- und Angelpunkt beim Betrieb verteilter DV- Technologien. Er erfordert einen sorgfaeltig optimierten Ablaufprozess, ein solides Qualitaetsfundament und eine professionelle Projektierung. Die Basis jeder erfolgreichen Loesung ist ein Trouble-Ticket-System. Allerdings muessen bei der Auswahl eine Reihe wichtiger Kriterien beachtet werden, die nur von wenigen Produkten erfuellt werden.

*Dr. Juergen Suppan ist Geschaeftsfuehrer der Comconsult- Kommunikationstechnik GmbH in Aachen. Zum Thema Planung und Realisierung eines User-Helpdesks ist bei Comconsult ein Technologiereport erschienen.