Artikelreihe: ITSM im Fokus - Von Big Bangs und Migrationen
Im zweiten Artikel wurde der Schwerpunkt auf die Projektmanagementmethode gelegt. Also gezielt die Frage beantwortet „Wie führe ich ein neues IT-Service-Management-Tool (ITSM-Tool) in meine Organisation ein?“. Mindestens genauso spannend ist jedoch die Antwort auf die Frage „Was wird abgelöst bzw. revitalisiert?“. Die Motivation hinter der Transformation der alten ITSM-Landschaft, wurde bereits im ersten Artikel intensiv diskutiert: In bestehenden bzw. gewachsenen IT-Organisationen kommt diesen etablierten, tool-gestützten ITSM-Prozessen eine zentrale Bedeutung zu. ITSM-Werkzeug und -Workflow sind untrennbar miteinander verbunden und jeder Eingriff in diese Beziehung sollte wohl überlegt sein. Im Projekt bewegt man sich thematisch damit zwischen zwei Extremen. Mit der Einführung eines neuen ITSM-Tools sollen
Bei der ersten Variante wird meist die Einführung eines geeigneten Standardtools angestrebt. Mit der zweiten Variante sind mindestens konfigurative Anpassungen am Werkzeug selbst erforderlich. In der Folge werden die Kosten der Individuallösung, die einer Standardlösung übersteigen. Für beide Lösungswege gilt: Während des Projektes wird eine intensive fachliche Diskussion zum Nutzen bestehender Prozesse entbrennen. Hier besteht die Gefahr nie endender Glaubenskämpfe innerhalb der IT-Organisation. Sowohl in der Projektlaufzeit als auch danach.
Wie kann diesen unterschiedlichen Auffassungen faktenbasiert begegnet werden? Ganz einfach: zu Beginn und vor der Auswahl eines Tools sowie eines Herstellers sollte die Ist-Situation klar definiert werden. Hierzu gehört neben der Erhebung und Beschreibung der betroffenen ITSM-Prozesse auch eine solide Abschätzung der damit verbundenen Kosten (Personal, Lizenzen und Betrieb). Bei der „gedanklichen Überführung“ vom Ist-Zustand zum Zielbild müssen besonders die vertraglichen Verpflichtungen (z. B. als interner/externer Dienstleister) sowie der Umfang der verantworteten Services (nur IT-Support bis „full managed service“) berücksichtigt werden.
Um ein erstes Bild von der Situation zeichnen zu können, bedarf es nicht zwingend monatelanger Analysephasen und Konzeptarbeiten. Ein zeitlich befristeter erster Quickcheck hilft bei der groben Einschätzung: Wo können Prozessredundanzen reduziert werden?
Im Anschluss folgt die Detailanalyse der ITSM-Prozesse, z. B. die End-to-End-Betrachtung des Incident-Management. Hier werden Lean-Ansätze angewendet und Potenziale zur Automatisierung identifiziert. Ergänzend sollten spätestens zu diesem Zeitpunkt die Ist-Kosten detailliert erhoben werden.
Die Detailanalyse wird folgende Ergebnisse zu Tage fördern:
Das Zielbild der neuen ITSM-Landschaft kann aus den zuvor beschriebenen Ergebnissen und den zukünftig abzubildenden IT-Services abgeleitet werden. Die Validität des Business Case muss zu diesem Zeitpunkt offensichtlich sein. Es kann durchaus vorkommen, dass die Attraktivität der Transformation bei dieser Detailanalyse „leidet“ (z. B. weil die Kosten gestiegen sind). Jedoch ist es besser vor dem Projektstart diese Diskussion mit den Stakeholdern zu führen, als im laufenden Projekt Budgetveränderungen vornehmen zu müssen.
Kurzum: Alte Prozesse haben meist gut gedient, sollten aber vor der Überführung in die „neue Welt“ hinsichtlich Effizienz und Effektivität intensiv verprobt werden. Bei der Ablösung eines ITSM-Tools im Zuge einer Neueinführung ist Entschlossenheit gefragt. Machen alte Prozesse Sinn, können diese übernommen werden – aber bitte nicht ungeprüft.
Alles was ein Ende hat, braucht einen Anfang. Kein erfolgreicher Go-Live ohne vernünftigen Projektstart. Welche Bedingungen zwingend erfüllt sein müssen, damit das Projekt den richtigen Pfad einschlägt, ist Thema des nächsten Artikels dieser Reihe.
Wir sind vom Wettbewerbsvorsprung durch adaptive IT überzeugt. Und wir erläutern Ihnen gern, wie sich Ihr Unternehmen hierfür am besten positioniert. Nutzen Sie unser Angebot und sprechen Sie mit einem Cassini-Experten darüber, welche Rolle Ihre IT-Organisation einnehmen könnte.
