SAP ECC zu S/4HANA: Welche Daten sollten migriert werden?

Autor: Satya Prasad, Senior SAP ILM Delivery Lead bei der TJC Group

Das Verschieben jedes Datensatzes von SAP ECC nach S/4HANA kann die Anforderungen an das HANA-Sizing, den Migrationsaufwand und die langfristigen Betriebskosten erhöhen. Eine strukturierte Datenbewertung hilft Unternehmen bei der Entscheidung, was migriert, archiviert, gelöscht oder außerhalb des Kern-ERP aufbewahrt werden sollte. Dieser Artikel erklärt, wie diese Entscheidungen eine schlankere S/4HANA-Umgebung schaffen und gleichzeitig die historischen Informationen bewahren können, die für Compliance, Reporting, Analysen und zukünftige KI-Anwendungsfälle benötigt werden.

Einführung

Der Wechsel von SAP ECC zu SAP S/4HANA ist nicht einfach ein technischer Datentransfer von einem System in ein anderes. Es ist eine Gelegenheit zu entscheiden, welche Daten, Prozesse und historischen Informationen die zukünftige SAP-Landschaft enthalten soll.

Die Migration jedes historischen Datensatzes mag als die sicherste Option erscheinen. Sie kann jedoch die Anforderungen an das HANA-Sizing erhöhen, Migrations- und Testfenster verlängern und alte Datenprobleme in die neue Umgebung übertragen. Andererseits birgt das Löschen von zu vielen Daten ein anderes Risiko. Historische Informationen werden möglicherweise noch für Audits, Reporting, Rechtsstreitigkeiten, Steuer-Compliance oder zukünftige Analysen benötigt. Das Ziel ist daher nicht, alles zu verschieben oder alles zu entfernen. Es geht darum, jede Datenkategorie in der Umgebung zu platzieren, in der sie einen Mehrwert zu angemessenen Kosten und Risiken liefert.

Prüfen Sie vor der Migration nach S/4HANA die Anforderungen an das Business Reporting. Stellen Sie sich die folgende Frage: Wenn ich meine Finanzbuchhaltungsdaten vor der Migration/Konvertierung archiviere, werde ich in der Lage sein, meine Konten nach der Migration/Konvertierung abzustimmen?

Hier ist ein anschauliches Beispiel: Bei der TJC Group haben wir Fälle gesehen, in denen SAP-Kunden in ihrer alten Umgebung von einer kontenbasierten Lösung zu einer Ledger-basierten Lösung in ihrer S/4HANA-Umgebung wechseln. Das Problem entsteht, wenn der Kunde alle Belege für einen bestimmten Zeitraum anzeigen möchte, einschließlich der „alten Welt (ERP)“ und der „neuen Welt (sFin)“ vor und nach der Migration (einschließlich führender und nicht-führender/Erweiterungs-Ledger), und das Unternehmen zudem archivierte und Online-Posten innerhalb EINER Transaktion einbeziehen möchte. SAP bietet für solche Fälle keine Standardlösung an.

Für die meisten Unternehmen bedeutet dies, die SAP ECC-Daten in vier Gruppen zu unterteilen:

Datenentscheidung	Typischer Zweck
Nach S/4HANA migrieren	Unterstützung laufender Geschäftsprozesse, operativer Aktivitäten und des aktuellen Reportings.
Vor der Migration archivieren	Entfernen abgeschlossener oder selten genutzter Daten aus der Live-Datenbank bei gleichzeitiger Aufbewahrung für zukünftigen Zugriff, Compliance- oder Audit-Zwecke.
Außerhalb von S/4HANA aufbewahren	Bewahrung historischer Geschäftsinformationen nach der Stilllegung von SAP- oder Nicht-SAP-Altsystemen, während sie bei Bedarf zugänglich bleiben.
Daten löschen	Dauerhaftes Entfernen von Daten, die keinen gültigen geschäftlichen, rechtlichen, regulatorischen oder operativen Zweck mehr haben. Zum Beispiel veraltete Buchungskreise, Testdaten, Systemprotokolle oder Daten, deren Aufbewahrungsfrist überschritten ist.

Der endgültige Umfang sollte immer für die eigene SAP-Landschaft des Unternehmens definiert werden. Eine Greenfield-Implementierung, eine Brownfield-Konvertierung und eine Selective Data Transition bieten jeweils unterschiedliche Optionen und Einschränkungen dafür, was migriert, archiviert, gelöscht oder außerhalb des Kern-ERP aufbewahrt werden kann. Die richtige Entscheidung hängt auch von den Anforderungen an das Business Reporting, Compliance-Verpflichtungen, Systemabhängigkeiten, der Datenqualität und der Menge an historischen Informationen ab, die nach dem Go-Live verfügbar bleiben müssen.

