Sie müssen SAP-Daten archivieren? Das sind Ihre Optionen

In dieser Blogreihe geht es um das Ende. Aber um das Ende von Daten oder ganzen Systemen. Ich möchte Ihnen dabei helfen, ein würdiges und friedliches Ende für Ihre SAP®-Systeme und -Daten zu planen, anstatt ein eher grausames Ende mit Blut auf dem Boden des Serverraums und Menschen, die in Tränen ausbrechen (wir alle haben irgendwann in unserer IT-Karriere an solchen Projekten teilgenommen, hoffentlich ohne Blut).

5 Gründe, die für ein Display-only-System sprechen

1. Verkauf
2. Übernahme
3. Konsolidierung
4. Ausstieg aus SAP
5. Greenfield SAP

Warum müssen Sie Systeme oder Daten archiveren?

Beginnen wir mit der Frage, wann und wie die Notwendigkeit entsteht, Daten oder ganze System zu archivieren. Viele unterschiedliche Gründe sprechen dafür: Unter anderem wenn ein Unternehmen verkauft wurde und im Zuge dessen das gesamte System kopiert und an den Käufer übergeben wurde. Aufgrund finanzieller und gesetzlicher Anforderungen muss das verkaufende Unternehmen die Daten noch einige Jahre nach der Transaktion aufbewahren.

Es könnte sich um ein Unternehmen handeln, das übernommen wurde. Vielleicht war es ein SAP-System oder ein anderes ERP-System, das on-premise installiert war. Bei der Zusammenführung der Geschäftsprozesse wurde beschlossen, die Prozesse in den bestehenden Systemen der Käuferunternehmen neu zu implementieren, wobei jedoch nur die offenen Posten übernommen wurden. Alle historischen Transaktionen, die möglicherweise für die Einhaltung von Vorschriften oder als Referenz benötigt werden, werden in dem „stillgelegten“ System aufbewahrt.

Es könnte sogar eine Folge des Wechsels von SAP zu einer anderen Technologie sein. Während viele Unternehmen ihre SAP-Investitionen modernisieren, werden einige unweigerlich wegfallen und zu kleineren branchenspezifischen Anbietern wechseln. Oder es könnte sich um Unternehmen handeln, die auf S/4HANA umsteigen, sich aber für eine Neuimplementierung entschieden haben, anstatt ihr altes oder älteres SAP-System durch ein weiteres Upgrade zu schleifen.

Diese drei Beispiele führen uns zum gleichen Ziel – ein oder mehrere SAP-Systeme die den Zweck haben, einer viel kleineren Anzahl von Benutzern den Zugriff auf die Daten zu ermöglichen.

Zugriff auf die benötigten Daten

Auf den ersten Blick mag es lächerlich erscheinen, ein komplettes Goldstandard-ERP-System nur für eine begrenzte Anzahl von Benutzern zur reinen Datenanzeige in Betrieb zu halten. Sobald man sich jedoch mit der Extraktion der für die Einhaltung von Vorschriften und für künftige Abfragen erforderlichen Daten befasst, sieht man sich mit einem äußerst komplizierten und tiefen Datenmodell konfrontiert.

Ein typisches SAP-System hat über 30.000 Anwendungsdatentabellen. Ein einfacher Transaktionscode in SAP kann 50, 60, 70 oder mehr zugrunde liegende Tabellen berühren, wobei die Verknüpfungen zwischen diesen Tabellen nicht immer einfach sind. Zudem gibt es in vielen Fällen noch weitere Abhängigkeiten zu anderen Datentypen. Wenn ich mir einen Kundenauftrag ansehe, schaue ich mir dann die Lieferadresse des Kundenstamms an, oder wurde für diesen einen Auftrag eine spezielle, maßgeschneiderte Adresse hinzugefügt? Beides ist möglich.

Wenn ich diesen Kundenauftrag anzeige, muss ich möglicherweise mehrere Positionen integrieren, die sich in verschiedenen Tabellen befinden. Jede Position kann (oder auch nicht) auf Materialstämme verweisen, die in einem völlig anderen Datensatz gespeichert sind. Und wenn ich eine Abfrage zum Kundenauftrag durchführe, benötige ich möglicherweise auch die vorhergehenden oder nachfolgenden Dokumente: Lieferung, Vertrag, Rechnungsbeleg usw. Wenn der Benutzer also nicht damit zufrieden ist, eine CSV-Datei zu öffnen und nach dem Auftrag 40231100 zu suchen und dann eine weitere CSV-Datei zu öffnen, um die Positionen 10, 20 und 30 zu überprüfen, damit er sieht, dass das Material 801-110 an den Kunden A3000 mit der Adresse 34677 verkauft wurde, brauchen wir etwas wesentlich Entwickelteres.

Und es geht noch weiter. In den Anwendungsdatentabellen wird es Verweise auf Customizing-Werte geben. Reicht es aus, ob sich diese Daten auf das Werk 3000 beziehen, oder müssen wir aus einer Customizing-Tabelle wissen, wie die Beschreibung dieses Werks tatsächlich lautet? Oder die Daten können Felder enthalten, denen Wertebereiche zugewiesen sind. Der Benutzer muss vielleicht wissen, was 01, 02 und 03 tatsächlich bedeuten, nicht nur die Codes. Das Customizing in SAP umfasst weitere 50.000 Tabellen, aber welche davon werden von unserem System verwendet? Welche enthalten von SAP ausgelieferte Standarddaten, die wir nicht benötigen?

