SAP S/4HANA: Der intelligente Ansatz ist selektiv und schlank im Design

Wir sprechen schon seit langem über SAP® HANA® und dann über S/4HANA®.

Zuerst kam HANA im Jahr 2010...

Die HANA-Datenbank an sich war eine revolutionäre Neuerung, die bereits 2010 eingeführt wurde - ein ERP-Unternehmen erkannte die große Menge an Daten, die heute in ERP-Systemen vorhanden ist. SAP konzentrierte seine Investitionen zunächst auf eine Technologieplattform, die eine moderne ERP-Anwendungslandschaft unterstützen kann, die den wachsenden Anforderungen an eine schnellere Verarbeitung komplexer, zunehmend digitalisierter und vernetzter Unternehmen gerecht wird; Unternehmen, die heute Milliarden von Datenzeilen zu ihrer Steuerung verwenden.

Und so wurde die Entscheidung getroffen, und die HANA-Diskussion begann als eine technische Diskussion - eine Datenbankdiskussion - über fünf Jahre hinweg. Bis S/4HANA 2015 veröffentlicht wurde, war dies bereits in den Köpfen der Menschen verankert. Der Umstieg auf HANA (wie es damals bekannt war) konnte Ihnen viele Ressourcen- und Zeitüberschüsse ersparen und dem Unternehmen verbesserte Effizienz und Reaktionsfähigkeit verschaffen, einfach indem die Fähigkeiten der HANA-Datenbank genutzt wurden. Es war ein kostspieliges, leistungsstarkes System, daher wurde es nur dort übernommen, wo die Kosten durch Geschäftsvorteile ausgeglichen oder übertroffen wurden. Die Lizenzierung von S/4HANA war eine weitere Kostenquelle, und so wurde die Diskussion verwirrend: 

Führen wir neue Prozesse auf HANA aus? Müssen wir das, wenn es so schnell ist, dass unsere alten Prozesse in der Hälfte der Zeit funktionieren?

Mit der leistungsstarken, aber teuren Datenbank begann auch der zunehmende Trend, zu analysieren, wo die Daten gespeichert werden sollten. Welche Daten müssen in der Hochleistungsanwendung gespeichert werden, und welche müssen nur zu Analysezwecken herangezogen oder verwendet werden? Was kostet uns die Replikation dieser Daten in Test- und Entwicklungsumgebungen, wenn wir mit HANA arbeiten?

Heute, dreizehn Jahre später, arbeiten viele Kunden immer noch nicht mit HANA oder S/4HANA, sondern mit ORACLE, MySQL, DB2/6 und Sybase ASE-Datenbanken (die von SAP übernommene Zwischenlösung, die IQ und andere Technologien mit sich brachte).

Es gibt auch viele SAP-Kunden, die auf HANA und S/4HANA umgestiegen sind, aber es ist ein langsamer und signifikanter Wechsel - etwa 80 % der Kernkunden müssen noch umsteigen.

Zwei Dinge schienen viele zu beschäftigen:

• Erstens: Wenn man nicht die Anforderungen komplexer Unternehmen hatte, war der Wertzuwachs von HANA nicht ausreichend, um in das System zu investieren.

• Zweitens haben die Unternehmen inzwischen 20 bis 45 Jahre alte Daten in ERP-Systemen erfasst (30 Jahre ist 1994 her, und SAP wurde 1972 gegründet, so dass man manchmal Daten in Systemen findet, die bis in die 1970er Jahre zurückreichen), so dass man erkannte, dass man nicht alle diese Daten in einer HANA-Datenbank speichern musste. Dies war eindeutig ein Schritt, den man mit Zittern und sorgfältiger Planung angehen musste.

