SAP S/4HANA Cutover: GxP-Freigabe und Rückfall planen

Einordnung und Geltungsbereich

Dieser Beitrag behandelt das Umschaltfenster zwischen Alt- und Neusystem. Die grundsätzliche Migrationsvalidierung und die Einführung von S/4HANA werden in den verlinkten Grundlagen erklärt. Die konkrete SAP-Edition, eingesetzte Migrationswerkzeuge und kundeneigene Erweiterungen bestimmen die technischen Schritte.

Quellen: [1] [2]

Warum eine erfolgreiche Generalprobe die letzte Datenübernahme nicht ersetzt

Trennen Sie technische Betriebsbereitschaft von fachlicher Nutzbarkeit. Der Systemzugriff kann funktionieren, während ein Laborergebnis noch im Altsystem festliegt oder eine Lieferfreigabe auf einem überholten Status beruht. Beschreiben Sie die erste erlaubte Tätigkeit und die noch gesperrten Abläufe. Ein globales „Go“ ohne diese Grenzen ist für die Schichtübergabe wenig hilfreich.

Ein Rückfall muss auch die seit dem Umschalten neu entstandenen Aufzeichnungen berücksichtigen. Sobald beide Systeme Geschäftsvorgänge verarbeitet haben, reicht das Zurückspielen einer Sicherung unter Umständen nicht mehr. Regeln Sie den Datenabgleich und die Verantwortlichkeit für solche Übergangsvorgänge bereits im Plan.

Quellen: [1] [2]

Ein Cutover-Runbook mit fachlichen Haltepunkten erstellen

Der Cutover verbindet technische Umschaltung und fachlichen Betriebsbeginn. Ein Runbook sollte deshalb nicht nur Jobs und Uhrzeiten enthalten. Benennen Sie je Schritt Eingangsvoraussetzung, ausführenden Verantwortlichen, erwartetes Ergebnis, Nachweis und Entscheidung bei Abweichung. Ein fachlicher Haltepunkt bedeutet, dass der nächste kritische Schritt erst nach der bezeichneten Bewertung beginnt.

Grenzen Sie die SAP-Edition, Landschaft und eingesetzten Werkzeuge ab. Ein On-Premises-Projekt mit eigener Transportsteuerung unterscheidet sich von einer Cloud-Edition mit anderen Betriebs- und Änderungswegen. Beschreiben Sie genau, welche Schritte der Anbieter, der Implementierungspartner und Ihr Team übernehmen. Ein fremdes Muster-Runbook kann eine Orientierung sein, muss aber auf die tatsächliche Architektur übertragen werden.

Planen Sie die erste erlaubte produktive Tätigkeit. Darf das Team zunächst nur Stammdaten prüfen oder bereits qualitätsrelevante Materialbewegungen ausführen? Welche Abläufe bleiben bis zur Klärung gesperrt? Diese Nutzungsgrenzen helfen der Schichtübergabe erheblich. Eine pauschale Aussage „SAP ist live“ enthält diese Information nicht.

Quellen: [1] [2]

Die letzte Delta-Übernahme nachvollziehbar prüfen

Ein Probelauf kann freitags bestanden sein, während am Wochenende noch Chargen gesperrt, Bestände gebucht oder Aufträge abgeschlossen werden. Legen Sie deshalb fest, wie der finale Quellstand bestimmt wird. Benötigt werden nachvollziehbare Zeitpunkte und eine klare Regel für Änderungen nach dem vereinbarten Schnitt. Das kann je Objekt unterschiedlich umgesetzt sein.

Vergleichen Sie nicht nur Mengen. Eine unveränderte Anzahl von Chargen kann geänderte Statuswerte verdecken. Ein unveränderter Gesamtbestand kann falsch zugeordnete Mengen enthalten. Identifizieren Sie kritische Änderungen anhand eindeutiger Schlüssel und vergleichen Sie deren fachliche Bedeutung. Dokumentieren Sie bewusst ausgeschlossene Vorgänge und ihren weiteren Bearbeitungsort.

