S/4-Transformation: Daten sind das größte Risiko

Conversion-Deadline 2027/2030

Was lange verdrängt wurde, bahnt sich allmählich seinen Weg ins Bewusstsein der SAP-Verantwortlichen: die Frage, wie sich die teilweise massiven Bestände an Altdaten aus SAP-, aber auch aus Non-SAP-Systemen und ADK-Archiven schnell und rechtssicher nach SAP S/4 Hana migrieren und transformieren lassen.

Altdaten: Risiken statt Bonanza

Bei der Transformation auf SAP S/4 Hana kommt es darauf an, die vorhandenen Altdaten zusammen mit ihrem Kontext zu erhalten und für Analysen und Erkenntnisse zur Verfügung zu stellen. Dem stehen jedoch die Abhängigkeiten zwischen den Daten, ihren Strukturen und den Systemen und Anwendungen, in denen sie entstanden sind, im Weg, die wie die Wände eines Silos praktisch undurchdringlich sind.

Hinzu kommt die Frage der Datenqualität. Viele verschiedene Datentöpfe mit unterschiedlichen Strukturen, zahllose redundante und fehlerhafte Stammdatensätze zu ein und demselben Kunden oder Lieferanten senken die Qualität der Daten und machen damit das Fundament digitaler Geschäftsmodelle und -prozesse mehr als brüchig.

Und dann ist da noch der Gesetzgeber. Diverse Aufbewahrungspflichten und -fristen verhindern, dass die Unternehmen Daten und ihre Strukturen ändern dürfen. Genau das aber ist der Fall, wenn Altdaten in SAP S/4 Hana übernommen werden. Darüber hinaus verpflichtet insbesondere die europäische Datenschutz-Grundverordnung (EU-DSGVO) 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 Fragen des Datenwerts und der Datenqualität gesellt sich also noch die Frage nach der Rechtssicherheit.

All das führt dazu, dass SAP-Bestandskunden allzu oft viel zu viele Daten und dazu noch unzureichender Qualität nach SAP S/4 Hana migrieren – und dabei den Geschäftskontext verlieren. Auch deshalb betreiben sie ihre Altsysteme und -archive unter großem Aufwand weiter, bis die Aufbewahrungsfristen der darin aufbewahrten Legacy-Informationen – teils erst nach Jahrzehnten – abgelaufen sind.

Kein Wunder also, dass so viele SAP-Bestandskunden weiterhin mit der Transformation auf SAP S/4 Hana zögern. Und kein Wunder, 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.

Die sieben goldenen Regeln der S/4-Transformation

Lange diskutierten SAP-Bestandskunden und Experten, ob es geschickter sei, bei der S/4-Transformation sämtliche Altdaten und Geschäftsobjekte in die neue Welt zu konvertieren (klassischer Brownfield-Ansatz) oder darauf komplett zu verzichten und unbelastet auf der grünen Wiese (Greenfield) neu zu beginnen. Schon bald kristallisierte sich als in der Praxis anwendbarer Kompromiss der Ansatz der selektiven Datenübernahme und -transformation heraus, bei dem die Unternehmen neben den Stammdaten nur ausgewählte operative Daten transformieren und der im Markt in verschiedenen Farbschattierungen angeboten wird.

Doch auch dieser Kompromiss birgt große Risiken, wenn er auf Tabellenebene stattfindet. Denn auf dieser Ebene gleicht er einer riskanten Operation am offenen Herzen. Ganz zu schweigen davon, dass die Datenübernahme dabei nicht über die von SAP vorgesehenen Werkzeuge wie das Migration Cockpit erfolgen kann.

Was können SAP-Bestandskunden also tun? Sie sollten die sieben goldenen Regeln der S/4-Transformation beachten. Dann können sie die genannten Risiken eindämmen und sogar beseitigen.

1. Separieren statt migrieren

Die meisten Transformationsprojekte dauern nicht nur wegen der technischen Hürden länger als notwendig, sondern wegen der Konflikte zwischen IT und Fachabteilungen. Die Fachabteilungen 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. 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. Gleichzeitig kann die IT die Frage, welcher Teil der Legacy-Daten im Anschluss nach SAP 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. Auf Daten zugreifen, statt sie zu transformieren

Durch die Trennung der Anwendungs- von der Altdatenebene 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 Altdaten transformieren wollen, die z. B. älter als drei Monate sind. Das minimiert den Migrations- und Transformationsaufwand enorm, in der Regel um 50 Prozent und mehr. Zum Beispiel konnte die international tätige Bühler-Gruppe, führender Hersteller von Maschinen und Anlagen für die Lebensmittelindustrie und den Fahrzeugbau, mithilfe einer separaten Plattform ihren Datenbestand beim Umstieg auf die Hana-Datenbank und S/4 um zwei Drittel von 6 TB auf unter 2 TB reduzieren.

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-Hana-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 Systemlandschaft, 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 Mergers & 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 zusammen mit ihrem Geschäftskontext 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 Übrigen unterstützt die Plattform auch einen – angepassten – Brownfield-Ansatz. Die Unternehmen übernehmen dabei in einem ersten Schritt sämtliche Einstellungen und Individualentwicklungen ihres bisherigen SAP-Systems in das neue S/4, ohne jedoch die Stamm- und Bewegungsdaten zu konvertieren und einzuspielen. Der Clou dabei: Dadurch können sie sämtliche Anpassungen bei den Konfigurationen und Individualentwicklungen im neuen System unabhängig von den Daten flexibel nach ihren Wünschen und Anforderungen 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.

