Die meisten S/4HANA Go-live Checklisten sind Projektmanagement-Dokumente: Verantwortliche, Abschlussdaten, Freigabespalten. Sie verfolgen, ob Aufgaben erledigt wurden. Sie prüfen nicht, ob das System in jeder Phase der Migration tatsächlich gesund ist.

Diese Checkliste ist anders. Jeder der 20 Punkte unten ist eine monitoring-spezifische Validierung: etwas, das Sie anhand echter Systemdaten bestätigen, nicht durch das Abhaken einer erledigten Aufgabe. Zehn Punkte gelten vor dem technischen Cutover. Zehn weitere gelten in den Stunden und Tagen nach dem Go-live. Zusammen decken sie die Bedingungen ab, die nach einer SAP S/4HANA Migration am häufigsten zu Incidents führen.

Die Punkte sind innerhalb jeder Phase nach Risiko sortiert, nicht nach Aufwand. Die Punkte ganz oben sind diejenigen, bei denen ein Versäumnis die höchsten Kosten verursacht.

Vor dem Go-live: 10 Monitoring-Validierungen, die vor Beginn des Cutover-Fensters abgeschlossen sein müssen

Diese 10 Punkte sollten während der Projektphase freigegeben werden, nicht am Cutover-Wochenende. Mehrere davon benötigen mehrere Wochen Vorlauf, um korrekt umgesetzt zu werden.

01 Baseline des Quellsystems über mindestens 6 Wochen erfassen

Verbinden Sie Ihre Monitoring-Plattform spätestens 8 Wochen vor dem geplanten Go-live mit dem ECC-System oder dem bestehenden S/4HANA Altsystem. Erfassen Sie Dialog-Antwortzeiten nach Transaktionscode, Laufzeiten von Hintergrundjobs, HANA oder Datenbank-Performance-Metriken sowie Durchsatzvolumen der Schnittstellen.

Sechs Wochen sind das Minimum, weil die Baseline-Daten mindestens einen vollständigen Monatsabschlusszyklus enthalten müssen. Die Monatsendlast in ECC ist oft 30 bis 50 % höher als im Tagesbetrieb. Wenn Ihre Baseline nur normale Tage abdeckt, wird der Performance-Vergleich nach der Migration die Monatsendlast als Regression markieren, obwohl es sich um erwartetes Verhalten handelt.

Warum das wichtig ist: Ohne Baseline des Quellsystems werden Performance-Diskussionen nach der Migration subjektiv. Jedes Gespräch wird zur Meinung. Mit Baseline-Daten hat jedes Gespräch Zahlen als Grundlage.

02 HANA Sizing unter UAT-Last validieren, nicht nur anhand der initialen Schätzung

Das initiale HANA Sizing für S/4HANA basiert auf dem ECC-Datenvolumen und einer geschätzten Benutzerlast. UAT ist die einzige Umgebung, in der vor dem Go-live eine reale S/4HANA Workload läuft. Führen Sie während des UAT einen Lasttest durch, der Spitzenbedingungen der Produktion abbildet, und erfassen Sie die HANA-Speicherauslastung unter Peak-Last.

Wenn der HANA-Speicher während des UAT-Lasttests mehr als 75 % des Allocation Limits überschreitet, ist das Produktionssystem im Verhältnis zur erwarteten Workload unterdimensioniert. Eine Unterdimensionierung, die im UAT entdeckt wird, kann vor dem Go-live korrigiert werden. Wird sie erst beim ersten Monatsabschluss in Produktion entdeckt, ist das nicht mehr einfach möglich.

Warum das wichtig ist: HANA ist eine In-Memory-Datenbank. Eine Unterdimensionierung führt nicht zu einer langsamen, schrittweisen Verschlechterung. Sie führt zu einem Notstopp, sobald das Allocation Limit erreicht ist.

03 Hintergrundjob-Plan dokumentieren und unabhängig in S/4HANA verifizieren

