Fallback im Cut-over? So bereitest du dich vor und erstellst einen Plan

Ein Fallback muss bspw. eingeleitet werden, wenn:

• Wichtige Ressourcen inkl. Vertretung ausfallen
• Manuelle oder maschinelle Tätigkeiten viel länger dauern, als geplant
• Die Datenmigration fehlerhaft ist und nicht mehr in angemessener Zeit korrigiert werden kann
• Die Migrationsprogramme zu lange laufen und die Nacht sprichwörtlich “zu kurz” wird
• Schwerwiegende Fehler in Softwarekomponenten oder Schnittstellen auftreten

Du hast die Risiken vorab reduziert, sofern es dir möglich war. Dennoch brauchst du einen Plan für den Fall, der eigentlich gar nicht eintreten soll. Je besser du vorbereitet bist, desto kontrollierter kannst du agieren und dabei einen kühlen Kopf bewahren. Im einfachsten Fall reicht es möglicherweise aus, die Backups deines SAP-Systems und der Satellitensysteme zurückzuspielen. Gehe deinen Cut-over-Plan gedanklich rückwärts durch. Was muss alles zurückgestellt werden, damit der ursprüngliche Zustand wiederhergestellt ist?

Typische Aktivitäten sind:

• Backups einspielen: SAP und Satellitensysteme
• Prüfungen durchführen (Bilanz und Bestände Vorher / Nachher)
• Hintergrundjobs starten
• Schnittstellen aktivieren
• Sicht- und Live-Tests durchführen
• Benutzer freischalten
• Im Cut-over gebuchte Belege erneut im Alt-System buchen
• Stakeholder informieren

Terminiere rückwärts ab dem spätmöglichsten Arbeitsbeginn am Montag früh. Deine Berechnung ergibt dann den Beginn, bspw. am Sonntag um 18:30 Uhr. Der Point of no Return ist danach überschritten.

Als Point of no Return wird laut wikipedia der Punkt bezeichnet, “…von dem an eine Rückkehr zum Anfangs- oder Ausgangspunkt nicht mehr möglich ist.” Wann ist dieser Zeitpunkt in deinem Cut-over erreicht? Wenn das erste IDoc verbucht worden ist? Wohl eher nicht, denn das kannst du normalerweise noch relativ einfach stornieren. Interessanter wird es bei Massendaten, also wenn die Menge der Belege zu groß für eine geordnete Rückabwicklung ist.

Wenn etwas richtig schief geht, solltest du zunächst ein Expertenteam versammeln. Das Team ist dabei breit aufgestellt: Entwicklung, Fachbereiche, fachfremde Personen, Projektmanager, Führungspersonal… Kreatives Denken ist jetzt ausdrücklich erwünscht. Verwende bspw. die Methode des Brainstormings.

Ist dein Fallback komplex und beinhaltet sehr viele Aktivitäten? Dann solltest du deinen Plan managementtauglich darstellen und kommunizieren. So ist es für Außenstehende einfacher, deinen Plan zu verstehen. Du kannst dieselben Techniken wie im Beitrag Einen Cut-over-Plan managementtauglich darstellen verwenden.

Für den Fall, dass die IT-Systeme komplett ausfallen, gibt es Notfallpläne. Oder es sollte zumindest welche geben 😉

• Ist eine Lösung abzusehen (bspw. Stromausfall in 30 Minuten behoben), könnte ein Notfallszenario so aussehen: abwarten.
• Ist keine schnelle Lösung in Sicht, wird bspw. mit Papier und Stift gearbeitet. Jede Warenbewegung wird aufgeschrieben. Entsprechende Formulare können vorab erstellt, ausgedruckt und verteilt werden.
• Konnten die Warenbewegungen nicht aufgeschrieben, wird eine Inventur durchgeführt.
• Alternativ werden einzelne Filialen oder Verteilzentren vorübergehend geschlossen

Wenn du dir die typischen Gründe anschaust, warum ein Fallback überhaupt auftritt, fällt eins direkt auf: viele Risiken kannst du bereits im Vorfeld reduzieren, sodass es erst gar nicht zum Fallback kommt. Beispielsweise ersparst du dir viel Ärger mit einem guten Testmanagement. Darüber hinaus führst du eine oder mehrere Generalprobe(n) durch, indem du deinen Cut-over auf dem Testsystem simulierst:

• Wie viel Zeit wird für die jeweiligen Aktivitäten tatsächlich benötigt?
• Funktioniert die Kommunikation zwischen den beteiligten Personen?
• Wie lange laufen die Migrationsprogramme?
• Welche Fehler treten auf und können beim nächsten Lauf vermieden werden?

In Extremfällen kann auch eine temporäre Doppelpflege im alten und neuen System in Betracht gezogen werden.