Das frühzeitige Treffen dieser Entscheidungen kann ein schlankeres S/4HANA-System schaffen und gleichzeitig die historischen Informationen bewahren, die zukünftige Geschäfts-, Compliance-, Analyse- und KI-Anwendungsfälle erfordern könnten.

Warum die Migration aller ECC-Daten unnötige Komplexität schaffen kann

Die Migration von SAP ECC nach SAP S/4HANA ist mehr als ein technisches Upgrade. Sie ist eine Gelegenheit, das System zu vereinfachen und die langfristige Performance zu verbessern. Ein weit verbreiteter Irrglaube ist, dass jedes Datenelement aus dem ECC-System migriert werden muss. In der Realität erhöht die Migration aller historischen Daten oft Kosten, Komplexität und Projektrisiko, ohne einen signifikanten geschäftlichen Mehrwert zu bieten.

HANA-Speicherbedarf und damit verbundene Kosten

Das Datenvolumen beeinflusst den HANA-Speicher- und Speicherplatzbedarf, die Dauer von Systemkopien, Backup- und Wiederherstellungszeiten, die Disaster-Recovery-Planung, den Testaufwand, die Migrationslaufzeiten und die Kosten für die Wartung von Entwicklungs-, Qualitätssicherungs- und Produktionsumgebungen.

Der Finanzabschluss wird mühsam

Große Datenmengen können auch die Komplexität der täglichen Systemadministration erhöhen. Finanzberichte und Periodenabschlussaktivitäten müssen möglicherweise historische Datensätze aus Jahren verarbeiten, die für den aktuellen Geschäftsbetrieb nicht mehr relevant sind. Backups dauern länger, System-Refreshes benötigen mehr Zeit und Ressourcen, und zukünftige Upgrades müssen eine größere Datenbank verarbeiten.

Die Auswirkungen sind noch größer, wenn mehrere SAP ECC-Systeme in einer einzigen SAP S/4HANA-Umgebung konsolidiert werden. Beispielsweise können verschiedene Systeme Folgendes enthalten:

• Doppelte Kunden- und Lieferantenstammsätze
• Unterschiedliche Kontenpläne
• Inaktive Buchungskreise
• Historische Daten von erworbenen oder veräußerten Geschäftsbereichen
• Kundeneigene Tabellen und Objekte, die nicht mehr verwendet werden
• Altdatensätze mit unklarer geschäftlicher Zuständigkeit
• Daten, deren erforderliche Aufbewahrungsfrist überschritten ist

Das Verschieben all dieser Informationen schafft nicht automatisch ein vollständigeres oder nützlicheres S/4HANA-System. Es kann einfach bestehende Komplexität in eine teurere Umgebung übertragen.

Die BT Group erlebte die praktischen Auswirkungen hoher SAP-Datenvolumina während ihrer Transformation. Zu einem Zeitpunkt hatte ihr Datenvolumen 12,5 TB erreicht und beeinträchtigte die Systemperformance. Durch Datenarchivierung und Tiering wurde dies auf 8 TB reduziert, während der Übergang des Unternehmens von mehreren SAP ECC-Datenbanken zu SAP S/4HANA unterstützt wurde.

Die Carlsberg Group verfolgte ein langfristiges Programm zum Management des Datenvolumens, während sie mehrere ERP-Systeme konsolidierte und sich auf die Cloud-Migration vorbereitete. Ihr Programm reduzierte die Datenbankgröße um 62,5 % und führte laufende Kontrollen ein, um ein erneutes ungebremstes Wachstum zu verhindern.

Diese Beispiele verdeutlichen, warum die Datenvorbereitung vor der Migrationsausführung beginnen sollte. Die Archivierung sollte nicht als Aufräumaktion betrachtet werden, die am Ende eines S/4HANA-Programms hinzugefügt wird. Sie sollte Teil des Migrationsdesigns sein.

Wie entscheidet man, welche Daten nach S/4HANA migriert werden sollen?

Die Migration nach SAP S/4HANA bietet die Möglichkeit, vorhandene Daten zu überprüfen und festzustellen, ob sie den Geschäftsbetrieb weiterhin unterstützen. Anstatt alle Daten aus dem SAP ECC-System zu verschieben, sollten Unternehmen Informationen basierend auf ihrem Geschäftswert, ihren rechtlichen Verpflichtungen und ihren operativen Anforderungen klassifizieren.

Die folgenden Fragen können helfen, die Entscheidung zu leiten:

• Werden die Daten für laufende Geschäftsprozesse benötigt? Daten, die für den täglichen Betrieb, die Planung, das Reporting oder den Kundenservice benötigt werden, sollten normalerweise migriert werden.
• Werden die Daten noch aktiv genutzt? Häufig genutzte Transaktions- und Stammdaten gehören im Allgemeinen nach SAP S/4HANA, während selten genutzte historische Daten besser für die Archivierung geeignet sein können.
• Werden die Daten für rechtliche, regulatorische oder Audit-Zwecke benötigt? Wenn historische Informationen aufbewahrt werden müssen, aber operativ nicht mehr relevant sind, können sie oft archiviert oder in einer konformen Aufbewahrungslösung gespeichert werden, anstatt migriert zu werden.
• Unterstützen die Daten zukünftige geschäftliche Anforderungen? Überlegen Sie, ob die Informationen einen Mehrwert für Analysen, Trendanalysen oder zukünftige Geschäftsentscheidungen bieten.
• Sind die Daten korrekt und relevant? Veraltete, doppelte, inkonsistente oder qualitativ minderwertige Daten sollten vor der Migration bereinigt oder entfernt werden.
• Ist die Aufbewahrungsfrist der Daten überschritten? Informationen, die keinen geschäftlichen, rechtlichen oder regulatorischen Zweck mehr erfüllen, sollten gemäß den Unternehmensrichtlinien sicher gelöscht werden.

Ein praktischer Entscheidungsrahmen

Ein einfacher Ansatz besteht darin, Daten in vier Kategorien zu klassifizieren:

Datenkategorie	Empfohlene Maßnahme
Aktive operative Daten	Nach SAP S/4HANA migrieren
Historische Daten, die für rechtliche oder Audit-Zwecke benötigt werden	Archivieren und außerhalb der Live-Datenbank aufbewahren
Historische Daten, die gelegentlich benötigt werden könnten	Vor der Migration archivieren und bei Bedarf Zugriff gewähren
Veraltete, doppelte oder abgelaufene Daten	Nach entsprechenden Genehmigungen löschen

Das Ziel ist nicht, die maximale Datenmenge zu migrieren, sondern die richtigen Daten. Eine gut geplante Strategie zur Datenauswahl reduziert den Migrationsaufwand, senkt die Infrastruktur- und Wartungskosten, verbessert die Systemperformance und führt zu einer saubereren, besser verwaltbaren SAP S/4HANA-Landschaft.

Es gibt keine allgemeingültige Anzahl von Jahren für historische Daten, die jedes Unternehmen migrieren sollte. Der richtige Umfang hängt von der Migrationsmethode, den aktuellen Prozessen, den Reporting-Anforderungen, den regulatorischen Verpflichtungen, den Datenabhängigkeiten und der technischen Machbarkeit einer konsistenten Trennung der Datensätze ab.

Ein nützlicher Ausgangspunkt ist es, drei Fragen zu stellen:

• Werden die Daten benötigt, um einen aktiven Geschäftsprozess abzuschließen?
• Müssen sie für die häufige operative Nutzung direkt in S/4HANA verfügbar sein?
• Würde eine Aufbewahrung außerhalb des Live-ERP die geschäftlichen und Compliance-Anforderungen weiterhin erfüllen?

Diese Fragen sollten nicht als starre Vorlage angewendet werden. Die Antwort variiert je nach Migrationsansatz des Unternehmens. In einem Greenfield-Projekt hat das Unternehmen möglicherweise mehr Freiheit, Prozesse neu zu gestalten und nur ausgewählte Daten zu übernehmen. Bei einer Brownfield-Konvertierung bleiben möglicherweise mehr bestehende Strukturen und Abhängigkeiten bestehen. In einer Selective Data Transition kann das Unternehmen einen maßgeschneiderten Umfang nach Buchungskreis, Geschäftsjahr, Prozess oder Organisationseinheit definieren. Aus diesem Grund sollte der Migrationsumfang von den Stakeholdern aus Business, IT, Daten, Compliance und Audit vereinbart werden, bevor die Ausführung beginnt.

Für aktive Geschäftsprozesse erforderliche Daten

Offene und aktive Geschäftsdaten müssen in der Regel nach S/4HANA verschoben werden. Dazu können gehören:

• Offene Posten von Kunden und Lieferanten
• Aktive Einkaufs- und Verkaufsbelege
• Aktuelle Verträge
• Offene Fertigungsaufträge
• Aktive Projekte und Anlagen
• Nicht abgerechnete Finanzbelege
• Aktuelle Inventar- und Lagerbestände
• Laufende Service-, Garantie- oder Wartungsdatensätze