Wir hatten also eine große Debatte über Datenbanken und Vorteile, Technologie und Daten selbst in großem Maßstab, zusammensetzbare ERP und saubere Kerne. Neue Geschäftsprozesse waren möglich, aber nicht, weil SAP sie für Sie entwickeln würde, sondern weil sie Ihnen eine neue Plattform zur Verfügung stellen würden, um Ihre Geschäftsprozesse zu ermöglichen. Es war in erster Linie eine Überlegung der IT-Abteilung im Hinblick auf die Leistungsfähigkeit der ERP-Plattform hinter ECC.

... dann S/4HANA im Jahre 2015

Fünf Jahre nach der Veröffentlichung von HANA brachte SAP 2015 SAP S/4HANA auf den Markt, seine neue ERP-Plattform, die R/3 und NetWeaver vollständig ersetzen sollte. Nur dass es sich dabei - anders als bei der Umstellung von R/2 auf R/3 - nicht um ein komplett neues System handelt. Der ABAP-Code-Kern ist immer noch da, das Client/Server-Modell ist absolut noch da (wenn auch mehr mit der Cloud verbunden) und das Upgrade hat in erster Linie die zentralen Finanzoperationen verändert (und es ist bemerkenswert, dass CFIN auf ECC installiert werden konnte).

Während S/4HANA den Finanzkern umgestaltete, wurden die anderen Geschäftsbereiche, die schon immer integriert waren (Lieferanten und Beschaffung, Lieferkette, große Kundenbeziehungssysteme), in andere Technologien ausgelagert. SAP erwarb externe Unternehmen und prüfte, wo die HANA-Basis genutzt werden konnte. Die Technologie war jedoch nicht tief integriert, und so hatten Kunden, die SuccessFactors (das neue HCM, nur ohne Gehaltsabrechnung), C4C (das neue CRM, nur ohne HubSpot oder Salesforce), Ariba usw. erwarben, erhebliche Wachstumsschmerzen bei der Umstellung auf ein kompatibles Modell, das zwar alle unter die Lizenzstruktur eines Unternehmens fielen, aber nicht wirklich eine einzige Technologie darstellten - und schon gar nicht eine, die ausschließlich auf HANA basierte.

Die Botschaft war also verworren. Aber mit BTP, der Umstellung von S/4HANA auf eine Roadmap zur Bereinigung des Kerns (und der schrittweisen Umstellung auf ein DevOps-Cloud-Modell, das es mit den erworbenen Cloud-Funktionen und den Best-of-Breed-Wettbewerbern in Einklang bringen würde), bewegt sich SAP in die richtige Richtung, um das Beste aus der Technologie herauszuholen.

Der Regenbogen der "Feld"-Ansätze, die die Leute in Betracht ziehen, wenn sie auf S/4HANA umsteigen wollen, ist vielfältig in der Diskussion, aber meistens recht einfach. Ein grüner oder brauner Kern, und dann eine ausgewählte Prozesstransformation. Wie die meisten Leute jetzt nach einem langwierigen Branchendialog wissen, sind die beiden grundlegenden Routen in etwa so:

• Greenfield: Beginnen Sie mit einem brandneuen System und neuen Prozessen - keine historischen Daten, nur Stammdaten und Schlüsselinformationen, die für eine vollständige Neugestaltung Ihres ERP erforderlich sind. Mit anderen Worten: versuchen Sie einen radikalen Wandel.
• Brownfield: Behalten Sie Ihre Daten und historischen Daten - führen Sie langsam Veränderungen auf der neuen Plattform durch.

Und genau hier kommt unsere Nische bei EPI-USE ins Spiel. Oft wird davon ausgegangen, dass "Greenfield" keine historischen Daten bedeutet und "Brownfield" alle Ihre Daten. Das ist nicht richtig.

