IT-Organisation und VorgehenLesezeit 4 Minuten
ITSM: Das Werkzeug ist nicht das Projekt
Eine ITSM-Einführung wird fast immer als Werkzeugbeschaffung aufgesetzt: auswählen, lizenzieren, anpassen, Tickets migrieren. Dabei ist die Software der kleinste Teil des Vorhabens – und der einzige, der sich sauber planen lässt.
Der Ablauf ist in den meisten Häusern derselbe. Es gibt Unzufriedenheit mit dem bestehenden Ticketsystem, eine Marktsichtung, eine Auswahlentscheidung, ein Einführungsprojekt. Nach dem Go-live ist die Unzufriedenheit nicht verschwunden, sie hat nur ein neues Oberflächendesign.
Ich habe drei solche Einführungen begleitet: ein neues ITSM-Werkzeug bei einem Rechtsschutzversicherer, über zweieinhalb Jahre die Implementierung von ITSM-Lösungen nach ITIL als Projektleiter, und derzeit die Einführung eines konzernweiten Systems in einem Industriekonzern. In den ersten beiden Fällen war Matrix42 das Werkzeug. Dazu lag in meiner Linienverantwortung einmal ein Service Desk nach ITIL. Das Muster ist jedes Mal dasselbe gewesen.
Was das Werkzeug sichtbar macht
Ein Ticketsystem verlangt Festlegungen, die vorher informell waren. Welche Kategorien gibt es? Was ist ein Incident, was ein Request, was ein Change? Wer arbeitet im ersten, wer im zweiten Level? Wer darf eine Leistung beauftragen, und wer genehmigt sie? Bis zu welchem Aufwand entscheidet die IT allein?
Diese Fragen hat das Haus vorher bereits beantwortet – nur unterschiedlich, je nach Person und Situation. Ein Werkzeug verträgt das nicht. Es braucht eine Antwort, und zwar eine für alle.
Damit ist eine ITSM-Einführung in Wahrheit ein Organisationsvorhaben mit einem Softwareanteil. Wer sie als Softwarevorhaben aufsetzt, verlegt die unvermeidlichen Entscheidungen in die Konfigurationsphase, wo sie von denen getroffen werden, die gerade das Formular bauen.
Drei Entscheidungen, die vor die Auswahl gehören
Was ist bei uns ein Service, und wer verantwortet ihn? Ein Servicekatalog ist keine Liste installierter Software, sondern eine Liste von Leistungen mit je einem Verantwortlichen und einer zugesagten Qualität. Diese Liste zu erstellen dauert Wochen und erzeugt die nützlichsten Konflikte des ganzen Vorhabens.
Wer darf beauftragen? In jedem Haus gibt es Leistungen, die bisher auf Zuruf erbracht wurden. Sobald sie in einem Werkzeug stehen, braucht es eine Regel: wer anfordert, wer genehmigt, ab welchem Umfang jemand anderes zustimmt.
Welche Prozesse führen wir wirklich ein? ITIL beschreibt eine große Zahl von Praktiken. Für den Anfang tragen drei: Störungen, Anforderungen, Änderungen. Wer mehr gleichzeitig einführt, bekommt nicht mehr Reife, sondern mehr Pflichtfelder.
Der Teil, der regelmäßig unterschätzt wird
In regulierten Häusern ist das Berechtigungsmanagement kein Modul des Werkzeugs, sondern das eigentliche Vorhaben. Wer darf welche Berechtigung anfordern, wer genehmigt sie fachlich, wer prüft sie turnusmäßig nach, und wie wird all das gegenüber der internen Revision und der Wirtschaftsprüfung nachgewiesen?
Für die Prozesskonzeption und Umsetzung eines aufsichtskonformen Auftrags- und Berechtigungsmanagements haben wir rund hundert Personentage gebraucht – für diesen einen Prozess, zusätzlich zur Werkzeugeinführung. Das klingt nach viel und war gut angelegt: Es ist der Teil, auf den die Prüfer zuerst sehen, und der einzige, bei dem eine Feststellung unmittelbar Geld und Aufmerksamkeit kostet.
Womit ich anfangen würde
- Mit dem Servicekatalog, nicht mit der Marktsichtung. Wer seine Leistungen benennen kann, kann ein Werkzeug auswählen. Umgekehrt funktioniert es nicht.
- Mit drei Prozessen. Alles Weitere nach dem ersten Betriebsjahr, auf Basis dessen, was im Betrieb tatsächlich gefehlt hat.
- Mit dem Berechtigungsprozess von Anfang an, nicht als zweite Ausbaustufe. Er ist der aufwendigste Teil und derjenige, der am schlechtesten nachträglich eingezogen werden kann.
- Mit einer Person, die über Kategorien entscheidet. Namentlich. Sonst entstehen vierzig Kategorien, von denen sechs benutzt werden.
Die Frage für den Lenkungsausschuss
Vor der Werkzeugentscheidung gehört eine andere beantwortet: Welche Zuständigkeit ist bei uns heute nicht aufgeschrieben – und wer entscheidet sie, wenn das Werkzeug uns dazu zwingt?
Wenn darauf eine Antwort mit Namen folgt, wird die Einführung anstrengend und erfolgreich. Wenn nicht, bekommen Sie ein gut konfiguriertes Werkzeug, in dem dieselben Unklarheiten stehen wie vorher, nur jetzt in Pflichtfeldern.
Die Frage, ob Sie ein Werkzeugproblem oder ein Zuständigkeitsproblem haben, lässt sich in einem Gespräch klären. Danach sieht der Projektzuschnitt anders aus.