Die Auswahl muss Abhängigkeiten zwischen Objekten berücksichtigen. Ein offener Kundenauftrag kann beispielsweise von zugehörigen Kundenstammdaten, Preiskonditionen, Materialsätzen, Lieferungen, Fakturen und Buchhaltungsbelegen abhängen. Die Migration nur einiger Teile dieser Kette kann die Prozesskontinuität beeinträchtigen oder die Interpretation der Informationen erschweren.

Aus diesem Grund sollte der Migrationsumfang gemeinsam von den Geschäftsprozessverantwortlichen, Datenspezialisten, Compliance-Teams und dem Migrationsprogramm vereinbart werden. Er sollte nicht allein nach dem Alter der Datensätze entschieden werden.

Jüngere historische Daten, die für das Reporting benötigt werden

Einige abgeschlossene Transaktionen werden möglicherweise noch häufig für Vergleiche und das Reporting verwendet. Zum Beispiel:

• Finanzteams benötigen möglicherweise Vorjahreszahlen während des Abschlusses.
• Einkaufsteams vergleichen möglicherweise die aktuelle Lieferantenperformance mit jüngeren Zeiträumen.
• Vertriebsteams benötigen möglicherweise Zugriff auf die Bestellhistorie der Kunden, Retouren und Preistrends.

Dies bedeutet nicht, dass jede historische Transaktion in S/4HANA verbleiben muss. Die Entscheidungsträger sollten definieren, wie viel jüngere Historie innerhalb des Live-Systems für Vorjahresvergleiche, Finanzberichterstattung, operative Analysen, Kundenservice, Garantieansprüche, Planung und Prognose, regulatorisches Reporting und langfristige Projekte erforderlich ist.

Eine Selective Data Transition kann Geschäftsjahre, Organisationseinheiten oder eine Kombination aus beidem verwenden, um zu definieren, welche Datensätze verschoben werden. Der richtige Zeitraum sollte die tatsächliche Nutzung widerspiegeln und nicht die Annahme, dass mehr Historie immer besser ist.

Stamm- und Kundendaten, die noch vom Unternehmen genutzt werden

Relevante Stammdaten müssen mit den Prozessen verschoben werden, die von ihnen abhängen. Dazu können aktive Geschäftspartner, Kunden und Lieferanten, Materialien, Anlagen, Kosten- und Profitcenter, Werke und Lagerorte, Kontenpläne, Organisationsstrukturen und Klassifizierungsdaten gehören.

Die S/4HANA-Migration ist auch eine Gelegenheit, doppelte, unvollständige oder inaktive Stammsätze zu bereinigen. Die Datenqualitätsarbeit sollte feststellen, welche Version eines Datensatzes maßgeblich ist, ob er einen gültigen Eigentümer hat und ob er noch einen aktiven Prozess unterstützt. Das Übertragen doppelter Stammdaten nach S/4HANA kann das Reporting schwächen und Probleme für die zukünftige Automatisierung schaffen.

Kundeneigene Daten benötigen eine separate Bewertung. Eine kundeneigene Tabelle sollte nicht einfach migriert werden, weil sie in SAP ECC existiert. Das Unternehmen sollte bestätigen, dass der zugehörige Prozess, Bericht, die Schnittstelle oder Anwendung in S/4HANA fortgeführt wird. Wo kundeneigene Funktionen stillgelegt werden, sind deren Daten möglicherweise besser für die Archivierung oder Aufbewahrung außerhalb des Kernsystems geeignet.

Welche Daten vor der Migration archiviert werden sollten

Die SAP-Datenarchivierung entfernt berechtigte Informationen aus den Live-Datenbanktabellen und schreibt sie in Archivdateien, während der kontrollierte Zugriff erhalten bleibt. Sie kann das nach S/4HANA übertragene Volumen reduzieren, ohne aufbewahrte Informationen als wegwerfbar zu behandeln.

Die Datenarchivierung in SAP erfordert jedoch mehr als nur die Auswahl der ältesten Datensätze. Die Daten müssen die relevanten geschäftlichen und technischen Voraussetzungen erfüllen, einschließlich Abhängigkeiten von zugehörigen Objekten und offenen Prozessen.

Abgeschlossene Transaktionsdaten

Abgeschlossene Transaktionen, die für den täglichen Betrieb nicht mehr benötigt werden, sind oft gute Kandidaten für die Archivierung. Beispiele können sein:

• Ausgeglichene Finanzbelege
• Abgeschlossene Verkaufs- und Einkaufsbelege
• Abgeschlossene Fertigungsaufträge
• Historische Materialbelege
• Abgeschlossene Wartungsdatensätze
• Alte Anwendungsprotokolle und technische Daten
• Vollständig abgerechnete Projekte

