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:  

1. Prozessredundanzen
2. Realistische Prozesskosten
3. Potenziale zur Automatisierung 

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.