Exportieren Sie den vollständigen Produktionsjobplan aus SM36 im Quellsystem. Für jeden Tier-1-Job, also geschäftskritische Jobs mit harter Frist, prüfen Sie, ob der entsprechende Job in S/4HANA die korrekten Einstellungen hat: Planungsvariante, Servergruppen-Zuordnung, Vorgänger-Nachfolger-Abhängigkeit und Ausgabevariante.

Verifizieren bedeutet, den Job in SM36 auf S/4HANA zu öffnen und ihn Zeile für Zeile mit der Quelldokumentation zu vergleichen. Es bedeutet nicht, die Person zu fragen, die die Jobs neu erstellt hat, ob sie alles korrekt umgesetzt hat.

Warum das wichtig ist: Fehler bei der Neuerstellung von Jobs gehören zu den häufigsten Ursachen für stille Ausfälle in den ersten Wochen nach dem Go-live. Ein Job, der mit der falschen Servergruppe neu erstellt wurde, startet auf der falschen Instanz. Eine fehlende Vorgängerabhängigkeit führt dazu, dass zwei Jobs parallel laufen, obwohl sie sequenziell laufen sollten.

Achtung: Jobs mit benutzerspezifischen Varianten, zum Beispiel Varianten, die nach einem bestimmten SAP-Benutzer benannt sind, werden bei der Neuerstellung möglicherweise nicht korrekt übertragen. Wenn das Benutzerkonto im Zielsystem einen anderen Mandanten oder eine andere Berechtigungskonfiguration hat, kann die Variantenreferenz bei der ersten Ausführung stillschweigend fehlschlagen.

04 Schnittstelleninventar mit Volumen-Baseline und Fehlerraten pro Schnittstelle abschließen

Dokumentieren Sie jede produktive Schnittstelle, die Daten an das SAP-System sendet oder von ihm empfängt: Nachrichtentyp, IDoc, RFC, REST oder SOAP, durchschnittliches Tagesvolumen, normale Fehlerrate und unterstützter Geschäftsprozess. Für hochkritische Schnittstellen erfassen Sie stündliche Volumenmuster über den gesamten Baseline-Zeitraum.

Diese Dokumentation hat zwei Zwecke. Erstens definiert sie, wie die Wiederverbindung der Schnittstellen nach dem Cutover aussehen muss: welche Schnittstellen reaktiviert werden müssen, in welcher Reihenfolge und was ein erfolgreicher erster Nachrichtenfluss bestätigt. Zweitens legt sie die Referenz fest, gegen die die Schnittstellengesundheit nach dem Go-live bewertet wird.

Warum das wichtig ist: Eine Schnittstelle mit null Volumen nach dem Cutover kann korrekt funktionieren, weil noch keine Nachrichten vorliegen, oder sie kann nicht wiederverbunden worden sein. Ohne Volumen-Baseline für diese Schnittstelle können Sie den Unterschied nicht erkennen.

05 Alert-Schwellenwerte pro Instanzprofil konfigurieren, nicht aus Standards kopieren

Standard-Alert-Schwellenwerte in SAP Monitoring Tools sind auf generische Umgebungen kalibriert. Ihre S/4HANA Umgebung hat ein spezifisches HANA Memory Allocation Limit, eine spezifische Anzahl an Dialog-Work-Processes pro Instanz, ein spezifisches Batch-Fenster und spezifische Schnittstellenvolumen. Standardwerte erzeugen in einigen Bereichen Fehlalarme und übersehen in anderen echte Probleme.

Mindestens sollten Schwellenwerte für die HANA-Speicherauslastung konfiguriert werden, bezogen auf das Allocation Limit und nicht auf den gesamten RAM, außerdem Dialog-Work-Process-Auslastung pro Instanz, HANA Log Volume Auslastung, Laufzeit von Hintergrundjobs pro Tier-1-Job und Schnittstellenfehlerraten pro Schnittstelle.