3. Bei der Datenqualität vorsorgen statt nachbessern

Das bei den Risiken erwähnte Problem der Abhängigkeiten während der Transformation zu lösen 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 Hana ü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 Drittherstellern, und ADK-Archive nicht nur zurückbauen, sondern komplett stilllegen und entsorgen – auch im Greenfield-Szenario einer S/4-Transformation eine lohnende Vorgehensweise: Im Vergleich zum Weiterbetrieb sparen SAP-Bestandskunden dadurch in der Regel 80 Prozent und mehr an Betriebskosten.

Genau das ist auch bei der bereits erwähnten Bühler-Gruppe der Fall. Das Unternehmen hat ab 2003 alle länderspezifischen ERP-Systeme, die meisten von SAP, auf einen einzigen zentralen SAP-
Mandanten konsolidiert und mithilfe eines separaten Plattformansatzes komplett stillgelegt. Seither hat die Bühler-Gruppe die Kosten für den SAP-Betrieb um 80 Prozent gesenkt.

5. Für (Rechts)Sicherheit sorgen

Damit der Systemstilllegung nicht die gesetzlich vorgeschriebenen Aufbewahrungspflichten und  -fristen im Weg stehen, muss eine solche Plattform die Legacy-Informationen unverändert überspielen und aufbewahren. Gleichzeitig sollte die 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 bis auf die Ebene einzelner Datensätze hinunter lückenlos zu erfüllen. Das sorgt für Rechtssicherheit auch ohne den Weiterbetrieb der Legacy-Systeme.

Die Datenübernahme auf eine separate und moderne Plattform trägt im Übrigen 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, was sich automatisieren lässt

Angesichts der gewaltigen Datenmengen, mit denen insbesondere SAP-Bestandskunden aus dem Enterprise-Segment zu kämpfen haben, kommt es entscheidend auf einen möglichst hohen Automatisierungsgrad an. Dies gilt insbesondere für den ersten Schritt, die Extraktion von Daten und ihres Geschäftskontextes. 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, auf die Plattform zu überspielen und dort rechtssicher bis zu deren Löschung aufzubewahren.

Aber auch was die Anzeige der Legacy-Informationen in der SAP-S/4-Hana-Welt über SAP GUI oder SAP 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 z. B. zu den SAP-ECC-Geschäftsobjekten „Kunde“ oder „Lieferant“ in S/4 Hana in der Struktur des Geschäftsobjekts „Partner“ darstellen, als ob sie in dieser Struktur erzeugt worden wären.

Dieser Automatisierungsgrad von der Datenextraktion bis zur Anzeige in der neuen Umgebung ist der Wesenskern des separaten Plattformansatzes zur selektiven Datentransformation über den Application Layer, der sich treffend als One-Click-Transformation bezeichnen lässt.

7. One-Click-Transformation as a Service nutzen

In allen Transformationsszenarien kommt es zu ähnlichen und wiederkehrenden Aufgaben. Dazu zählen 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, und 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 für die Datenextraktion, -analyse, -optimierung, -transformation und -aufbewahrung genutzten Plattform 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.

Versicherungspolice gegen Transformationsrisiken

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 zum Patent angemeldetes Verfahren zur Turbo-Extraktion von Altdatenbeständen.

Mithilfe von JiVS IMP konnte zum Beispiel die Hawle Armaturen AG, ein führendes Schweizer Produktions- und Handels-unternehmen in den Bereichen Wasser, Gas und Abwasser, ihr Projekt zur Datentransformation und -migration im Rahmen des Umstiegs auf SAP S/4 Hana innerhalb von nur drei Monaten erfolgreich durchführen.

Seit dem vergangenen Jahr stellt Data Migration International das als SaaS-Lösung bereitgestellte One-Click-Transformation-Cockpit seiner Plattform ergänzend zur Seite und macht damit die Vorbereitung von Transformationsprojekten zu einem Service. Übrigens ist auch die Plattform selbst als Cloud-Dienst verfügbar.

JiVS IMP und das One-Click-Transformation-Cockpit sind die Versicherungspolice gegen Datenrisiken. Als zentrales Element einer unternehmensweiten Data Fabric unterstützen sie Transformationsprojekte aller Art und ebnen den Weg zum datengesteuerten Unternehmen.