Erfolgsfaktoren für die Einführung von ITSM-Tools

Über das Design von ITIL-Prozessen gibt es Unmengen an Literatur. Das Thema „Einführung von ITIL-Tools“ führt im Vergleich dazu eher ein Schattendasein. Dabei gehen gerade ITIL-Tooleinführungsprojekte oft schief. Die Fehler, die hier gemacht werden sind immer wieder dieselben. Wir haben zusammen mit Kunden und Tool-Herstellern eine Vorgehensweise zur Implementierung von ITIL-Tools entwickelt, die eine schnelle und problemlose Einführung ermöglicht. So konnte z.B. bei einem großen Kunden in nur fünf Monaten eine CMDB zur Abbildung von 200.000 CIs eingeführt werden.

Grund für das Scheitern vieler ITSM-Tool-Einführungen ist fast immer, dass die Projekte nicht als Change-Projekte aufgesetzt werden. Der Projektauftrag sieht in der Regel „nur“ vor ein Tool zur Unterstützung der bereits definierten ITIL-Prozesse einzuführen. Dabei wird übersehen, dass in der Regel erst mit der Tooleinführung die Prozesse institutionalisiert werden. Die Auswirkungen, die eine solche Tool-Einführung auf die Organisation hat, werden daher nicht ausreichend berücksichtigt

Anwender einbeziehen

Weil ITIL-Tool-Einführungsprojekte die Organisation ändern, treffen sie häufig auf Widerstände. Werden die Anwender nicht rechtzeitig mit einbezogen, so findet die implementierte Lösung keine Akzeptanz egal wie gut sie ist. Bereits bei der Toolauswahl sollten die Anwender dabei sein. Natürlich können Entscheidungen nicht mit allen Anwendern diskutiert werden. Empfehlenswert ist daher die Bildung eines Anwenderausschusses. Nur der Anwenderausschuss ist berechtigt, Anforderungen an das neue Tool zu stellen. Seine Aufgabe ist es, Anforderungen in den jeweiligen Bereichen abzustimmen. In der Praxis bewähren sich Teams mit bis zu 15 Personen. Erfolgskritisch ist die Auswahl der Mitglieder dieses Gremiums. Die Mitglieder müssen sehr gut innerhalb der Organisation vernetzt sein und sollten über ein gutes „standing“ verfügen und am besten hierarchisch nicht zu hoch angesiedelt sein; denn die Organisation von Meetings mit 15 Vertretern des mittleren Managements ist in den meisten Unternehmen kurzfristig kaum machbar.

Perspektivenwechsel nach der Toolentscheidung

Der reinen Lehre zufolge werden zuerst die Prozesse definiert und dann erst wird ein Tool zur Prozessunterstützung eingeführt. Diese Vorgehensweise führt in der Praxis aber oft dazu, dass die Tools unnötigerweise „verbogen“ werden; denn die detaillierte Festlegung von Prozessen beruht in der Regel auf Festlegungen, die so oder auch anders getroffen werden können, ohne dass dies für den Anwender eine Einschränkung darstellt. Beispielsweise kann die Reihenfolge von einzelnen Prozessschritten oft vertauscht werden, ohne dass dies zu einer Qualitätsbeeinträchtigung führt. Legt man also eine bestimmte Aktivitätenreihenfolge ohne genaue Toolkenntnis fest, wird diese vom Tool so evtl. nicht unterstützt. Im schlimmsten Fall wird dann das Tool angepasst ohne zwingenden Grund.

Besser ist es daher, den Prozess nur so detailliert zu planen, wie für die Tool-Auswahl notwendig. Wenn die Toolentscheidung aber einmal getroffen ist, sollte ein Perspektivenwechsel stattfinden: Ausgangspunkt sind dann die konkreten Eigenschaften des Tools, die bestimmte Prozessvarianten besser unterstützen als andere. Zu prüfen ist dann, wo das Tool zwingend angepasst werden muss, weil die vorgegebenen Prozessabläufe nicht zu den Randbedingungen im Unternehmen passen. Ratsam ist dabei, den gewählten Standard zunächst möglichst wenig zu verändern. Die Erfahrung zeigt, dass die Priorisierung der Anforderungen schon wenige Monate oder gar Wochen nach Tool-Einführung ganz anders getroffen wird als in den frühen Design-Phasen.

Time- und Budget-Boxing