Warum das wichtig ist: Die Kalibrierung der Schwellenwerte dauert einen halben Tag. Alert Fatigue durch falsch konfigurierte Schwellenwerte während der Go-live-Woche zu bewältigen, dauert deutlich länger und führt oft dazu, dass echte Alerts ignoriert werden.

06 ITSM-Integration End-to-End mit einem echten Alert testen, nicht nur konfigurieren

Die meisten Monitoring-zu-ITSM-Integrationen werden in einer Testumgebung konfiguriert und dann als produktionsreif angenommen. Die Annahmen, die typischerweise scheitern, sind: Die produktive ITSM-Instanz hat andere API-Endpunkte oder eine andere Authentifizierung als die Testinstanz, das für die Integration konfigurierte Benutzerkonto hat in Produktion nicht die nötigen Berechtigungen, oder die Zuordnungen von Incident-Kategorie und Priorität erzeugen falsch klassifizierte Tickets.

Lösen Sie einen echten Testalert über die produktive Monitoring-Verbindung zu S/4HANA aus und prüfen Sie, ob im ITSM-System ein korrekt aufgebautes Incident-Ticket erscheint, mit der richtigen Kategorie, Priorität und zuständigen Gruppe. Lösen Sie anschließend den Test-Incident und bestätigen Sie, dass das Monitoring-System diese Lösung widerspiegelt.

Warum das wichtig ist: Während des ersten produktiven Incidents festzustellen, dass die ITSM-Integration defekt ist, sorgt für zusätzliche Verwirrung und Verzögerung in einer ohnehin angespannten Situation.

07 HANA Log Volume dimensionieren und Log-Backup-Konfiguration unter Last prüfen

Das HANA Log Volume enthält alle nicht bestätigten Transaktionsdaten. Wenn es 100 % Auslastung erreicht, führt die Datenbank einen sofortigen Stopp durch. Log Backups geben verwendete Log-Segmente frei und verhindern, dass das Volume vollläuft. Das Log-Backup-Intervall muss auf den Schreibdurchsatz der produktiven Workload abgestimmt werden.

Überwachen Sie während des UAT-Lasttests die Füllrate des Log Volumes unter maximaler Transaktionslast. Berechnen Sie, wie schnell das Log Volume volllaufen würde, wenn Log Backups für 2 Stunden ausfallen. Wenn das Log Volume in diesem Fenster 100 % erreichen würde, muss entweder das Log Volume vergrößert oder das Backup-Intervall verkürzt werden.

Warum das wichtig ist: Das Sizing des Log Volumes wird oft aus ECC Sizing Dokumenten übernommen, ohne HANA-spezifische Schreibmuster zu berücksichtigen. Es ist eine der häufigsten Ursachen für ungeplante HANA Stopps in den ersten Monaten nach dem Go-live.

08 Enqueue Replication Server Konfiguration mit simulierter Störung verifizieren

Wenn die produktive S/4HANA Landschaft hochverfügbar aufgebaut ist, hält der Enqueue Replication Server, kurz ERS, eine Kopie der Sperrtabelle auf einer sekundären Instanz vor. Der ERS ist häufig konfiguriert, aber nicht verifiziert: Die Instanz existiert, sie repliziert die Sperrtabelle, aber die Pacemaker-Integration, die sie bei einem Ausfall der Primärinstanz automatisch promoted, wurde nie getestet.

Simulieren Sie vor dem Go-live einen Ausfall des primären Enqueue Servers in der QA- oder Pre-Production-Landschaft und bestätigen Sie, dass der ERS sauber promoted wird, dass aktive Benutzersitzungen ihre Transaktionen fortsetzen können und dass die Promotion innerhalb des erwarteten Zeitfensters abgeschlossen ist.

Warum das wichtig ist: Eine nie getestete ERS-Konfiguration ist eine Annahme, keine Fähigkeit. Der Promotion-Test dauert 30 Minuten. Eine unentdeckte ERS-Fehlkonfiguration während eines produktiven Failovers zu beheben, dauert deutlich länger.

