Technische Hürden sind niedriger als organisatorische Erste Schritte im Service-Management (Teil 2)

Autor / Redakteur: Rico Barth / Ulrike Ostler

Eine technische Lösung zur Organisation der Arbeiten am Helpdesk sieht in der Praxis am Ende ganz anders aus, als zunächst gedacht. Deshalb sollte man darauf achten, die einzelnen Projektschritte klein und ausbaubar zu halten. Es ist vor allem wichtig, dass die technische Basis sehr stabil und flexibel ist, um später die Grundlage weiterer Maßnahmen zu bilden.

Firma zum Thema

Lange Leitung darf nicht sein im Helpdesk
Lange Leitung darf nicht sein im Helpdesk
(Bild: Rainer Sturm, pixelio.de)

Am Service-Desk sollten – mit Ausnahme bei sehr großen IT-Stäben - die Tickets wie auch die Bearbeitungsstrukturen nicht zu tief klassifiziert sein. Häufig werden sie in die fachlichen Arbeitsgruppen wie TK, Netze, Hardware, Software – und maximal zwei Ebenen darunter – unterteilt. Eine Hotline-Warteschlange für alle bis dahin noch unklassifizierten Tickets ist zu empfehlen.

Bildergalerie
Bildergalerie mit 8 Bildern

Einfache Klassifikation hat zwei Vorteile. Erstens macht es eine automatische und eine manuelle Zuordnung von Tickets zu Fachthemen einfach und schnell. Zweitens sind die Support-Abteilungen (beispielsweise im Mittelstand) meistens so klein, dass wegen der Urlaubs- und Ausfallzeiten eine Spezialisierung nicht zu empfehlen, aber Zusammenarbeit auf Zuruf möglich ist.

Häufige Probleme und Lösungen im Wiki erfassen

Es erleichtert die Arbeit im Helpdesk ungemein und vermeidet personelle Engpässe, ein Helpdesk-Wiki oder FAQ aufzubauen. Zunächst umfasst das nur Lösungswege für häufig auftauchende Störungen und Probleme. Hieraus lassen sich später auch kurze Anleitungen für ein Anwender-Wiki kopieren („Passwort vergessen“).

Die IT-Mitarbeiter sollten, auch wenn es anfangs lästig ist, unbedingt ihre Lösungen in strukturierter Form dokumentieren. Denn daraus entsteht mit der Zeit eine ziemlich umfangreiche Wissensdatenbank, die enorm Arbeitszeit sparen und den User-Support beschleunigen wird. Teile davon lassen sich später zu einer Art „Jetzt helfe ich mir selbst“ für die IT-Anwender zusammenstellen.

Limits für Reaktionszeiten gegen das Vergessen

Die Abläufe im Support müssen so angelegt sein, dass kein Ticket „auf der langen Bank“ dem Vergessen anheim fällt. Also sollte sich die Abteilung Gedanken machen, in welcher Zeit welche Anfragen und Störungen behoben sein müssen. Entsprechend lässt sich später das System mit einem Servicekatalog und den zugehörigen Service Level Agreements (SLAs) für Reaktions- und Lösungszeiten einrichten. Dabei gilt es, Vorkehrungen für den Fall zu treffen, dass ein Ticket über die Tische mehrerer Bearbeiter läuft.

Für solche Fälle – die betreffen zum Beispiel auch Beschaffungsmaßnahmen oder Softwareprojekte – entsteht bei vielen ITSM-Projekte recht früh der Wunsch nach Einrichtung automatischer Workflows. Solche automatischen Prozesse bieten sich zuerst bei Standardänderungen an, die ein klar definiertes Vorgehen haben. Die IT-seitige Einbindung neuer Mitarbeiter im Unternehmen ist da nur eines von vielen Beispielen.

Derlei sollte man allerdings erst einrichten, wenn das Team mit dem Ticketing-System Routine hat, weil es neue Prozesse mit sich bringt. Auch sollte die Einrichtung von Workflows schrittweise erfolgen und jederzeit nachjustierbar sein; denn deren Anlage kann sich als vertrackt und fehlerträchtig erweisen.

Bei Anruf schon die User-Konfiguration auf dem Monitor

Als sehr praktisch hat sich die Kopplung von OTRS mit VoIP-Telefonanlagen erwiesen. Denn bei einem Anruf sieht der Support sofort, wer anruft und welche IT-Umgebung der Anrufer hat. Wenn die TK-Anlage, Telefone oder PC-Softphones „Action-URLs“ unterstützen, lassen sich in der Hotline sogar unmittelbar Aktionen auslösen.