Aber auch wenn man sich nur auf die notwendigsten Anpassungen beschränkt, wird man feststellen, dass die Zahl der Anforderungen wächst und wächst. Man hat also die Wahl, den geplanten Einführungstermin immer weiter nach hinten zu verschieben oder man betreibt von vorneherein Time- und Budget-Boxing: Es wird also ein fester Zeit- und Budget-Rahmen gesetzt und es wird nur das realisiert, was innerhalb dieses Rahmens realisiert werden kann. Alles andere wird bis zu einem späteren Release zurückgestellt. Entscheidende Bedeutung kommt hier dem Anforderungsmanagement zu, das sicherstellen muss, dass die Anforderungen mit dem größten Kundennutzen auch umgesetzt werden.

Inkrementelles Vorgehen

Trotz Time- und Budget-Boxing wird man jedoch Überraschungen erleben; insbesondere dann, wenn die Anwender zum ersten Mal Praxisfälle mit dem neuen Tool durchspielen. Ist zu diesem Zeitpunkt kein Budget mehr für Änderungen vorhanden, hat man meist verloren, denn es werden vielfältige Anpassungen notwendig sein. Daher sollte für das erste Beta-Release, das Grundlage der ersten Praxistests ist, nicht mehr als 50% des Budgets veranschlagt werden. Die neuen Anforderungen, die im Rahmen dieser Tests in der Regel identifiziert werden, können dann gegenüber bereits früher gestellten Anforderungen und notwendigen Fehlerkorrekturen priorisiert werden.

Richtig spannend wird es, wenn die Tests zum ersten Mal mit Echtdaten durchgeführt werden. Erst dann werden viele konzeptionelle Fehler und Lücken erkannt. Wenn also eine Daten-Migration notwendig ist, sollte diese möglichst so frühzeitig erfolgen, dass die Praxistests auf Basis von Echtdaten erfolgen können.

Internes und externes Know-how nutzen

Und wie vermeidet man die vielen Stolperfallen, die ein solches Projekt mit sich bringt? Die Grundlage hierfür wurde bereits mit dem Anwenderausschuss (s.o.) gelegt. Das hier vertretene Know-how zu den Besonderheiten im Unternehmen erlaubt es viele Klippen schadlos zu umschiffen, wenn es richtig eingebunden wird. Genauso wichtig ist hier aber externes Know-how, denn ohne die Erfahrungen aus vielen ähnlich gelagerten Projekten wird man sicher mindestens einige der Fehler wiederholen, die viele andere bereits vor einem gemacht haben.

Ganz besonders wichtig ist das interne Prozess-Know-how in den durchzuführenden Schulungen. Reine Tool-Schulungen durch den Tool-Hersteller sollten vermieden werden. Die Schulungen müssen vielmehr vermitteln wie der unternehmenseigene Prozess mit dem neuen Tool gelebt werden kann. In der Praxis bewährt sich die Ausbildung von internen Multiplikatoren, die das Know-how dann in die jeweiligen Bereiche tragen.

Kommunikation ist alles

Das Nebeneinander von internem und externem Know-how funktioniert nicht immer konfliktfrei. Eine gute Möglichkeit, die beiden Seiten zusammen zu bringen ist es, das Projekt mit einem mehrtägigen Workshop zu starten. Hier sollten auch teambildende Methoden genutzt werden. Neben dem Projekt-Kernteam sollten alle Mitglieder des Anwenderausschusses an dieser Veranstaltung teilnehmen.

Solche Kickoff-Workshops fördern die Bereitschaft für Veränderungen ungemein. Die relativ hohen Kosten für die Workshops werden von einem funktionierenden Team meist sehr schnell wieder eingespart.

Management Support

Aber alle diese Maßnahmen können eines nicht ersetzen: Ausreichende Unterstützung durch das Senior-Management. Ganz selten nur wird es so sein, dass alle Stakeholder bereit sind für die anstehenden Änderungen. Um hier endlose Diskussionen abzukürzen, sind klare Entscheidungen oft nicht nur hilfreich, sondern sogar notwendig.

Das Vorgehensmodell in der Praxis

Auf der Basis des beschriebenen Ansatzes konnten wir z.B. bei einem großen Kunden in nur fünf Monaten eine CMDB mit einer darauf aufbauenden Change-Management-Lösung einführen. In weiteren fünf Monaten wurden die Prozesse Incident- und Problem-Management auf die neue Plattform migriert. Heute arbeiten fast 1.000 Anwender mit dem Tool, erfassen täglich ca. 1.000 Incidents und setzen sie in Beziehung zu den ca. 200.000 CIs.