09 Business Process Owner definieren und bestätigen Monitoring-Akzeptanzkriterien

Das SAP Basis Team kann bestätigen, dass HANA gesund ist und die Dialog-Antwortzeiten innerhalb technischer Normen liegen. Das ist nicht dasselbe wie zu bestätigen, dass der Order-to-Cash-Prozess korrekt läuft, dass Finanzbuchungen im erwarteten Zeitfenster abgeschlossen werden oder dass der EDI-Partner korrekt formatierte Nachrichten erhält.

Vor dem Go-live sollte jeder Tier-1-Geschäftsprozess einen benannten Process Owner, ein definiertes Akzeptanzkriterium und einen Bestätigungsschritt im Post-Go-live-Runbook haben. Ein Beispiel wäre: „Alle ORDERS05 IDocs werden innerhalb von 10 Minuten nach Eingang verarbeitet.“ Der Process Owner bestätigt anhand echter Monitoring-Daten, dass das Kriterium erfüllt ist.

Warum das wichtig ist: Ohne fachlich definierte Akzeptanzkriterien basiert die Go-live-Freigabe auf technischen Gesundheitsmetriken, die möglicherweise nicht zeigen, ob das Unternehmen auf dem neuen System tatsächlich arbeiten kann.

10 Cutover-Runbook mit Monitoring-Checkpoints, benannter Verantwortung und Pass/Fail-Kriterien ergänzen

Ein Cutover-Runbook, das Aufgaben ohne Monitoring-Checkpoints auflistet, geht davon aus, dass alles funktioniert, solange niemand ein Problem meldet. Ein Runbook mit Monitoring-Checkpoints schafft Sichtbarkeit im Prozess: An definierten Meilensteinen prüft eine benannte Person eine konkrete Metrik und bestätigt, dass sie im erwarteten Bereich liegt, bevor der nächste Schritt gestartet wird.

Monitoring-Checkpoints, die in das Cutover-Runbook gehören, sind unter anderem: HANA-Speicherauslastung nach Abschluss der Datenmigration, Log Volume Auslastung bei T+2h während des Cutovers, Verfügbarkeit der Dialog Work Processes vor Öffnung des Systems für Benutzer und Schnittstellen-Queue-Tiefe nach der Wiederverbindung.

Warum das wichtig ist: Monitoring-Checkpoints im Cutover-Runbook machen den Unterschied zwischen einem Cutover, bei dem das Team sicher weiß, dass das System bereit ist, und einem Cutover, bei dem das System für Benutzer geöffnet wird und Hoffnung zur Strategie wird.

Nach dem Go-live: 10 Monitoring-Validierungen für die ersten 72 Stunden

Diese 10 Punkte gelten ab dem Moment, in dem sich der erste Fachanwender anmeldet, bis zum Ende der ersten 72 Stunden produktiven Betriebs. Mehrere davon erfordern Maßnahmen innerhalb der ersten Stunde. Keiner davon sollte auf den nächsten Arbeitstag verschoben werden.

11 HANA Cold-Start Memory Profil erfassen und mit der UAT-Baseline vergleichen

Wenn sich die ersten Fachanwender nach dem Go-live in S/4HANA anmelden, beginnt das System, Column-Store-Daten von der Festplatte in den Speicher zu laden, sobald Abfragen erstmals darauf zugreifen. Diese Cold-Start-Phase erzeugt eine Speicherverbrauchskurve, die sich vom stabilen Betrieb und von UAT-Lasttests unterscheidet, bei denen einige Daten bereits warm waren.

Erfassen Sie die HANA-Speicherauslastung in 15-Minuten-Intervallen während der ersten 2 Stunden. Wenn die Kurve darauf hindeutet, dass der Speicher 85 % des Allocation Limits überschreiten wird, bevor der Arbeitsdatensatz vollständig geladen ist, eskalieren Sie sofort an das Infrastrukturteam. Warten Sie nicht, bis die 85 %-Schwelle tatsächlich überschritten wird.

