Fragt man die Mitarbeiter im IT-Support, ob sie mit ihrem Service-Desk-Tool zufrieden sind, lautet die Antwort im besten Falle "Geht so". Warum kommt hier so gut wie nie Begeisterung auf? Liegt das vielleicht daran, dass der Service-Desk nur interessant ist, wenn er einmal nicht funktioniert? Oder daran, dass die Verantwortlichen falsche Erwartungen an das Tool stellen? Erwartungen, die das Werkzeug gar nicht erfüllen kann - nicht, weil es technisch minderwertig wäre, sondern weil es falsch implementiert wurde?
Foto: Kjetil Kolbjornsrud - shutterstock.com
Auf die Frage, was ein Service-Desk-Tool leisten soll, gibt es einige allgemeingültige Antworten. Es soll die Arbeit der Service- und Supportspezialisten vereinfachen, die Zusammenarbeit innerhalb der IT sowie zwischen IT und Kunde verbessern, Art und Dauer bestimmter Tätigkeiten transparent machen, Expertenwissen - zum Beispiel über eine Knowledge Base - verbreiten, durchgängige Prozesse definieren und den Arbeitsaufwand verringern.
Soweit die Theorie. Im gelebten Alltag ist es häufig so, dass das vorhandene Werkzeug die Arbeitsweise der Mitarbeiter eigentlich gar nicht unterstützt, weil die abgebildeten Abläufe den Wunschprozessen des Managements entsprechen und wenig mit den tatsächlich gelebten Prozessen zu tun haben. Vor diesem Hintergrund überrascht es, dass "Unzufriedenheit mit dem Tool" die häufigste Antwort auf die Frage ist, warum Unternehmen ihr Service-Management erneuern sollten. Als ob ein anderes Werkzeug etwas an den Prozessen ändern würde! Zweitwichtigstes Wechselmotiv ist die Absicht, den IT-Service-Management-Standard ITIL mit Hilfe eines Tools einzuführen. Aber wie soll das gelingen? Ein Tool bleibt ein Tool - an den Prozessen ändert es erstmal gar nichts.
Alte ITSM-Gewohnheiten
Tatsächlich laufen entsprechende Projekte meist so: Der Systemintegrator, der mit der Einführung beauftragt wurde, will von seinem Kunden eine Vorgabe für die gewünschte Konfiguration. Der aber ist mit dem Tool noch gar nicht richtig vertraut. Wenn er nun sagen soll, wie er es implementiert haben möchte, kann er sich nur an dem orientieren, was er kennt, sprich: am vorhandenen Tool. Damit bleibt die Innovation der neuen Lösung auf der Strecke.
Dazu ein simples Beispiel: Das neue System verfügt über eine Warenkorb-Funktion, mit der IT-Services online bestellt werden können. Das Unternehmen hat zum Erfassen der Service-Anforderungen bislang aber immer Tickets genutzt. Also wird er diese Anforderung auch an das neue Tool stellen. Und weil der Kunde König ist, wird der Berater das auch so umsetzen. Die neue Software, die dafür angeschafft wurde, das Service-Management zu vereinfachen und zu verbessern, bietet also keinen Warenkorb, sie wird vielmehr umständlich verbogen, damit der Support im gewohnten Stil weiterarbeiten kann.
Aber es kommt noch schlimmer: Damit das neue System der alten Lösung entspricht, ist meist ein aufwändiges Customizing notwendig. Und das dürfte der Philosophie des neuen Werkzeugs auch noch widersprechen. So entsteht dann die nächste Dauerbaustelle. Oft genug werden die Abläufe im Service-Management auch von Mitarbeitern definiert, die gar nicht für Service und Support zuständig sind. Diejenigen, die später tatsächlich damit arbeiten, müssen sich dann mit konstruierten Komplexitätsmonstern herumschlagen, die wenig mit ihrer Arbeitswirklichkeit zu tun haben.
Service Desks und der "sonstige" Ärger
Rechtzeitige Schulungen könnten solche Implementierungsfehler abfedern. Aber sie sind in den meisten Unternehmen "nice to have". Am Training der Mitarbeiter wird gerne gespart. So lernen diese nie, richtig mit dem Tool umzugehen. Umständliche Handhabungen und Workarounds schleichen sich ein, die dann irgendwann als Standard etabliert sind.
Ein Beispiel dafür liefert die Kategorisierung von Tickets. Können Mitarbeiter die Frage richtig beantworten, ob es sich bei einem Problem um einen Hardware-, Software- oder Infrastrukturfehler handelt, lassen sich Störungsmeldungen ohne Umwege den jeweils zuständigen Technikexperten zuweisen. Außerdem werden statistische Auswertungen über die Art und Häufigkeit von Fehlfunktionen einfacher und präziser, was das Problemmanagement unterstützt.
Dazu müssten die Mitarbeiter aber mithilfe von Schulungen eine Vorstellung davon bekommen, unter welcher Kategorie sie welche Störungen erfassen sollen. Anderenfalls werden sie der Einfachheit halber die meisten Störungen unter "Sonstiges" verbuchen - unter einer Kategorie also, die es bei vernünftiger Schulung gar nicht geben müsste. In vielen Service-Desks fallen zwei Drittel der Störungen unter Sonstiges. Wie sich das auf die Serviceprozesse und das Problemmanagement auswirkt, lässt sich leicht ausmalen. Die erhoffte Transparenz und Auswertbarkeit bleibt genauso auf der Strecke wie der übersichtliche und nachvollziehbare Prozess.
Wir machen kein ITIL? - Unfug!
In vielen Unternehmen hört man das Credo: "ITIL - machen wir nicht!" Alles, was nach Normierung klingt, ist dem dortigen IT-Bereich suspekt. Und damit auch jedes Tool, das diesem Standard folgt. Tatsache ist aber, dass heute alle führenden Service-Desk-Lösungen nach ITIL arbeiten. Und im Grunde auch jeder IT-Service-Desk. Vielleicht benutzt er andere Begriffe, aber er macht auf jeden Fall Incident Management. Denn die Beseitigung von Störungen ist ja das zentrale Ziel eines jeden Supports.
Auch Problemmanagement ist überall vorhanden - wenn auch in unterschiedlichen Ausprägungen. Oder sollte es tatsächlich Support-Einheiten geben, die stumpf eine wiederkehrende Störung wie eine schmierende Druckerpatrone immer wieder aufs Neue beseitigen, ohne sich Gedanken darüber zu machen, ob man vielleicht einen Modellwechsel in Betracht ziehen sollte, um das Problem ursächlich zu lösen?
Gleiches gilt für das Change Management: Es existiert in jeder IT-Abteilung, ist doch schon das Ausbringen eines Patches nichts anderes als ein Change. Die Frage ist also nur: Welche Ausprägung haben die Abläufe, und wie nennt man die Prozesse?
Es gibt allerdings auch Unternehmen, die "erst mal nur ein Incident Management" einführen wollen - gemeint ist hier nur ein Ticket-System. Die anderen ITSM-Funktionen könne man dann ja irgendwann später hinzufügen. Das ist gefährliche Augenwischerei. Ein Incident Management ohne Problemmanagement ist sinnlos, weil der Support nunmal nicht bei jeder Störung von Null anfangen sollte.
Sobald aber Problemmanagement, Changes oder Service-Anforderungen ein Thema werden, brauchen die IT-Management-Experten geeignete Werkzeuge dafür. Sonst tendieren sie dazu, diese Funktionen - so gut es eben geht - im immer gleichen Incident-Objekt abzubilden. Auf derart überfrachtete Systeme lassen sich später keine Filter mehr setzen, und damit büßen sie ihre Transparenz ein.
Wenn Dokumentation als Zeitverschwendung gilt
Niemand erfasst heute gerne Aufgaben oder dokumentiert Lösungen. Solche bürokratischen Tätigkeiten gelten als überflüssige Zeitfresser. Aber die Mitarbeiter im Service-Desk müssen wissen, dass dieser Aufwand sinnvoll ist. Wenn sich nicht alle penibel an die vorgeschriebenen Abläufe halten, stimmen am Ende die Reports nicht. Den Mitarbeitern im Service-Desk dies klarzumachen ist Aufgabe des IT Managements, wenn nicht gar der Unternehmensleitung. Es geht darum, die durchschnittlichen Bearbeitungszeiten nachweislich kurz zu halten. Die Betonung liegt auf nachweislich!
Selbstverständlich kann die Dokumentation einer kurzen Störung, wie sie der Reboot eines PCs darstellt, deutlich länger dauern als der Incident selbst. Aber wer darauf verzichtet, schneidet sich ins eigene Fleisch. In der Statistik senken solche kurzen Reparaturarbeiten die durchschnittliche Bearbeitungszeit, was die IT-Abteilung anhand entsprechender Kennzahlen in ein positives Licht rückt - auch gegenüber der Geschäftsführung.
Vor diesem Hintergrund wäre es theoretisch sogar sinnvoller, die wirklich langwierigen Incidents undokumentiert zu lassen. Das soll selbstverständlich keine Empfehlung sein, denn die so entstehenden Kennzahlen würden niemandem weiterhelfen und die Realität nur beschönigen, so dass keine zusätzlichen Ressourcen bewilligt werden.
Sicher, eine detaillierte Dokumentation wird die ohnehin viel zu langen Arbeitszeiten noch weiter verlängern. Aber wie sonst will der Service-Mitarbeiter den Nachweis erbringen, dass er mindestens acht Stunden täglich beschäftigt ist, wo doch eine einzelne Aufgabe nur wenige Minuten in Anspruch nimmt? Nur wenn die Überbelastung dokumentiert ist, kann sein Vorgesetzter einen Ressourcenbedarf begründen. Ohne Nachweis gibt es keine Entlastung!
Service-Desk-Projekte in falschen Händen
Last but not least ist wichtig, wer die Einführung des neuen ITSM-Tools verantwortet. Häufig übernimmt diese Aufgabe weder ein Service-Desk-Manager noch das IT-Management. Im Extremfall bleibt das Vorhaben einem frischgebackenen Studienabgänger oder sogar einem Praktikanten überlassen. Die strategischen Prozesse werden folglich definiert, ohne dass die Strategen ein Wort mitreden. Durchbrechen Sie diesen Teufelskreis! Ein paar einfache Tipps können Ihnen helfen, Ihr Service-Desk-Projekt auf Kurs zu bringen:
Akzeptieren Sie, dass auch Sie längst mit ITIL arbeiten! Im Grunde nutzen fast alle eine Spielart der dort beschriebenen Best Practices - auch wenn vielleicht andere Begriffe verwendet werden.
Nehmen Sie Ihre Mitarbeiter ernst und erklären Sie ihnen, warum eine durchgängige Dokumentation so wichtig ist. Für den Fall, dass Sie selbst es vergessen haben: Nur so wird der Ressourcenbedarf transparent. Dass eine Wissensdatenbank ohne Dokumentation ein Unding ist, sollten Sie auch noch erwähnen.
Bereinigen Sie zu Projektbeginn die Stammdaten und Assets. Sonst implementieren Sie denselben Mist, der Sie schon vorher behindert hat, in die neue Lösung. Alte Tickets zu übernehmen ist verführerisch. Aber die Hoffnung, damit von Anfang an Reports zu bekommen, trügt. Es sei denn, Sie haben Zeit und Lust, jedes Ticket erst einmal so zu bearbeiten, dass es den neuen Vorgaben entspricht.
Versuchen Sie niemals, die alte Lösung in die neue hinein zu konfigurieren. Und arbeiten Sie auch nicht gegen die Philosophie des neuen Tools an. Beides führt zu unnützer Komplexität und frustrierten Mitarbeitern.
Führen Sie Ihre Mitarbeiter behutsam an die neue Lösung und die veränderten Prozesse heran. Identifizieren Sie die Blockierer, die es fast in jedem Projekt gibt; notfalls nehmen Sie sie aus dem Team. Überlegen Sie, welche flankierenden Maßnahmen Sie benötigen - und setzten Sie diese um.
Suchen Sie sich einen Systemintegrator, der Sie bei Ihren Prozessen abholt, Ihre Wünsche ernst nimmt - aber Ihnen notfalls auch mal widerspricht oder zumindest hartnäckig nachfragt. Sie brauchen niemanden, der zu allem Ja und Amen sagt. Ein guter Berater muss auch mal ein begründetes Nein aussprechen können.
Wenn Sie ein aufwändiges Customizing anstreben, denken Sie noch einmal über den Sinn und Zweck nach. Untrügliche Indikatoren für ein unnützes Customizing sind folgende drei Aussagen: "Das haben wir im alten Tool auch so gelöst", "Der Prozess ist komplex, aber er hat sich bewährt" oder "Der Chef will es so." Überlegen Sie sorgfältig, ob Ihre Abläufe wirklich anders sein müssen, als es das Tool vorsieht. Vielleicht können Sie sich ja dem Werkzeug anpassen. Meist wird die Wahrheit irgendwo in der Mitte liegen.
Wenn Sie diese sieben Punkte beherzigen, können Sie viele der üblichen Stolpersteine umgehen. Damit steigen Ihre Chancen enorm, dass die Erneuerung des Service-Desk kein Mythos bleibt. (hv/fm)