SAP spricht schon seit einiger Zeit von Selective Data Transitions (SDT) und Landscape Transformation (LT / SAP LT / SLO / SLT). Es ist durchaus möglich, Kunden in die Lage zu versetzen, die Bedenken bezüglich der Daten von dem allgemeinen Ansatz zur Einführung von S/4HANA zu trennen. Das bedeutet, dass jede Konvertierung selektiv sein kann, unabhängig von der Art der Umstellung auf S/4HANA. Das ist wichtig, denn es geht um die Maximierung der Kapitalrendite und um die effiziente Nutzung der Hochleistungsdatenbank, die seit 2010 für so viel Wirbel sorgt.

Wo  soll man also anfangen?

Es ist wichtig zu verstehen, dass jeder seine Geschäftsprozesse verbessern möchte, aber wenn Ihre ERP-Umgebung nicht sehr klein ist, ist es unwahrscheinlich, dass sich die Kosten für einen Neuanfang lohnen, da der Fokus auf alle Ihre Prozesse verteilt wird und nicht nur auf diejenigen, die Sie mit S/4HANA deutlich verbessern können. Während ein Brownfield - auch wenn es eine Reihe langsamerer selektiver Transformationen erfordert - immer noch einige wichtige Geschäftskonfigurationen und -prozesse ändern kann.

Meine Empfehlung wäre also, mit einem Pilotprojekt zu beginnen und die wichtigsten Prozesse zu testen (Daten können immer noch selektiv sein!) und nur dort, wo sie einen Mehrwert bringen, schrittweise zu Standardprozessen überzugehen.

Es kann auch ein guter Schritt sein, ein paralleles Pilotprojekt durchzuführen - eine kleine Teilmenge von Daten in ein grünes und ein brachliegendes Pilotsystem einzuspeisen. Schärfen Sie die Axt, bevor Sie versuchen, den Baum zu fällen!

Zusammenfassend:

(Natürlich sind meine Überlegungen zu diesem Thema von meinen eigenen Erfahrungen geprägt, und ich freue mich über Kommentare und Diskussionen).

Jedes Unternehmen, das von ECC auf SAP S/4HANA umsteigen möchte, sollte dies tun:

• einen selektiven Datenübertragungsansatz verfolgen, unabhängig von der Farbe des Feldes, auf dem sie ihr Lager aufschlagen wollen.

• einen sauberen Kern anstreben (ein bewundernswertes Ziel), sich aber darüber im Klaren sein, dass es immer noch Anpassungen geben wird (auf BTP und ähnlichen Plattformen), und wenn Ihr Unternehmen so komplex ist, dass es SAP einsetzen muss, dann wollen Sie wahrscheinlich nicht in einem Schritt zu einer reinen Greenfield-Einrichtung übergehen. Wenn in diesem Fall ein "Brownfield"-Ansatz immer noch selektiv und transformativ sein kann, aber geringere Kosten für die Umstellung mit sich bringt - warum dann nicht diesen Weg wählen? Solange Sie keinen eindeutigen geschäftlichen Nutzen aus dem grünen Ansatz ziehen können, wäre dies meine Empfehlung.

• parallele Betrachtung der braunen und grünen Piloten auf einer Teilmenge der (aktuellen) Kerndaten, um eine fundierte Entscheidung treffen zu können.

Vergessen Sie nie, dass jedes Projekt dieser Art (wie Cloud-Migrationen und Upgrades der alten Schule) eine einmalige Veränderung und eine einmalige Chance ist - wenn Sie kurzzeitig zwei parallele Landschaften haben - um Ihre Geschäftskonfiguration (Anpassung) im ERP neu zu gestalten und Ihre Daten von den Entwicklungssystemen in die Produktionssysteme umzuwandeln (und vielleicht sogar S/4HANA so aufzustellen, dass die nicht produktiven Systeme von nun an immer anonymisiert oder pseudonymisiert sind, um Ihre Daten zu schützen).

