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.
- Klar definieren, wer jetzt was zu tun hat
Mit dem Change geraten Zuständigkeiten und Rollen ins Fließen. Von Tag Eins an muss jeder Mitarbeiter wissen, was er jetzt im Moment zu tun hat. Bis sich das ändert und eine neue Ansage kommt. - Die Aufgaben nur skizzieren
Wer seine Mitarbeiter mitgestalten lässt, erreicht mehr. Deshalb ist es ratsam, eine grobe Skizze des Veränderungsprojektes zu zeichnen und das Team Vorschläge zur Ausarbeitung machen zu lassen, als einen schon komplett ausgereiften Plan zu präsentieren. - Die Team-Perspektive einnehmen
Wie betrifft der Change die Team-Mitglieder, was bedeutet die Initiative aus ihrer Sicht – wer diese Perspektive einnimmt, hat die Mitarbeiter auf seiner Seite. - Erfahrungen teilen
Erfahrungen teilen: Soweit möglich, sollten Mitarbeiter an konkreten Aktivitäten wie etwa Besuchen beim Kunden teilnehmen. Je näher sie den Change miterleben, umso besser. - Fragen zulassen
Fragen, die aus dem Team kommen, dürfen nie als Widerstand gelten. Ganz im Gegenteil. Ein Chef, der Fragen zulässt und sie beantwortet, kann schneller Teilverantwortungen an die Mitarbeiter übertragen. - Die Wirtschaftlichkeit darstellen
Neben viel Kommunikation mit dem Team geht es auch darum, Metriken und Kennzahlen für das Veränderungsprojekt zu entwickeln und diese deutlich zu machen. - Wissen, wo der Fokus ist
Innerhalb eines Changes ist viel Kleinteiliges zu klären und zu organisieren. Der Fokus darf darüber nicht vergessen werden. Regelmäßige Treffen müssen sich immer wieder auf diesen Fokus beziehen, eindeutige Metriken müssen deutlich machen, wo das Team gerade steht. - Teilziele updaten
Nicht jeder Meilenstein wird so zu erreichen sein wie ursprünglich geplant. Es ist daher wichtig, gemeinsam mit dem Team Teilziele regelmäßig auf den aktuellen Stand zu bringen. - Sich abstimmen
Gemeinsame Kalender für das Veränderungsprojekt und gemeinsam entwickelte Guidelines, die die Prioritäten festlegen: Das sind gute Wege, um die Arbeit der einzelnen Team-Mitglieder immer wieder aufeinander abzustimmen. - Commitment organisieren
Wer übernimmt die Verantwortung wofür und wie regelt das Team, dass diese Verantwortlichkeiten auch konkret ausgeführt werden? Solche Fragen sind gemeinsam zu klären. Die einzelnen Mitarbeiter müssen wissen, welchen Teil sie übernehmen, und sie müssen konkret formulieren können, was sie dafür von ihrem Chef brauchen. - Den Change in seine Geschichte einbinden
Das Team muss wissen, an welche früheren Punkte im Unternehmen der jetzige Change anknüpft und welche zukünftige Richtung sich damit abzeichnet.
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)