Autor: Thierry Julien, CEO, TJC Group<\/p>\n\n
Sie m\u00fcssen FI_DOCUMNT archivieren.<\/strong> Sie \u00f6ffnen die Transaktion SARA, geben den Objektnamen ein und dr\u00fccken Enter. Der Bildschirm l\u00e4dt. Und jetzt? Sie sehen eine Reihe von Buttons: Schreiben, L\u00f6schen, Speichern, Lesen sowie einen Link zu Customizing. Ab hier liegt alles bei Ihnen: welche Buchungskreise, welche Gesch\u00e4ftsjahre, welche Variante, wann geplant werden soll, was zu tun ist, wenn etwas schiefgeht. SARA hat Ihnen die Werkzeuge gegeben. Einen Plan hat es Ihnen nicht gegeben. Dieser Artikel erkl\u00e4rt, warum dieser Unterschied wichtig ist \u2013 und wie vollst\u00e4ndige Archivierungsautomatisierung tats\u00e4chlich aussieht. <\/p>\n\n Beginnen wir dort, wo jede Archivierungsinitiative beginnt: mit einem echten Problem.<\/p>\n\n Ihr SAP-System l\u00e4uft seit einigen Jahren. Die ACDOCA-Tabellen sind auf Hunderte Millionen Datens\u00e4tze angewachsen. Die Systemperformance verschlechtert sich so stark, dass Sie nicht sicher sind, ob der Jahresabschluss n\u00e4chstes Jahr noch m\u00f6glich sein wird, und Sie glauben nicht, dass Budget f\u00fcr zus\u00e4tzlichen Speicher oder einen Wechsel auf eine gr\u00f6\u00dfere T-Shirt-Gr\u00f6\u00dfe vorhanden ist. Ihr Basis-Team sagt Ihnen, die Datenbank braucht Entlastung<\/a>. <\/p>\n\n Die Antwort, darin sind sich alle einig, sobald Aging und Tiering als irref\u00fchrende L\u00f6sungen erkannt wurden, lautet Datenarchivierung<\/a>. Sie werden FI_DOCUMNT archivieren, das Archivierungsobjekt f\u00fcr Finanzbuchhaltungsbelege. Es umfasst Tabellen wie BKPF, BSEG, BSAD, BSAK, BSAS und (in S\/4HANA) ACDOCA. Es ist eines der volumenst\u00e4rksten Archivierungsobjekte in jedem SAP-System und typischerweise einer der ersten Kandidaten in jedem Archivierungsprogramm. <\/p>\n\n Sie melden sich also in SAP an, geben SARA in das Befehlsfeld ein, tragen FI_DOCUMNT als Archivierungsobjekt ein und dr\u00fccken Enter. Der Bildschirm \u201eArchive Administration\u201c erscheint. Sie sind bereit zu beginnen. Aber womit genau? <\/p>\n\n SARA, SAP Archive Administration, ist ein gut strukturiertes Bildschirmbild. F\u00fcr FI_DOCUMNT zeigt es Ihnen Folgendes: <\/p>\n\n Schreiben:<\/strong> Hier erstellen und planen Sie den Schreib-Job. Das Schreibprogramm (FI_DOCUMNT_WRI) liest Finanzbelege aus der Datenbank und schreibt sie in Archivdateien. Bevor Sie es ausf\u00fchren k\u00f6nnen, ben\u00f6tigen Sie eine Schreibvariante \u2013 also eine Auswahlkriterienmenge, die dem Programm sagt, welche Belege zu selektieren sind. Bei FI_DOCUMNT sind die wichtigsten Selektionsfelder Buchungskreis und Gesch\u00e4ftsjahr\/-periode. Sie k\u00f6nnen au\u00dferdem nach Belegart, Buchungsdatum und weiteren Kriterien filtern. <\/p>\n\n L\u00f6schen:<\/strong> Sobald der Schreib-Job gestartet ist und die erste Archivdatei erstellt hat, entfernt das L\u00f6schprogramm (FI_DOCUMNT_DEL) die entsprechenden Datens\u00e4tze aus der Datenbank. Dieser Schritt gibt tats\u00e4chlich Speicher frei. Der L\u00f6sch-Job akzeptiert keine eigenen Selektionskriterien. Er arbeitet mit der Archivierungssitzungsnummer, die w\u00e4hrend der Schreibphase erzeugt wurde. <\/p>\n\n Speichern:<\/strong> Der Speicher-Job \u00fcbertr\u00e4gt die Archivdateien optional in ein Content-Repository oder einen externen Speicher. Je nach Ihrem Customizing kann dies automatisch nach der Schreibphase laufen oder manuell angesto\u00dfen werden. <\/p>\n\n Nachbearbeitung:<\/strong> Das Nachbearbeitungsprogramm (FI_DOCUMNT_PST) bereinigt Sekund\u00e4rindextabellen (BSAK, BSAS, BSIS), indem es Datens\u00e4tze entfernt, die w\u00e4hrend der L\u00f6schphase markiert wurden. Es sollte direkt nach dem L\u00f6schen laufen. <\/p>\n\n \u00dcber Customizing konfigurieren Sie objektspezifische Einstellungen: den logischen Dateinamen f\u00fcr Archivdateien, die maximale Dateigr\u00f6\u00dfe, ob L\u00f6sch- und Speicher-Jobs automatisch oder manuell laufen, sowie das Archivierungsszenario (L\u00f6schen vor Speichern oder Speichern vor L\u00f6schen). Au\u00dferdem pflegen Sie eine Mindestverweildauer, um Daten zu sch\u00fctzen, die nicht archiviert werden sollen. <\/p>\n\n Wo es angebracht ist: SARA bietet Ihnen eine vollst\u00e4ndige, transparente Sicht auf die Archivierungsinfrastruktur f\u00fcr jedes Objekt. Sie sehen die Programme, das Customizing, die Protokolle fr\u00fcherer Sitzungen und den Status aktueller L\u00e4ufe. F\u00fcr eine einzelne Archivierungssitzung auf einem einzelnen Objekt liefert es alles, was Sie ben\u00f6tigen, um den Prozess korrekt auszuf\u00fchren. <\/p>\n\n Das ist wirklich n\u00fctzlich. SARA ist eine zuverl\u00e4ssige, gut dokumentierte Oberfl\u00e4che, die SAP-Kunden seit Jahrzehnten dient. Das Problem ist nicht, was SARA Ihnen zeigt. Das Problem ist alles, was es von Ihnen erwartet, als N\u00e4chstes zu tun \u2013 allein, manuell, jedes einzelne Mal. <\/p>\n\n SARA zeigt Ihnen die Programme. Es gibt Ihnen Zugriff auf die Buttons. Aber es liefert keine Logik, um sie sicher, in der richtigen Reihenfolge, in gro\u00dfem Ma\u00dfstab und wiederkehrend auszuf\u00fchren. Hier werden die L\u00fccken sichtbar \u2013 und sie wachsen schnell, sobald Sie von der Archivierung eines einzelnen Objekts zur Durchf\u00fchrung eines unternehmensweiten Archivierungsprogramms \u00fcbergehen. <\/p>\n\n Um FI_DOCUMNT f\u00fcr Buchungskreis 1000 und die Gesch\u00e4ftsjahre 2015\u20132018 zu archivieren, erstellen Sie eine Schreibvariante mit diesen Selektionskriterien. F\u00fcr Buchungskreis 2000 erstellen Sie eine weitere. F\u00fcr Buchungskreis 3000 noch eine. Wenn Sie 40 Buchungskreise haben und f\u00fcr jeden sechs Gesch\u00e4ftsjahre archivieren m\u00f6chten, sprechen wir von Dutzenden Varianten \u2013 jede einzeln erstellt, benannt und manuell gepflegt. Das klingt nach nur ein paar Dutzend Jobs, aber ein vollst\u00e4ndiges Archivierungsprogramm endet bei Zehntausenden Jobs. Da es sich um einen nicht umkehrbaren Datenarchivierungsprozess handelt, ist ein manueller Lauf nicht gerade das, was das Top-Management erwartet, sobald es sich des Prozesses bewusst ist. <\/p>\n\n SAP bietet zwar Variantenvariablen, die Daten dynamisch berechnen k\u00f6nnen, doch diese Funktionalit\u00e4t st\u00f6\u00dft schnell an Grenzen. Die Archivierung von Finanzbelegen wird typischerweise durch Gesch\u00e4ftsperiode und Verweildauer gesteuert \u2013 nicht durch das Kalenderdatum. Variantenvariablen verwenden das aktuelle Systemdatum als Referenzpunkt, was bedeutet, dass sie die Selektionskriterien f\u00fcr einen verz\u00f6gerten Archivierungslauf, der eigentlich vor Jahren h\u00e4tte laufen sollen, nicht korrekt erzeugen k\u00f6nnen. Die Variante muss dann vor der Nutzung manuell angepasst werden \u2013 ein m\u00fchsamer, fehleranf\u00e4lliger Schritt, der den Zweck jeder eingerichteten Planung zunichtemacht. <\/p>\n\n Eine Archivierungssitzung besteht aus mehreren Jobs, und einige davon (der Speicher-Job und der L\u00f6sch-Job) sind zu Beginn der Sitzung noch nicht bekannt. Sie wissen nicht einmal, wie viele L\u00f6sch-Jobs laufen sollen. Deren Ausf\u00fchrung h\u00e4ngt vom Ergebnis des Schreib-Jobs ab. In SARA haben Sie zwei M\u00f6glichkeiten: diese Jobs so konfigurieren, dass sie automatisch \u00fcber ADK starten, oder sie nach Abschluss des Schreib-Jobs manuell planen. <\/p>\n\n Wenn Sie den automatischen Start w\u00e4hlen, verlieren Sie die Kontrolle dar\u00fcber, wie viele Jobs gleichzeitig laufen. Diese L\u00f6sch-Jobs, parallel ausgef\u00fchrt, k\u00f6nnen die Datenbank \u00fcberlasten und w\u00e4hrend der Spitzenzeiten Performance-Probleme verursachen. Wenn Sie den manuellen Start w\u00e4hlen, sind Sie wieder beim Beobachten und Warten: pr\u00fcfen, ob der Schreib-Job fertig ist, und dann die n\u00e4chste Phase manuell ansto\u00dfen. Keine der beiden Optionen ist zufriedenstellend. Was Sie tats\u00e4chlich brauchen, ist eine gesteuerte Ausf\u00fchrung: Jobs, die nach definierten Regeln, in definierten Zeitfenstern und mit Grenzen f\u00fcr parallele Verarbeitung gestartet werden. Das bietet SARA nicht. <\/p>\n\n FI_DOCUMNT wird selten isoliert archiviert. Ein typisches Archivierungsprogramm umfasst MM_MATBEL (Materialbelege), SD_VBAK (Kundenauftr\u00e4ge), IDOC (Intermediate Documents) und potenziell Dutzende weiterer Objekte. Einige dieser Objekte \u2013 inzwischen auch FI_DOCUMNT \u2013 haben Abh\u00e4ngigkeiten. Bestimmte ILM-Objekte<\/a> m\u00fcssen in einer definierten Reihenfolge verarbeitet werden, wobei die Sitzung f\u00fcr Objekt A erst starten darf, nachdem die Sitzung f\u00fcr Objekt B erfolgreich abgeschlossen wurde. <\/p>\n\n SARA hat keinen Mechanismus, um diese Abh\u00e4ngigkeiten zu verwalten. Jedes Objekt wird unabh\u00e4ngig administriert. Wenn Objekt B fehlschl\u00e4gt und Sie es nicht bemerken, wird Objekt A entweder mit veralteten Daten laufen oder beim geplanten Start ebenfalls fehlschlagen. Die Koordination der Reihenfolge \u00fcber 20 oder 30 Objekte hinweg, \u00fcber mehrere Buchungskreise, ist eine manuelle Orchestrierungsaufgabe, die st\u00e4ndige Aufmerksamkeit erfordert. Wenn der Archivierungs-\/ILM-Consultant das Unternehmen verl\u00e4sst oder im Urlaub ist, steht alles still \u2013 und startet meist nie wieder. <\/p>\n\n Archivierungssitzungen schlagen fehl. Ein Beleg ist durch einen anderen Prozess gesperrt. Ein Batch-Job l\u00e4uft in ein Timeout. Das System startet w\u00e4hrend eines Wartungsfensters neu. Wenn das in SARA passiert, bleibt die Sitzung h\u00e4ngen. Der Administrator muss den Fehler bemerken (durch Pr\u00fcfen von Logs oder Jobstatus), die Ursache diagnostizieren, sie beheben und die unterbrochene Phase manuell neu starten. <\/p>\n\n SAP hat im Laufe der Jahre OSS-Hinweise ver\u00f6ffentlicht, um dies zu verbessern (Hinweis 2520094 gibt Hinweise zum Fortsetzen unterbrochener Sitzungen, Hinweis 2586921 warnt vor nicht abgeschlossenen vorherigen L\u00e4ufen), aber das sind Informationshilfen \u2013 keine automatisierten Wiederherstellungsmechanismen. Der Mensch bleibt der Fehlerbehandler. Diese manuellen Fallstricke geh\u00f6ren zu den Hauptgr\u00fcnden, warum SAP-Datenarchivierungsprojekte scheitern k\u00f6nnen<\/a>.<\/p>\n\n Archivierungsjobs verbrauchen Systemressourcen. Einen gro\u00dfen FI_DOCUMNT-Schreib-Job w\u00e4hrend der Spitzenzeiten auszuf\u00fchren, verschlechtert die Antwortzeiten f\u00fcr Online-Nutzer. Ihn w\u00e4hrend des Monatsabschlusses laufen zu lassen, ist noch schlimmer. Die Jobplanung in SARA ist rudiment\u00e4r: Sie w\u00e4hlen Startdatum und -zeit. Es kennt keine Gesch\u00e4ftskalender, Wartungsfenster oder Sperrzeiten. Archivierungsl\u00e4ufe an diese Rahmenbedingungen anzupassen, ist eine manuelle Abstimmungsaufgabe zwischen Archivierungsteam, Basis-Team und Fachbereich. <\/p>\n\n Das ist die folgenreichste L\u00fccke. Ein initiales Archivierungsprojekt f\u00fcr FI_DOCUMNT kann sechs Jahre historischer Belege entfernen, und die anschlie\u00dfende ACDOCA-Komprimierung kann die relevanten Tabellen um 30 % oder mehr reduzieren. Beeindruckende Ergebnisse. Aber SAP-Datenbanken wachsen typischerweise um 15\u201320 % pro Jahr. Ohne regelm\u00e4\u00dfige, wiederkehrende Archivierungssitzungen werden diese Gewinne innerhalb von 18 Monaten wieder aufgezehrt. <\/p>\n\n SARA bietet keinen Mechanismus, um sicherzustellen, dass die Archivierung weiterl\u00e4uft, nachdem das Projektteam weitergezogen ist. Es gibt keine Wiederholungs-Engine, kein geplantes Sitzungsprogramm und keine Alarmierung, wenn die Archivierung \u00fcber einen definierten Zeitraum nicht gelaufen ist. Deshalb starten so viele Organisationen alle paar Jahre Archivierungsprojekte von Grund auf neu \u2013 ein kostspieliger, frustrierender Zyklus, den die TJC Group in mehr als 25 Jahren SAP-Datenmanagement-Engagements immer wieder erlebt hat. Von Anfang an die richtigen Archivierungsstrategien<\/a> zu w\u00e4hlen \u2013 einschlie\u00dflich Planung f\u00fcr Automatisierung und Wiederholung \u2013 ist entscheidend, um diesen Zyklus zu durchbrechen. <\/p>\n\n SARA ist ein Startpunkt, kein Motor.<\/strong> Es zeigt Ihnen die Archivierungsprogramme, das Customizing und die Protokolle. Es plant Ihre Sitzungen nicht, generiert Ihre Varianten nicht, sequenziert Ihre Objekte nicht, stellt sich nicht nach Fehlern wieder her und stellt nicht sicher, dass die Archivierung n\u00e4chsten Monat l\u00e4uft. Alles, was \u00fcber das Dr\u00fccken der Buttons hinausgeht, liegt in Ihrer Verantwortung. <\/p>\n\n Die eigentliche Herausforderung ist nicht, eine Sitzung auszuf\u00fchren. Es ist, ein Archivierungsprogramm dauerhaft aufrechtzuerhalten. <\/strong> Ein einzelner FI_DOCUMNT-Lauf in SARA ist unkompliziert. 30 Objekte \u00fcber 40 Buchungskreise hinweg jeden Monat, \u00fcber Jahre, ohne L\u00fccken oder Fehler zu betreiben, ist ein grundlegend anderes Problem. Dieses Problem erfordert Automatisierung. <\/p>\n\n Archivierungsgewinne sind ohne automatisierte Wiederholung nur tempor\u00e4r.<\/strong> Datenbanken wachsen um 15\u201320 % pro Jahr. Ein initiales Archivierungsprojekt verschafft Zeit; automatisierte Wiederholung \u00fcber ASC<\/a> macht die Reduktion dauerhaft. <\/p>\n\nInhalts\u00fcbersicht<\/h2>
Das Szenario: Sie m\u00fcssen Finanzbelege archivieren<\/h2>\n\n
Was SARA Ihnen tats\u00e4chlich zeigt<\/h2>\n\n
Die Aktions-Buttons<\/h3>\n\n
Der Customizing-Link<\/h3>\n\n
Was SARA gut macht<\/h3>\n\n
Die L\u00fccke: SARA ist ein Startpunkt, kein Motor<\/h2>\n\n
Sie m\u00fcssen jede Variante manuell erstellen und pflegen<\/h3>\n\n
Sie haben keine Kontrolle dar\u00fcber, was nach dem Schreib-Job passiert<\/h3>\n\n
Die Sequenzierung \u00fcber Objekte hinweg liegt vollst\u00e4ndig in Ihrer Verantwortung<\/h3>\n\n
Fehlerbehebung ist manuell<\/h3>\n\n
Es gibt kein Bewusstsein daf\u00fcr, wann Archivierung laufen sollte \u2013 oder nicht<\/h3>\n\n
Ohne Wiederholung verpuffen die Gewinne<\/h3>\n\n
Die wichtigsten Erkenntnisse<\/h2>\n\n