Wir sehen viele Unternehmen, die sich auf die Verbesserung von Geschäftsprozessen konzentrieren, dabei aber die Optimierung ihrer DevOps-Umgebung vergessen. Das Problem dabei ist, dass sie am Ende oft eine sehr hohe Plattformrechnung für ihre S/4HANA-Umgebung haben. Es ist durchaus üblich, die Daten auf diese Weise zu übersehen, vor allem, wenn man die gesamte Landschaft betrachtet (Dev, QA, Pre-Prod, Project Tracks, bis hin zur Produktion). Wenn Sie jedoch die gesamte Landschaft vor der Umstellung nicht sorgfältig planen, können Sie Jahre damit verbringen, sie nachträglich zu optimieren (und bis dahin die entsprechenden Rechnungen zu bezahlen).

Optimieren Sie Ihren Umstieg auf S/4HANA mit spezieller Software wie dem Data Sync Manager von EPI-USE, um eine 'Lean Secure' SAP-Umgebung sicherzustellen.

Ich habe das Paradigma des "Lean Secure SAP" schon seit einiger Zeit in die Diskussion gebracht. Es konzentriert sich auf Daten aus der Produktion und durch alle nicht produktiven DevOps-Systeme. Es passt immer noch, und ich empfehle jedem, der auf S/4HANA umsteigt, ein Datendesign für die gesamte Landschaft zu erstellen; das Ziel ist, mit schlanken Daten, schlanken Systemen und integriertem Datenschutz zu arbeiten.

Der saubere Kern und der Übergang zu Standardcode, Prozessen und einem besseren Geschäftsaufbau können Ihren Datenansatz beeinflussen, müssen ihn aber nicht bestimmen.

Wenn Sie sich sorgfältig vorbereiten - vor allem auf die Geschäftspartner und die Finanzabteilung - und Ihren Ansatz in Bezug auf Code, Prozesse und Daten sorgfältig planen, dann können Sie Ihre Kapitalrendite optimieren und Ihre Gesamtbetriebskosten in den nächsten fünf Jahren (durch diese gute Planung) möglicherweise so stark senken, dass Ihr Wert und Ihre Vorteile Ihre Investition in die S/4HANA-Plattform wirklich deutlich aufwiegen können. Die HANA- und S/4HANA-Technologie ist wirklich fantastisch. Sie brauchen zwar Fachwissen, um Ihre Lizenzkosten und Ihren Ansatz sorgfältig zu prüfen, aber Sie haben hier eine ERP-Plattform von Weltklasse, die über technische und funktionale Fähigkeiten verfügt, die Ihre Geschäftsabläufe verändern können.

Ich würde empfehlen, mit einem braunen, selektiven Ansatz zu beginnen und diesen zu erproben und auch die Einrichtung eines kleinen grünen Systems in Betracht zu ziehen, um den besten Ansatz für Ihr Unternehmen zu testen.

Dann würde ich einen Lean-Secure-SDT-Ansatz befürworten; das Green-to-Brownfield-Spektrum nur als einen Ansatz für Code und Prozesse zu betrachten. Eine gestrichelte Linie zu den Daten zu ziehen und zu fragen, wie es aussieht, wenn man nur das nimmt, was man braucht.

Vielleicht möchten Sie einfach alle Ihre Daten behalten, wenn Sie nur ein paar Jahre Geschichte und eine kleine Landschaft haben, aber ansonsten würde ich dafür plädieren, dass jeder von Natur aus selektiv ist und sich bewusst ist, wie er seine Daten während dieses Projekts verwaltet, für Prod- bis DevOps-, Test- und Projektsysteme.

Dieses Projekt könnte Ihre letzte Chance sein, Ihre Landschaft während einer großen Umstellung zu optimieren. Jetzt, da SAP einen regelmäßigeren Zeitplan für die Veröffentlichung von Cloud-Produkten mit einem sauberen Kernkonzept anstrebt, wird es jemals wieder eine größere Umstellung dieser Art geben? Wenn ja, dann wird es sehr lange dauern, bis sich eine solche Gelegenheit wieder bietet: Schärfen Sie also Ihre Äxte, bevor Sie sie schwingen!