Risiken statt Bonanza
Bei der Transformation auf SAP S/4 Hana kommt es darauf an, die vorhandenen Altdaten zusammen mit ihrem Kontext zu erhalten, um sie für aussagekräftige Analysen und Erkenntnisse zur Verfügung zu stellen. Das ist der Schatz, den die Unternehmen im Zuge ihrer digitalen Transformation heben und versilbern wollen. Doch genau dieser Kontext geht bei der Transformation verloren, weil die S/4-Welt andere Datenstrukturen verlangt als die Vorgängergeneration. Anstatt auf eine Bonanza hoffen zu dürfen, sehen sich die Unternehmen mit einem Verlustrisiko konfrontiert.
Hinzu kommt die Frage der Datenqualität. Viele verschiedene Datentöpfe mit unterschiedlichen Strukturen und zahllose redundante oder fehlerhafte Stammdatensätze zu ein und demselben Kunden und Lieferanten senken die Qualität der Daten, bis das Fundament digitaler Geschäftsmodelle und -prozesse bricht. Mit Katzengold lässt sich kein Geld verdienen.
Und dann ist da noch der Gesetzgeber. Diverse Aufbewahrungspflichten und -fristen verhindern, dass die Unternehmen Daten und ihre Strukturen ändern dürfen. Darüber hinaus verpflichtet insbesondere die europäische Datenschutzgrundverordnung (EU-DSGVO) und seit Kurzem auch das neue Schweizer Datenschutzgesetz die Unternehmen dazu, Informationen auf der Ebene des einzelnen Datensatzes löschen zu können. Diese Fähigkeit in den Altsystemen nachzurüsten ist aber entweder technisch nicht mehr möglich oder nur unter großem Aufwand zu realisieren. Zu den Risiken des Wert- und Qualitätsverlusts gesellt sich also noch die mangelnde Rechtssicherheit. Statt Gewinnsteigerung und Boni drohen Strafzahlungen und die persönliche Haftung der Vorstände und Geschäftsleitungen.
S/4-Transformation: Sieben goldene Regeln
Kein Wunder also, dass so viele SAP-Bestandskunden weiterhin mit der Transformation auf SAP S/4 zögern und ihre Altsysteme und -archive unter großem Aufwand weiterbetreiben, bis die Aufbewahrungsfristen der darin aufbewahrten Legacy-Informationen – teils erst nach Jahrzehnten – abgelaufen sind. Was können SAP-Bestandskunden also tun, um diesen Risiken zu entkommen und den Umstieg auf die neue Softwaregeneration aus Walldorf zu ihrem Vorteil zu nutzen? Die Antwort liegt in den sieben goldenen Regeln der S/4-Transformation:
1. Separieren statt migrieren
Die meisten Transformationsprojekte dauern nicht nur wegen der technischen Hürden länger als notwendig, sondern auch und vor allem wegen der Konflikte zwischen IT und Fachabteilungen. Letztere wollen nach der Transformation weiterhin auf sämtliche Altdaten zusammen mit deren Geschäftskontext zugreifen. Damit aus dieser Anforderung kein überbordendes und langwieriges Projekt wird, beharrt die IT darauf, nur wenige Jahrgänge zu transformieren.
Da das Geschäft in der Regel Vorrang vor der IT hat, setzen vielfach die Fachabteilungen ihre Interessen durch. Das führt dazu, dass die meisten Transformationsprojekte viel länger dauern als nötig – im Fall von großen und sehr großen Unternehmen fünf Jahre und länger anstatt weniger Monate.
Um dieses Problem erst gar nicht aufkommen zu lassen, sollten SAP-Bestandskunden die erste goldene Regel anwenden: separieren statt migrieren. Das bedeutet, den kompletten Altdatenbestand einschließlich der Daten aus ADK-Archiven und ihres Geschäftskontextes aus den Legacy-Systemen zu extrahieren und unverändert auf einer eigenen modernen Plattform aufzubewahren.
Das hat den entscheidenden Vorteil, dass sämtliche Daten unabhängig von den Altsystemen vorliegen, den Fachabteilungen also jederzeit zur Verfügung gestellt werden können. Das Risiko, den Geschäftskontext zu verlieren, ist damit beseitigt. Gleichzeitig kann die IT die Frage, welcher Teil der Legacy-Daten im Anschluss nach S/4 Hana übernommen und transformiert werden soll, autonom beantworten. So wird die S/4-Transformation zu einem technischen Projekt, das aber gleichzeitig die Wünsche der Fachabteilungen berücksichtigt.
2. Zugreifen statt transformieren
Durch die Trennung der Anwendungs- von der Datenebene können die Unternehmen rein auf Basis geschäftlicher Überlegungen bestimmen, welche Stammdaten sie überhaupt noch in S/4 benötigen und ob sie wirklich operative Daten transformieren wollen, die zum Beispiel älter als drei Monate sind. Das minimiert den Migrations- und Transformationsaufwand enorm, in der Regel um 50 Prozent und mehr.
Außerdem hält dieser Ansatz die Hana-Datenbank dauerhaft schlank. Denn der Vorgang, veraltete Bewegungsdaten generell auf der separaten Plattform auszulagern, lässt sich unbegrenzt wiederholen. Dass sich dadurch die Gesamtbetriebskosten der neuen S/4-Umgebung um 25 Prozent senken lassen, ist eine realistische Schätzung.
Hinzu kommt: Da sie unabhängig von SAP-Systemen ist, lassen sich auf einer separaten Plattform auch Altdaten von Non-SAP-Systemen aufbewahren. Das erlaubt nicht nur die Konsolidierung von heterogenen Systemen hin zu einer harmonisierten IT-Landschaft, sondern macht auch den Weg frei für weitere agile Geschäftsszenarien. Dazu zählen insbesondere die Übernahme und Integration von ererbten Datenbeständen und Systemlandschaften im Zuge von Übernahmen und Fusionen (Mergers and Acquisitions). Aber auch im umgekehrten Fall des Verkaufs eines Geschäftsbereichs oder einer Tochterfirma, sogenannter Carve-outs, spielen dieser Ansatz und die dafür benötigte separate Plattform ihre Trümpfe zum Vorteil der Unternehmen aus.
Aber der vielleicht alles entscheidende Vorteil besteht darin, dass eine solche separate Plattform die Möglichkeit bietet, die selektierten Stamm- und Bewegungsdaten verlustfrei und risikolos über den Application Layer zu transformieren und zu migrieren. Dadurch können SAP-Bestandskunden die von SAP dafür vorgesehenen Werkzeuge, namentlich das SAP Migration Cockpit, nutzen.
Im Endeffekt macht dieser Plattformansatz sogar aus jedem Brownfield- ein Greenfield-Projekt für einen Neustart mit einem optimal an die Herausforderungen der Zukunft angepassten S/4-System. Die Unternehmen konvertieren dabei in einem ersten Schritt sämtliche Einstellungen und Individualentwicklungen ihres bisherigen SAP-Systems in das neue S/4, jedoch ohne Stamm- und Bewegungsdaten. Dadurch können sie ihre Geschäftsobjekte, aber auch sämtliche Anpassungen bei den Konfigurationen und Individualentwicklungen im neuen System unabhängig von den Daten flexibel nach ihren Wünschen und Anforderungen für die Zukunft gestalten. Erst in einem zweiten Schritt befüllen sie diese „leere“, aber individuell angepasste Hülle, jedoch nur mit denjenigen Stamm- und Bewegungsdaten, die sie zuvor auf der Plattform selektiert haben. In der Regel lässt sich im Ergebnis die Zahl der Geschäftsobjekte halbieren und die Menge der benötigten Stammdaten um 80 Prozent senken, die der Bewegungsdaten sogar um 90 Prozent und mehr.
3. Vorsorgen statt nachbessern
Zwischen den Legacy-Daten, ihren Strukturen sowie den Systemen und Anwendungen, in denen sie entstanden sind, bestehen große Abhängigkeiten, die wie die Wände eines Silos praktisch undurchdringlich sind. Diese Wände bei der Transformation zu durchbrechen hat nur minimale Aussicht auf Erfolg. Überspielen SAP-Bestandskunden ihren kompletten Altdatenbestand hingegen zusammen mit dessen Geschäftskontext vor der Transformation auf eine separate Plattform, stellt sich das Problem der Abhängigkeiten gar nicht mehr.
Gleichzeitig erhält die IT die Möglichkeit, diejenigen Altdaten, die sie nach S/4 überspielen will, losgelöst von den Quellsystemen auf der separaten Plattform vor der Transformation zu bereinigen und dabei Dubletten und Fehler zu beseitigen. Darüber hinaus kann sie diese Datensätze mit solchen aus Drittquellen anreichern. Das ist insbesondere in Analytics-Szenarien von Bedeutung und gilt im Übrigen nicht nur für die Bewegungs-, sondern auch für sämtliche Stammdaten einschließlich der für die digitale Transformation so wichtigen Kunden-, Lieferanten- und Artikel- sowie Materialstämme.
4. Abschalten und sparen
Sind die Altdaten aus SAP- und Non-SAP-Systemen samt Geschäftskontext auf die separate Plattform überspielt, lassen sich die Legacy-Systeme, ob von SAP oder Drittanbietern, einschließlich der ADK-Archive nicht nur zurückbauen, sondern komplett stilllegen und entsorgen. Im Vergleich zum Weiterbetrieb sparen SAP-Bestandskunden dadurch in der Regel 80 Prozent und mehr an Betriebskosten.
5. Für (Rechts-)Sicherheit sorgen
Damit der Systemstilllegung nicht die gesetzlich vorgeschriebenen Aufbewahrungspflichten und -fristen im Wege stehen, muss eine solche Plattform die Legacy-Informationen im Originalzustand überspielen und revisionssicher aufbewahren. Gleichzeitig sollte diese revisionssichere Aufbewahrung der Informationen von Wirtschaftsprüfern zertifiziert sein. Darüber hinaus aber muss die Plattform in der Lage sein, die Löschverpflichtungen der EU-DSGVO und des Schweizer Datenschutzgesetzes sowie verschiedenster internationaler Datenschutzbestimmungen lückenlos zu erfüllen. Das sorgt für Rechtssicherheit auch ohne den Weiterbetrieb der Legacy-Systeme.
Zudem trägt die Datenübernahme auf eine separate und moderne Plattform zu mehr IT- und damit Datensicherheit bei, weil sich eine moderne Plattform im Gegensatz zu manchem Legacy-System auch in Zukunft patchen lässt.
6. Automatisieren, automatisieren, automatisieren
Angesichts der gewaltigen Datenmengen, mit denen insbesondere SAP-Bestandskunden aus dem Enterprise-Segment zu kämpfen haben, kommt es auf einen möglichst hohen Automatisierungsgrad an. Dies gilt insbesondere für den ersten Schritt, die Extraktion der Daten und ihres Geschäftskontextes über den Application Layer. Es muss möglich sein, auf Knopfdruck selbst Mengen zwischen 10, 100 und mehr Terabyte an Informationen in wenigen Stunden und Tagen statt Monaten oder gar Jahren völlig automatisiert aus Legacy-Systemen und ADK-Archiven herauszulösen und auf die Plattform zu überspielen.
Aber auch was die Anzeige der Legacy-Informationen in der SAP-S/4-Welt über SAP GUI oder Fiori betrifft, spielt Automatisierung eine wichtige Rolle. Hierfür braucht es das Verfahren des „Technical Structure Mapping“. Dabei werden die Altdaten on the fly transformiert, ohne die ursprüngliche Struktur der historischen Daten auf der Plattform selbst zu verändern. So lassen sich Daten zum Beispiel zu den SAP-ECC-Geschäftsobjekten „Kunde“ oder „Lieferant“ in S/4 über das Geschäftsobjekt „Partner“ darstellen, als ob sie in dieser Struktur erzeugt worden wären. Die Automatisierung von der Datenextraktion bis zur Anzeige in der neuen Umgebung stellt als „One Click Transformation“ den Wesenskern eines separaten Plattformansatzes zur selektiven Datentransformation über den Applica-tion Layer dar.
7. Transformation-as-a-Service nutzen
In allen Transformationsszenarien kommt es zu ähnlichen und wiederkehrenden Aufgaben. Dazu zählt etwa die Bestandsaufnahme der vorhandenen System- und Applikationslandschaft inklusive Releaseständen oder die Analyse, wie groß das Potenzial zur Reduktion des Altdatenbestands (die sogenannte Data Potential Reduction Analysis oder DPRA) ist und welche Daten genau (aber nicht mehr!) bei einem Carve-out übergeben werden müssen, wie auch die Definition der Filter- und Transformationsregeln.
Um diese Szenarien und die damit verbundenen Vorteile, Synergien und Vorarbeiten völlig risikolos durchspielen zu können, benötigen die Unternehmen eine Servicelösung, die das unabhängig von der Plattform selbst ermöglicht. Der Service arbeitet dabei mit Metadaten wie zum Beispiel Angaben zu Systemen, Anwendungen und Datenbanken, die für die S/4-Transformation oder den zum Verkauf anstehenden Geschäftsbereich relevant sind. Die Erkenntnisse, die diese SaaS-Lösung für Transformationsprojekte verschafft, liefern SAP-Bestandskunden eine realistische und verlässliche Entscheidungsgrundlage für ihre Transformationsprojekte.
Sowohl die Plattform als auch der Transformationsservice existieren bereits. JiVS IMP, die systemunabhängige Informationsmanagementplattform des Schweizer Anbieters Data Migration International, hat ihren Nutzen bereits in über 2000 Projekten weltweit unter Beweis gestellt. Die Plattform sorgt für eine saubere Trennung zwischen Daten- und Anwendungsebene und dadurch für die radikal beschleunigte Extraktion, Transformation und Migration von Altdaten über den Application Layer und die Standardwerkzeuge von SAP. Möglich macht das die Plattform durch die Unterstützung von mehr als 3000 Geschäftsobjekten aus SAP- und Non-SAP-Systemen unterschiedlichster Releasestände sowie ein Verfahren zur Turbo-Extraktion von Altdatenbeständen.
