In großen IT-Transformationen entscheidet sich der Erfolg nicht allein durch ein gutes Systemdesign oder saubere Migrationstabellen – sondern im Moment des Übergangs. Der Cutover, also der kontrollierte Wechsel von einer alten auf eine neue Systemlandschaft, ist oft die kritische Phase im gesamten Projekt. Besonders im HR-Bereich, wo Datenqualität, gesetzliche Fristen und hochsensible Prozesse aufeinandertreffen, kann ein schlecht geplanter Cutover gravierende Folgen haben.
Dieser Artikel gibt einen umfassenden Überblick über das Thema Cutover Management im HR-Umfeld, erklärt, was dahintersteckt, welche Fragen man sich stellen sollte – und warum es sich lohnt, diesen Übergang sorgfältig und mit klarer Methodik zu gestalten.
Was ist ein Cutover überhaupt?
Der Begriff „Cutover“ bezeichnet den geplanten Übergang von einem alten System oder Prozess zu einer neuen Lösung. Dabei geht es um weit mehr als einen simplen Go-Live Termin. Der Cutover ist ein komplexes Zusammenspiel aus technischen, organisatorischen und kommunikativen Maßnahmen, die minutiös geplant und durchgeführt werden müssen. Besonders im HR-Bereich betrifft der Cutover sensible Daten wie Personalstammdaten, Abwesenheiten, Zeitwirtschaft, Payroll-Daten oder Organisationsstrukturen.
Die typischen Inhalte eines Cutover sind vielfältig. Bei einem Wechsel auf ein neues System müssen für gewöhnlich die Daten vom alten System auf das neue übertragen werden. Die Datenmigration kann in vollen Datenladungen oder bei Bedarf auch in Teilladungen erfolgen. Die Anforderungen an die Datenmigration sollten zuvor mit den einzelnen Abteilungen geklärt werden. Teilladungen haben den Vorteil, dass bei großen Datenmengen nicht alle Daten erneut übertragen werden müssen, sondern nur jene, die eine Änderung erfahren haben. Initial erfolgt die Datenmigration aber in der Regel mit einer Vollladung. Die Teilladungen bauen dann auf der initialen Vollladung auf.
Für gewöhnlich unterscheidet sich die Datenstruktur der neuen Systemlandschaft vom alten System. Aus diesem Grund geht mit einem Systemwechsel auch eine Konvertierung oder Transformation der Daten vom Altsystem einher. Auch neue Rechte- und Rollenkonzepte müssen definiert werden, um eine korrekte Handhabung des Systems gewährleisten zu können.
Zum Cutover-Zeitpunkt erfolgt dann die finale Umstellung auf die neue Systemlandschaft. Hierfür werden die Schnittstellen auf das neue System umgeschaltet, das neue System aktiviert und das alte offline genommen. Begleitet wird der gesamte Prozess durch umfangreiche Kommunikationsmaßnahmen.
Warum ist ein Cutover notwendig?
Parallel zum Tagesgeschäft ist ein Systemwechsel in der Regel nicht einfach so durchführbar. HR-Systeme sind essenziell für den Betrieb – von Lohnzahlungen über Zeiterfassung bis zu gesetzlichen Meldungen. Ein sauberer Cutover stellt sicher, dass alle diese Daten vollständig, korrekt und im richtigen Format überführt werden. Nebenbei müssen operative Prozesse nahtlos weiterlaufen und gesetzliche Anforderungen eingehalten werden. Kurz gesagt: Die Benutzer müssen direkt arbeitsfähig sein. Um also den Wechsel auf das neue System zeitlich so kurz wie möglich zu halten, wird ein dediziertes Cutover-Wochenende definiert, an dem der konkrete Wechsel stattfindet.
Welche Rahmenbedingungen bringt ein Cutover mit sich?
Ein Cutover wird nicht im luftleeren Raum geplant. Ebenso wenig ist der Cutover eine einfache ToDo-Liste, die es abzuarbeiten gilt. Der Cutover ist eine komplexe Struktur aus Aufgaben, Zeiten, Abhängigkeiten und Ressourcen, die an eine Vielzahl an Rahmenbedingungen geknüpft sind, die es zu berücksichtigt gilt.
Die Rahmenbedingungen können zeitliche Vorgaben sein, um bspw. dem Monatswechsel zuvorzukommen und Gehaltszahlungen über das neue System gewährleisten zu können. Auch steht ein System nicht für sich allein. In den meisten Fällen ist es ein Zusammenspiel aus mehreren unterschiedlichen Systemen. Einzelne Komponenten können voneinander abhängig sein. Der Cutover muss daher sicherstellen, dass alle Systeme zum gleichen Zeitpunkt funktionsfähig und nutzbar sind. Für die Funktionsfähigkeit müssen die Fachbereiche, die IT und externe Dienstleister sicherstellen, dass die nötigen Ressourcen zur Verfügung stehen. Aktivitäten der zuständigen Ressourcen benötigen Zugriffe auf Test- und Produktivumgebungen. Um den Cutover erfolgreich durchführen zu können, muss Verfügbarkeit und Stabilität garantiert werden.
Was ist für einen Cutover-Prozess notwendig?
Damit der Cutover-Prozess funktioniert und nachvollziehbar abläuft, kann man ihn auf vier Säulen stützen. Diese sind:
- Planung und Struktur
- Steuerung und Kommunikation
- Die Generalprobe
- Dokumentation und Nachverfolgung
Planung und Struktur
Die erste Säule beschreibt einen detaillierten Cutover-Plan mit wenigen, präzisen Meilensteinen, sowie den Verantwortlichkeiten und Zeitfenstern für jede Aktivität während des Cutover Prozesses. Ein Cutover-Plan, gerne auch als Drehbuch bezeichnet, kann je nach Umfang des Projektes mehrere Hundert Aktivitäten umfassen. Bei sehr großen Projekten sind weit über tausend Aktivitäten keine Seltenheit. Hier ist eine Balance zwischen Detailgrad und handlungsfähig bleiben eine sinnvolle Maßnahme. Schließlich möchte man, während eines solchen komplexen Prozesses den Überblick wahren und das Ziel nicht aus den Augen verlieren.
Steuerung und Kommunikation
Die zweite Säule nimmt Bezug auf das Cutover Koordinationsteam, oft auch als „Command Center“ bezeichnet. Das Command Center ist die zentrale Steuerungseinheit während des gesamten Cutover Prozesses. Man könnte sagen, es baut die erste Säule auf – erstellt den Plan, beschreibt die nötigen Aktivitäten, identifiziert den Zeitrahmen, die Verantwortlichkeiten und Abhängigkeiten der Aktivitäten. Unerlässlich für eine funktionsfähige Steuerung des Prozesses ist eine klare Eskalationsstruktur. Wege und Entscheidungsverantwortlichkeiten müssen klar definiert und beschrieben sein, damit in Notfällen effektiv und effizient gehandelt werden kann.
Generalprobe
Die dritte Säule nimmt Bezug auf einen großen Testlauf (mindestens einer sollte durchgeführt werden). Die sogenannte Generalprobe dient dem Testen der zeitlichen Abläufe, dem Datenvolumen und der damit einhergehenden Kapazitäten der neuen Systeme sowie sämtlicher identifizierter kritischen Punkte. Die Generalprobe ist ein nicht zu unterschätzender Bestandteil des Cutover. Sie erlaubt die nüchterne und kritische Betrachtung der eigenen Planung. Die Lessons Learned, die aus der Generalprobe resultieren, sind ein elementarer Bestandteil des weiteren Vorgehens und erlauben es das Unbekannte und Unerwartete sichtbar zu machen.
Dokumentation und Nachverfolgung
Die vierte Säule nimmt Bezug auf die Transparenz während eines Cutovers. Um Transparenz zu gewährleisten, können viele Methoden herangezogen werden – Checklisten, Templates, Statusberichte, etc. – im Grunde alles, was Kontrolle über das Fortschreiten im Prozess ermöglicht. Es ist ein leichtes in der Komplexität eines Cutovers den Überblick zu verlieren. Die Dokumentation und Nachverfolgung erlaubt es das Ziel stets im Blick zu behalten, Abwege zu identifizieren und Korrekturen einzuleiten.
Was sollte man bei der Cutover-Planung beachten?
Bei der Cutover-Planung gilt vor allem sich selbst ehrlich machen und das Ego vor der Tür zu lassen. Es mag etwas klischeehaft klingen, aber Perfektionismus ist der Feind des Guten. Selbst, wenn man glaubt alles perfekt getestet zu haben, so treten beim echten Cutover fast immer Überraschungen auf. Vor allem Abhängigkeiten zwischen Aktivitäten und Systemen müssen stets im Blick behalten werden. Das Alt- und Neusystem müssen synchronisiert werden. Es könnten mehrere Freeze-Phasen (Soft-Freeze und Hard-Freeze) geplant sein, die ein nachträgliches Synchronisieren der Daten erfordern, da während des Soft-Freezes vielleicht noch Änderungen an den Daten stattfanden.
In allen Belangen ist die Kommunikation das A und O. Nicht selten geschehen unerwartete oder unerwünschte Dinge, weil jemand nicht informiert wurde – intern wie extern. Es muss also klar sein, wer wann und worüber informiert werden muss. Auch sollte es nicht als selbstverständlich angesehen werden, dass ein Cutover positiv abgeschlossen wird. Was passiert, wenn ein kritischer Schritt fehlschlägt? Der Cutover-Prozess beinhaltet auch das Erstellen von Fallback-Szenarien. Jede involvierte Abteilung benötigt klare Anweisungen, wie sie wieder auf das Alt-System zurückstellen können. Ein Fallback ist im Grunde ein rückgewandter Cutover Plan, mit seinen dedizierten Aktivitäten, zeitlichen Parametern, Verantwortlichkeiten und Abhängigkeiten.
Und final müssen noch Go-/No-Go Kriterien festgelegt werden, wann der Cutover erfolgreich war oder gestoppt werden muss. Diese objektiven Kriterien sind projekt- bzw. themenspezifisch. Bei einem Cutover auf eine neue HR-Landschaft kann ein solches Kriterium die korrekte und vollständige Migration sämtlicher Daten auf das neue System sein. Ist dies, neben diversen anderen Kriterien, gegeben, so würde der Cutover ein Go erhalten. Kann dies jedoch nicht sichergestellt werden oder man ist sich sogar sicher, dass die Daten zu einem hohen Grad fehlerhaft und unvollständig sind, liegt ein No-Go des Cutovers nahe.
Welche typischen Risiken gibt es und wie lassen sie sich vermeiden?
Kein Projekt ist ohne Risiko. Je komplexer das Projekt, umso umfangreicher und undurchsichtiger die damit einhergehenden Risiken. Ein Cutover ist ebenso ein Projekt, daher gilt hier das gleiche Prinzip. Die folgende Tabelle erhebt keinen Anspruch auf Vollständigkeit, beschreibt aber die typischen Risiken in einem Cutover und welche Gegenmaßnahmen existieren, um ihnen zu begegnen.
| Risiko | Gegenmaßnahme |
| Datenmigration fehlerhaft/unvollständig | Wiederholte Testläufe und Datenprüfung |
| Systeminkonsistenzen | Schnittstellen- und Integrationstests |
| Unklare Zuständigkeiten | RACI-Matrix, klare Rollenbeschreibungen |
| Ausfall Ressourcen | Ressourcenplan und effektive Nutzung und Überwachung der Ressourcen |
| Kommunikationslücken | Info-Mails, Ansprechpartnerlisten |
| Technische Probleme am Go-Live Tag | Notfallpläne, IT-Support |
Welche Rolle spielt das Change Management im Cutover?
Der Wechsel auf ein neues System (z. B. eine neue HR-Landschaft) ist nicht nur ein technischer, sondern auch ein kultureller Schritt. Mitarbeiter müssen neue Oberflächen nutzen, andere oder veränderte Prozesse verstehen, Rollen neu interpretieren. Ein begleitendes Change Management sorgt dafür, dass Nutzer frühzeitig eingebunden werden, Schulungen rechtzeitig stattfinden, Unsicherheiten abgebaut werden und das Vertrauen in das neue System gestärkt wird. All diese Faktoren zahlen darauf ein, dass das neue System von den Mitarbeitern akzeptiert wird. Durch die Nutzung des neuen Systems können Anforderungen entstehen, die zuvor nicht identifiziert wurden. Das Change Management fängt diese Anforderungen auf, analysiert sie und initiiert notwendige Änderungen, um kritischen Faktoren gerecht zu werden.
Warum sind Testphasen und Generalproben unverzichtbar?
Ein Cutover „aus dem Bauch heraus“ funktioniert in komplexen Projekten (bspw. HR-Landschaften) selten. Testphasen und vor allem die Generalprobe zeigen auf, wie lange die geplanten Aktivitäten tatsächlich dauern. Für ein harmonisches Zusammenarbeiten aller Systeme werden in der Regel eine Vielzahl von Schnittstellen genutzt. Sie müssen alle einwandfrei funktionieren. Ein Test zeigt, wo es ggf. klemmt und nochmal Hand angelegt werden muss. Sind die Datenformate korrekt definiert und implementiert worden? Auch dies zeigen Tests besser als nur Vermutungen. Der Teufel steckt oft im Detail. Die Generalprobe zeigt vor allem aber auch wie gut das Zusammenspiel aller Beteiligten funktioniert. Es ist der letzte Härtetest vor dem Go-Live.
Wie wichtig ist die enge Abstimmung mit Payroll, Finanzen und IT?
Im Kontext eines HR-Cutover gibt es aufgrund besonders hoher Risiken einige Bereiche, die ein besonderes Augenmerk verdienen. Zu diesen Bereichen gehören:
- die Payroll-Prozesse,
- die Finanzdaten,
- und die IT,
- Betriebsrat,
- Datenschutz.
Payroll-Prozesse, also die Gesamtheit des Verfahrens zur Erstellung und Ausführung der Lohn- und Gehaltsabrechnungen müssen exakt mit dem Systemwechsel harmonieren. Sollte der Payroll-Prozess nach einem Cutover nicht funktionsfähig sein, ist man gezwungen das alte System zur Gewährleistung der Lohn- und Gehaltszahlungen weiter in Betrieb zu halten. Das bindet Ressourcen auf mehreren Ebenen: ein Team arbeitet weiterhin daran die Funktionsfähigkeit im neuen System herzustellen, ein anderes Team muss die Funktionsfähigkeit des alten Systems sicherstellen (Schnittstellen und Datentransfer aller nötigen Daten sind aber bereits auf das neue System umgestellt), die Nutzer des Payroll-Prozesses müssen vermutlich ineffiziente, manuelle Arbeit aufbringen, um die Zeit bis zur Fertigstellung zu überbrücken, Server müssen weiter betrieben werden, die eigentlich abgeschaltet sein müssen, dies führt zu weiteren Kosten, die eigentlich nicht im Budget sind und einen zuvor eingeplanten Puffer aufzehren. Die damit einhergehenden Probleme wachsen jeden Tag höher. Hinzu kommt, dass Finanzdaten Reporting- und Auditpflichten unterliegen. Die Nutzung paralleler Systeme, die nicht aufeinander abgestimmt sind, verkompliziert das Reporting nur noch mehr. Die IT ist hier in der Pflicht die technische Infrastruktur bereitzustellen, sowie die Schnittstellen und Migrationstools zu konfigurieren. Abschließende Tests helfen die Risiken für oben beschriebenen, negativen Eventualitäten auf ein handhabbares Maß zu reduzieren.
Zwei weitere Punkte umfassen die Abstimmungen mit dem Betriebsrat und dem Datenschutz. Zwei nicht zu unterschätzende Bereiche eines Cutover Prozesses. Sollten diese beiden Institutionen außenvorgelassen werden, besteht ein erhöhtes Risiko, dass bspw. Funktionen eines Systems entgegen gesetzlichen Richtlinien entwickelt werden. Dies hat zur Folge, dass erneut Ressourcen unplanmäßig eingebunden werden, die an anderer Stelle einen besseren Nutzen hätten.
Wie sieht ein effektives Cutover Command Center aus?
Das Cutover Command Center ist das zentrale Steuerungs- und Koordinationsteam während des gesamten Cutover. Der Cutover ist kein Termin oder ein Zeitpunkt. Er ist ein Prozess, der gut und gerne mal einen gesamten Monat in Anspruch nimmt (die Planung und Vorbereitung, die nochmals mehrere Monate in Anspruch nimmt, nicht eingerechnet).
Ein Szenario könnte wie folgt aussehen: Der Zeitpunkt für den Start des Cutover wurde kommuniziert. Anfang des kommenden Monats ist es so weit, keine zwei Tage mehr. Die Generalprobe ist abgeschlossen, das Feedback zur Optimierung des Plans wurde umgesetzt. Der Cutover wird in zwei Phasen unterteilt: dem Soft-Freeze und dem Hard-Freeze. Während des Soft-Freeze (ca. 3 Wochen) können die Mitarbeiter weiterhin Änderungen am Datenbestand des Alt-Systems vornehmen. Sie wurden jedoch gebeten dies nur in kritischen Fällen zu tun und alle anderen Änderungen auf nach den Go-Live zu verschieben. Für die Kommunikation zwischen dem Command Center und den restlichen Teilnehmern des Cutover wurde ein MS Teams Chat mit strikten Regeln erstellt. Es gilt präzise mitzuteilen, welche Aktivität gestartet werden kann, welche Abhängigkeit besteht und die einzelnen Teilnehmer des Cutover berichten ihrerseits präzise den Abschluss oder die Verzögerung ihrer Aktivitäten. Der Cutover Plan ist jedem zugänglich, sodass jeder Teilnehmer seine Aktivitäten kennt und einen Überblick über seine Aufgaben hat. Das Command Center kommuniziert die initiale Aktivität und der Cutover beginnt. Das Command Center ist im ständigen Austausch mit den Cutover-Teilnehmern. Auf diese Weise wird ein Echtzeit-Monitoring zur Statusverfolgung etabliert. Die Kommunikationskanäle und -form sind klar geregelt. Mit der initialen Aktivität beginnt das Migrationsteam die Daten vom Alt-System auf die neue System-Landschaft zu überführen. Nach einiger Zeit treten die ersten Verzögerungen auf. Migrationsprozesse, die auf den Testsystemen noch einwandfrei und zügig durchliefen, benötigen auf dem Zielsystem ein Vielfaches der eingeplanten Zeit. Das Command Center muss nun die Verzögerung auf die folgenden Aktivitäten ausweiten und eine Aussicht auf die kommenden Tage erstellen. Die zuvor identifizierten Abhängigkeiten zwischen den Aktivitäten erweisen sich nun als große Hilfe bei der Analyse. Kurz vor dem Abschluss der Migration der Basisdaten folgen weitere Abteilung mit der Migration ihrer Daten sowie dem Bereitstellen der nötigen Schnittstellen. Einige Schnittstellen zeigen Fehlverhalten. Das Migrieren der separaten Abteilungsdaten funktioniert nicht. Das Command Center muss die Verantwortlichkeiten identifizieren und die Problemlösung initiieren. Eine klar definierte Eskalationskette reduziert die Zeit, um die nötigen Schritte einleiten zu können. Nun müssen nur noch die Schnittstellen zum Alt-System abgestellt werden, bevor in den Hard-Freeze übergegangen werden kann. Es folgt die nächste Migrationsphase der Basisdaten. In Form eines Delta-Loads müssen die von den Mitarbeitern vorgenommenen Änderungen während des Soft-Freeze auf das neue System überführt werden. Bevor dies geschieht, muss jedoch der Zugang zum Alt-System unterbunden werden. Das ist der große Unterschied zwischen dem Soft-Freeze und dem Hard-Freeze.
Damit sind wir in der kritischen Phase des Cutover angekommen, dem Cutover-Wochenende. Die Migration des Delta-Loads verläuft ohne große Probleme, das Team wird sogar vor der eigentlichen Deadline fertig. Damit hat das Test-Team mehr Zeit, um die Daten auf Korrektheit und Vollständigkeit zu prüfen. Das ist ein wesentliches Kriterium für die Go-/NoGo-Entscheidung. Das Command Center trägt die Informationen des Test-Teams zusammen. In einem gemeinsamen Meeting des Command Center, der Projektleitung, der Geschäftsführung sowie Vertreter der einzelnen Abteilungen wird der Status des Cutover besprochen und ein Go oder NoGo für die finale Umstellung auf die neue System-Landschaft entschieden. Laut dem Test-Team sind die Daten weitestgehend korrekt und vollständig. Einige wenige Fehler haben sich eingeschlichen, die aber in der folgenden Hyper Care Phase adressiert werden können. Dem Wechsel auf die neue System-Landschaft steht also nichts im Wege.
Zugegeben, dies ist ein stark reduziertes Szenario, aber es beschreibt den Cutover-Prozess in seiner minimalistischen Form genauso wie er ist. Das Command Center ist die zentrale Steuerungsinstanz und ist dafür verantwortlich die Cutover-Teilnehmer durch die geplanten Aktivitäten zu führen, Verzögerungen und Störungen zu adressieren und wenn nötig an die nächsthöhere Stelle zu eskalieren. Hilfreich sind dabei klar geregelte Kommunikationskanäle und Kommunikationsregel.
Welche Tools oder Template haben sich bewährt?
Es ist hilfreich sich zur Planung des Cutover-Prozesses ein Set an Werkzeugen zuzulegen. Es hat sich gezeigt, dass für die konkrete Planung des Cutover MS Project eine gute Wahl ist. Es vereinfach die minutiöse Planung und vor allem das Abbilden von Abhängigkeiten zwischen den Aktivitäten. Insbesondere das Identifizieren und Hervorheben der Abhängigkeiten ist eine nicht zu unterschätzende Handlung in der Planung des Cutover. Aus diesem Grund sollte ein Tool solch eine Funktion nativ bereitstellen. Ein Umweg über händische ID Vergabe und Referenzierungen ist fehleranfällig, sodass Excel als Hauptprogramm zur Planung des Cutover nicht in Frage kommt. Hinzu kommt, dass so wenige Personen wie möglich im und am Plan arbeiten sollten, um Inkonsistenzen und Fehler zu vermeiden. Ein paralleles Arbeiten innerhalb eines MS Project Dokumentes ist nicht möglich (es gibt die Möglichkeit der Synchronisation via SharePoint, auf die wir hier aber nicht näher eingehen möchten), in Excel hingegen schon, was Excel in dieser Hinsicht erneut fehleranfälliger macht.
Wo es Excel an Möglichkeiten der effektiven und effizienten Planung eines detaillierten Cutovers mangelt, kommt es perfekt als Kommunikations- und Austauschmittel zwischen dem Cutover-Team und den einzelnen Abteilungen zum Tragen. Die Aktivitäten des Cutover Plans fallen nicht vom Himmel, sie müssen in zeitintensiver Arbeit gemeinsam mit den Abteilungen ermittelt und beschrieben werden. Eine Excel-Vorlage kann hier eine große Hilfe sein. Reduziert auf alle nötigen Parameter hilft sie in mehrfachen Iterationen eine robuste Planung geschlossener Aktivitäten-Cluster vorzunehmen. Abschließend müssen die Aktivitäten nur noch aus dem Excel-Dokument in den MS Project Plan überführt werden. Excel-Vorlagen können überall dort zum Einsatz kommen, wo mehrere Personen gleichzeitig arbeiten können sollen und wo es explizit erwartet wird, dass Personen außerhalb des Cutover-Teams Änderungen vornehmen. Ein weiteres Thema in diesem Kontext ist die Rufbereitschaft für den Go-Live. Eine simple Liste mit Abteilungen, Personen und einem Zeitstrahl (Datum und Uhrzeiten), zur Einsicht, wann wer bspw. am Cutover-Wochenende erreichbar sein muss. Eine weitere hilfreiche Vorlage ist die Lessons Learned Vorlage für die Nacharbeitung nach der Generalprobe. Jede Abteilung erhält eine Vorlage, um sie während der Generalprobe mit Anmerkungen, offenen Fragen, Problemen oder anderweitigen Erkenntnisse zu füllen. Der tatsächliche Sinn der Generalprobe ist das Lernen, ob der geplante Prozess auch durchführbar ist. Die Vorlage für das Lessons Learned hilft die aufgetretenen Ereignisse nicht zu vergessen und sie als Feedback für den Plan aufzugreifen.
Was passiert nach dem Cutover?
Der eigentliche Cutover ist nicht das Ende. Für die Benutzer ist es erst der Anfang. Auf den Cutover folgt die Hypercare Phase. In dieser Phase, die einige Tage oder Wochen umfassen kann, kommt eine fokussierte Unterstützung der Benutzer zum Einsatz. Der Cutover ist erfolgt, nun müssen die Benutzer den Standard-Betrieb aufnehmen. Es wird zwangsläufig zu Fehlern kommen, diese können systembedingt oder durch eine falsche Nutzung auftreten. Die Hypercare Phase dient dazu, die Benutzer in der unsicheren Anfangszeit nicht allein zu lassen. Parallel findet ein konzentriertes Monitoring der Systeme statt. Wie ist die Verfügbarkeit? Wie ist die Fehlerquote? Gibt es Nutzer-Feedback? Alles Fragen, die nach einer Antwort verlangen. Schließlich muss die Übergabe an den Betrieb und Support erfolgen. Zum Abschluss folgt noch eine Revision des Projektes. Auch hier werden typische Fragen beantwortet: Was lief gut? Was nicht? Was lernen wir für das nächste Projekt. Es zeigt sich, die Planung und Durchführung eines Cutover ist nur die halbe Arbeit. Die zweite Hälfte folgt direkt im Anschluss in der Form der sogenannten Hypercare Phase.
Wie wird der Erfolg eines Cutovers gemessen?
Der Grad des Erfolges eines Cutovers lässt sich anhand einiger typischer Kriterien des Projektmanagement erfassen:
- Zeit- und Budgeteinhaltung
- Datenqualität nach Migration
- Anzahl produktiver Fehler
- Anzahl offener Tickets nach Go-Live
- Nutzerzufriedenheit (z. B. per Survey)
Zeit- und Budgeteinhaltung
Im Rahmen des Projektes müssen einige nüchterne Fragen gestellt werden. Wurde die geplante Zeit für den Cutover eingehalten? Wurde das geplante Budget für den Cutover eingehalten? Wird eine der beiden Fragen mit Nein beantwortet, sollte klar dargelegt werden können, weshalb es zu der Differenz in Zeit und/oder Budget kam. Eine Dokumentation des Vorgehens sollte es erlauben in diesem Sachverhalt Auskunft zu geben.
Datenqualität nach der Migration
Die Datenqualität nach der Migration entscheidet über die Betriebsfähigkeit des täglichen Geschäfts. Wurde trotz einer schlechten Datenqualität der Go-Live beschlossen, wird ein wesentlicher Teil der Hypercare Phase dafür benötigt die Datenqualität wiederherzustellen – nicht selten durch manuelle Arbeit. Dies hat negative Folgen für die Benutzer des neuen Systems, womit auch die Akzeptanz auf wackeligen Beinen steht.
Anzahl produktiver Fehler
Sind ganze Systembereiche nicht funktionsfähig, handelt es sich um produktive Fehler, die in den Go-Live übernommen wurden. Dies kann dramatische Konsequenzen bis hin zu einem Totalausfall der Betriebsfähigkeit führen. Dies ist ein Kriterium von hohem Gewicht, beim Messen des Erfolgsgrades eines Cutover.
Anzahl offener Tickets nach dem Go-Live
Das Incident Management ist ein Bestandteil der Hypercare Phase. In komplexen Projekten sind Fehler unausweichlich. Ein effektives und effizientes Incident Management hilft dabei diese Fehler zu adressieren. Zeigt sich, dass die Fehler in der Hypercare kontinuierlich abnehmen und bei Übergabe an den Betrieb und Support gar nicht mehr oder nur noch in geringer Menge existieren, ist dies ein gutes Zeichen. Auf der anderen Seite ist eine hohe Anzahl offener Incidents kein Erfolgskriterium für einen Cutover.
Nutzerzufriedenheit
Für gewöhnlich ist das Cutover-Team oder die Projektleitung nicht die direkte und tägliche Nutzergruppe der Systeme. Aus diesem Grund sollte die Zufriedenheit der Nutzer erfasst werden. Interne Umfragen helfen dabei ein Bild der Stimmung der Nutzer zu bekommen. Der Erfolg eines Cutover hängt stark von der Zufriedenheit der Nutzer ab.
Fazit
Cutover Management ist keine rein technische Disziplin. Es ist ein Zusammenspiel aus Präzision, Kommunikation, Erfahrung und Führung. Wer diesen Übergang ernst nimmt, schafft nicht nur einen erfolgreichen Go-Live, sondern legt den Grundstein für nachhaltigen Projekterfolg.