Die Berechtigung hängt vom SAP-Archivierungsobjekt und den Regeln des Unternehmens ab. Ein Dokument kann nicht sicher archiviert werden, wenn es mit einem unvollständigen Prozess verbunden bleibt. Archivierungsbewertungen sollten daher offene Posten, Abhängigkeiten, Verweilzeiten und Zugriffsanforderungen identifizieren, bevor die Ausführung beginnt.

Daten von inaktiven Organisationseinheiten

Historische Daten können sich auf Buchungskreise, Werke, Verkaufsorganisationen oder Geschäftseinheiten beziehen, die nicht mehr aktiv sind. Dies kann nach Unternehmensumstrukturierungen, Fusionen und Übernahmen, Veräußerungen, Marktaustritten, Werkschließungen oder der Konsolidierung von Rechtseinheiten geschehen.

Wo die Daten weiterhin aufbewahrt werden müssen, kann eine Archivierung oder die Stilllegung von Altsystemen angemessener sein, als sie in die aktive S/4HANA-Umgebung zu verschieben. Die Bewertung muss auch die Eigentumsverhältnisse berücksichtigen. Historische Daten im Zusammenhang mit einem veräußerten Unternehmen können vertraglichen, rechtlichen oder regulatorischen Regeln unterliegen, die definieren, welches Unternehmen sie wie lange aufbewahren darf.

Daten, die für rechtliche oder steuerliche Zwecke aufbewahrt werden müssen

Informationen, die operativ nicht mehr benötigt werden, müssen möglicherweise dennoch aus steuerlichen, audit-bezogenen, produkthaftungsrechtlichen oder anderen regulatorischen Gründen aufbewahrt werden. Die Archivierung kann helfen, diese Daten von der Live-Transaktionslast zu trennen und gleichzeitig den Zugriff für autorisierte Benutzer aufrechtzuerhalten.

Aufbewahrungsfristen können je nach Land, Rechtseinheit, Dokumententyp, Geschäftsprozess, Branche und Aufsichtsbehörde variieren. Ein multinationales Unternehmen kann sich daher nicht auf eine einzige Aufbewahrungsfrist für seine gesamte SAP-Landschaft verlassen.

Das Datenmanagementprogramm der Carlsberg Group musste beispielsweise Steuer-, Audit- und DSGVO-Anforderungen in mehreren europäischen Gerichtsbarkeiten berücksichtigen. Das Programm kombinierte Datenarchivierung, Aufbewahrungsrichtlinien, Datensperrung und kontrollierte Datenvernichtung, anstatt die Reduzierung des Datenvolumens und Compliance als separate Projekte zu behandeln.

Welche Daten vor der Migration gelöscht werden können

Archivierung und Löschung dienen unterschiedlichen Zwecken. Archivierte Daten werden aufbewahrt und bleiben zugänglich. Gelöschte Daten werden dauerhaft vernichtet.

Eine Löschung sollte daher erst erfolgen, nachdem das Unternehmen die Entscheidung gegen gesetzliche Aufbewahrungsfristen, steuerliche und audit-bezogene Verpflichtungen, vertragliche Pflichten, aktive Legal Holds, Rechtsstreitigkeiten und operative Abhängigkeiten geprüft hat. Selbst wenn Daten veraltet erscheinen, sollte die Vernichtung nur fortgesetzt werden, wenn die relevanten Genehmigungen und Nachweisanforderungen geprüft und dokumentiert wurden.

Als Faustregel gilt, prüfen Sie, ob:

• Die erforderliche Aufbewahrungsfrist abgelaufen ist
• Kein Legal Hold vorliegt
• Die Informationen nicht für einen aktiven Prozess benötigt werden
• Die Daten keinen fortbestehenden steuerlichen, audit-bezogenen, vertraglichen oder regulatorischen Wert haben
• Der ursprüngliche Verarbeitungszweck nicht mehr gilt
• Abhängigkeiten mit anderen Datensätzen geklärt wurden
• Die Vernichtung autorisiert und dokumentiert ist

Daten, die zur Einhaltung des Datenschutzes gelöscht werden müssen

Datenschutzregeln können Unternehmen verpflichten, personenbezogene Daten zu entfernen, wenn kein rechtmäßiger Grund mehr für deren Aufbewahrung besteht. Informationen auf unbestimmte Zeit aufzubewahren, weil sie eines Tages nützlich sein könnten, ist keine vertretbare Datenmanagement-Richtlinie.

Gleichzeitig müssen Datenschutzverpflichtungen gegen gesetzliche Aufbewahrungs-, Prozess-, Steuer- und Audit-Anforderungen abgewogen werden. Personenbezogene Daten sollten nicht vernichtet werden, wenn eine andere gültige rechtliche Verpflichtung deren Verfügbarkeit erfordert. SAP Information Lifecycle Management kann dieses Gleichgewicht durch Aufbewahrungsregeln, Sperren, Legal Holds und kontrollierte Vernichtung unterstützen.

