Selten endet die Einführung eines ITSM-Tools mit dem Go-Live. Häufig folgen auf den Tag der Wahrheit weitere schweißtreibende Tätigkeiten wie bspw. während einer Hypercare-Phase. Und doch ist der Go-Live in der Regel der Meilenstein, auf den das gesamte Projekt ausgerichtet ist. Genau aus diesem Grund steht dessen Betrachtung am Anfang – und nicht am Ende – dieser Artikelserie zur Einführung eines ITSM-Tools.
Losgelöst von der Motivation für die Einführung eines ITSM-Tools und dem methodischen Vorgehen ist der Go-live: Der Tag der Entscheidung. Mit dem Verlassen der „geschützten“ Projektumgebung werden auch die Benutzer mit dem neuen Werkzeug in Berührung kommen, welche bisher nicht in das Projekt eingebunden waren. Die Nutzer betreten aus ihrer Sicht Neuland und sehen sich mit einer Vielzahl von Veränderungen konfrontiert. Die ersten Tickets werden über neuartige Eingabemasken aufgeben, Workflows sind nicht mehr so wie gewohnt und der Rücklauf der Informationen präsentiert sich stark verändert. Beim Austausch oder der Einführung eines ITSM-Tools sind auch der Gewohnheitsgrad der User an bestehende Werkzeuge und die damit verbundene Akzeptanz wichtige Einflussfaktoren. Aber auch der emotionale Aspekt sollte nicht unterschätzt werden.
Prinzipiell können drei Modelle des Go-live voneinander unterschieden werden. Alle drei Modelle zum Go-Live zahlen mehr oder weniger stark auf die benannten Aspekte ein. Wichtige Fragen hierbei sind: Welche Chancen und welche Risiken bestehen bei der Einführung des Tools?
Der Big Bang: Zum Stichtag kommt es zur Inbetriebnahme des neuen ITSM-Werkzeugs. Der feste Termin begründet sich meist darin, dass Termintreue im Projekt Vorrang hat. Die Veränderung ist unausweichlich und der Auftraggeber wünscht einen klaren und raschen Change. Mit dem Go-Live werden alle Prozesse, Tool-Ansichten und Funktionen in „einem Rutsch“ in Betrieb genommen.
Die Migration: In diesem Modell wird das neue ITSM-Tool mit allen Prozessen sukzessive in Betrieb genommen. Schrittweise werden Organisationseinheiten (bspw. Finance, HR oder auch Betriebsstandorte) auf die neue Plattform überführt.
Der Go-Live mit Pilotbetrieb: In dem Pilotbetrieb werden Leistungsmodule in Betrieb genommen und beim Massenrollouts in einer definierten Qualität, bzw. festgelegten Reifegrad bereitgestellt. Als Leistungsmodule können ausgewählte ITIL-Prozesse in definierten Unternehmensbereichen (Incident-Management, Change-Management oder auch Request-Management) in Betrieb genommen werden.
Nun stellt sich die Frage, welches Szenario das geeignete für ihr Unternehmen ist. Sicherlich können alle drei Varianten überall zum Einsatz kommen. Dennoch ist es sinnvoll, hier im Einzelfall zu beurteilen.
Der Big Bang bietet sich grundsätzlich für (kleinere) Unternehmen an, bei denen die Nutzung des Werkzeugs intern erfolgt und die Individualisierung der ITSM-Prozesse nicht weit fortgeschritten ist.
Die Migration bietet Vorteile für Konzerne, die mit unterschiedlichen Abteilungen, Fachbereichen und verteilten Standorten die Implementierung des ITSM-Tools erfolgreich meistern wollen. Die IT agiert als interner und externer Serviceprovider und verfügt über eine Vielzahl von Schnittstellen (Datenbanken, ERP, CRM und andere Ticketsysteme). Die Migration ermöglicht den separaten Roll-out eines neuen ITSM-Werkzeugs an Standorten sowie in Fachabteilungen und ermöglicht die ganzheitliche, chronologisch Implementierung der ITSM-Prozesse.
Der Go-Live mit einem vorgeschalteten Pilotbetrieb ist analog zur Migration für Konzerne eine vorteilhafte Vorgehensweise. In diesem Szenario ist es allerdings nur möglich, ITSM-Prozesse in der Implementierung voneinander zu separieren. Als erster ITIL-Prozess bietet sich Request-Management an, da dieser meist gut zu isolieren ist. Darauf folgt anschließend Incident-, Problem- und Change-Management.
Alle drei Varianten haben miteinander gemeinsam, dass es einen Tag gibt, an dem ein neues Tool entweder als Ersatz bestehender Lösungen oder als neue Implementierung live geht. Die „richtige“ Terminwahl für einen Go-Live ist ein entscheidender Erfolgsfaktor. Generell bietet ein späterer Go-Live die Chance auf einen höheren Umsetzungsgrad der Lösung in den Dimensionen Performance, Stabilität und Akzeptanz. Zudem verringert sich in der Regel der Supportaufwand nach dem Go-Live. Hingegen besteht bei einem früheren Go-Live-Zeitpunkt die Chance schneller ein Ergebnis zu präsentieren. Allerdings mit dem Risiko in der ersten Betriebsphase den Support mit einem erhöhten Ticketvolumen, aufgrund der geringeren Produktreife, zu überfordern. Die Wahl des Zeitpunkts sollte wohl überlegt sein und anhand klar definierter KPIs und einer realistischen Einschätzung der Gesamtlage erfolgen.
Vor allem müssen sowohl Projektteam als auch Management den Go-Live wirklich wollen. Nackenschläge „auf den letzten Metern“ sind in solchen Implementierungsprojekten vorprogrammiert. Ungeahnte Performanceengpässe oder auch nicht bedachte Funktionen und modifizierte Anforderungen aus dem Business bilden oftmals die unerfreulichen Hürden. Der „Zug zum Tor“ wird in dieser Phase zum entscheidenden Erfolgsfaktor.
Der Go-Live ist ein wichtiges Puzzlestück bei der erfolgreichen Inbetriebnahme eines (neuen) ITSM-Tools. Aber mindestens genauso wichtig ist der Weg dorthin. Die Vorgeschichte des Go-Live und die zur Auswahl stehenden Projektmanagementmethode sind Gegenstand des nächsten Artikels.
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 unserer Cassini-Experten darüber, welche Rolle Ihre IT-Organisation einnehmen könnte.