Warum das wichtig ist: Das Cold-Start-Speicherverhalten ist der eine Datenpunkt, den UAT nicht vollständig replizieren kann. Die ersten Produktionsstunden bieten die einzige Möglichkeit, dieses Verhalten unter realen Bedingungen zu beobachten, und zwar zu einem Zeitpunkt, an dem infrastrukturseitig noch Handlungsspielraum besteht.

12 Alle Tier-1-Hintergrundjobs am Tag 1 auf erfolgreiche Ausführung prüfen

Ein Job, der korrekt in SM36 neu erstellt wurde, aber nie gelaufen ist, ist kein verifizierter Job. Am ersten Arbeitstag nach dem Go-live sollte jeder geplante Tier-1-Hintergrundjob in SM37 geprüft werden: Status, Startzeit, Abschlusszeit und bei kritischen Jobs auch die Spool-Ausgabe auf applikationsbezogene Fehler.

Achten Sie besonders auf Jobs mit startzeitbasierter Planung, die vor dem Go-live-Datum eingerichtet wurden. Ein Job, der täglich um 06:00 ab einem Datum vor dem Go-live laufen soll, kann eine verpasste Ausführung in seiner Historie haben. Manche Planungskonfigurationen führen ihn beim nächsten Systemstart sofort aus, andere ignorieren ihn vollständig.

Warum das wichtig ist: Ein Tier-1-Job, der am Tag 1 nicht läuft, erzeugt ein Datendefizit, das sich aufbaut. Wird es erst an Tag 3 entdeckt, müssen drei Tage Daten abgestimmt werden, nicht nur einer.

13 Schnittstellen-Wiederverbindung mit ersten echten Nachrichtenflüssen bestätigen, nicht nur mit Verbindungstests

Die Wiederverbindung von Schnittstellen nach dem Cutover umfasst normalerweise das Reaktivieren von Verbindungen, die während des Migrationsfensters eingefroren waren. Ein SM59-Verbindungstest bestätigt, dass der Netzwerkpfad existiert. Er bestätigt nicht, dass Nachrichten fließen, dass das empfangende System sie verarbeitet oder dass Payloads unter S/4HANA Nachrichtentypen korrekt generiert werden.

Warten Sie für jede Tier-1-Schnittstelle auf die erste echte Nachricht nach dem Go-live, prüfen Sie, dass sie fehlerfrei versendet wurde, über BD87 für IDocs, SM58 für tRFC oder den Integration Suite Monitor für BTP Flows, und bestätigen Sie, dass das empfangende System den Eingang quittiert hat. Diese erste erfolgreiche End-to-End-Nachricht ist der tatsächliche Nachweis für Schnittstellengesundheit.

Warum das wichtig ist: Verbindungstests bestehen. Nachrichtenflüsse scheitern. Das ist nicht dieselbe Bestätigung.

In der Praxis: Schnittstellen, die auf festem IP-basiertem Routing beruhten, können nach dem Cutover weiterhin zur ECC-IP-Adresse routen, wenn DNS-Einträge oder RFC-Destinationen nicht aktualisiert wurden. Dadurch kann ein Verbindungstest erfolgreich sein, weil das alte ECC-System noch antwortet, während Nachrichten an das falsche Ziel gesendet werden. Prüfen Sie, dass jede RFC-Destination auf das S/4HANA System zeigt, nicht auf das Legacy-System.

14 Alert Routing verifizieren: Testalert auslösen und Empfang durch das Bereitschaftsteam innerhalb des SLA-Fensters prüfen

Alert-Konfigurationen, die in Nicht-Produktionsumgebungen getestet wurden, können in Produktion an andere Teams oder Kanäle routen als beabsichtigt. Die Bereitschaftskontaktliste kann sich zwischen Konfiguration und Go-live geändert haben. Das Monitoring-System kann ausgehende E-Mails oder Webhooks unter produktiven Netzwerkregeln anders behandeln.

