Die meisten Gespräche über S/4HANA Monitoring beginnen in der Woche nach dem Go-live. Das System läuft produktiv, Anwender melden Performance-Probleme und das Projektteam versucht zu verstehen, was auf einer Plattform passiert, die zum ersten Mal unter realer Last betrieben wird. Zu diesem Zeitpunkt ist Monitoring per Definition reaktiv. Das Zeitfenster für eine proaktive Überwachung ist bereits geschlossen.
Die Monitoring-Entscheidungen, die darüber bestimmen, ob die ersten Wochen auf S/4HANA stabil oder chaotisch verlaufen, werden Wochen vor dem Cutover getroffen, nicht danach. Es geht darum, was auf dem Legacy-System gemessen werden muss, bevor das Migrationsfenster beginnt, was während des technischen Cutovers überwacht werden sollte, wie die Gesundheit des neuen Systems geprüft wird, bevor der erste Business User sich anmeldet, und wie der erste Monat im Produktivbetrieb aussehen muss, bevor das Team den Go-live als stabil bezeichnen kann.
Dieser Guide beschreibt diese Phasen Schritt für Schritt. Er richtet sich an die Personen, die für die technische Readiness der Migration verantwortlich sind: SAP Basis Teams, Monitoring-Architekten, MSPs und IT Operations Leads, die während des Cutover-Wochenendes und in den darauffolgenden Wochen in Bereitschaft sind.
Die Monitoring-Lücke, die die meisten S/4HANA Projekte haben
Warum das Cutover-Fenster die risikoreichste Phase mit der geringsten Sichtbarkeit ist
Betrachten wir, was bei einem typischen technischen S/4HANA Cutover passiert. Das ECC-Quellsystem wird für Business-Transaktionen gesperrt. Ein Tool wie SUM mit DMO, also Database Migration Option, oder ein Export/Import-Verfahren läuft. HANA wird mit migrierten Daten geladen. Der Prozess dauert je nach Datenvolumen und Hardware zwischen 12 Stunden und mehreren Tagen. Während des größten Teils dieses Fensters beschränkt sich die Sichtbarkeit des Operations Teams auf regelmäßige Fortschrittsanzeigen und die Hoffnung, dass nichts Unerwartetes geschieht.
Es gibt keine Dialoglast zu beobachten, weil keine Anwender im System sind. Batch-Jobs sind eingefroren. Schnittstellen sind gestoppt. Die Monitoring-Disziplin, die normalerweise den Produktivbetrieb absichert, hat hier keine offensichtliche Anwendung. Das Team schaut auf den Fortschrittsbalken des Migrationstools und wartet.
Was in diesem Zeitraum nicht überwacht wird, ist die HANA-Instanz selbst: Speicherverbrauch während die Migrationsdaten geladen werden, Wachstum des Log-Volumes während der Datenladephase, I/O-Sättigung auf der Storage-Ebene, wenn große Tabellen mit dauerhaft hohem Durchsatz geschrieben werden. Genau diese Bedingungen führen dazu, dass Migrationsphasen hängen bleiben oder fehlschlagen. Trotzdem werden sie fast nie proaktiv überwacht. Das erste Anzeichen eines Problems ist eine Phase, die nicht mehr voranschreitet. Danach beginnt eine manuelle Untersuchung, die durch eine vorkonfigurierte Warnung hätte ersetzt werden können.
Die Kosten von Monitoring-Lücken in der ersten Produktionswoche
Die erste Woche auf S/4HANA hat einen ganz eigenen operativen Charakter. Das Projektteam ist vom Cutover-Wochenende erschöpft. Das Operations Team lernt ein neues System kennen. Business User begegnen einer anderen Oberfläche, anderen Transaktionsnamen und anderem Verhalten bei Prozessen, die sie seit Jahren gleich ausführen. Alles steht unter Beobachtung.
Wenn in diesem Kontext ein Performance-Problem auftritt, ist der Druck, die Ursache schnell zu identifizieren und zu beheben, sofort da. Wenn die Monitoring-Infrastruktur nicht vorhanden ist, beginnt die Analyse bei null: Basis-Daten aus SM50 ziehen, Ad-hoc-HANA-Abfragen zur Speicherprüfung ausführen, Batch-Job-Logs manuell kontrollieren. Die Tools, die eine Untersuchung von 90 Minuten auf 10 Minuten verkürzen würden, sind genau die Tools, die vor dem Go-live hätten konfiguriert werden müssen.
Die Monitoring-Lücke in der ersten Woche ist nicht nur eine technische Unannehmlichkeit. Sie beeinflusst das Vertrauen. Ein Unternehmen, das in eine S/4HANA Migration investiert hat und in der ersten Woche unerklärliche Langsamkeit erlebt, ohne eine klare technische Erklärung zu bekommen, beginnt, die Projektentscheidungen zu hinterfragen, die dazu geführt haben. Gutes Monitoring verkürzt nicht nur die Incident Resolution Time. Es liefert die Daten, die erklären, was passiert und warum. Genau das ist während der Stabilisierung ein eigener Projektwert.
Phase 1: Baselines auf dem Quellsystem vor Beginn der Migration etablieren
Was sollte auf ECC vor dem Start des Migrationsfensters gemessen werden?
Die am meisten unterschätzte Monitoring-Aktivität in jeder S/4HANA Migration ist die Erfassung einer Baseline auf dem Quellsystem, bevor das Projekt startet. Nicht ein einzelner Snapshot, sondern eine kontinuierliche Aufzeichnung über einen repräsentativen Zeitraum: mindestens acht Wochen, inklusive normaler Arbeitstage, eines Monatsabschlusses und aller weiteren periodischen Batch-Ereignisse, die für die Organisation relevant sind.
Die Baseline-Metriken, die für den Vergleich nach der Migration entscheidend sind, sind Dialog-Antwortzeiten nach Transaktionscode, durchschnittliche Auslastung der Background Work Processes nach Tageszeit, Datenbank-Antwortzeiten für die häufigsten SQL-Statements und allgemeine Lastprofile des Systems während Peak-Zeiten. Diese Zahlen, systematisch vor der Migration erfasst, werden zum Benchmark, an dem die S/4HANA Performance nach dem Go-live bewertet wird.
Ohne diese Baseline basieren Performance-Diskussionen nach dem Go-live auf Meinungen. „Das System fühlt sich langsamer an“ ist eine andere Diskussion als „Die durchschnittliche Antwortzeit der Transaktion VA01 lag in ECC bei 1,2 Sekunden. In S/4HANA liegt sie aktuell bei 2,8 Sekunden bei gleichem Transaktionsvolumen.“ Die zweite Aussage eröffnet einen klaren Lösungsweg. Die erste nicht.
Timing: Starten Sie die Baseline-Erfassung mindestens 8 Wochen vor dem geplanten Migrationsfenster. Zwei Wochen Daten reichen nicht aus, um das Monatsabschlussverhalten abzubilden. Gerade der Monatsabschluss in ECC zeigt oft Workload-Muster, die im Tagesbetrieb nicht sichtbar sind.
Batch-Job-Profile und Interface-Throughput-Baselines erfassen
Background Jobs migrieren nicht automatisch von ECC nach S/4HANA. Sie werden vom Basis Team manuell neu angelegt, entweder durch manuelle Eingabe in SM36 oder durch einen Transport, der die Job-Scheduling-Konfiguration enthält. In beiden Fällen entstehen Fehlermöglichkeiten: falsche Zuordnung zu einer Servergruppe, fehlende Job-Step-Parameter, fehlerhafte Variantenreferenzen.
Vor Beginn der Migration sollte jeder produktive Background Job dokumentiert werden: geplante Frequenz, erwartete Laufzeit bei normalem Volumen und bei Monatsabschlussvolumen, Servergruppe oder benannter Server, auf dem er läuft, sowie seine Vorgänger- und Nachfolgerbeziehungen. Diese Dokumentation nutzt das Basis Team, um die korrekte Neuanlage der Jobs in S/4HANA vor dem Go-live zu prüfen. Das Operations Team nutzt sie, um Alerting-Schwellen für Job-Laufzeiten im neuen System zu konfigurieren.
Interface-Throughput-Baselines folgen derselben Logik. Jede produktive Schnittstelle in ECC hat ein durchschnittliches tägliches Nachrichtenvolumen, eine normale Verarbeitungszeit und eine Fehlerrate, die beschreibt, wie Normalbetrieb aussieht. Diese Werte vor der Migration zu erfassen, liefert die Vergleichsdaten, die benötigt werden, um zu bestätigen, dass Schnittstellen in S/4HANA korrekt verarbeiten, nicht nur, dass sie technisch aktiv sind.
Die Performance-Baseline, die den Vergleich nach der Migration aussagekräftig macht
Es gibt ein Monitoring-Setup, das den Vergleich nach der Migration deutlich einfacher macht und dennoch fast nie umgesetzt wird: Das Monitoring-Tool läuft während der Validierungsphase vor dem Go-live parallel gegen das ECC-Quellsystem und das S/4HANA-Zielsystem. Dafür muss die Monitoring-Plattform im Rahmen des Migrationsprojekts mit ECC verbunden werden, nicht erst nach dem Go-live mit S/4HANA.
Wenn beide Systeme von derselben Plattform überwacht werden, nutzt der Vergleich zwischen ECC-Baseline-Performance und S/4HANA Performance während Lasttests und User Acceptance Tests dieselben Metriken, dieselben Schwellenwerte und dasselbe Dashboard-Format. Regressionen zu erkennen wird dann zu einer Frage von zwei Linien im selben Diagramm, statt Zahlen aus unterschiedlichen Quellen mit unterschiedlichen Erhebungsmethoden zu vergleichen.
Die praktische Voraussetzung dafür ist, das Monitoring-Tool früh zu verbinden, in der Projektphase, in der ECC noch das Produktivsystem ist, und es so zu konfigurieren, dass die spezifischen Metriken erfasst werden, die später für den Vergleich nach der Migration genutzt werden. Das ist ein Setup-Aufwand von drei bis vier Wochen, den viele Projekte depriorisieren, weil Monitoring als Go-live-Aufgabe behandelt wird und nicht als Pre-Migration-Anforderung.
Phase 2: Monitoring-Abdeckung während des technischen Cutovers
Was während der Datenmigrationsphase überwacht werden sollte
Die Datenmigrationsphase, egal ob mit SUM und DMO, klassischem Export/Import oder Shell Conversion, setzt das HANA-System einer dauerhaften Schreiblast aus, die keinem normalen Produktionsmuster entspricht. Große Tabellen werden massenhaft eingefügt. Der HANA Delta Store sammelt Einträge schneller, als Auto-Merge sie verarbeiten kann. Das Log-Volume wächst mit einer Geschwindigkeit, die durch die Migration bestimmt wird, nicht durch das normale Transaktionsvolumen.
Drei Metriken verdienen in dieser Phase kontinuierliches Monitoring. Erstens der HANA-Speicherverbrauch im Verhältnis zum Allocation Limit, weil Bulk Inserts pro Zeile mehr In-Memory-Speicher verbrauchen als Steady-State-Operationen, während Merge-Prozesse die Daten verarbeiten und komprimieren. Zweitens die Log-Volume-Auslastung, weil Log-Backups während eines Migrationsfensters eine spezifische Konfiguration erfordern, die in der Pre-Cutover-Checkliste leicht vergessen wird. Drittens die Dauer der Migrationstool-Phasen im Verhältnis zum erwarteten Zeitplan, weil eine Phase, die 40 % länger läuft als im Probelauf, ein Entscheidungspunkt ist, nicht nur eine Beobachtung.
Duration Alerting pro Migrationsphase ist genau die Fähigkeit, die die meisten Projektteams nicht konfiguriert haben, weil sie Migrationstool-Phasen nie als überwachbare Ereignisse betrachtet haben. SUM und DMO erzeugen Log-Dateien mit Timing-Daten pro Phase, die von Monitoring Agents oder einem einfachen Custom Script gelesen werden können. Wenn eine Warnung ausgelöst wird, sobald eine Phase mehr als 50 % länger dauert als im Probelauf, entstehen während des Migrationsfensters handlungsrelevante Daten. Das ist deutlich besser, als wenn jemand das Migrationstool alle 30 Minuten manuell prüfen muss.
Häufiger Fehler: Der HANA Log Mode während DMO sollte nur bei Nicht-Produktionsmigrationen auf „overwrite“ gesetzt werden, wenn keine Point-in-Time-Recovery erforderlich ist. Bei Produktionsmigrationen, bei denen RPO relevant ist, sollte der Log Mode auf „normal“ bleiben und Log-Backups sollten während des gesamten Migrationsfensters laufen. Prüfen Sie das in der Konfigurationsreview vor dem Start des Migrationsfensters, nicht währenddessen.
Interface-Freeze-Monitoring: Wie echte Stille aussieht
Der Interface Freeze vor dem Cutover ist ein bekanntes Migrationskonzept. Alle eingehenden Datenflüsse nach ECC werden gestoppt. Nachrichten, die sich noch in Verarbeitung befinden, werden verarbeitet und Queues werden geleert. Das Quellsystem erreicht einen sauberen Zustand, bevor die Migration beginnt.
Weniger gut verstanden ist, wie bestätigt wird, dass der Freeze wirklich vollständig ist. Eine Schnittstelle auf Middleware-Ebene zu stoppen, verhindert, dass neue Nachrichten gesendet werden. Es leert aber nicht sofort alle Nachrichten, die bereits in der Queue liegen oder verarbeitet werden. Eine Nachricht, die zwei Minuten vor Beginn des Freeze-Fensters eingegangen ist, kann sich noch in der IDoc- oder qRFC-Queue befinden, teilweise verarbeitet, wenn die Datenmigration beginnt. Wenn diese Nachricht nach Beginn der Erfassung des Datenstands fertig verarbeitet wird, entsteht eine Reconciliation-Abweichung.
Das Monitoring der Queue-Tiefe bis auf null ist der entscheidende Verifizierungsschritt. Es reicht nicht, zu bestätigen, dass die Interface-Konfiguration gestoppt ist. Die Message Queues müssen leer sein. SM58 für transactional RFC, SMQ1/SMQ2 für qRFC, BD87 für IDoc-Verarbeitung und jedes Middleware-seitige Queue-Monitoring der Integrationsschicht müssen null ausstehende Elemente bestätigen, bevor die Datenmigration startet. Diese Prüfung gehört als abgezeichneter Checkpoint auf die Go-live-Cutover-Checkliste, nicht als Annahme.
Der letzte Batch Close: Den letzten Lauf auf dem Quellsystem überwachen
Die Batch-Jobs, die in den Tagen vor dem Go-live auf ECC laufen, tragen ein echtes Business-Risiko. Ein fehlgeschlagener Period-Close-Job, ein Fehler in der Payroll-Vorverarbeitung oder ein Billing Run, der nicht sauber abgeschlossen wird, hinterlässt das Quellsystem in einem inkonsistenten Zustand. Dieser Zustand wird in S/4HANA als Datenqualitätsproblem übernommen.
Die letzten Batch-Läufe auf ECC sollten mit derselben Aufmerksamkeit überwacht werden wie ein Monatsabschluss, nicht wie routinemäßige Background-Verarbeitung, die sich schon irgendwie selbst erledigt. Das bedeutet, nicht nur den Job-Status FINISHED zu prüfen, sondern auch den Spool-Inhalt auf Anwendungsebene-Fehler zu kontrollieren, bei Bedarf die Generierung von Output-Dateien zu bestätigen und sicherzustellen, dass nachgelagerte abhängige Jobs in der richtigen Reihenfolge abgeschlossen wurden.
Ein spezifisches Szenario ist besonders wichtig: Vorgänger-Nachfolger-Jobketten, die über das Interface-Freeze-Fenster hinweg laufen. Wenn ein Job, der Output für ein externes System erzeugt, während der Freeze-Periode geplant war, wurde dieser Output möglicherweise nicht vor dem Freeze ausgeliefert. Der Business Process Owner muss auf Basis von Monitoring-Nachweisen ausdrücklich bestätigen, dass der Datenstand in ECC zum Zeitpunkt der Migration für seinen Prozessbereich vollständig und sauber ist, nicht auf Basis einer Annahme.
Phase 3: Die ersten Stunden nach dem Go-live auf S/4HANA
HANA-Speicher und Performance in den ersten 24 Stunden
Wenn Business User zum ersten Mal ein frisch produktiv gesetztes S/4HANA-System nutzen, befindet sich die HANA-Instanz im Verhältnis zur Produktionslast in einem kalten Zustand. Column-Store-Daten, die während der Migration geladen wurden, wurden noch nicht von realen Transaktionen abgerufen. Die ersten User Queries veranlassen HANA, Column-Store-Partitionen zu laden, die seit der Migration nicht berührt wurden. Das erzeugt I/O auf dem Data Volume und erhöht den Speicherverbrauch.
Dieses Cold-Start-Verhalten bedeutet, dass die ersten Stunden des Produktivbetriebs anders aussehen als die Performance im Lasttest, selbst wenn dieser gut geplant war. Antwortzeiten in den ersten 30 bis 60 Minuten sind typischerweise höher, als sie sein werden, sobald der Working Dataset warm im Speicher liegt. Das Operations Team muss das im Voraus wissen, damit normales Cold-Start-Verhalten nicht als Systemproblem interpretiert wird, das sofortige Intervention erfordert.
Was hingegen sofortige Intervention erfordert, ist ein Speicherverbrauch, der sich dem Allocation Limit nähert, bevor der Working Dataset vollständig geladen ist. Wenn HANA Memory am ersten Tag nach zwei Stunden User-Aktivität bereits bei 82 % liegt, während weiterhin Daten in den Cache geladen werden, hat das System ein Sizing-Problem, das sich verschärfen wird, wenn der Datensatz warm wird. Den Speicherverbrauch ab der ersten User-Anmeldung gegen das Allocation Limit zu überwachen, nicht erst ab der ersten ausgelösten Warnung, gibt dem Operations Team die Trenddaten, die für diese Bewertung erforderlich sind.
In der Praxis: Setzen Sie für die ersten 48 Stunden nach dem Go-live einen temporär sensibleren Memory Alert Threshold: 75 % statt 85 %. In der Cold-Start-Phase treten unerwartete Speicherverbrauchsmuster am ehesten auf. Ein niedrigerer Schwellenwert gibt dem Team Zeit zur Analyse, bevor die Situation kritisch wird.
Background Job Scheduling: Prüfen, ob der Zeitplan korrekt übertragen wurde
Die Neuanlage von Jobs in S/4HANA ist ein manueller Prozess und eine häufige Quelle von Post-Go-live-Incidents. Die drei häufigsten Fehlerbilder sind Jobs, die gar nicht neu angelegt wurden und daher im Schedule fehlen, Jobs, die mit falschen Servergruppen-Zuweisungen neu angelegt wurden und auf einem Server laufen, der die Last nicht bewältigen kann oder nicht die nötigen Berechtigungen hat, und Jobs, bei denen Vorgänger-Nachfolger-Abhängigkeiten nicht korrekt konfiguriert wurden, sodass sie unabhängig starten statt in Sequenz.
Der Verifizierungsprozess besteht nicht darin, eine Jobliste anzusehen und Namensgleichheit zu bestätigen. Er besteht darin, die erste geplante Ausführung jedes kritischen Jobs laufen zu lassen, ihn in SM37 auf S/4HANA zu beobachten, zu bestätigen, dass er auf dem erwarteten Server läuft, innerhalb eines auf der ECC-Baseline basierenden erwarteten Zeitfensters abgeschlossen wird und den erwarteten Output produziert. Für Tier-1-Jobs sollte diese Prüfung stattfinden, bevor Business User informiert werden, dass das System vollständig betriebsbereit ist.
Täglich laufende Jobs können innerhalb der ersten 24 Stunden verifiziert werden. Jobs mit geringerer Frequenz, etwa wöchentliche Reporting-Jobs oder monatliche Close-Vorbereitungen, sind vor ihrer ersten echten Ausführung schwieriger zu prüfen. Für diese Jobs ist die Prüfung dokumentationsbasiert: Bestätigen Sie, dass die SM36-Konfiguration der dokumentierten Spezifikation aus der Job-Profil-Erfassung vor der Migration entspricht.
Die ersten Business-Transaktionen: Was überwacht werden sollte und was zu erwarten ist
Die Transaktionscodes mit dem höchsten Traffic in den ersten Stunden nach dem Go-live sind diejenigen, die bereits in ECC existierten und deren Verhalten sich in S/4HANA verändert hat. VA01 für die Sales Order Creation, ME21N für die Purchase Order, FB60 für die Vendor Invoice: Das sind Transaktionen, die Business User auswendig kennen und bei denen sie sofort merken, wenn sich etwas anders verhält. Antwortzeit-Regressionen bei genau diesen Transaktionen führen innerhalb weniger Minuten zu Helpdesk-Anrufen.
Dialog-Antwortzeiten nach Transaktionscode zu überwachen, nicht als Durchschnitt über alle Transaktionen, sondern segmentiert nach spezifischer Transaktion, ist die operativ nützlichste Performance-Sicht für den ersten Tag. Sie zeigt dem Operations Team, welche konkrete Business-Aktivität langsam ist, statt nur zu zeigen, dass das System generell unter Last steht. Diese Genauigkeit macht den Unterschied zwischen einer Analyse von 15 Minuten und einer Analyse von zwei Stunden.
Das Operations Team sollte vor dem Go-live eine Liste der 10 bis 15 geschäftskritischsten Transaktionscodes haben, inklusive ECC-Baseline-Antwortzeiten, und Monitoring so konfigurieren, dass eine Warnung ausgelöst wird, wenn sich einer dieser Codes in den ersten 48 Stunden um mehr als 50 % gegenüber der Baseline verschlechtert.
Phase 4: Stabilization Monitoring in den ersten 30 Tagen
Erster Monatsabschluss auf S/4HANA: Warum er besondere Monitoring-Aufmerksamkeit braucht
Ein Monatsabschluss auf einem System, das seit weniger als vier Wochen produktiv ist, unterscheidet sich grundlegend von einem Monatsabschluss auf einem stabilen Produktivsystem. Batch-Jobs laufen zum ersten Mal auf S/4HANA mit echten Datenvolumen aus einem vollen Monat produktiver Transaktionen. Das HANA-System verarbeitet Queries, die es noch nie gesehen hat. Für Job-Laufzeiten gibt es noch keine S/4HANA-Baseline, nur historische ECC-Daten aus der Pre-Migration-Erfassung.
Zwei spezifische Risiken sind während des ersten Monatsabschlusses höher als zu jedem späteren Zeitpunkt. Erstens die Batch-Job-Dauer: Jobs, die in ECC 45 Minuten liefen, können in S/4HANA 25 Minuten laufen, was aufgrund der In-Memory-Performance von HANA häufig vorkommt, oder deutlich länger dauern, etwa wegen Datenmodellunterschieden oder fehlender Datenbankstatistiken im neuen System. Ohne Monitoring entdeckt das Team Abweichungen erst, wenn ein Job sein Zeitfenster verpasst. Zweitens der HANA-Speicher: Der Monatsabschluss erzeugt größere Working Datasets als der Tagesbetrieb und lädt Daten, die seit dem Go-live möglicherweise nicht abgerufen wurden. Der Speicherverbrauch während der Monatsabschluss-Batch-Verarbeitung kann deutlich höher sein als in den ersten Wochen des normalen Tagesbetriebs.
Die Empfehlung lautet, den ersten Monatsabschluss als gesteuertes Ereignis mit expliziter Monitoring Watch zu behandeln: zugewiesene Mitarbeitende, die den Batch-Job-Fortschritt gegen den Zeitplan prüfen, Memory- und I/O-Metriken in Echtzeit beobachten und ein definierter Eskalationsprozess für Jobs, die mehr als 30 % über der erwarteten Dauer liegen.
Monitoring vom Projektteam an Operations übergeben: Der Handover, der oft scheitert
In fast jedem S/4HANA Projekt gibt es eine Phase, in der Projektteam und Operations Team das System gleichzeitig betreuen. Das Projektteam hat die Monitoring-Konfiguration aufgebaut, versteht, warum jeder Schwellenwert so gesetzt wurde, und weiß, welche Alerts während der Stabilisierung wahrscheinlich False Positives sind. Das Operations Team wird das System ab dem dritten Monat betreiben, lernt es aber in den Wochen eins bis acht noch kennen.
Der Handover, der scheitert, ist derjenige, bei dem das Operations Team Zugriff auf das Monitoring-Tool und eine kurze Einführung erhält und anschließend ohne das institutionelle Wissen arbeiten soll, das in die Konfiguration eingeflossen ist. Schwellenwerte, die für den Go-live-Zeitraum bewusst konservativ gesetzt wurden, werden nie für den Steady State angepasst. Alerts, die während der Stabilisierung relevant waren, bleiben nach Ende der Stabilisierung aktiv und erzeugen Rauschen. Das Operations Team beginnt, bestimmte Alert-Kategorien zu ignorieren, weil nicht klar ist, ob sie real sind oder Überbleibsel der Projektphase.
Ein nützliches Handover-Dokument für Monitoring hat drei Bestandteile: die Begründung für jeden Schwellenwert, zum Beispiel warum 75 % für Memory statt 85 % gewählt wurde und wann sich das ändern sollte, die Liste der Alerts, die für die Stabilisierung konfiguriert wurden und an Tag 30 überprüft werden sollten, sowie die Eskalationspfade für jede Alert-Kategorie. Dieses Dokument muss nicht lang sein. Es muss existieren.
Monitoring Readiness Checklist: Was vor dem Cutover vorhanden sein muss
Die folgende Tabelle ordnet die Monitoring-Readiness-Checkpoints über die vier Projektphasen hinweg. Jeder Checkpoint enthält, was zu prüfen ist und warum diese Prüfung wichtig ist. Nutzen Sie diese Übersicht in Pre-Go-live-Readiness-Reviews, um sicherzustellen, dass die Monitoring-Abdeckung vor dem Start des Migrationsfensters steht.
| Readiness Checkpoint | Was zu prüfen ist | Warum es wichtig ist |
|---|---|---|
| PRE-MIGRATION BASELINE, 6 bis 8 Wochen vor Cutover | ||
| ECC/Quellsystem-Baseline erfasst | Dialog-Antwortzeit, durchschnittliche Work-Process-Last, HANA Memory, Top 20 Transaktionen nach Ausführungsanzahl | Erforderlich, um S/4HANA Performance nach dem Go-live zu validieren. Ohne diese Daten gibt es keinen Vergleichspunkt. |
| Batch-Job-Laufzeitprofile dokumentiert | SM37-Historie für alle Tier-1- und Tier-2-Jobs, inklusive Monatsabschlussvarianten | S/4HANA Job-Laufzeiten werden abweichen. Baselines sind nötig, um abnormal von erwartet zu unterscheiden. |
| Interface-Throughput-Baselines erfasst | Volumen, Frequenz und Fehlerraten aller produktiven Schnittstellen über einen Zeitraum von 30 Tagen | Erkennt Regressionen in der Integrationsschicht nach dem Cutover. |
| Monitoring-Tool mit Quellsystem verbunden | Agentless Connection, autorisierter RFC User, laufende Datenerfassung | Monitoring sollte auf ECC laufen, bevor die Migration beginnt, damit Baseline-Daten im Tool liegen und nicht in einer Tabelle. |
| CUTOVER WINDOW MONITORING, T-48h bis T+0 | ||
| Finaler Batch Close auf dem Quellsystem überwacht | Alle Tier-1-Batch-Jobs auf ECC mit Status FINISHED abgeschlossen und Spool geprüft | Der letzte ECC Batch Run ist ein Meilenstein. Jeder Fehler hier beeinflusst den Startdatenstand in S/4HANA. |
| Interface Freeze bestätigt und überwacht | Alle eingehenden Schnittstellen nach ECC gestoppt, Message Queues auf null geleert | Restnachrichten während des Cutovers verursachen Reconciliation-Probleme nach dem Go-live. |
| HANA Log Mode Konfiguration geprüft | Log Mode für die Migrationsphase gemäß SAP-Empfehlung korrekt gesetzt | Ein falscher Log Mode während der Migration kann Log-Volumes erzeugen, die vor Abschluss des Cutovers voll laufen. |
| Migrationstool-Fortschritt SUM/DMO verfolgt | Aktives Monitoring von SUM- oder DMO-Phasen mit Dauer-Schwellenwerten pro Phase | Langlaufende Migrationsphasen ohne Monitoring sind Black Boxes. Duration Alerting ermöglicht Go/No-Go-Entscheidungen. |
| S/4HANA technische Konnektivität getestet | Monitoring-Tool vor dem Business Go-live mit dem Zielsystem S/4HANA verbunden | Der erste Alert auf S/4HANA sollte nicht erst in Produktion auftreten. Testen Sie die Verbindung während der technischen Cutover-Phase. |
| GO-LIVE, T+0 bis T+24h | ||
| HANA Memory Profil bei erster User-Anmeldung | Genutzter Speicher vs Allocation Limit in dem Moment, in dem erste Business User das System nutzen | Cold Start, initiales Datenladen und erste reale Query-Last erzeugen ein Memory-Profil, das keinem Testlauf entspricht. |
| Background Job Schedule in S/4HANA geprüft | Alle Tier-1- und Tier-2-Jobs vorhanden, freigegeben und mit korrekten Serverzuweisungen geplant | Jobs aus ECC werden nicht automatisch übertragen. Manuelle Neuanlage führt zu Scheduling-Fehlern, die erst sichtbar werden, wenn ein Job sein Fenster verpasst. |
| Erste Dialog-Transaktionsantwortzeiten | Baseline-Vergleich gegen ECC-Dialog-Antwortzeiten aus der Pre-Migration-Erfassung | Die erste Stunde User-Aktivität auf S/4HANA zeigt die kritischsten Performance-Lücken. |
| Interface Monitoring auf S/4HANA aktiv | Alle eingehenden und ausgehenden Schnittstellen wieder verbunden, erste Message Flows bestätigt | Die Reaktivierung von Schnittstellen nach dem Cutover ist manuell und sequenziell. Monitoring bestätigt, dass jede Schnittstelle tatsächlich verarbeitet. |
| Alert Routing geprüft | Test-Alert ausgelöst und Empfang durch das On-Call-Team bestätigt | In einer Testumgebung konfiguriertes Alert Routing kann von Produktion abweichen. Prüfen Sie es vor dem ersten echten Incident. |
| STABILIZATION WINDOW, T+1 bis T+30 Tage | ||
| Erster MRP Run überwacht | Dauer, Speicherverbrauch, Background-Job-Abschluss und Output-Volumen gegen Erwartung geprüft | Der erste produktive MRP auf S/4HANA ist schwer vorhersehbar. Oft ist er der erste echte Lasttest des neuen Systems. |
| Erster Monatsabschluss überwacht | Alle Period-Close-Batch-Jobs gegen ECC-Baseline-Dauern verfolgt | Monatsabschluss auf einem neuen System unterscheidet sich grundlegend vom Tagesbetrieb. Er braucht spezifische Monitoring-Aufmerksamkeit. |
| HANA Delta Merge Backlog verfolgt | Anzahl ausstehender Delta Merges und Fehlerrate in M_DELTA_MERGE_STATISTICS | Post-Go-live-Insert-Volumen beschleunigt häufig das Wachstum des Delta Stores in den ersten Wochen. Erkennen Sie es, bevor es Query Performance beeinträchtigt. |
| Monitoring-Handover an Operations dokumentiert | Runbooks, Schwellenwert-Begründungen und Eskalationspfade an Operations Team übergeben | Ein Projekt-Handover ohne dokumentierte Monitoring-Begründung lässt Operations mit Schwellenwerten arbeiten, die sie nicht verstehen. |
Monitoring ist ein Projekt-Deliverable, keine Post-Go-live-Aufgabe
Die SAP-Projekte mit den reibungslosesten Go-lives haben meist eines gemeinsam: Sie haben Monitoring-Infrastruktur als Projekt-Deliverable behandelt, mit eigenem Zeitplan, eigenen Abnahmekriterien und eigenem Sign-off-Checkpoint. Nicht als etwas, das das Operations Team einrichtet, nachdem das Business bereits live auf dem neuen System arbeitet.
Das Argument für diesen Ansatz ist einfach. Das Go-live-Fenster selbst, das Cutover-Wochenende, ist der Moment, in dem Sie Sichtbarkeit am dringendsten brauchen und gleichzeitig am wenigsten davon haben. Die erste Produktionswoche ist der Moment, in dem Performance-Fragen am dringendsten sind und Baseline-Vergleichsdaten den größten Wert haben. Beide Zeitfenster erfordern Monitoring, das vor Beginn der Migration aufgebaut, getestet und verifiziert wurde.
Eine Monitoring-Plattform, die sechs Wochen vor dem Go-live mit ECC verbunden wird, Baselines erfasst, normale Job-Laufzeiten lernt und Alert Routing verifiziert, ist während des Go-lives ein grundlegend anderes Werkzeug als eine Plattform, die erst am Tag der Business-Live-Schaltung konfiguriert wird. Der technische Aufwand, sie früh anzubinden, ist gering im Vergleich zum operativen Wert, den sie liefert, wenn das System unter Druck steht und das Team Antworten braucht.
Redpeaks verbindet sich ohne Agents oder Transports mit ECC-Quellsystemen und S/4HANA-Zielsystemen, erfasst Pre-Migration-Baselines und liefert Side-by-Side-Visibilität während des Go-lives. Einsetzbar in RISE with SAP und On-Premise-Umgebungen.
