Foto: Makkuro GL - shutterstock.com
Die durchschnittliche Beschäftigungsdauer von Mitarbeitern in der IT beträgt unterschiedlichen Studien zufolge nur vier Jahre. Mit der Türklinke übergeben dann IT-Entscheider wie CIOs, IT-Leiter oder IT-Service-Desk-Verantwortliche ihrem Nachfolger das mehr oder - meist - weniger beliebte Service-Desk-Tool. Oft wird dieses schon zum Amtsantritt in Frage gestellt, auch um das neue Revier zu markieren.
Mitarbeitende im First- und Second-Level-Support können ein Lied vom heilbringenden neuen Service-Desk-Tool singen. Es bietet angeblich schnellere Reaktions- und Bearbeitungszeiten, und natürlich garantiert es auch zufriedenere Anwender und Kunden. Die wenigen Beschäftigten, die über zehn und mehr Jahre in einem Betrieb arbeiten, haben nicht selten drei oder vier Tool-Migrationen hinter sich. Das neue Service-Desk-Tool kommt stets mit vermeintlich viel frischem Wind - in jedem Fall aber mit hohem Implementierungsaufwand (siehe auch: Die besten Helpdesk-Tools).
Der Service-Desk entscheidet über Anwenderzufriedenheit
Der Service Desk ist der häufigste Berührungspunkt zwischen Endanwendern und IT. Er wird besonders intensiv wahrgenommen und entscheidet maßgeblich über Anwenderzufriedenheit. Erbringt der First-Level-Support keinen Service der Extraklasse, ist sein Ansehen schnell dahin - und das der gesamten IT ebenso. Vor diesem Hintergrund scheint die hohe Aufmerksamkeit also gerechtfertigt. Als neuer Entscheider kann man signalisieren, dass man alles tut, um den Muff des Vorgängers schnell zu beseitigen. Veränderungen müssen eben auffallen, wenn sich die IT von ihrer besten Seite zeigen will.
Aber Vorsicht! Eine Tool-Migration im Service Desk ähnelt einer Operation am offenen Herzen, zumal sie meistens "on the fly", also im laufenden Betrieb, erfolgen muss, ohne diesen zu stören. Leider tut sie in aller Regel genau das. Daher ist schlechte Laune meist absehbar.
Warum die Kette der Misserfolge nicht abreißt
Warum sind Service-Desk-Migrationen so oft nicht erfolgreich? Die Gründe für das Scheitern sind vielfältig. So kommt es vor, dass die Consultants des implementierenden Systemintegrators vom Kunden eine gewünschte Konfiguration als Vorgabe verlangen. Oft sagt dann derjenige, der das Tool am wenigsten kennt, wie es implementiert werden soll. Auch beliebt: Der Kunde möchte, dass das neue Tool entsprechend der alten Lösung konfiguriert wird und die Altdaten bei den Tickets übernommen werden. Aufwändige Customizings sind bei diesem Vorgehen die Folge, die Philosophie des neuen Tools wird nicht berücksichtigt.
Ein weiteres Beispiel: Der Kunde definiert theoretische Prozesse, die mit den tatsächlichen nichts gemein haben. Dann finden sich die Mitarbeitenden in der Lösung nicht wieder und empfinden diese als komplex. Als weitere Klassiker seien - ohne Anspruch auf Vollständigkeit - genannt:
Es wird ausgerechnet an der Schulung der Mitarbeiter gespart.
Der Kunde sperrt sich gegen standardisierte Prozesse, nach dem Motto: "Wir machen kein ITIL!"
Die Verantwortlichkeiten sind nicht festgelegt.
Vor dem Tool ist nach dem Tool
Die Begeisterung über einen Tool-Wechsel hält sich daher bei erfahrenen Support-Mitarbeitern meist in Grenzen. Die Missstimmung wird dann im Laufe des Migrationsprojekts immer wieder zur Sprache gebracht - manchmal versteckt, oft sehr deutlich.
Warum gelingt es nicht, diejenigen, die den ganzen Tag mit dem Tool arbeiten sollen, für die neue Lösung zu begeistern? Versetzen Sie sich einmal in die Rolle eines Support-Mitarbeiters hinein, oder setzen Sie sich nur einen Tag neben ihn. Sie werden schnell erkennen, dass eine Service-Desk-Lösung die Support-Experten nicht weniger, sondern mehr Zeit kostet - und die ist meistens knapp, denn ständig klingelt das Telefon. Die Auszahlung der Provisionen erfolgt häufig auch auf der Basis der Anzahl erledigter Tickets. Die Herausforderung besteht also darin schnell zu sein, wenn die mehr oder minder freundlicher Endanwender bedient werden wollen.
Oft erfolgt die Dokumentation eine Vorgangs, noch während der nächste Anwender schon sein Anliegen vorbringt. Für den Support-Mitarbeiter sind also die aus der Einführung eines neuen Tools resultierenden Pflichten zeitraubend und nervig. Das Tool wird zum Symbol für Mehrarbeit, Stress und Einkommenseinbußen. Der Nutzen mag auf der Ebene der Ressourcenplanung und -steuerung liegen, doch davon haben die Support-Mitarbeiter nichts.
Eine Knowledge Base garantiert keinen Erfolg
Auch wenn eine Knowledge Base angelegt wird, ist das nicht zwingend ein Erfolgsgarant für ein solches Projekt. Meistens nimmt der verantwortliche Projektleiter dafür die Champions aus dem Support in sein Team auf, damit diese Lösungsartikel für das gesamte Team schreiben. Sie müssen dann Zeit für etwas aufwenden, dass ihnen selbst wenig nützt, aber viel Arbeit bringt.
Die tatsächlichen Aufgaben und Lösungen sind im neuen Tool - genauso wie schon davor im alten - meistens nur zu einem Bruchteil erfasst. Die Lösung wird so eher als Behinderung bei der Arbeit empfunden, nicht als Unterstützung. Das Migrationsprojekt, das ein Aushängeschild für die neu aufgestellte IT hätte sein sollen, wird nun zu einem allgemeinen Ärgernis, die versprochenen Mehrwerte bleiben auf der Strecke.
Neue Lösungsansätze braucht das Land
Natürlich gibt es eine Vielzahl an Vorschlägen und Lösungsansätzen, um die beschriebenen Fettnäpfchen zu umgehen. So hinterfragen schlaue Anwender das vom Systemintegrator vorgeschlagene aufwändige Customizing und stellen auch ihre eigenen Prozesse in Frage, wenn diese zu aufwändigen Anpassungen führen. Sie wissen, dass sie sich selbst in ihren Prozessen genauso wie das gewählte Tool an den Vorgaben von ITIL orientieren - auch wenn beide Seiten das nicht immer so nennen.
Der wichtigste Orientierungspunkt bei einer solchen Tool-Einführung sollten die Bedürfnisse der Support-Mitarbeitenden sein. Wenn diese Leidenschaft für ein neues Tool entwickeln sollen - wie man es beispielsweise von Administratoren von Softwareverteilungen kennt - müssen sie schon zu Projektbeginn Mehrwerte für sich erkennen können. Angepasste Prozesse oder eine vereinfachte Dokumentation werden keine Begeisterung wecken, denn im täglichen Stress an der Hotline geht es vor allem darum, gute Lösungen schnell herbeizuführen. Der Prozess ist dort nicht transparent und fühlbar. Und die zeitraubende Dokumentation bleibt lediglich ein nerviges Pflichtthema. Wird sie einfacher, ist das schön und gut, aber noch längst kein Grund für Begeisterung.
Support-Mitarbeiter entlasten - darum geht's!
Support-Mitarbeiter möchten vor allem eines: die Probleme der Endanwender schnell lösen. Sie wollen der Person, die ihnen gerade am Telefon die sprichwörtliche Hölle heiß macht, unmittelbar helfen und dabei ihre Kompetenz beweisen. Doch anders als etwa ein Flugkapitän, der ständig Live-Informationen darüber erhält, wie sich das Wetter in den nächsten Stunden entwickeln wird oder wie es sich mit dem Flugverkehr in seiner aktuellen Umgebung verhält, hat der First-Level-Support-Mitarbeiter meistens keine integrierte Cockpit-Umgebung, um alles zu steuern.
Wenn jemand anruft, muss er erst einmal umständlich ein standardisiertes Interview führen und sich per Remote-Zugriff einen Überblick über den aktuellen Zustand des PCs des Anrufenden machen. Dabei schlägt er sich mit einem bunten Sammelsurium unterschiedlichster Tools zur Problemlösung herum - jedes mit einer anderen Oberfläche und Benutzerführung sowie einem eigenen Berechtigungskonzept.
Kopierte Pflichtenhefte sind ein Problem
Nehmen wir einmal an, es gäbe für den Support - wie in einem Flugzeug - ein einziges Cockpit, über das der First Level alle für ihn wichtigen Informationen und Prognosen erhielte. Es würde alle Funktionen zur Beseitigung von mindestens 80 Prozent der häufigsten Störungen unter einer Oberfläche vereint. Und ein Großteil der Dokumentation würde - wie bei einem Flugschreiber - automatisch erfolgen. Nach solchen Lösungen muss man lange suchen, sie sind kein Standard.
Häufig scheitert die Recherche nach dem richtigen Tool bereits an der Ausschreibung des Projekts. Denn für die Auswahl werden oft kopierte Pflichtenhefte externer Berater herangezogen, in denen etliche Punkte gar nicht oder nur unzureichend aufgeführt sind. Am Ende geht es ja in fast allen Ausschreibungen immer noch um das eine: den Preis.
Anbieter, die im Sinne des Kunden eine sinnvolle Lösung anbieten würden, hätten kaum eine Chance: Mit etwas, das der Kunden nicht anfordert, lässt sich auch nicht punkten - und schon gar nicht ein höherer Preis durchsetzen. So bleiben innovative Ansätze mit hochintegrativen und multifunktionalen Cockpits oft auf der Strecke - genauso wie die Belange des First-Level-Supports. Die Pflichtenhefte sind seit Jahren geprägt von langweiligen ITIL-Abfragen, die jede ernstzunehmende Service-Desk-Lösung längst als Standard mitbringt.
Das Ende vom Lied
Natürlich kann der Wechsel einer Service-Desk-Lösung Sinn ergeben - schon, weil die vorhandene Lösung aufgrund falschen Einsatzes politisch verbrannt sein kann. Wenn man aber wechselt, sollte man das Projekt zum Anlass nehmen, den Belangen der First-Level-Mitarbeiter endlich Genüge zu leisten. Manchmal kann dazu schon die Erweiterung der bestehenden oder der neuen Lösung um eine integrierte Oberfläche ausreichen.
Damit ist es möglich, den Support-Mitarbeitern unterschiedlichste Live-Informationen zum aktuellen Zustand des PCs des Anrufenden oder Ticketerstellers zur Verfügung zu stellen. Und mit einer Cockpit-artigen Sicht lässt sich eine Art Werkbank erstellen, die Lösungen für die meisten Tickets direkt zur Verfügung stellt. Auch die Dokumentation ließe sich mit einer solchen Integrationslösung besser automatisieren, indem zum Beispiel Logfiles per Mausklick eingesammelt und an den Second Level verschickt werden.
Service-Desk-Tools sollten den Support-Mitarbeiter mit seinen Bedürfnissen in den Mittelpunkt stellen und ihm Vorteile für seinen Arbeitsalltag bieten. Er ist darauf angewiesen, Problemursachen schnell zu erkennen und für die sofortige Lösung die richtigen Standardfälle an der Hand zu haben. Nur wenn das gelingt, wird man in der IT-Belegschaft und im First-Level-Support die nötige Unterstützung für ein Help-Desk-Migrationsprojekt oder die Einführung einer neuen Lösung bekommen.
Zudem empfiehlt es sich, für die Systemintegration einen echten Spezialisten heranzuziehen, der erfahren in der Implementierung solcher Lösungen ist. Er wird Innovationen den ausreichenden Raum geben und sie nicht schon im Keim ersticken, indem er sich kopierte und seit zehn Jahren unveränderte Ausschreibungsunterlagen von Dienstleistern und Beratern andrehen lässt. (hv)