Weitere Informationen zu Datenschutzanforderungen in verschiedenen Ländern und Regionen finden Sie in der TJC Group Data Privacy Series.

Daten, die keinen gültigen Zweck mehr erfüllen

Veraltete, irrelevante und doppelte Datensätze können die Data Governance schwächen und die Menge an Informationen erhöhen, die geschützt, verwaltet und überprüft werden müssen. Typische Beispiele sind veraltete technische Daten, doppelte Stammsätze, Testdaten oder Informationen zu Organisationsstrukturen, die nicht mehr existieren.

Unternehmensausgliederung (Carve-out): Ein Unternehmen verkauft eine Tochtergesellschaft. Nach Ablauf der relevanten vertraglichen und gesetzlichen Aufbewahrungsfristen dienen einige Daten der ehemaligen Einheit möglicherweise keinem geschäftlichen Zweck mehr. Das Unternehmen sollte feststellen, welche Datensätze an den Käufer übertragen werden müssen, welche es behalten darf oder muss und welche schließlich vernichtet werden können.

Produkteinstellung: Ein Telekommunikationsunternehmen hat den Verkauf mehrerer Telefonmodelle eingestellt. Die zugehörigen Artikelnummern, Spezifikationen, Bestandsdatensätze und die Transaktionshistorie müssen möglicherweise noch für Garantien, Steuern, Produkthaftung oder das Reporting aufbewahrt werden. Sobald diese Anforderungen auslaufen, können Datensätze ohne verbleibenden Zweck zur Vernichtung freigegeben werden.

In beiden Szenarien reicht das Alter allein nicht aus. Das Unternehmen benötigt eine richtlinienbasierte Entscheidung, die durch geschäftliche Zuständigkeit, Aufbewahrungsregeln und dokumentierte Genehmigung gestützt wird.

Welche Daten außerhalb von S/4HANA zugänglich bleiben sollten

Nicht alle nützlichen historischen Daten müssen in der Live-S/4HANA-Datenbank liegen. Auf einige Informationen wird möglicherweise selten zugegriffen, sie haben aber dennoch einen erheblichen geschäftlichen oder rechtlichen Wert. Die Aufbewahrung außerhalb des Kern-ERP kann diesen Wert bewahren und gleichzeitig die Kosten für den Betrieb der vollständigen alten Umgebung vermeiden.

Historische Informationen, die für Audits und Reporting benötigt werden

Finanz-, Steuer-, interne Revisions- und Business-Teams benötigen möglicherweise Zugriff auf historische Rechnungen und Buchungen, ursprüngliche Finanzberichte, Belege, vergangene Transaktionen, Kunden- und Lieferantendatensätze, Daten von geschlossenen Rechtseinheiten, Informationen von erworbenen Unternehmen und Datensätze aus Nicht-SAP-Anwendungen.

Zugriffsanforderungen sollten definiert werden, bevor das Quellsystem abgeschaltet wird. Die aufbewahrten Informationen müssen verständlich bleiben. Ein roher Datenbankextrakt bietet einem Auditor oder Business-Anwender möglicherweise nicht genügend Kontext, um die Datensätze mehrere Jahre später zu interpretieren. Ein geeigneter Aufbewahrungsansatz sollte relevante Beziehungen, Berichte, Dokumente, Metadaten und die Rückverfolgbarkeit bewahren.

Daten, die einem Legal Hold unterliegen

Ein Legal Hold unterscheidet sich von einer gewöhnlichen Aufbewahrungsfrist. Eine Aufbewahrungsregel definiert, wie lange eine Datenkategorie normalerweise aufbewahrt werden sollte. Ein Legal Hold setzt die geplante Löschung oder Vernichtung von Informationen im Zusammenhang mit Rechtsstreitigkeiten, Untersuchungen, Audits oder anderen rechtlichen Angelegenheiten aus.

In SAP ILM kann ein Legal Hold verhindern, dass relevante Daten vernichtet werden, selbst wenn die normale Aufbewahrungsfrist abgelaufen ist. Er kann sowohl für Daten gelten, die sich noch in der Datenbank befinden, als auch für Informationen, die in einem ILM-Ablagesystem gespeichert sind. Das bedeutet, dass Legal Holds geprüft werden müssen, bevor ein Löschprogramm vor der Migration beginnt.