Bei mehreren Extraktionen muss erkennbar sein, welcher Lauf welchen Datenstand erzeugt hat. Erhalten Sie Paketkennung, Mappingversion und Abgleichsbericht. Ein späterer manueller Nachtrag darf nicht die Verbindung zwischen ursprünglicher Extraktion und endgültigem Ziel verdecken. Bewerten Sie außerdem, ob Wiederholungsimporte bereits verarbeitete Datensätze verändern oder duplizieren können.

Quellen: [1] [2]

Beispiel: gesperrte Charge im letzten Umschaltfenster

Das Beispiel ist konstruiert. Am Freitag wird die Generalprobe abgeschlossen. Am Sonntag erhält Charge C-72 im Quellsystem einen Sperrstatus. Am Montag soll das Ziel starten. Die letzte Übernahme enthält die Charge, aber nicht ihre Statusänderung. Ein Abgleich der Datensatzanzahl meldet Erfolg. Erst der inhaltliche Deltaabgleich erkennt die fehlende Änderung.

Der eigene Starttest verlangt, dass eine definierte Auslieferung mit C-72 entsprechend der gewählten Prozessregel nicht möglich ist. Ein freigegebener Vergleichsbestand soll dagegen den erlaubten Ablauf ermöglichen. Dokumentieren Sie Datenstand, Benutzerrolle, aufgerufene Aktion und tatsächliche Reaktion. Der Artikel behauptet keine universelle Sperrwirkung jedes SAP-Status; die Regel wird für den konkreten Prozess festgelegt.

Wird die falsche Nutzung möglich, folgt eine bewertete Abweichung. Klären Sie, ob weitere Statusänderungen seit Freitag fehlen. Die Ursache kann in Deltaauswahl, Mapping oder Ladereihenfolge liegen. Nach Korrektur wird der betroffene Umfang erneut abgeglichen und der Fachtest wiederholt. Die bloße manuelle Korrektur von C-72 ist bei einem systematischen Deltafehler zu wenig.

Quellen: [1] [2]

Schnittstellen und Nachrichten beim Wechsel kontrollieren

Beschreiben Sie, wann Sender und Empfänger gestoppt und wieder gestartet werden. Nachrichten können vor dem Schnitt erzeugt, aber danach verarbeitet werden. Eine technische Warteschlange kann Daten enthalten, die bereits im Ziel übernommen wurden. Ohne eindeutige Regeln drohen fehlende oder doppelte fachliche Vorgänge.

Verknüpfen Sie Nachrichtenkennung und Geschäftsobjekt. Prüfen Sie eine normal verarbeitete Nachricht, eine verzögerte Nachricht und eine kontrollierte Wiederholung. Beobachten Sie den fachlichen Endzustand beim Empfänger. Eine technische Empfangsbestätigung beantwortet noch nicht, ob beispielsweise der richtige Status auf die richtige Charge angewandt wurde.

Legen Sie fest, wer während der Startphase Warteschlangen und Fehler beurteilt. Eine automatische Wiederholung kann technische Erreichbarkeit herstellen, aber fachliche Dopplungen erzeugen. Benötigt werden passende Erkennungs- oder Vermeidungsmechanismen und ein klarer Klärungsweg. Die konkrete technische Ausgestaltung hängt von Schnittstelle und Landschaft ab.

Quellen: [1] [2]

Rückfall vor dem Start fachlich durchdenken

Ein Backup und ein Rückfallplan sind nicht dasselbe. Ein Rückfall muss klären, welcher Systemstand wiederhergestellt wird und wie seit der Umschaltung entstandene Vorgänge behandelt werden. Haben Mitarbeiter im Ziel bereits Bestände gebucht oder Entscheidungen getroffen, kann ein bloßes Zurückspielen einer Sicherung Informationen verlieren oder widersprüchliche Stände erzeugen.