Lösen Sie innerhalb der ersten 2 Stunden nach dem Go-live bewusst einen Testalert aus: Senken Sie vorübergehend einen Schwellenwert unter die aktuellen Werte, bestätigen Sie, dass der Alert ausgelöst wird, bestätigen Sie, dass er den richtigen Bereitschaftskontakt über den erwarteten Kanal erreicht, also E-Mail, SMS oder ITSM-Ticket, und bestätigen Sie, dass der Alert verschwindet, sobald der Schwellenwert wiederhergestellt ist.

Warum das wichtig ist: Während des ersten echten Incidents festzustellen, dass das Alert Routing defekt ist, ist der falsche Zeitpunkt.

15 Dialog-Antwortzeiten innerhalb der ersten 2 Stunden pro Transaktionscode mit der ECC-Baseline vergleichen

Dialog-Antwortzeiten auf S/4HANA sind für dieselben Transaktionscodes oft schneller als auf ECC, weil HANA In-Memory-Verarbeitung viele Datenbanklesevorgänge eliminiert, die ECC-Antwortzeiten belastet haben. Wenn sie nicht schneller sind oder bestimmte Transaktionen deutlich schlechter abschneiden, liegt die Ursache fast immer in einem von drei Bereichen: fehlende Datenbankstatistik auf HANA, wofür UPDATE STATISTICS auf den betroffenen Tabellen ausgeführt werden sollte, ein kundeneigenes ABAP-Programm, das nicht an S/4HANA Datenmodelländerungen angepasst wurde, oder ein Konfigurationsproblem in der Applikationsschicht.

Vergleichen Sie die Top-20-Transaktionscodes nach Nutzungshäufigkeit aus der ECC-Baseline mit ihren Antwortzeiten in den ersten zwei Stunden der S/4HANA Produktion. Eine Regression von mehr als 50 % bei einer häufig genutzten Transaktion verdient eine Untersuchung am selben Tag.

Warum das wichtig ist: Antwortzeitregressionen, die an Tag 1 nicht untersucht werden, werden an Tag 3 zu festen Benutzerbeschwerden und an Tag 5 zu Eskalationen.

16 SM13 Update Queue innerhalb der ersten Stunde fachlicher Transaktionen auf fehlgeschlagene Updates prüfen

Fehlgeschlagene Update Requests in SM13 stehen für gespeicherte Transaktionen, deren Datenbankschreibvorgänge nicht abgeschlossen wurden. Benutzer haben eine Speicherbestätigung erhalten. Die Daten sind nicht in der Datenbank. Das ist ein Datenintegritätsproblem, kein Performance-Problem.

Öffnen Sie SM13 auf S/4HANA innerhalb der ersten Stunde Benutzeraktivität und filtern Sie nach Einträgen mit Fehlerstatus. Jeder Eintrag erfordert sofortige Untersuchung, bevor der betroffene Benutzer weitere Aktionen auf Basis der Annahme ausführt, dass seine Daten gespeichert wurden. Update-Fehler in der ersten Produktionsstunde werden häufig durch fehlende Berechtigungen des Update-Benutzers, eine Konfigurationsabweichung zwischen Testumgebung und Produktion oder eine kundeneigene Erweiterung verursacht, die nicht im Update-Kontext getestet wurde.

Warum das wichtig ist: Update-Fehler, die 4 Stunden nach ihrem Auftreten entdeckt werden, müssen gegen nachfolgende Transaktionen abgeglichen werden, die auf der Annahme basieren, dass das Speichern erfolgreich war. Werden sie innerhalb von 30 Minuten entdeckt, können sie in der Regel korrigiert werden, indem das Update nach Behebung der Ursache erneut ausgeführt wird.

17 Erste Batchjob-Abschlusszeiten mit ECC-Baseline-Laufzeiten vergleichen

Der erste nächtliche Batchlauf auf S/4HANA ist der erste echte Test des Batchplans mit produktiven Datenvolumen. Erfassen Sie die tatsächliche Abschlusszeit jedes Tier-1-Jobs und vergleichen Sie sie mit der ECC-Baseline.

