Go-Live: Muss es immer der große Knall sein?
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.
Tag der Wahrheit: der Go-Live
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.
Die drei Idealtypen des Go-live
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.
- Risiko: Die Akzeptanz bei Usern ist nicht gegeben, (wesentliche) Bausteine und Funktionen sind während des Projektes nicht bedacht und nicht hinreichend getestet worden.
- Chance: Bei kurzer Laufzeit und einer standardisierten Lösung kann in kürzerer Zeit ein komplettes Toolset bereitgestellt werden.
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.
- Risiko: Aufwandssteigerung gegenüber der ursprünglichen Planung sowie eine potenzielle Projektverzögerung bei zu kleinteiligem Vorgehen. Ursache für diese Risiken sind zumeist umfangreiche Überarbeitungen (z. B. in Form von technischen Nachbesserungen) von bereits ausgerollten Prozessen.
- Chance: Der Reifegrad des Tools wächst während der Migration und es ist möglich viele Unternehmensbereiche an der Entwicklungsarbeit teilhaben zu lassen. Die Identifikation der Nutzer mit dem neuen Werkzeug kann zum Start gestärkt werden.
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.
- Risiko: Da Altwerkzeuge in der Pilotphase parallel zur neuen Lösung betrieben werden, wird die Komplexität für den Benutzer erhöht. Zudem besteht die Gefahr eines Informationsverlusts oder auch einer SLA-Verletzung, da bspw. Tickets übersehen und nicht bearbeitet werden.
- Chance: In abgekapselten Unternehmensbereichen bietet der Pilotbetrieb wie auch die Migration die Möglichkeit, User an der Entwicklung des neuen Werkzeugs zu beteiligen und damit die Akzeptanz zu stärken. Zusätzlich wird der Reifegrad der Lösung gesteigert.
Welches Modell ist für ihr Unternehmen von Vorteil?
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.
Weitere Erfolgsfaktoren: Terminwahl und Zähigkeit
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.
Die Artikelreihe im Überblick
- Artikel 0:
Im Nachhinein ist man immer schlauer - ITSM Tool Einführung rückwärts gedacht. - Artikel 1:
Go-Live - Muss es immer der große Knall sein? - Artikel 2:
Wie wird implementiert? Zwischen methodischem Dogmatismus und „einfach fertig machen“. - Artikel 3:
„Alte Liebe oder reif für die Entsorgung“ – die alte ITSM-Landschaft zwischen Ablösung und Revitalisierung - Artikel 4:
ITSM, auf die Plätze, fertig, los! Aber was ist noch mal das Ziel? - Artikel 5: Retrospektive
Erkenntnisse der Retrospektive: Hätte, wenn und aber – diese Stolpersteine gilt es zu vermeiden.
Ihre Ansprechpartner für IT-Exzellenz
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.
