SAP Go Live absichern und Betrieb stabil halten

Ein SAP-Go-Live scheitert selten an einem einzelnen Fehler. Kritisch wird es, wenn unvollständige Tests, offene Datenkorrekturen, ungeklärte Berechtigungen und fehlende Entscheidungen gleichzeitig auf den Cutover treffen. Wer den SAP Go Live absichern will, muss deshalb nicht nur die technische Produktivsetzung planen. Entscheidend ist, ob Prozesse, Daten, Schnittstellen und die Betriebsorganisation unter realen Bedingungen belastbar zusammenspielen.

Gerade bei S/4HANA-Transformationen, Carve-outs oder der Ablösung gewachsener ERP-Landschaften entsteht häufig ein trügerisches Bild: Das System ist technisch transportiert, Fachbereiche haben abgenommen und der Go-Live-Termin steht. Trotzdem fehlen oft Nachweise dafür, dass kritische End-to-End-Prozesse mit produktionsnahen Daten, realistischen Rollen und angebundenen Umsystemen funktionieren. Ein stabiler Betrieb beginnt nicht mit dem Schalter zur Produktivsetzung, sondern mit einer nachvollziehbaren Go-Live-Readiness.

SAP Go Live absichern: Vom Termin zur Freigabeentscheidung

Ein Go-Live-Termin ist ein Planungsinstrument, keine fachliche Freigabe. Die Freigabe sollte an klaren Kriterien hängen, die für Projektleitung, Fachbereiche, IT-Betrieb und Management gleichermaßen nachvollziehbar sind. Dazu gehören abgegrenzte Restmängel, dokumentierte Risiken, eine verbindliche Entscheidungslogik und benannte Verantwortliche für die Zeit vor, während und nach dem Cutover.

In der Praxis hilft eine Go-Live-Readiness-Bewertung, die nicht bei Statusmeldungen stehen bleibt. Sie bewertet den tatsächlichen Reifegrad entlang der kritischen Liefergegenstände: Geschäftsprozesse, Stamm- und Bewegungsdaten, Integrationen, Berechtigungen, Betriebsprozesse sowie Support und Kommunikation. Entscheidend ist nicht, ob alle Arbeitspakete formal grün gemeldet werden. Entscheidend ist, ob eine Abweichung die Fähigkeit beeinträchtigt, Aufträge zu bearbeiten, zu produzieren, abzurechnen, zu beschaffen oder regulatorische Nachweise zu führen.

Ein offener Fehler im Reporting kann akzeptabel sein, wenn ein dokumentierter manueller Ersatzprozess vorhanden ist und keine steuerungsrelevanten Entscheidungen betroffen sind. Ein Fehler in der Preisfindung, der Fakturierung oder einer EDI-Schnittstelle kann dagegen den Go-Live gefährden, auch wenn seine technische Priorität zunächst niedrig erscheint. Diese Unterscheidung verlangt fachliche Bewertung, nicht nur Ticketmanagement.

Kritische Prozesse unter Produktionsbedingungen testen

Viele Testkonzepte sind funktional sinnvoll, aber für die Betriebsfreigabe zu schmal. Einzelne Transaktionen bestehen den Test, während die Prozesskette an Medienbrüchen, Fehlermeldungen aus Umsystemen oder falschen Berechtigungen scheitert. Für die Absicherung sind daher Ende-zu-Ende-Tests erforderlich, die den tatsächlichen Geschäftsablauf abbilden.

Ein Handelsunternehmen sollte beispielsweise nicht nur Auftragserfassung und Rechnungserstellung getrennt testen. Relevant ist die gesamte Kette vom Kundenauftrag über Verfügbarkeitsprüfung, Lieferung, Versandmeldung und Fakturierung bis zur Übergabe an Finanzbuchhaltung, Kreditversicherung oder Logistikdienstleister. In der Energieversorgung kommen Marktkommunikation, Abrechnungslogiken und Fristen hinzu. In Chemie und Life Sciences müssen Chargenbezug, Freigabestatus, Qualitätsprozesse und dokumentationspflichtige Ausnahmen besonders genau betrachtet werden.

Testfälle benötigen deshalb belastbare Testdaten. Anonymisierte Daten können sinnvoll sein, wenn Datenschutzanforderungen dies verlangen. Sie müssen jedoch die Komplexität des Betriebs erhalten: Sonderkonditionen, Altdatenkonstellationen, unvollständige Stammsätze, Massenvorgänge und Ausnahmefälle. Eine Testabnahme mit idealisierten Daten liefert keine ausreichende Aussage über die Produktivfähigkeit.

Ebenso wichtig sind Berechtigungstests. Rollenmodelle werden häufig erst kurz vor dem Go-Live finalisiert, obwohl sie bestimmen, ob Fachbereiche tatsächlich arbeiten können. Zu weit gefasste Berechtigungen erhöhen Kontrollrisiken. Zu restriktive Rollen verursachen operative Blockaden und eine Flut kurzfristiger Änderungsanträge. Ein produktionsnaher Test prüft daher nicht nur, ob eine Rolle grundsätzlich funktioniert, sondern ob sie Aufgaben sauber trennt, Vertretungen ermöglicht und kritische Freigaben nachvollziehbar dokumentiert.

Cutover als steuerbaren Betriebsübergang organisieren

Der Cutover-Plan darf keine bloße Abfolge technischer Aktivitäten sein. Er verbindet Datenmigration, Transports, Schnittstellenumschaltung, Systemzugänge, Fachbereichsaktivitäten und Kommunikationsschritte in einem zeitlich abgestimmten Ablauf. Jede Aktivität braucht einen verantwortlichen Owner, ein Zeitfenster, klare Eintritts- und Austrittskriterien sowie einen dokumentierten Rückfallweg.