HANA-native Jobs laufen erwartungsgemäß schneller als in ECC, manchmal deutlich schneller. Jobs, die für ECC entwickelt, aber nicht an S/4HANA angepasst wurden, können wegen Compatibility-View-Overhead oder Datenmodelländerungen langsamer laufen. Ein Job, der in ECC 40 Minuten dauerte und in S/4HANA 2 Stunden benötigt, ist keine Performance-Regression, die man akzeptieren sollte. Es ist ein technisches Problem, das vor dem nächsten Lauf untersucht werden muss.

Warum das wichtig ist: Der erste nächtliche Batchlauf legt die S/4HANA Baseline für künftige Vergleiche fest. Wenn dieser erste Lauf nicht präzise gemessen wird, hat jede spätere Abweichung keinen Referenzpunkt.

18 HANA Delta Merge Backlog nach den ersten 48 Stunden Schreibaktivität prüfen

Die ersten 48 Stunden produktiven S/4HANA Betriebs erzeugen eine Welle von INSERT-Aktivität: neue Kundenaufträge, neue Produktionsaufträge, neue Finanzbuchungen, alle in Tabellen, die beim Go-live leer oder nahezu leer waren. Diese starke INSERT-Aktivität füllt den HANA Delta Store schneller als im stabilen Betrieb. Wenn Delta Merges zurückfallen, beginnt die Query-Performance auf den betroffenen Tabellen zu sinken.

Prüfen Sie nach 48 Stunden M_DELTA_MERGE_STATISTICS auf ausstehende Merges und Merge-Fehler. Eine Delta-Merge-Fehleranzahl über null erfordert Untersuchung. Eine wachsende Pending-Merge-Queue, die sich zwischen Merge-Zyklen nicht abbaut, zeigt, dass die Auto-Merge-Konfiguration mit dem Schreibvolumen nach dem Go-live nicht Schritt hält.

Warum das wichtig ist: Ein Delta Merge Backlog erzeugt keinen Fehler, keinen Alert und kein offensichtliches Symptom, bis Query-Pläne suboptimale Pfade wählen. Er ist für alle unsichtbar, außer für die Person, die weiß, wo sie suchen muss.

Hinweis: HANA-Datenbankstatistiken auf neu befüllten Tabellen müssen nach den ersten 48 Stunden Datenladung möglicherweise ebenfalls aktualisiert werden. Neu erstellte Tabellen mit signifikanten Datenmengen, aber veralteten Statistiken, erzeugen schlechte Query-Pläne. UPDATE STATISTICS auf den am häufigsten abgefragten Tabellen nach der initialen Go-live-Datenladung ist Standardwartung, wird in Cutover-Checklisten aber häufig übersprungen.

19 Business Process Owner bestätigen die korrekte Verarbeitung erster Transaktionen anhand von Daten

Technische Gesundheitsmetriken bestätigen, dass das System läuft. Sie bestätigen nicht, dass das System korrekte Geschäftsergebnisse produziert. Bis zum Ende des ersten Arbeitstags sollte jeder Tier-1-Business-Process-Owner den tatsächlichen Output seines Prozesses geprüft und bestätigt haben, dass er korrekt ist.

Diese Bestätigung basiert auf Daten, nicht auf der Abwesenheit von Beschwerden. Das Finanzteam bestätigt, dass die ersten Finanzbuchungen aus dem Produktionslauf die richtigen Konten und Beträge zeigen. Das Logistikteam bestätigt, dass die ersten Warenbewegungen auf die richtigen Lagerorte gebucht wurden. Das Einkaufsteam bestätigt, dass die ersten Bestellungen, die über die EDI-Schnittstelle erstellt wurden, den richtigen Lieferanten und die korrekten Preisdaten enthalten.

