Vorprojekte Adieu!
SAP-Bestandskunden haben nur noch vier Jahre Zeit, um ihre bisherige SAP-System- und -Applikationslandschaft ohne zusätzliche Wartungsgebühren auf die neue Generation S/4 zu transformieren. Und dennoch zögern sie. Ein zentraler Grund dafür ist – das zeigen Gespräche mit SAP-Nutzern immer wieder – gar nicht nur die Transformation selbst, sondern der befürchtete Zusatzaufwand durch vorbereitende Projekte. Dazu zählen insbesondere:
Archivierung: Viele SAP-Bestandskunden sitzen auf Bergen von Altdaten. Da die Hana-Datenbank im immer noch teuren Arbeitsspeicher läuft, wollen sie den Datenbestand vor der Transformation möglichst stark senken.
New GL: Viele Unternehmen meinen, Zeit zu sparen, wenn sie zuerst das neue General Ledger (GL) einführen. Schließlich gibt es das neue SAP-Hauptbuch schon seit ECC 6.0. Andererseits ist es ein Muss in der S/4-Welt.
Hana: Wieder andere implementieren SAP Hana, bevor sie sich den Anwendungen widmen. Sie erhoffen sich durch die Aufspaltung der Transformation in ein Daten- und ein Anwendungsprojekt ein weniger komplexes Gesamtprojekt, machen sich jedoch keine Illusionen darüber, dass es sich hier um ein rein technisches Projekt handelt, das für sich genommen wenig oder keinen geschäftlichen Nutzen hat.
Neues Geschäftsobjekt, GP: Die Hana-Datenbank erfordert generell eine andere Datenstruktur. Hinzu kommt: Das neue Business-Objekt (BO) Geschäftspartner (GP) vereinigt die bisherigen BOs Kunde und Lieferant. Viele SAP-Bestandskunden halten es deshalb für notwendig, die Struktur ihrer bisherigen Kunden- und Lieferantendaten schon vor ihrer Migration an GP anzupassen.
Datenbereinigung: Viele SAP-Bestandskunden wollen völlig zu Recht die Transformation nutzen, um ihren Datenbestand von Fehlern und Dubletten zu bereinigen. Schließlich ist der Umstieg auf S/4 ein zentraler Bestandteil ihrer Zukunftsstrategie, für die gilt: Ohne Datenqualität keine Digitalisierung.
Blinder Fleck: Altdaten
Nur um einem Missverständnis vorzubeugen: Die Überlegungen, die den jeweiligen Vorprojekten zugrunde liegen, sind völlig gerechtfertigt. Und doch vermögen sie ein zentrales Problem nicht zu lösen: das, was nach der abgeschlossenen Transformation mit den Legacy-Daten und -Systemen geschehen soll. Das ist der blinde Fleck, der nicht zuletzt deshalb viel zu selten wahrgenommen wird, weil die Projektteams, die mit der Transformation betraut sind, sich nicht dafür interessieren (müssen).
Es scheint fast so, als hätten sich viele SAP-Bestandskunden damit abgefunden, ihre Altsysteme nach dem Umstieg auf die S/4-Welt weiter zu betreiben und ihre Altdaten, deren Struktur aus gesetzlichen Gründen teilweise für Jahrzehnte nicht verändert werden darf, in Archiven zu lagern. Letzteres bedeutet aber, dass auch die Legacy-Systeme so lange weiterlaufen müssen, weil sich die archivierten Daten nur mit ihnen aufrufen und anzeigen lassen.
Abgesehen von dem langfristigen Mehraufwand birgt diese Vorgehensweise erhebliche Risiken hinsichtlich IT- und Rechtssicherheit. Die weiterlaufenden Altsysteme fallen in der Regel aus der Wartung, wichtige Sicherheits-Patches werden nicht mehr eingespielt und Cyberkriminelle freuen sich. Hinzu kommen ständig neue Anforderungen vom Gesetzgeber.
Vorschriften der europäischen Datenschutz-Grundverordnung oder des neuen Schweizer Datenschutzgesetzes wie zum Beispiel die Möglichkeit, gezielt auf der Ebene des einzelnen Datensatzes zu löschen, lassen sich in zahlreichen Altsystemen gar nicht mehr oder nur unter viel Aufwand implementieren.
Außerdem ist in diesem Szenario SAP-Nutzern der unmittelbare Zugriff auf Legacy-Daten weitgehend oder ganz verwehrt. Das stellt ein nicht zu vernachlässigendes Risiko für die Produktivität und Qualitätssicherung in den Unternehmen dar. Aus diesem Grund aber sämtliche Altdaten zu transformieren und nach S/4 zu migrieren, ergibt wirtschaftlich keinen Sinn.
Transformation ohne Legacy
Allen Vorprojekten gemeinsam sind der große blinde Fleck und die damit verbundenen wirtschaftlichen, sicherheitsrelevanten und rechtlichen Risiken. SAP-Bestandskunden sollten deshalb darüber nachdenken, einen radikal neuen Ansatz zu wählen, der nicht nur die Probleme löst, sondern auch die vermeintlich notwendigen Projekte überflüssig macht und deren Risiken beseitigt.
Dieser Ansatz besteht darin, den kompletten Lebenszyklus von Legacy-Daten bis zu ihrer endgültigen und rechtssicheren Löschung separat, das heißt losgelöst von den Altsystemen und -applikationen, zu managen und mit dem Lebenszyklusmanagement der Ziel-Anwendungen und -Systeme einer S/4-Hana-Landschaft zu synchronisieren.
Nötig ist dafür eine Plattform, auf der sich sämtliche Altdaten von SAP- und Non-SAP-Systemen rechtssicher aufbewahren und löschen lassen, die aber gleichzeitig alle Möglichkeiten zur Weiterbearbeitung dieser Daten wie ihre Reduktion, Selektion, Optimierung und Transformation über das Migration Cockpit und den Application Layer bietet. Diese Plattform ist mit S/4 integriert, um Legacy-Daten on the fly und automatisch an die neuen Datenstrukturen wie zum Beispiel die des Business-Objekts GP anzupassen und in SAP Fiori anzuzeigen. Dies geschieht, als ob sie in S/4 erzeugt worden wären. Möglich wird diese Funktionalität, weil sämtliche Metadaten zur abzulösenden SAP- und Non-SAP-Landschaft auf Knopfdruck in einem Transformations-Cockpit erfasst und gespeichert werden.
Zusätzlich wird jeder Projektschritt dokumentiert und die Plattform weiß, welches Altsystem die Unternehmen stilllegen und entsorgen können. Auf Knopfdruck und im Turbo-Verfahren lassen sich sämtliche Legacy-Daten aus den ADK-Archiven über den Application Layer extrahieren und damit ihre Information zum Lebenszyklus von Daten und Systemen für andere Lösungen im Bereich Application Lifecycle Management (ALM) bereitstellen.
Eine Plattform für alles
Keine Vorprojekte, kein Legacy-Problem und kein Tool-Wirrwarr muss der SAP-Bestandskunde fürchten. Eine solche Plattform versetzt SAP-Bestandskunden in die Lage, gleich drei Fliegen mit einer Klappe zu schlagen: Erstens analysiert und managt die Plattform den kompletten Lebenszyklus sämtlicher Legacy-Daten und bietet, zweitens, alle erforderlichen Funktionalitäten für die rechtssichere Aufbewahrung und Analyse sowie selektive Transformation und Migration dieser Daten und löst, drittens, das Problem der Altanwendungen und -systeme bei der Transformation ein für alle Mal und macht aus jedem Brownfield- ein Greenfield-Projekt.
Der SAP-Bestandskunde ersetzt nicht den Readiness-Check der SAP, der sich auf Prozesse und Standards bezieht, sondern ergänzt ihn als Kern einer unternehmensweiten und intelligenten Data Fabric. Dadurch beseitigt die DMI-Lösung als „eine Plattform für alles“ die Komplexität des ansonsten für die Datenebene typischen Tool-Wirrwarrs. Die Plattform, die den blinden Fleck der S/4-Transformation auf Knopfdruck ausleuchten und die Vorprojekte auf dem Weg dorthin überflüssig machen kann, hat einen Namen: JiVS IMP.
2 Kommentare
Markus Brasch
Ich finde die Überschrift wirklich irreführend. Im Schwerpunkt geht es in Ihrem Text um Datenmigration und Verfügbarkeit von Altdaten im Kontext der S/4-Migration. “Vorprojekt” hat für mich aber eine ganz andere Bedeutung und spielt sich nicht nur auf der Datenebene statt, sondern bezieht die Geschäftsprozesse mit ein. Vorprojekte, die aufgrund der Ergebnisse des Readiness Checks analysieren, wie der Impact auf der Prozeßebene ist, haben nach wie vor ihre Berechtigung. “Adieu Vorprojekte” ist daher als Statement unseriös.
E3 Magazin
Hallo! Inhaltlich haben Sie großteils recht. Wir haben auch im E3-Printmagazin einen anderen Titel gewählt: Conversion right now. Naturgemäß auch journalistisch, aber wir wollen den Leser darauf hinweisen, dass eventuell manche Vorprojekte ein wenig zu groß geraten. Ich haben einen Vortrag bei einem SAP-Arbeitskreis in Zürich von Schweizer CIOs gehört, wo auch dieses Thema angesprochen wurde. Kurzes Resümee aus der Schweiz: Weniger Organisation, dafür mehr Interaktion und mehr Kommunikation. Die Diskussion geht weiter …