Der Prozess sollte festlegen, welche Angelegenheit den Hold erfordert, welche Datensätze und Datenobjekte betroffen sind, wer ihn autorisiert hat, wann er angewendet wurde, ob er sowohl archivierte als auch Live-Informationen abdeckt, wer den Hold aufheben kann und wie die Vernichtung nach Ende des Holds wieder aufgenommen wird. Ein Legal Hold sollte die relevanten Beweise bewahren, ohne zu einem Grund zu werden, nicht zusammenhängende Daten auf unbestimmte Zeit aufzubewahren.

Daten aus stillgelegten SAP- und Nicht-SAP-Systemen

Nach dem S/4HANA-Go-Live zahlen einige Unternehmen weiterhin für alte Systeme, weil Benutzer gelegentlich historische Informationen benötigen. Dies schafft eine zweite ERP-Landschaft, die weiterhin gehostet, gesichert, gepatcht, unterstützt und überwacht werden muss.

Die Stilllegung von Altsystemen (Legacy System Decommissioning) bietet eine weitere Option. Die erforderlichen Daten, Dokumente, Berichte und der Kontext können in eine kontrollierte Umgebung extrahiert werden. Die ursprüngliche Anwendung kann dann stillgelegt werden, während autorisierte Benutzer weiterhin Zugriff auf die benötigten Informationen haben. Dies ist besonders wichtig, wenn die breitere Landschaft mehrere SAP- und Nicht-SAP-Systeme umfasst.

Wie bessere Datenentscheidungen zukünftige KI-Anwendungsfälle unterstützen

Eine KI-bereite S/4HANA-Umgebung benötigt nicht jeden historischen Datensatz in der Live-Datenbank. Sie benötigt zuverlässige, gut kontrollierte, rückverfolgbare und zugängliche Daten, die einen definierten Geschäftszweck unterstützen können. Für viele zukünftige KI-Anwendungsfälle werden Datenqualität, Data Governance, Data Lineage und Kontext wichtiger sein als das verfügbare Gesamtdatenvolumen.

Datenbereitschaft (Data Readiness) betrifft die Qualität und Relevanz der in der aktiven Umgebung verwendeten Informationen. Die Archivierung abgeschlossener und inaktiver Datensätze kann unnötiges Volumen reduzieren und gleichzeitig den Fokus des Live-Datensatzes verbessern.

Datenverfügbarkeit (Data Availability) betrifft die Frage, ob nützliche historische Informationen bei Bedarf noch gefunden, verstanden und Analyse- oder KI-Plattformen zur Verfügung gestellt werden können.

Historische Daten können zukünftige Anwendungsfälle wie Lieferantenrisikoanalysen, Zahlungsvorhersagen, Kundenverhaltensanalysen, Bedarfsprognosen, Betrugserkennung, Anomalieerkennung und Wartungsplanung unterstützen. Die Aufbewahrung von mehr Historie macht ein System jedoch nicht automatisch KI-bereiter. Die Daten müssen verständlich, rückverfolgbar, kontrolliert und unter den richtigen Berechtigungen zugänglich bleiben. Andernfalls können große Mengen historischer Daten einfach Rauschen, Risiken und Komplexität hinzufügen.

Das Unternehmen muss weiterhin Aufbewahrungs- und Löschregeln, Datenschutzrollen, Benutzerberechtigungen, Datenmaskierung, zweckgebundenen Zugriff, Rückverfolgbarkeit, Qualitätsprüfungen und Legal Holds anwenden.

KI-Bereitschaft ist daher nicht nur eine Frage der Datenmenge. Sie hängt davon ab, ob das Unternehmen weiß, welche Daten es besitzt, warum sie aufbewahrt werden, woher sie kommen, wer darauf zugreifen kann und ob sie für den beabsichtigten Zweck zuverlässig genug sind.

Wie die TJC Group Datenbewertung, Archivierung und Zugriff auf Altsysteme unterstützt

Die TJC Group hilft Unternehmen bei der Entscheidung, was nach S/4HANA verschoben werden soll, was archiviert werden kann, was gelöscht werden sollte und was nach der Stilllegung von Altsystemen zugänglich bleiben muss.

Datenarchivierung und die Stilllegung von Altsystemen sind wichtige Bestandteile der S/4HANA-Vorbereitung, aber sie sind nicht das gesamte Transformationsprogramm. Unternehmen müssen sich auch mit Datenbereinigung, Harmonisierung, Stammdaten-Governance, Prozessneugestaltung und der Zuständigkeit für kritische Datenobjekte befassen. Die Datenarchivierung in SAP hilft, unnötiges Live-Datenvolumen zu reduzieren und den Zugriff auf abgeschlossene Datensätze zu bewahren, während Bereinigung und Governance sicherstellen, dass die nach S/4HANA verschobenen Daten korrekt, konsistent und fit für zukünftige Geschäfts- und KI-Anwendungsfälle sind.