Benennen Sie einen Entscheidungspunkt und die Informationen, die dort verfügbar sein müssen. Dazu können verbleibende Zeit, Ursache des Befunds, betroffener Umfang und Wiederherstellbarkeit gehören. Die letzte technisch mögliche Rücksicherung ist nicht automatisch der letzte fachlich sinnvolle Rückfall. Halten Sie diese Grenze im Runbook sichtbar.

Erproben Sie geeignete Teile des Rückfallwegs in der Generalprobe. Der Test sollte relevante Systemabhängigkeiten und Datenabgleiche berücksichtigen. Eine geschätzte Dauer ist schwächer als ein beobachteter Ablauf unter bezeichneten Bedingungen. Wenn Teile nicht praktisch erprobt werden können, bleibt diese Grenze ausdrücklich in der Entscheidung sichtbar.

Quellen: [1] [2]

Freigabeprotokoll und erste Betriebsphase

Die Freigabe sollte den tatsächlich gestarteten Stand bezeichnen: Release, relevante Konfiguration, Datenübernahme, Rollen und Schnittstellen. Verweisen Sie auf bewertete Befunde und erlaubte Nutzungsgrenzen. Die zuständigen Rollen entscheiden anhand der vorgesehenen Verfahren; ein Projektleiter ersetzt nicht automatisch die fachliche Qualitätsentscheidung.

Für die ersten Betriebstage eignen sich eine eindeutige Kontaktliste, ein gemeinsamer Fehlerkanal und Kriterien für Eskalation. Trennen Sie einen Bedienhinweis von einem Datenintegritätsbefund. Erhalten Sie die Verbindung zu Cutover-Schritten, damit eine Abweichung nicht vorschnell als gewöhnliches Betriebsproblem behandelt wird. Verbleibende Aufgaben brauchen Verantwortliche und nachvollziehbare Termine.

Der Abschluss des Cutovers erfolgt erst mit der geordneten Übergabe. Migrationsnachweise, offene Vorgänge, historische Zugriffe und die Verantwortung für Monitoring bleiben verfügbar. Ein technisch erfolgreicher Start ist ein Meilenstein im Lebenszyklus, kein Ende aller Nachweis- und Betriebsaufgaben.

Quellen: [1] [2]

Arbeitsvorlage: Go- oder Rückfallentscheidung mit Datenstand begründen

Bereiten Sie die Entscheidungsunterlage vor dem Umschaltfenster vor. Sie sollte die tatsächlich benötigten Informationen enthalten, nicht erst unter Zeitdruck als Folienzusammenfassung entstehen. Benennen Sie Zuständigkeit, letzte sinnvolle Entscheidungsgrenze und Folgen eines Rückfalls. Eine technische Rücksicherung kann fachlich ungeeignet werden, sobald neue Vorgänge entstanden sind.

Die Vorlage verbindet Zeit, Daten und Nutzung. Ein grüner Gesamtfortschritt darf einen ungeklärten kritischen Befund nicht verdecken. Umgekehrt sollte ein unabhängiger kleiner Restpunkt nicht ohne fachliche Bewertung den gesamten Ablauf bestimmen. Die Entscheidung wird anhand konkreter Wirkung, geeigneter Kontrollen und verfügbarer Rückfalloptionen getroffen.

Halten Sie die tatsächlich getroffene Entscheidung und ihre Voraussetzungen fest. Wenn sich danach neue Informationen ergeben, wird die Bewertung angepasst. Ein früheres Go ist keine unbegrenzte Erlaubnis für eine inzwischen veränderte Situation. Die erste Betriebsphase braucht deshalb einen passenden Weg für Befunde, Datenabgleich und Eskalation.

Quellen: [1] [2]

Die nächsten Schritte

• Quell- und Zielstand einschließlich offener Vorgänge schriftlich abgrenzen.
• Start- und Abbruchkriterien gemeinsam mit QA, Fachbereich und IT festlegen.
• Delta-Übernahme, kritische Berechtigungen und erste Ende-zu-Ende-Vorgänge prüfen.
• Abweichungen, Entscheidung und zuständige Ansprechpartner für die Startphase dokumentieren.