Besonders anfällig sind Abhängigkeiten, die zwischen Teams liegen. Die Migration von offenen Belegen kann erst abgeschlossen werden, wenn ein fachlicher Datencheck erfolgt ist. Eine Schnittstelle darf erst produktiv geschaltet werden, wenn Zertifikate, Kommunikationspartner und Monitoring geprüft sind. Der Fachbereich kann seine Startfreigabe erst geben, wenn die relevanten Rollen aktiv sind. Werden diese Bedingungen nur implizit vorausgesetzt, entstehen Verzögerungen genau dann, wenn der Handlungsdruck am größten ist.

Ein praxistauglicher Cutover arbeitet deshalb mit kurzen Steuerungszyklen und einem zentralen Lagebild. Dieses Lagebild zeigt nicht nur den Fortschritt, sondern auch Blocker, Entscheidungen, Eskalationen und Auswirkungen auf Folgeaktivitäten. Für jede kritische Abhängigkeit sollte eindeutig feststehen, wer entscheidet, bis wann eine Entscheidung benötigt wird und welche Konsequenz ein Verzug hat.

Ein Rollback ist dabei kein Zeichen mangelnden Vertrauens in das Projekt. Er ist eine kontrollierte Option für den Fall, dass definierte Abbruchkriterien eintreten. Ob ein vollständiger Rückbau realistisch und wirtschaftlich sinnvoll ist, hängt vom Migrationsansatz ab. Bei irreversiblen Datenbewegungen kann ein stabilisierender Weiterbetrieb mit begrenztem Funktionsumfang die bessere Alternative sein. Diese Entscheidung muss vor dem Go-Live fachlich, technisch und organisatorisch vorbereitet werden.

Hypercare mit klaren Prioritäten und belastbaren Kennzahlen

Nach der Produktivsetzung beginnt die Phase, in der sich die Qualität der Vorbereitung zeigt. Hypercare wird oft als verlängerte Supportbereitschaft verstanden. Tatsächlich braucht sie eine eigene Betriebssteuerung: eindeutige Meldewege, priorisierte Incident-Bearbeitung, tägliche Lagebewertung und eine Trennung zwischen produktionskritischen Störungen und Optimierungswünschen.

Ein sinnvoller Hypercare-Plan definiert für kritische Geschäftsprozesse konkrete Kennzahlen. Dazu können die Anzahl fehlerhafter Belege, Durchlaufzeiten, Schnittstellenfehler, manuelle Nacharbeiten, Berechtigungsanträge oder nicht verarbeitete Hintergrundjobs gehören. Die Kennzahlen müssen zum jeweiligen Betrieb passen. Ein hoher Ticketbestand allein sagt wenig aus, wenn die Vorgänge keine geschäftliche Auswirkung haben. Umgekehrt kann ein einzelner Fehler bei der Rechnungsstellung erhebliche Folgen für Liquidität und Kundenbeziehungen verursachen.

Wichtig ist auch die Übergabe in den Regelbetrieb. Sie sollte nicht allein nach Ablauf einer Kalenderwoche erfolgen, sondern anhand definierter Stabilitätskriterien. Dazu zählen behobene kritische Fehler, etablierte Monitoring-Routinen, geschulte Supportteams, dokumentierte Betriebsverfahren und ein abgestimmter Umgang mit verbleibenden Known Errors. So entsteht revisionssicheres Reporting über den Betriebsübergang und keine bloße Liste geschlossener Tickets.

Governance und Compliance nicht erst nachziehen

Ein SAP-Go-Live kann auch Kontroll- und Compliance-Anforderungen berühren. Das gilt etwa für Berechtigungskonzepte, Protokollierung, Aufbewahrung, Datenschutz bei Migrationen oder kritische Schnittstellen zu externen Dienstleistern. Wenn neue Datenflüsse, Rollen oder Auswertungen entstehen, müssen Verantwortlichkeiten und Kontrollmechanismen zur Zielarchitektur passen.

Nicht jede Anpassung verlangt ein umfangreiches Governance-Projekt. Es hängt von Systemlandschaft, Datenarten, Risikoprofil und regulatorischem Kontext ab. Bei besonders schutzbedürftigen Daten, kritischen Versorgungsprozessen oder streng regulierten Branchen sollten Kontrollanforderungen jedoch frühzeitig in Test- und Freigabekriterien einfließen. Rechtliche Fragestellungen zu Datenschutz, NIS2 oder IT-Recht können dabei, soweit erforderlich, durch die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingeordnet werden.

Ein Quick Check vor dem Go-Live schafft Entscheidungssicherheit

Quteco unterstützt SAP-Projekte mit Go-Live-Readiness-Checks, Testmanagement und operativer Cutover-Begleitung. Im Fokus stehen kritische Prozessketten, Datenqualität, Integrationen, Rollenmodelle, Betriebsübergabe und ein belastbares Entscheidungsbild für die Freigabe. Je nach Projektlage kann dies als kompakter Workshop oder als Begleitung in der heißen Phase des Go-Lives umgesetzt werden.

Ein abgesicherter Go-Live bedeutet nicht, dass nach der Produktivsetzung keine Störung mehr auftritt. Er sorgt dafür, dass bekannte Risiken bewertet, Verantwortlichkeiten geklärt und Störungen im Betrieb kontrolliert bearbeitet werden können. Genau diese Steuerbarkeit entscheidet darüber, ob aus einem Projektabschluss ein stabiler Betrieb wird.