Warum das wichtig ist: Ein Geschäftsprozess, der läuft, aber falsche Ergebnisse produziert, ist kein gesunder Go-live. Es ist ein Datenqualitäts-Incident, der mit jeder weiteren Transaktion, die auf falschen vorherigen Daten aufbaut, Schaden anhäuft.

20 Monitoring-Handover-Dokument an den Betrieb übergeben, bevor das Projektteam demobilisiert

Das Projektteam, das die Monitoring-Konfiguration aufgebaut hat, weiß, warum jeder Schwellenwert so gesetzt wurde, welche Alerts während der Stabilisierungsphase voraussichtlich Rauschen erzeugen und welche sofort eskaliert werden müssen. Das Betriebsteam, das das System ab dem zweiten Monat betreibt, hat dieses Wissen nicht, wenn es nicht dokumentiert und übergeben wird.

Das Handover-Dokument sollte Folgendes enthalten: die Begründung für jeden nicht standardmäßigen Schwellenwert, die Liste der Stabilization-Period-Alerts, die an Tag 30 überprüft und gegebenenfalls angepasst werden sollten, den Eskalationspfad für jede Alert-Kategorie und den Prozess zur Aktualisierung von Baselines, wenn sich die Workload verändert. Es muss nicht lang sein. Es muss existieren, bevor das Projektteam den Einsatz abschließt.

Warum das wichtig ist: Projektteams demobilisieren. Wenn sie das tun, verschwindet das institutionelle Wissen darüber, warum das Monitoring so konfiguriert ist, wie es ist, sofern es nicht dokumentiert wurde.

Diese Checkliste in einem realen Projekt nutzen

Zwanzig Validierungspunkte über zwei Phasen hinweg ergeben ein vollständiges Bild der Monitoring Readiness für eine S/4HANA Migration. In der Praxis erhalten nicht alle Punkte gleich viel Aufmerksamkeit. Die Punkte, die am häufigsten übersprungen werden, sind diejenigen, die frühzeitiges Handeln erfordern: Baseline des Quellsystems, Punkt 1, HANA Sizing unter realer UAT-Last, Punkt 2, und Kalibrierung der Alert-Schwellenwerte, Punkt 5.

Diese drei Punkte sollten im Projektzeitplan bewusst geschützt werden, weil ihr Vorlauf nicht komprimiert werden kann. Eine Baseline erfordert Wochen der Datenerfassung. Die HANA Sizing Validierung erfordert einen realistischen UAT-Lasttest. Die Schwellenwertkalibrierung erfordert aussagekräftige Baseline-Daten. Wenn alle drei zu spät beginnen, entsteht die Situation, die die meisten S/4HANA Teams kennen: Go-live mit einer Monitoring-Plattform, die technisch verbunden, aber operativ nicht kalibriert ist und Alerts produziert, denen niemand vertraut.

Die 10 Post-Go-live-Punkte sind in der entgegengesetzten Richtung zeitkritisch. Die Punkte 11 bis 16 müssen innerhalb der ersten Stunden des produktiven Betriebs umgesetzt werden. Sie auf „nach dem ersten Stress“ zu verschieben, bedeutet, sie auf einen Zeitpunkt zu verschieben, an dem Früherkennung nicht mehr präventiv ist. Eine HANA-Speicherkurve, die in Stunde 2 sichtbar ist, ist handlungsrelevant. Dieselbe Kurve in Stunde 8, nachdem sie bereits Performance-Probleme verursacht hat, ist reaktiv.

Beide Phasen, vor und nach dem Go-live, folgen demselben Grundprinzip: Monitoring, das vor dem Ereignis vorhanden ist, das es erkennen soll, ist Monitoring. Alles andere ist Untersuchung.

Redpeaks unterstützt S/4HANA Migrationen mit agentenlosem Monitoring von Quell- und Zielsystemen, Pre-Migration Baseline Capture und Post-Go-live Stabilization Dashboards. Keine Transporte, keine Agents, kein zusätzlicher Change-Management-Aufwand. Entdecken Sie, wie Redpeaks S/4HANA Migrationen abdeckt.