Der Prozess beginnt mit einer Bewertung der bestehenden SAP-Landschaft. Dies kann Folgendes umfassen:

• Analyse der aktuellen Datenbankgröße
• Identifizierung großer und schnell wachsender Tabellen
• Prüfung offener Posten und Datenabhängigkeiten
• Schätzung des zukünftigen Datenwachstums
• Mapping geschäftlicher und regulatorischer Aufbewahrungsanforderungen
• Identifizierung inaktiver Organisationseinheiten
• Quantifizierung potenzieller Archivierungsmöglichkeiten
• Priorisierung von Quick Wins
• Planung eines laufenden Datenvolumen-Managements

In einem Projekt für einen globalen Anbieter von Lösungen für gewerbliche Reinigung, Hygiene und Infektionsprävention wurden in einer ersten Archivierungsphase 27,6 TB an Daten entfernt. Das Unternehmen ging dann von einer einmaligen Aufräumaktion zu einer laufenden automatisierten Archivierung über, um das zukünftige Wachstum unter Kontrolle zu halten.

Automatisierung der SAP-Datenarchivierung mit Archiving Sessions Cockpit

Das Archiving Sessions Cockpit (ASC) ist eine SAP-zertifizierte Software, die von der TJC Group entwickelt wurde, um SAP-Datenarchivierungs- und ILM-Prozesse zu automatisieren. Es unterstützt den kompletten Archivierungs-Workflow, einschließlich der Erstellung und Verwaltung von Archivierungsdateien, der Löschung aus Live-Tabellen, der Sitzungsüberwachung und der wiederkehrenden Ausführung. ASC ist in zwei Versionen erhältlich: ASC Standard und ASC für ILM.

ASC Standard für klassische Datenarchivierung

Diese Edition konzentriert sich auf die traditionelle SAP-Datenarchivierung und die Reduzierung des Datenvolumens. Sie hilft Unternehmen, wiederkehrende Archivierungsjobs zu automatisieren und die Kontrolle über das Datenbankwachstum vor und nach der S/4HANA-Migration zu behalten.

ASC für ILM für die Datenlöschung

Diese Edition kombiniert Archivierungsautomatisierung mit SAP ILM-Prozessen. Sie unterstützt das Retention Management und die kontrollierte Datenvernichtung im Einklang mit Richtlinien wie den DSGVO-Anforderungen.

Automatisierung ist unerlässlich, da die Vorteile eines ersten Archivierungsprojekts verschwinden können, wenn das Datenwachstum wieder ungebremst zugelassen wird. Eine regelmäßige Ausführung hilft, die während der Migrationsvorbereitung erreichte Datenbankreduzierung beizubehalten. Die Archivierungsautomatisierung sollte jedoch in eine umfassendere Datenmanagementstrategie eingebettet sein, die auch Datenqualität, Stammdaten-Governance, Aufbewahrungsrichtlinien und eine klare Zuständigkeit für das zukünftige Datenwachstum umfasst.

Zugriff auf Altdaten mit ELSA erhalten

Wo historische Informationen außerhalb von S/4HANA zugänglich bleiben müssen, unterstützt die Enterprise Legacy System Application (ELSA) der TJC Group die Stilllegung von SAP- und Nicht-SAP-Systemen. ELSA basiert auf der SAP Business Technology Platform und kann den Zugriff auf Altdaten, Dokumente, Berichte und Transaktionen bewahren, nachdem die ursprüngliche Anwendung stillgelegt wurde.

Sie unterstützt zudem Funktionen wie den zentralisierten Zugriff auf mehrere Altsysteme, Benutzer- und Sicherheitsmanagement, Rückverfolgbarkeit, Datenmaskierung, vordefinierte und kundeneigene Abfragen, Zugriff aus aktuellen Anwendungen sowie Datenschutz- und Compliance-Kontrollen.

Zusammen decken ASC und ELSA verschiedene Teile der Migrationsentscheidung ab. ASC hilft durch Archivierung und ILM-Automatisierung, eine schlanke, kontrollierte SAP-Umgebung aufrechtzuerhalten. ELSA hilft Unternehmen, Altsysteme stillzulegen und gleichzeitig den kontrollierten Zugriff auf die weiterhin wertvollen historischen Informationen zu bewahren.

Das Ergebnis ist kein leeres S/4HANA-System und auch keines, das Jahrzehnte unnötiger Daten mit sich führt. Es ist eine ERP-Umgebung, die die für den aktuellen Betrieb benötigten Informationen enthält, unterstützt durch eine kontrollierte historische Datenebene für Reporting, Compliance, Analysen und zukünftige KI-Anwendungsfälle.