Bei der Neueinführung eines Helpdesk-Systems werden die meisten User aus Gewohnheit die Durchwahl eines ihnen bekannten Support-Mitarbeiters anrufen oder ihm „zwischen Tür und Angel“ Wünsche und Probleme mitteilen. Hier hilft nur Erziehung, der wiederholte Hinweis, dass es nur eine zentrale Nummer und eine interne E-Mail-Adresse für den Support gibt, während jeder andere Kontakt den Service nur verzögert, weil dieser IT-Mitarbeiter das Anliegen vergessen könnte und nun ein Ticket aufsetzen muss, das längst vorliegen könnte.

Die Anwender mit Bedacht mitnehmen

Ferner ist es nützlich, ein einfaches Webformular einzurichten, in dem User ihr Anliegen ohne Ausfüllen von Detailinformationen unstrukturiert eintragen können. Hauptsache ist, dass sich eine automatische Zuordnung des Tickets einrichten lässt, zum Beispiel über die Stichwortvorgabe „Problem mit Drucker“. Dieses Formular, lässt sich später zu einem umfangreicheren Self-Service-Portal ausbauen.

Wichtig ist, die Anwender behutsam und schrittweise an das sich anonym anfühlende Ticketing heranzuführen. Eine Einführung neuer Service-Prozesse „von oben“ ist ebenso fatal wie Fehler in der technischen Konfiguration des Systems. Unabhängig davon ist eine klare managementseitige Unterstützung des Vorhabens und das „Mitnehmen“ der Anwender unerlässlich für den Projekterfolg.

Es ist übrigens nicht immer hilfreich, vor Einführung eines Service-Systems zunächst alle Fachabteilungen ausführlich nach ihren Wünschen zu befragen. Nach aller Erfahrung ergibt sich nur eine umfangreiche Liste, die eher wenig mit dem Kern der Serviceprozesse zu tun hat und die eigentlichen Aufgaben verschleiert. Man braucht eine Beschreibung des Ist-Zustands, die schon allein aus IT-Sicht etliche Herausforderungen an den Tag bringen wird. Weitere Fachabteilungen lassen sich danach sukzessive einbeziehen.

Aus einer Wunschliste umgehend eine Soll-Beschreibung abzuleiten ist ebenfalls nicht ohne Tücke. Die Wunschliste wird immer zu umfangreich sein. In der Praxis sieht ein Helpdesk am Ende regelmäßig anders aus, als es die Wünsche oder ersten Projektziele hätten erwarten lassen.

ITIL-Kenntnisse sollten schon sein

Man sollte sich schon mit Kenntnissen über Theorie und Praxis der IT Infrastructure Library (ITIL) an die Zielbeschreibung machen. ITIL ist kein einmaliges Projekt, sondern selbst ein fortlaufender Prozess, in dem eins auf dem anderen aufbaut. Deswegen ist es wichtig, die Grundlagen, vor allem die CMDB, sehr bedacht einzurichten und auf diesem Fundament eher viele Einzelschritte anzustreben.

Fehler und Rückschläge sind niemals ausgeschlossen. Die Notwendigkeit, bestehende Prozesse noch einmal zu verfeinern, wird sich schon auf der niedrigen ITIL-Ebene des IT-Supports früh einstellen. Gleichzeitig erscheint bald diese oder jene Erweiterung wünschenswert.

Der Autor, Rico Barth, ist Geschäftsführer der cape IT GmbH
Der Autor, Rico Barth, ist Geschäftsführer der cape IT GmbH
(cape IT)

Die Vorteile von Open Source ausnutzen

An diesem Punkt zeigt sich dann die Überlegenheit von Open-Source-Software gegenüber proprietären Lösungen. Sie garantiert zwar keinen Erfolg, aber die Offenheit des Codes, dokumentierte Schnittstellen und herstellerunabhängige Standards machen es deutlich einfacher, schrittweise zu arbeiten. Fehler lassen sich leichter identifizieren und beheben. Eine Open-Source-Lösung lässt sich mit weniger Aufwand in tangierende Anwendungen integrieren und später ausbauen.

* Rico Barth ist Mitbegründer und -geschäftsführer der capeIT GmbH in Chemnitz. Diese bietet mit KIX4OTRS eine erweiterte Lösung für das IT Service Management und diverse Zusatzmodule als Open Source an. CapeIT ist aktives Mitglied der Open Source Business Alliance und des IT Service Management Forums (itSMF).

(ID:43220269)