Clean Core für S/4
Man kann im SAP-System natürlich Customizing betreiben und Eigenentwicklungen bauen. Ich muss Prozesse erweitern, http-Bodies einbauen, eigene Felder hinzufügen und für gewisse Abläufe eine eigene Logik implementieren. Aber ganz schnell komme ich in den Projekten an einen Punkt, wo Customizing in eine Sackgasse führt. Somit erscheint es mir ratsam, vor einem S/4-Projekt die Business Technology Platform (BTP) einzuführen. Beim Customizing entferne ich mich immer weiter vom SAP-Standard – und das ist nicht schlau. Alle diese Erweiterungen müssen schließlich irgendwie hinübergerettet werden, wenn ein neues Software-Upgrade, ein Release-Wechsel oder ein Umzug in ein neues System anstehen.
Bei jedem Update muss ich diese speziellen Erweiterungen einzeln anfassen, anpassen, besonders untersuchen, mehrfach testen und quasi umtexten. Ein Riesenaufwand. Mache ich das nicht, entstehen sofort Fehler, sogenannte „Defects“. Auch sollte man keine Elemente von SAP verwenden, die nicht freigegeben sind, da sich diese ebenso ändern können wie der Standard.
Clean Core heißt Lean Core
Die Antwort ist einfach: Keep your core clean. Halte deinen Kern sauber. Was versteht man eigentlich unter Clean Core? Clean Core ist ein wichtiger Ansatz in der Softwareentwicklung, der darauf abzielt, die Kernsysteme so sauber und ordentlich wie möglich zu halten. Dieser Ansatz legt den Fokus auf die Qualität und Wartbarkeit des Kernsystems, indem er sicherstellt, dass der Kernbereich gut strukturiert und leicht verständlich ist.
Clean Core bedeutet auch, dass der SAP-Kern wirklich frei ist von jeglichen harten Modifikationen. Von extremen individuellen Logiken und Body-Implementierungen und von ganz eigenen Z-Logiken. Denn: Im Betriebskonzept von S/4 Hana sind solche Erweiterungen einfach nicht mehr vorgesehen. Es passen auch keine Drittanbieter-Add-ons mehr, die man über eine Cloud-Software anbindet, denn die setzen einen gewissen Standard voraus, der ja von der SAP ausgeliefert worden ist.
Da kommen auf SAP-Bestandskunden, die mit einem „verschmutzten“ Core unterwegs sind, viele Probleme zu. Manuelle Kleinstarbeit wird erforderlich und damit eine immense zeitliche Verzögerung in Projekten. Und möglicherweise kann sogar eine Sicherheitslücke entstehen.
20 Jahre alte Erweiterungen
Wobei, Clean Core ist eigentlich nicht korrekt, der Kern war ja vorher nicht schmutzig, sondern man hat Abhängigkeiten geschaffen, die einen mit Blick nach vorn ausbremsen. Sprechen wir also von Lean Core. Schlanker Kern. Es ist also elementar wichtig, seine Upgrade-Prozesse zu vereinfachen, damit zu beschleunigen und insgesamt sicherer zu machen.
Schauen wir uns an, was vor S/4 war. Oft werden verschiedene ERP-Systeme zu einem One ERP konsolidiert. Diese Systeme stammen zum Teil aus Zukäufen, mitunter auch aus verschiedenen Ländern mit unterschiedlichen Guidelines für Eigenentwicklungen. Wenn ich das alles nun in ein neues S/4-System konsolidiere, wird es natürlich schwierig, den Überblick zu behalten und das Ganze wartungsfähig zu halten.
Dann wird es höchste Zeit, seine komplette Erweiterungsstrategie neu zu überdenken. Viele Erweiterungen laufen schon 15 oder 20 Jahre, aber niemand hat sie ordentlich dokumentiert. Die Urheber sind oft gar nicht mehr im Unternehmen. Zum Teil sind Dokus einfach verloren gegangen. Wenn ich aber die Logik hinter einer Berechnung im Finanzsystem nicht mehr habe, kann ich schnell in die Bredouille komme, wenn mal der Wirtschaftsprüfer kommt. Die Welt ist im Umbruch, der Markt verändert sich in immer kürzeren Zyklen, sodass die Global Player mit klassischen, statischen Erweiterungen aus der alten Zeit gar nicht mehr weiterkommen. Pandemien, Klimawandel, politische Verwerfungen, Engpässe in der Supply Chain, Inflation, Cyberangriffe, Energiekrise und das Streben nach Nachhaltigkeit − vielschichtige Herausforderungen, die gelöst werden müssen.
Die nächste Generation
Daneben gilt es, die digitale Transformation zu meistern. Neue Geschäftsmodelle sind zu integrieren. Neue digitale Assets müssen aufgebaut werden, die es den Unternehmen ermöglichen, Schritt zu halten mit wachsenden Kundenanforderungen. Von den IT-Abteilungen wird erwartet, die nächste Generation der Unternehmenslösungen (Next One) aufzubauen – mit der man agiler auf neue Rahmenbedingungen reagieren und schneller neue Technologien implementieren kann.
Für ebendiese Innovationen ist die SAP Business Technology Platform, BTP, ideal, weil sie eine Fülle an Möglichkeiten bietet und einfach sehr nah am SAP-Kern ist, daneben können Kunden theoretisch aber auch Microsoft-Azure nutzen. Ich sage meinen Kunden immer: Ihr habt auch ein API-Business-Hub, mit dem ihr immer aufs SAP-System zugreifen und nach Belieben Daten austauschen könnt. Diese SAP-Cloud-Integration ist eine Platform as a Service, die eine reibungslose Integration von On-prem- und cloudbasierten Anwendungen und Prozessen mit von SAP verwalteten Werkzeugen und vorkonfigurierten Inhalten ermöglicht.
Industriewissen, spezielles Prozess-Know-how, Branchenexpertise – im eigenen Coding steckt viel drin. Mit der Business Technology Platform kann ich mein Investment perfekt schützen. Es sind die Z-Erweiterungen, die man künftig auf der BTP vornehmen sollte. Unsere Botschaft: Ihr kennt die Abap-Welt (Advanced Business Application Programming), seit 1990 basieren alle SAP-R/3-Module auf dieser Sprache, aber jetzt habt ihr die einmalige Chance, einen technologischen Evolutionssprung im Bereich Entwicklung zu erleben.
Wir wollen euch daher auf den neuesten Stand bringen: Wie tickt SAP? Wie verhält sich ein S/4-System in puncto Erweiterungen? Was kann man mit der BTP eigentlich alles machen? Die neue SAP-Welt ist anders, also müssen sich auch die Kunden verändern. Mein Rat: Auch wenn du erst in zwei Jahren auf S/4 umsteigst, mache dich doch heute schon mal mit der BTP vertraut.
Oft entscheidet sich der Kunde dann, ein paar Lizenzen zu kaufen, um einen ersten Eindruck vom Look-and-feel der BTP zu bekommen. Er kann dann zum Beispiel einen Proof of Concept (PoC) starten und eine Standardtransaktion aus dem SAP ERP/ECC 6.0 oder eine klassische Z-Erweiterung über die Cloud-Plattform abbilden.
Komplexität nimmt zu
Man muss sich allerdings klarmachen: Die BTP ist zunächst nur eine leere Hülle. Bis ich dahin komme, eine Business-Applikation bereitzustellen, die ich wirklich produktiv einsetzen kann, eine Anwendung, die meinen Unternehmensstandards entspricht und einen Mehrwert schafft, das ist noch mal ein sehr langer Weg.
Das bedeutet: Wenn ich meine agilen Entwicklungen erst starte, wenn S/4 im Unternehmen schon live geht, ist das ziemlich spät. Vielleicht zu spät. Denn dann bin ich schon von vorneherein technologisch im Rückstand.
Ich erkläre es den Kunden oft so: Wir haben ein kleines Projekt im S/4-Programm – mit dem können wir auch schon früher anfangen. Dann sind wir gewappnet für die Anforderungen, die während des S/4-Projektes vom Business kommen und die wir agil umsetzen müssen. Die BTP ist ja kein kleines Gadget in einer Nische, es ist kein „Nice-to-have“, sondern eine leistungsfähige Maschine mit Unternehmensanwendungen, die möglichst schnell zum Laufen gebracht werden sollen. Und manchmal bildet sie vielleicht sogar Kernprozesse des Unternehmens ab.
Steampunk
Muss man in Zukunft Angst haben vor einem schier unübersichtlichen Mix an hybriden Techniken? Es gibt Abap-Erweiterungen, In-App-Anpassungen, Side-by-Side Extensions, dazu existieren On-prem- und Cloud-Lösungen nebeneinander und, und, und. Wir sehen Abap-Spezialisten und Cloud-Entwickler nebeneinander – und manchmal habe ich noch einen dritten Entwickler, der das UI (User Interface) entwickelt hat. Da nimmt die Komplexität rund um das ERP deutlich zu. Und die gilt es zu meistern. Es ist eben nicht mehr nur eine kleine Personengruppe, die das volle Spektrum an Programmiersprachen und Schnittstellen beherrscht, sondern es sind mehr Personen und Rollen beteiligt.
Ziel muss es sein, Zuständigkeiten besser zu organisieren, sodass ich künftige Updates absichern kann, ohne das Customizing im Kernsystem machen zu müssen.
Ich halte es für ratsam, dass man möglichst eng an der SAP-Guidance bleibt, dass man neue Technologien früh in seine Planung 2023 und 2024 mit einbezieht, auch, wenn das ein radikales Umdenken erfordert. Keine Angst, Abap-Entwickler werden weiterhin gebraucht, denn rund ein Drittel der Erweiterungen passiert erfahrungsgemäß weiterhin im Kern. Es gibt eben noch nicht für jede Anforderung die passende In-App oder Side-by-Side-Lösung.
Und wie fängt man an? Diese Frage kommt immer wieder. Vielleicht lesen Sie die SAP-Blogs zum Thema In-App-Erweiterung und Erweiterbarkeit über die BTP. Oder Sie schauen, was es bei Steampunk Neues gibt! Der Begriff steht für die Nutzung von Abap in der Cloud. Steampunk ist eine gute Möglichkeit, um unabhängig von der eigenen SAP-On-prem-Landschaft und den Releases innovative Applikationen zu bauen. Ich sage es mal so: Wer neugierig ist und sich frühzeitig einfindet ins Thema, der wird dann auch viel Spaß in den kommenden S/4-Projekten haben.