Viele Unternehmen beginnen mit der Untersuchung, wie sie die Daten einfach aus SAP herunterladen können, und sehen genug vom Datenmodell, um zu erkennen, dass die Maßnahme sinnlos ist. Dies wird häufig durch eine vereinfachte Sichtweise der Kosten für die Aufrechterhaltung des Computersystems beeinflusst, bei der die tatsächlichen Kosten für die Zukunft unterschätzt werden.

Pflege des nur Display-only-Systems

Der erste Schritt bei der Umstellung eines Systems auf Display-only ist die Beschränkung der Berechtigungen auf die Anzeige von Transaktionen. Alle Schnittstellen wurden bereits in das Transaktionssystem verlagert, doch ist es sinnvoll, auch die Kommunikationssysteme - ALE, IDoc, E-Mail usw. - zu überprüfen, um sicherzustellen, dass keine Nachrichten versehentlich verschickt werden. Was die Lizenzen angeht, so benötigen wir keine SAP-Unterstützung mehr für das System, es spielt also keine Rolle, ob diese abgelaufen ist. Gelegentlich müssen wir das System neu starten, um Patches für das Betriebssystem aufzuspielen, so dass hierfür ein geringer Bedarf an SAP-Basis-Kenntnissen bestehen könnte.

Dann kommen noch die Festplatten- und Rechenkosten hinzu, oder, um es ganz altmodisch auszudrücken, die Hardwarekosten. Wenn es sich um eine On-P23remise Lösung handelt, können die vorhandenen Server wahrscheinlich bis ans Ende ihrer Tage dieses Display-only-System bereitstellen. Das klingt doch gar nicht so schlecht, oder? Bleiben wir dabei, und alle sind zufrieden. Die Benutzer können auf die Daten zugreifen, wie sie wollen, und wir brauchen kein kompliziertes Projekt, um die Daten zu extrahieren.

Springen wir nun aber zwei oder drei Jahre in der Lebenszeit dieses Systems nach vorne, so ist dies geschehen:

• Die Hauptnutzer, die mit SAP gearbeitet haben, sind alle weg. Die Benutzer der Finanzabteilung sind nun mit der XXX-Lösung für die Abwicklung der Geschäfte vertraut und haben keine Ahnung (oder Lust zu lernen), wie man einen SAP-GUI-Transaktionscode ausführt und die archaisch aussehenden Bildschirme interpretiert (wer will schon PONG spielen?). Und die IT-Abteilung hat keine Ahnung, wie sie die SAP-GUI auf ihre Desktop-Rechner bringen soll.
• Der IT-Leiter verfolgt einen reinen Cloud-Ansatz, und der Serverraum wird im Rahmen einer Immobilientransaktion veräußert. Jemand muss dieses System in Azure/AWS/GCP bringen. Werden die Migrations- und Verwaltungstools dieser Cloud-Plattform mit diesem alten Betriebssystem funktionieren?

ODER:

• Das Rechenzentrum arbeitet jetzt mit vollständig virtualisierten Servern. Es ist uns gelungen, den Server „so wie er ist“ auf eine virtuelle Maschine zu migrieren, aber jetzt wird die Lösung, die alle virtuellen Maschinen verwaltet, aufgerüstet und kann Windows 2012 nicht mehr unterstützen. Wir müssen den SAP-Host-Server aktualisieren. Ah, aber die verwendete Datenbankversion unterstützt nur Windows 2012, also müssen wir die Datenbank aktualisieren. Aber dann müssen wir das SAP-System patchen, damit es mit neueren Betriebssystem- und Datenbankversionen funktioniert. Weiß noch jemand, wie man SAP patcht? Moment mal, wir haben die Wartung eingestellt, also können wir die Patches nicht herunterladen.

Plötzlich ist der Weg des geringsten Widerstands, der vor einigen Jahren noch gangbar war, heute wie ein Schlag gegen die Wand.

Systemteile aus dem Verkeher ziehen

Nehmen wir an, ein SAP-System mit HCM wird auf SuccessFactors Employee Central umgestellt. Werden die historischen Mitarbeiterdaten zu einem späteren Zeitpunkt aus dem System entfernt? Wird man fünf Jahre später, wenn ein externer Anbieter für ein neues Projekt Zugang zu einer Sandbox erhält, daran denken, dass die Mitarbeiterdaten ein halbes Jahrzehnt lang unverändert herumliegen? Ich weiß, dass sich mein Geburtsdatum und meine Sozialversicherungsnummer in den letzten fünf Jahren nicht geändert haben. Diese Daten sind heute genauso wertvoll wie an dem Tag, an dem die Geschäftsprozesse aus dem SAP-System ausgelagert wurden. Dies kann aber auch zu einer Herausforderung werden, da wir aus Gründen der Einhaltung von Vorschriften über historische Gehaltsdaten für diese Mitarbeiter verfügen müssen. Wo könnten wir sie also ablegen, wo sie für die wenigen, die sie brauchen, zugänglich sind, in einem sicheren, benutzerfreundlichen System, so dass wir sie aus einem System entfernen können, das von der Personalabteilung längst vergessen wurde?

Dies könnte auch für Kundendaten gelten, die in die SAP Cloud for Customer überführt wurden, sich aber noch im On-Premise-SAP-System befinden, da dieses in den digitalen Kern überführt wird.