Der Jahresabschluss unterscheidet sich im SAP-Betrieb grundlegend von jeder anderen Phase. Manche Finanzabschlussläufe werden nur einmal pro Jahr ausgeführt. Batch-Jobs, die seit dem vergangenen Dezember nicht mehr getestet wurden, können nach einem weiteren Jahr Datenwachstum deutlich länger laufen. Externe Prüfer greifen mitten in der Reporting-Hochphase auf die Systeme zu. Gleichzeitig toleriert das Unternehmen zwischen Mitte Dezember und der ersten Januarwoche praktisch keine Ausfallzeit.
Die meisten SAP-Landschaften verändern sich im Laufe des Jahres schleichend. Batch-Zeitpläne werden informell angepasst. Alarmschwellen werden stummgeschaltet. Einst als Tier 1 eingestufte Jobs werden neu klassifiziert oder vergessen. Zertifikate nähern sich ihrem Ablaufdatum. RFC-Destinationen verweisen noch auf Systeme, die längst außer Betrieb sind. Im normalen Tagesgeschäft fallen solche Probleme häufig nicht auf. Sichtbar werden sie erst zum Jahresende — unter Last und genau dann, wenn dem Team am wenigsten Kapazität für ihre Behebung bleibt.
Dieser Leitfaden enthält 30 Fragen, die Sie vor Beginn des Jahresabschlussfensters beantworten sollten. Manche lassen sich in fünf Minuten klären. Andere decken Sachverhalte auf, deren Behebung mehrere Tage beansprucht. Genau deshalb gehört dieser Check in den November und nicht in den Dezember.
So führen Sie den SAP Health Check zum Jahresende durch
Bearbeiten Sie die Fragen in einer strukturierten Sitzung mit dem SAP-Basis-Verantwortlichen und mindestens einem Process Owner aus jedem wichtigen Funktionsbereich. Halten Sie die konkrete Antwort auf jede Frage fest, nicht nur die Bewertung „zufriedenstellend“ oder „nicht zufriedenstellend“. Diese Dokumentation bildet die Grundlage für die Freigabe der Jahresabschlussbereitschaft und liefert dem Betriebsteam während der Abschlussphase wichtigen Kontext.
Jede nicht zufriedenstellende Antwort braucht einen namentlich benannten Verantwortlichen und eine Frist vor dem Jahresende. Nicht jede Frage wird ein Problem offenlegen. Wo ein Risiko sichtbar wird, reichen jedoch weder ein anonymer Aktionspunkt noch eine Zeile in einem gemeinsam genutzten Dokument aus.
Empfohlener Zeitpunkt: Führen Sie den Check spätestens sechs Wochen vor Beginn Ihres Jahresabschlussfensters durch. Einige Maßnahmen — insbesondere Kapazitätsänderungen oder die Implementierung von Security Notes — benötigen Vorlauf.
SAP HANA: Kapazität, Backups und Hochverfügbarkeit
1. Wie hoch war die maximale SAP-HANA-Speicherauslastung beim letzten Monatsabschluss?
Entscheidend sind weder die aktuelle Auslastung noch der Tagesdurchschnitt. Relevant ist der Spitzenwert während des Monatsabschlusses, denn er ist der beste verfügbare Näherungswert für die Spitzenlast zum Jahresende. Lag dieser Wert über 82 %, wird der Jahresabschluss ihn sehr wahrscheinlich weiter erhöhen. Beim Jahresabschluss befindet sich ein vollständiges Datenjahr im Working Set, nicht nur der letzte Monat. Ein System, das Ende Oktober 84 % erreicht hat, läuft im Dezember ernsthaft Gefahr, sich dem Allocation Limit zu nähern.
Nicht zufriedenstellend: Spitzenwert über 80 % und keine geplante Sizing-Prüfung.
Maßnahme: Starten Sie umgehend eine Kapazitätsanalyse mit dem Infrastruktur- oder Cloud-Team. Der Wechsel des Instanztyps bei einem Hyperscaler erfordert Planung und ein Wartungsfenster. Eine Speichererweiterung im eigenen Rechenzentrum erfordert eine Beschaffung. Beides lässt sich nicht innerhalb einer Woche erledigen.
2. War das letzte vollständige Backup erfolgreich und ist die Log-Backup-Kette lückenlos?
Prüfen Sie M_BACKUP_CATALOG mit einem Filter auf vollständige Data Backups. Das letzte erfolgreiche Backup sollte nicht älter als 24 Stunden sein. Kontrollieren Sie anschließend, ob die Log-Backup-Kette Lücken enthält. Eine unterbrochene Sequenz macht eine Point-in-Time-Recovery für den Zeitraum nach der Lücke unmöglich. Beide Bedingungen sind leicht zu überprüfen, haben jedoch gravierende Auswirkungen auf die Wiederherstellbarkeit, wenn sie vor dem Jahresende nicht erfüllt sind.
Ein Backup-Problem während des Jahresabschlusses zu entdecken, wenn das Team bereits unter maximalem Druck steht, ist wesentlich kritischer, als es im November zu finden und genügend Zeit für Ursachenanalyse und Behebung zu haben.
3. Reicht die Plattenkapazität für das erwartete Datenwachstum bis nach dem Jahresabschluss?
Fragen Sie M_DISK_USAGE ab, um die aktuelle Größe des Datenvolumens zu ermitteln. Wenn Ihr Monitoring diese Kennzahl historisiert, berechnen Sie anhand des Trends die monatliche Wachstumsrate und erstellen Sie eine Prognose. Zum Jahresende entstehen mehr Daten als in einem typischen Monat: Abschlussbuchungen, Jahresabgrenzungen und Prüfungsanpassungen. Reicht die verbleibende Kapazität selbst ohne diese zusätzlichen Daten für weniger als vier Monate, muss eine Speichererweiterung eingeplant werden.
4. Sind in den vergangenen 30 Tagen Delta-Merge-Fehler aufgetreten?
Fragen Sie M_DELTA_MERGE_STATISTICS für die vergangenen 30 Tage mit dem Filter merge_reason = 'MERGE_ERROR' ab. Mehr als null fehlgeschlagene Delta Merges sind nicht in jedem Fall für sich genommen kritisch. Ein zunehmender Trend weist jedoch darauf hin, dass der automatische Merge-Prozess unterbrochen wird, typischerweise aufgrund von Ressourcenkonflikten.
Ein wachsender Rückstau ausstehender Merges verschlechtert die Leseleistung der betroffenen Tabellen. Wenn beim Jahresabschluss analytische Abfragen über ein vollständiges Datenjahr parallel zur Batch-Verarbeitung laufen, wirkt sich eine schwächere Read Performance im HANA Column Store direkt auf die Dauer des Abschlusses aus.
5. Ist die HANA-Replikation aktuell und wurde der Failover kürzlich getestet?
Prüfen Sie in Hochverfügbarkeitsumgebungen mit HANA System Replication den aktuellen Rückstand in M_SERVICE_REPLICATION. Ein dauerhaftes Lag von mehr als zehn Sekunden im Modus SYNCMEM ist ein Warnsignal. Der Rückstand zu einem bestimmten Zeitpunkt entspricht faktisch dem RPO, falls ein Failover erforderlich wird.
Noch wichtiger ist die Frage, wann dieser Failover zuletzt tatsächlich getestet wurde. Eine Konfiguration, die seit dem Go-live nie erprobt wurde, bleibt eine Annahme. Der Jahresabschluss ist der denkbar schlechteste Zeitpunkt, um einen falsch konfigurierten Pacemaker-Cluster zu entdecken.
6. Enthält der Row Store größere Mengen reservierten, aber ungenutzten Speichers?
Der Row-Store-Speicher in SAP HANA wird beim Löschen von Zeilen nicht automatisch freigegeben. Row-Store-Tabellen mit hoher Insert-/Delete-Aktivität sammeln daher im Laufe eines Betriebsjahres reservierten, aber ungenutzten Speicher an.
Analysieren Sie den Trend in M_RS_MEMORY für die vergangenen sechs Monate. Ist der reservierte Row-Store-Speicher gewachsen, ohne dass die tatsächliche Datenmenge entsprechend zugenommen hat, führen Sie vor dem Jahresende ALTER TABLE ... RECLAIM DATA SPACE für die größten Row-Store-Tabellen aus. Der Befehl gibt Speicher frei, ohne Datenverlust und ohne Systemneustart.
SAP Batch-Jobs: Laufzeiten, Kapazität und Abhängigkeiten
7. Laufen geschäftskritische Batch-Jobs länger als im Vorjahr?
Ziehen Sie die SM37-Historie für Oktober dieses Jahres und Oktober des Vorjahres heran. Berechnen Sie für jeden geschäftskritischen Tier-1-Job die durchschnittliche Laufzeit in beiden Zeiträumen. Ein Anstieg von mehr als 20 % gegenüber dem Vorjahr ist kein Zufall: Das Datenvolumen ist gewachsen, kundeneigenes ABAP, das bei kleineren Datenmengen noch ausreichend schnell war, ist zu langsam geworden, oder ein im Vorjahr neu aufgebauter Datenbankindex wurde dieses Jahr nicht regeneriert. Wird die Ursache jetzt erkannt, lässt sie sich noch vor dem Jahresende angehen.
Der Vergleich hilft außerdem, die Laufzeiten zum Jahresende abzuschätzen. Benötigte ein Job beim Oktoberabschluss vier Stunden und ist seine Laufzeit im Jahresvergleich um 15 % gestiegen, sollten Sie zum Jahresende bei Verarbeitung des Jahresvolumens mit etwa 4,5 bis 5 Stunden rechnen. Diese Schätzung gehört in die Planung des Jahresabschluss-Batchkalenders.
8. Haben täglich eingeplante Jobs unbemerkt aufgehört zu laufen?
Ein Job, der ohne Fehlermeldung nicht mehr ausgeführt wird, gehört zu den schwerer erkennbaren Störungen. Er ist weiterhin im Zeitplan vorhanden, und nichts steht auf „fehlgeschlagen“. Sichtbar wird das Problem nur, wenn jemand gezielt nach fehlenden aktuellen Instanzen sucht.
Durchsuchen Sie SM37 nach täglich eingeplanten Jobs und filtern Sie auf die vergangenen 14 Tage. Jeder tägliche Job ohne einzige Instanz in diesem Zeitraum hat ein Problem: Er kann pausiert sein, der Jobserver kann nicht verfügbar sein oder der Zeitplan wurde versehentlich gelöscht.
9. Ist der Batch-Zeitplan zum Jahresende aktuell und von den Process Ownern freigegeben?
Der Batch-Zeitplan für den Jahresabschluss unterscheidet sich von dem eines Monatsabschlusses: mehr Jobs, längere Zeitfenster, andere Abhängigkeiten und teilweise andere Servergruppenzuordnungen. Das Basis-Team pflegt diesen Plan meist auf Grundlage des Vorjahres. Er muss jedoch mit dem aktuellen Abschlusskalender abgeglichen werden — besonders dann, wenn der Jahreswechsel auf einen anderen Wochentag fällt als im Vorjahr und sich dadurch ändert, welche Jobs an welchem Wochenende laufen müssen.
„Von den Process Ownern freigegeben“ bedeutet, dass das Financial-Close-Team, die Logistik und alle weiteren Bereiche mit jahresendspezifischen Abläufen Jobliste und Zeitplan bestätigt haben. Eine unbeantwortete E-Mail des Basis-Teams ist keine Freigabe.
10. Gibt es fehlgeschlagene Jobs ohne Ticket oder formale Klärung?
Diese Frage ist unangenehm, weil sie in vielen Systemlandschaften mit Ja beantwortet werden muss. Jobs schlagen fehl, werden vom Team bemerkt und dennoch nicht formell geklärt, wenn keine unmittelbare Auswirkung erkennbar ist. So sammeln sich bekannte, aber ungelöste Fehler an.
Bereinigen Sie vor dem Jahresende die Liste fehlgeschlagener Jobs in SM37. Beheben Sie die Fehler oder dokumentieren Sie formal, warum die Jobs nicht mehr benötigt werden, und entfernen Sie sie aus dem Zeitplan. Ein seit September fehlgeschlagener Job ohne Ticket ist eine künftige Audit-Feststellung.
11. Reicht die Zahl der Background Work Processes für die maximale Anzahl paralleler Jobs?
Monats- und Jahresabschluss unterscheiden sich in der Anzahl gleichzeitig laufender Batch-Jobs. Zum Jahresende schließen häufig mehrere Funktionsbereiche parallel ab, sodass mehr Jobs zur selben Zeit ausgeführt werden.
Prüfen Sie, ob die aktuelle Anzahl der Background Work Processes, kurz WP, pro Instanz für den höchsten Parallelitätsgrad im Jahresabschlussplan ausreicht. Sind 18 gleichzeitige Jobs vorgesehen, während die Instanz nur 15 Background WPs besitzt, werden während der Spitzenphase fortlaufend mehrere Jobs warten müssen.
12. Berücksichtigen kritische Jobketten die für dieses Jahr geschätzten Laufzeiten?
Jobketten verschieben sich, wenn sich Laufzeiten ändern. Eine kritische Kette, in der Job B nach dem Abschluss von Job A startet, funktioniert, solange A drei Stunden dauert. Steigt die Laufzeit durch das diesjährige Datenvolumen auf 4,5 Stunden, startet B 1,5 Stunden später. Alle nachgelagerten Jobs verschieben sich ebenfalls.
Enthält der Jahresabschlussplan feste externe Fristen — etwa für regulatorische Meldungen oder Bank-Cut-off-Zeiten —, müssen die Ketten anhand der für dieses Jahr erwarteten Laufzeiten neu geprüft werden, nicht anhand der Ist-Werte des Vorjahres.
SAP-Schnittstellen: IDocs, RFC, Zertifikate und BTP
13. Ist die IDoc-Fehlerquote bei nachrichtenstarken Typen gestiegen?
Rufen Sie in BD87 oder WE05 die Daten der vergangenen 30 Tage ab. Berechnen Sie für jeden Nachrichtentyp mit hohem Volumen die Fehlerquote — Fehler geteilt durch Gesamtvolumen — und vergleichen Sie sie, sofern verfügbar, mit demselben Monat des Vorjahres.
Eine gegenüber dem Vorjahr gestiegene Quote für einen bestimmten Nachrichtentyp weist auf eine schleichende Verschlechterung der Datenqualität im sendenden System oder der Verarbeitungskonfiguration auf der Empfängerseite hin. Wenn das IDoc-Volumen zum Jahresende durch Fakturierung, Versandmeldungen und Finanzbuchungen stark ansteigt, führt schon eine Fehlerquote von 2 % zu einer wesentlich größeren absoluten Fehlerzahl.
14. Bestehen alle Typ-3-RFC-Destinationen in Produktion den Verbindungstest?
Führen Sie für sämtliche in Produktion konfigurierten Typ-3-RFC-Destinationen einen Verbindungstest aus. Destinationen, die den Test nicht bestehen und in den vergangenen 90 Tagen nicht genutzt wurden, sind Kandidaten für eine Stilllegung. Destinationen, die trotz aktueller Nutzung fehlschlagen, weisen auf eine unterbrochene Integration hin, die Geschäftsprozesse beeinträchtigen kann.
Diese Prüfung lässt sich an einem Nachmittag durchführen. Sie deckt sowohl veraltete Konfigurationen auf, die bereinigt werden sollten, als auch defekte Integrationen, die vor dem Jahresabschluss Aufmerksamkeit benötigen.
15. Läuft ein SSL-Zertifikat einer produktiven Schnittstelle vor Ende März ab?
Ein Zertifikat, das am 15. Januar abläuft, ist nicht nur ein Problem für den 15. Januar. Es wird genau in der Phase kritisch, in der das Team den Jahresabschluss finalisiert und am wenigsten Kapazität für eine Notfallmaßnahme hat.
Ermitteln Sie die Ablaufdaten aller Zertifikate, die von produktiven Schnittstellen verwendet werden. Jedes Zertifikat mit einem Ablaufdatum vor Ende März sollte noch vor dem Jahresende erneuert werden, nicht erst danach.
16. Sind qRFC-Queues in SMQ1 oder SMQ2 blockiert?
Öffnen Sie SMQ1 und SMQ2. Eine blockierte Queue mit dem Status SYSFAIL oder CPICERR stoppt die Verarbeitung sämtlicher Nachrichten, die hinter dem blockierenden Eintrag stehen. Existieren in Produktion bekannte blockierte Queues, um die das Team im Alltag herumarbeitet, wird das höhere Jahresendvolumen den Rückstau vergrößern und den Workaround aufwendiger machen. Beheben Sie die zugrunde liegende Blockade vor dem Jahresende.
17. Wurden die drei kritischsten Schnittstellen Ende-zu-Ende getestet?
Ein Verbindungstest bestätigt die Erreichbarkeit über das Netzwerk. Ein Ende-zu-Ende-Nachrichtentest bestätigt, dass die Daten in der gesamten Integrationskette korrekt verarbeitet werden. Das sind zwei verschiedene Prüfungen, die unabhängig voneinander fehlschlagen können.
Führen Sie vor dem Jahresende eine Testtransaktion über jede der drei geschäftskritischsten Schnittstellen aus und überprüfen Sie das Ergebnis im empfangenden System. Falls einer dieser Tests fehlschlägt, entdecken Sie den Fehler besser im November, solange Zeit für eine Korrektur bleibt.
18. Laufen BTP-Credentials oder Integration-Suite-Connectoren vor März ab?
Auf SAP BTP gehostete Flows und Integration-Suite-Connectoren verwenden Zugangsdaten mit eigenen Ablaufzyklen, unabhängig vom Zertifikatsmanagement des ABAP-Systems. Ein BTP Service Credential, das Mitte Dezember abläuft, unterbricht jede darauf angewiesene Integration. Auf SAP-Seite ist möglicherweise nur eine fehlgeschlagene Flow-Instanz zu sehen.
Rufen Sie die Ablaufdaten im Cockpit des BTP-Subaccounts ab und nehmen Sie alle Credentials, die vor März auslaufen, in die Erneuerungsliste auf.
SAP-ABAP-Performance: Speicher, Puffer und Benutzerlast
19. Welches sind die fünf Dialogprogramme mit der längsten Laufzeit, und ist ihre Dauer plausibel?
Entnehmen Sie diese Information dem Workload Monitor oder den STAD-Statistiken. Ermitteln Sie für jedes der fünf Programme, ob die Laufzeit erwartet wird — etwa bei einer bewusst lang laufenden Analyse — oder auffällig ist, weil ein eigentlich schnelles Programm langsamer geworden ist.
Programme mit ungewöhnlich langen Laufzeiten belegen Dialog Work Processes länger als nötig und reduzieren so die tatsächlich verfügbare Kapazität unter Spitzenlast. Vor dem Jahresende erkannt, können sie untersucht und möglicherweise optimiert werden. Während des Jahresabschlusses erkannt, führen sie zu operativer Brandbekämpfung.
20. Liegt die maximale Extended-Memory-Auslastung über 75 %?
Der Extended Memory wird von allen Sessions einer Applikationsserverinstanz gemeinsam genutzt. Ist er erschöpft, weichen Sessions auf Roll-File-Speicher auf der Festplatte aus, der um Größenordnungen langsamer ist als Arbeitsspeicher.
Prüfen Sie im ABAP Memory Monitor ST02 für jede produktive Instanz die höchste Extended-Memory-Auslastung der vergangenen 30 Tage. Zum Jahresende steigen sowohl die Zahl gleichzeitiger Benutzer als auch die Zahl speicherintensiver Sessions, beispielsweise durch große Reports und Jahresanalysen. Liegt der Spitzenwert bereits über 75 %, werden einzelne Sessions beim Jahresabschluss voraussichtlich in den Roll-File-Bereich ausweichen.
21. Bleibt die Trefferquote des Tabellenpuffers über 98 %?
Öffnen Sie ST02 und prüfen Sie die Quality-Spalte für den Tabellenpuffer. Eine Trefferquote unter 98 % zeigt, dass der Puffer nicht groß genug ist, um das vollständige Working Set häufig genutzter Tabellen aufzunehmen. Lesezugriffe, die aus dem Speicher kommen sollten, werden dadurch an die Datenbank weitergeleitet.
Bei vielen gleichzeitigen Benutzern erzeugen diese Pufferfehler zum Jahresende eine messbare zusätzliche Datenbanklast. Hat sich die Quote gegenüber dem Vorjahr verschlechtert, ist der Puffer möglicherweise im Verhältnis zum gewachsenen Working Set zu klein, oder eine gepufferte Tabelle ist stark gewachsen und muss geprüft werden.
22. Reicht die Zahl der Dialog Work Processes für die erwartete Benutzerspitze?
Zum Jahresende greifen viele Benutzer zu, die sonst kaum aktiv sind: Bereichsleiter prüfen Jahreszahlen, Prüfer erhalten temporären Systemzugang und Führungskräfte rufen Jahresend-Dashboards auf. Die höchste Zahl paralleler Sessions kann im Dezember um 30 % über jedem anderen Monat liegen.
Ermitteln Sie in AL08 die maximale Zahl gleichzeitiger Benutzer im vergangenen Dezember und vergleichen Sie sie mit dem aktuellen Dialog-WP-Pool jeder Instanz. Wurde eine Instanz beim Vorjahrespeak bereits zu mehr als 80 % ausgelastet und ist die Benutzerzahl seitdem gestiegen, müssen möglicherweise vor dem Jahresende zusätzliche Dialog Work Processes konfiguriert werden.
23. Verschlechtern sich Zahl oder Art der ABAP-Dumps im Jahresvergleich?
Vergleichen Sie in ST22 die Dump-Anzahl im Oktober dieses Jahres mit der im Oktober des Vorjahres. Ein steigender Trend deutet auf zunehmende Instabilität hin, häufig verursacht durch kundeneigene ABAP-Programme, die nicht an Änderungen des Datenmodells oder höhere Volumina angepasst wurden.
Achten Sie besonders auf die Dump-Klassen. MEMORY_NO_MORE_PAGING und TSV_TNEW_PAGE_ALLOC_FAILED weisen auf Speicherdruck hin; TIME_OUT zeigt, dass Programme bei den aktuellen Datenmengen das Step-Time-Limit überschreiten. Beide Fehlerarten treten zum Jahresende häufiger auf, wenn das Datenvolumen am größten ist.
SAP-Sicherheit und Audit-Vorbereitung
24. Ist jeder Benutzer mit SAP_ALL oder einer Notfallberechtigung weiterhin gerechtfertigt?
Rufen Sie die Benutzerliste mit einem Filter auf Zuweisungen von SAP_ALL oder Notfallrollen ab. Prüfen Sie für jeden Benutzer, ob der Zugriff weiterhin erforderlich ist, aktiv für den vorgesehenen Zweck genutzt wird und nicht zu einem ruhenden Konto mit weitreichenden Berechtigungen geworden ist.
Zum Jahresende achten externe Prüfer besonders auf überprivilegierte Konten. Eine Bereinigung im November ist Vorbereitung. Eine Bereinigung im Januar unter Audit-Druck ist lediglich eine Reaktion.
25. Entsprechen die Passwörter von Service- und RFC-Benutzern der Rotationsrichtlinie?
Service- und technische Benutzer in SAP sind häufig von Standardregeln zur Passwortrotation ausgenommen, weil ein Wechsel auch RFC-Destinationen und Verbindungszeichenfolgen von Schnittstellen betrifft. Über Jahre hinweg werden solche Credentials damit faktisch permanent.
Überprüfen Sie vor dem Jahresende das Datum der letzten Rotation jedes Servicekontos und technischen RFC-Benutzers. Stellen Sie sicher, dass es den Sicherheitsrichtlinien des Unternehmens entspricht, und planen Sie die Rotation nicht konformer Credentials. Dokumentieren Sie den Wechsel als Nachweis für das Audit.
26. Sind anwendbare SAP Security Notes mit einem CVSS-Score über 7,0 noch offen?
Prüfen Sie im SAP Security Notes Launchpad, ob Notes mit einem CVSS-Score über 7,0 für die in Produktion eingesetzten SAP-Komponenten relevant und noch nicht implementiert sind. Kritische Sicherheitspatches sollten nicht auf die Zeit nach dem Jahresabschluss verschoben werden.
Die Jahresendphase mit Systemzugriffen durch Prüfer und erhöhter Aufmerksamkeit für Finanzsysteme birgt ein besonders hohes Sicherheitsrisiko. Implementieren Sie kritische Security Notes vor dem Jahresende, nicht danach.
27. Sind Prüferberechtigungen auf das notwendige Minimum begrenzt und mit einem Entzugstermin versehen?
Externe Prüfer benötigen während der Jahresabschlussprüfung Lesezugriff auf bestimmte Transaktionsdaten, Berichte und Belege. Oft werden diese Rechte breiter vergeben als nötig, weil eine präzise Abgrenzung Zeit kostet.
Definieren Sie vor dem Jahresende den minimal erforderlichen Zugriff für jede Prüferrolle, lassen Sie ihn vom Security-Team validieren und hinterlegen Sie im Bereitstellungsvorgang ein Datum für den Entzug. Ein im Dezember gewährter Zugang, der wegen eines vergessenen Entzugsschritts bis April bestehen bleibt, wird im Folgejahr selbst zum Audit-Fund.
SAP-Monitoring, Recovery und Betriebskontinuität
28. Sind Monitoring-Schwellenwerte und Rufbereitschaft auf die Jahresendlast abgestimmt?
Schwellenwerte, die auf die durchschnittliche Tageslast abgestimmt sind, erzeugen während der Jahresabschlussverarbeitung Fehlalarme. Speicher-, CPU- und Work-Process-Auslastung liegen dann berechtigterweise über dem Normalniveau.
Überprüfen Sie vor dem Jahresende die Schwellenwerte für HANA-Speicher, Dialog- und Background-WP-Auslastung sowie Batch-Job-Laufzeiten und passen Sie sie an die erwarteten Spitzen an. Richten Sie zugleich Unterdrückungsfenster für die geplanten Abschlussaktivitäten ein, damit erwartete Lastspitzen oder Wartungsereignisse keine unnötigen Bereitschaftsalarme auslösen.
Kontrollieren Sie außerdem, ob der Eskalationsweg aktuell ist. Telefonnummern ändern sich, Mitarbeitende wechseln ihre Rolle. Ein vor 14 Monaten konfigurierter Eskalationsbaum kann noch immer an jemanden verweisen, der das Unternehmen im August verlassen hat. Testen Sie den gesamten Eskalationsweg vor dem Jahresabschluss, nicht währenddessen.
29. Wurde in den vergangenen sechs Monaten eine Wiederherstellung mit gemessenem RTO getestet?
Ein Backup, dessen Wiederherstellung nie getestet wurde, ist lediglich eine Annahme. Das Jahresende, an dem ein Ausfall die größten finanziellen und reputationsbezogenen Folgen hätte, ist nicht der richtige Zeitpunkt, diese Annahme erstmals zu prüfen.
Liegt der letzte Recovery-Test mehr als sechs Monate zurück, planen Sie vor dem Jahresende einen neuen ein. Dafür ist keine vollständige Produktionswiederherstellung nötig. Ein gezielter Restore eines repräsentativen Datensatzes in eine Testumgebung, gemessen vom Start bis zur bestätigten Datenverfügbarkeit, liefert ein belegtes RTO statt einer bloßen Schätzung.
30. Reicht der Backup-Speicher für Datenvolumen und Aufbewahrung zum Jahresende?
Zum Jahresende entstehen mehr Backup-Daten als in jeder anderen Phase: Vollständige Data Backups, Log Backups und Archive Logs laufen parallel, während die Datenbank durch die hohe Zahl von Abschlussbuchungen schneller wächst als üblich.
Berechnen Sie den Bedarf: aktuelles Datenvolumen plus erwartetes Jahresendwachstum, multipliziert mit der Backup-Aufbewahrungsrichtlinie, zuzüglich des Log-Backup-Volumens bei maximaler Log-Erzeugung, multipliziert mit dessen Aufbewahrungszeit. Nähert sich der Wert der verfügbaren Kapazität, müssen Sie den Speicher vor dem Jahresende erweitern oder die Aufbewahrung älterer Backups anpassen. Ein volles Backup-Volume während des Jahresabschlusses ist ein vermeidbarer Vorfall.
Was folgt nach dem SAP Health Check?
Nachdem Sie alle 30 Fragen beantwortet haben, ordnen Sie die Ergebnisse drei Kategorien zu:
- Zufriedenstellende Antworten fließen in die Freigabe der Jahresabschlussbereitschaft ein und erfordern keine weitere Maßnahme.
- Nicht zufriedenstellende Antworten mit geringem Behebungsaufwand sollten sofort bearbeitet werden.
- Nicht zufriedenstellende Antworten, die größeren Aufwand, Infrastrukturänderungen oder externe Koordination erfordern, brauchen einen namentlich benannten Verantwortlichen, einen realistischen Abschlusstermin und einen Eskalationsweg für den Fall einer Verzögerung.
Das häufigste Bild: 22 bis 25 Fragen sind zufriedenstellend beantwortet, drei bis fünf führen zu schnellen Korrekturen, und zwei oder drei legen Probleme mit echtem Handlungsbedarf offen. Gerade diese letzten Punkte rechtfertigen es, den Check sechs Wochen und nicht sechs Tage vor dem Jahresende durchzuführen.
Wiederholen Sie die Prüfung zwei Wochen vor Beginn des Jahresabschlussfensters. Sie müssen nicht alle 30 Fragen erneut bearbeiten. Konzentrieren Sie sich auf die zuvor nicht zufriedenstellenden Punkte sowie auf Monitoring und Backups, da sich deren Status kurzfristig ändern kann. Der zweite Durchlauf bestätigt, dass die Maßnahmen abgeschlossen wurden und seit der ersten Prüfung keine neuen Risiken entstanden sind.
Diese 30 Fragen garantieren keinen störungsfreien Jahresabschluss. Sie stellen jedoch sicher, dass die vorab erkennbaren Probleme auch tatsächlich gesucht und gefunden werden. Risiken, die erst unter der vollen Jahresendlast sichtbar werden, gehören in eine andere Kategorie und lassen sich nur durch Echtzeit-Monitoring erkennen.
Redpeaks Monitoring liefert die Daten für die meisten dieser Fragen in wenigen Minuten statt in mehreren Stunden. Trendansichten, Alarmhistorien und systemübergreifende Korrelationen stehen über eine zentrale Oberfläche zur Verfügung. Erfahren Sie, wie Redpeaks Ihre Vorbereitung auf den Jahresabschluss unterstützt.
