Wie wir wissen, wird SAP erst dann zufrieden sein, wenn jeder ihrer Kunden zu S/4HANA migriert ist – vorzugsweise in die Cloud. Die PR-Abteilungen betonen stets, dass S/4HANA schneller angenommen wird als jedes andere SAP-Produkt in der Geschichte des Unternehmens. Das mag zutreffen, doch das offensichtliche Problem ist, dass auf Veranstaltungen (wie der TECHED) bei der Frage, welche Organisation welche SAP-Version nutzt, oft schockiert und enttäuscht festgestellt wird, wie viele Unternehmen noch auf älteren Releases unterwegs sind. Einige nutzen sogar noch die Version 4.6C.
Wenn S/4HANA so überzeugend ist, warum haben nicht alle anderen Projekte fallengelassen, um es wie heiße Semmeln zu adoptieren? In diesem Blogbeitrag werde ich versuchen, so objektiv wie möglich die Vor- und Nachteile eines Wechsels zu S/4HANA aufzulisten. Ich habe seit über sechs Monaten keinen Blogbeitrag mehr geschrieben, da ich an der dritten Auflage meines ABAP-Buchs gearbeitet habe, das im ersten Quartal 2019 erscheint. Mehr kann ich dazu nicht sagen, um die Regeln der SAP Community nicht zu verletzen. Ich werde versuchen, strukturiert vorzugehen, aber wahrscheinlich wird es eher ein “Gedankenstrom”, bei dem ich einfach niederschreibe, was mir spontan in den Sinn kommt. Ich werde auch einige Experten aus der SAP-Technologie einladen, um verschiedene Bereiche der Verwirrung aufzuklären.
Die Entwicklung von SAP: Von jährlichen Upgrades zu Enhancement Packs
„The Way We Were“ – Ein Blick zurück mit Barbara Streisand
Hallo, hier ist Barbara Streisand. Wie Sie alle wissen, gab es lange Zeit fast jedes Jahr eine neue Version von SAP, und die meisten Unternehmen nutzten eine bestimmte Version etwa fünf oder sechs Jahre lang, bevor sie auf eine neue Version aktualisierten. Ich bin verliebt in dieses Konzept, denn damals wurden bei einem Upgrade alle neuen Funktionen automatisch aktiviert. Doch dann entschied SAP eines Tages, dass – obwohl ich „Don’t Rain on My Parade“ sang – sie genau das taten und keine neuen Versionen mehr veröffentlichten. Stattdessen schickten sie die Clowns, die sagten: „Keine neuen Versionen mehr (genug ist genug)“ und führten das Konzept der „Enhancement Packs“ ein.
„You Don’t Turn Me On“ – Die Herausforderungen der Enhancement Packs
Mit Enhancement Packs (EHPs) wurden neue Funktionen nicht mehr automatisch aktiviert. Stattdessen musste man manuell auswählen, welche Funktionen man wollte. Die ABAP-spezifischen Dinge wurden sofort aktiviert, da alles andere davon abhing. Man könnte also argumentieren, dass die Installation von Enhancement Packs ABAP-Entwicklern mehr nützte als den Fachabteilungen (und dem Unternehmen!), da sie mit jeder EHP-Installation einen sofortigen Nutzen erhielten. Es könnte auch argumentiert werden, dass ABAP-Entwickler dem Unternehmen insgesamt helfen, sodass die Installation eines EHP sowohl für einen „Build“-Ansatz als auch für einen „Buy“-Ansatz (wenn man die neuen Funktionen aktivierte) von Vorteil war.
Beachten Sie, dass das Hinzufügen eines EHP keine „Upgrade“ im herkömmlichen Sinne sein sollte, aber in Wirklichkeit war der Aufwand zu 100 % derselbe wie bei früheren Upgrades, da man immer noch alles testen musste. Der technische Teil eines Upgrades war nie der schwierigste; es war das Regressionstesting. Zudem zeigte meine Erfahrung, dass man am Ende ein technisches Upgrade durchführte (d.h. nichts Neues aktivierte) und somit genauso viel testen musste wie bei einem altmodischen Upgrade, aber ohne neue Funktionen zu erhalten!
Es war schon schwierig genug, Unternehmen dazu zu bringen, neue Funktionen zu nutzen, wenn diese standardmäßig aktiviert waren, geschweige denn, wenn sie inaktiv sind und manuell eingeschaltet werden müssen. Darüber hinaus führt die Situation „Lasst uns ein technisches Upgrade machen, die neuen Sachen schalten wir später ein“ oft dazu, dass „später“ nie eintritt. Der Grund dafür ist, dass das Einschalten einer Funktion buchstäblich alles im System beeinflussen könnte (es sollte nicht so sein, aber in der Realität konnte es das), sodass man jedes Mal umfangreiche Tests durchführen musste und niemand dieses Risiko eingehen wollte. Man könnte argumentieren, dass es einfacher gewesen wäre, alles standardmäßig aktiviert zu lassen wie zuvor, da dies den Testaufwand nicht wirklich reduziert hätte, und im unwahrscheinlichen Fall, dass man später etwas Neues nutzen wollte, wäre das Risiko viel geringer gewesen. Es ist wichtig, auch die Auswirkungen auf die Software-Sicherheit zu bedenken; oft können neue Funktionen oder Patches in EHPs auch Sicherheitslücken schließen, was durch das manuelle Aktivieren verzögert werden könnte. Um solche Downloads und Aktualisierungen effizient zu verwalten, kann Software wie ein rar linux download nützlich sein, um große Dateipakete zu handhaben.
„Being a Dinosaur“ – Der unvermeidliche Wandel mit Tyrannosaurus Rex
Grrr! Hier ist Tyrannosaurus Rex. In unserer Organisation nutzen wir gerne alle neuesten Funktionen jeder neuen SAP-Version, daher haben wir die optionalen Business Functions bei Bedarf aktiviert. Das hat wirklich gut funktioniert. Moment, ich muss nur schnell einen Triceratops fressen. Mampf mampf! Lecker, das war toll. Wie auch immer, erst letztes Jahr haben wir auf EHP8 aktualisiert und angefangen, alles zu aktivieren, was uns in den Weg kam. Das Problem ist, dass EHP8 im Januar 2016 veröffentlicht wurde und somit bald drei Jahre alt sein wird. Man spricht hier von einem Dinosaurier! Drei Jahre in der IT sind wie eine ganze geologische Epoche. Oh, schau mal – da kommt noch ein Tyrannosaurus Rex – ich glaube, den fresse ich auch!
Sie werden niemals jemanden, der für SAP arbeitet, laut sagen hören, aber EHP8 ist so gut wie garantiert das letzte EHP für ECC 6.0. Wenn Sie also warten, bis ECC 6.0 im Jahr 2025 das Ende seines Lebenszyklus erreicht, werden Sie zehn Jahre im Rückstand sein (vorausgesetzt, Sie nutzen tatsächlich die neuen Funktionen, für die Sie so viel Wartungsgeld bezahlen). Um dies in einen Kontext zu setzen: Vor zehn Jahren hatte ich noch nie von Skype gehört, und die Idee, über Ihr Telefon einen Videoanruf zu tätigen, war Science-Fiction.
Wenn Sie, wie der TREX oben, erst 2018 ein Upgrade auf EHP8 durchgeführt haben, mag es Ihnen verziehen werden, wenn Sie im nächsten Jahr kein weiteres Upgrade durchführen möchten. Historisch gesehen war es oft ziemlich schwierig, den Business Case für ein Upgrade alle fünf oder sechs Jahre oder überhaupt zu rechtfertigen. Dies ist natürlich Teil des Reizes eines cloudbasierten Systems – die Upgrades geschehen, ohne dass Sie „etwas“ tun müssen. Ich würde jedoch vorschlagen, dass Sie trotzdem testen müssen!
Die Frist – wann der Support für ECC 6.0 endet – ist Ende 2025. Man könnte argumentieren, dass man ohnehin keine kohärente Antwort erhält, wenn man eine OSS-Nachricht sendet, und es daher egal ist, ob man im Support ist oder nicht. Das wäre jedoch zynisch. Lassen Sie uns der Argumentation halber einfach sagen, dass der Support wichtig ist. Viele Unternehmen haben die Daumen gedrückt und sich sehnlichst gewünscht, dass SAP die Frist von 2025 auf 2030 oder Ähnliches verlängern wird. Andere Organisationen haben dem Weihnachtsmann das Gleiche geschrieben. Nun, diese Verlängerung könnte passieren – der Weihnachtsmann kann ziemlich einflussreich sein – aber man kann sie wirklich nicht garantieren, und mit jeder Organisation, die zu S/4HANA migriert, sinken die Chancen auf eine solche Verlängerung ein wenig.
Die Umstellung auf S/4HANA: Eine Neuimplementierung
„Rip it Up and Start Again“ – SAP S/4HANA mit Orange Juice
Hallo ihr (Wort gestrichen) SAP-Typen, hier ist die Punkband „Orange Juice“. Wir gehen davon aus, dass alle Schimpfwörter in unserer Erklärung bis zum Zeitpunkt des Lesens zensiert werden, aber stellen Sie sich einfach vor, sie wären da, im Verhältnis von zwei zu drei pro tatsächlichem Wort.
Um es brutal auszudrücken: Der Wechsel von ECC 6.0 zu S/4HANA ist überhaupt kein Upgrade, sondern eine (Wort gestrichen) neue ERP-Implementierung. Außerdem verlieren Sie, wenn Sie die Cloud-Version wählen, all Ihre (Wort gestrichen) „Z“-Sachen. Wir sagen Ihnen also: Sagen Sie (Wort gestrichen) SAP, was Sie (Wort gestrichen) von ihnen halten, dass sie Sie dazu zwingen, dies zu tun, und wenn Sie sowieso eine neue ERP-Implementierung durchführen müssen, dann gehen Sie zu (Wort gestrichen) Oracle oder jemand anderem.
Das war etwas harsch, aber Punkrocker sind nicht gerade für ihren Takt bekannt. Nun, als ob die Idee einer völlig neuen ERP-Implementierung nicht schon schlimm genug wäre, betrachten wir ein weiteres Problem, mit dem Sie bei der Umstellung auf S/4HANA konfrontiert werden…
„There can be only one!“ – Vereinfachungen und deren Auswirkungen mit The Kurgan
Hallo Sterbliche! Hier ist The Kurgan. Das Ding am ewigen Leben ist, dass man immer wieder dieselben Dinge sieht. In diesem Fall hat SAP festgestellt, dass es im aktuellen ERP-System drei oder vier Lösungen für jeden Bereich gibt, z.B. Kreditkontrolle, Versandkosten, Finanzen und so weiter. Sie haben beschlossen, „die einzige“ Lösung für jedes Problem auszuwählen und die Lösungsbesitzer der anderen beiden Lösungen in jedem Fall durch das Abschneiden ihrer Köpfe mit einem Schwert zu töten, genau das, was ich tun würde. Ich meine, wer würde das nicht tun? So bleibt Ihnen nur eine Lösung, sagen wir, für die Kreditkontrolle, und es ist nicht die SD-Lösung. Wenn Sie diese derzeit verwenden, haben Sie Pech gehabt HA HA HA HA! Ich muss Sie jetzt verlassen und „New York, New York“ singen.
Das riesige unsterbliche Monster hat einen Punkt – bei früheren Upgrades war alles abwärtskompatibel. Dieses Mal, da es überhaupt kein Upgrade ist, werden riesige Teile entfernt, und wenn Ihre Konfiguration oder Ihr Z-Code derzeit von einer der „veralteten“ Lösungen abhängen, haben Sie zusätzliche Arbeit zu erledigen, d.h. in diesem Bereich neu anzufangen. Auch die Wahl der richtigen Sicherheitssoftware ist entscheidend, besonders bei so tiefgreifenden Systemänderungen. Ein Vergleich von avast avira könnte hier zum Beispiel Aufschluss darüber geben, welche Lösung am besten zu den neuen Anforderungen passt.
Die SAP HANA Datenbank und das Datenmodell
Miley Cyrus über die HANA Datenbank
Hallo, hier ist Miley Cyrus. Die meisten Leute kennen mich durch meine Arbeit im Kinderfernsehen, im Gegensatz zu meinen bahnbrechenden Forschungsarbeiten über Computertechnologie und Datenbankdesign im Allgemeinen, die mir nicht weniger als dreimal den Nobelpreis eingebracht haben und die natürlich grundlegend für Hasso Plattners Design der HANA-Datenbank waren, weshalb er ihr diesen Namen gab. Das zeigt nur, wie die Medien immer den falschen Bereich in den Mittelpunkt rücken. Jedenfalls sind in der vorliegenden Sache keine der Komponenten der HANA-Datenbank wirklich neu, aber dennoch ist das Ganze mehr als die Summe seiner Teile.
Es gibt viele kostenlose Informationen im Internet, aber wenn Sie sich das SAP Press Buch zur ABAP-Entwicklung in SAP HANA ansehen können, wird es Ihnen in kristallklaren (technischen) Begriffen erklären, wie gut diese Datenbank tatsächlich ist. Sobald Sie verstanden haben, warum dies anders/besser ist, wird es Sie buchstäblich umhauen.
Dieses Mal gibt es keine Grauzone – die Konkurrenz kritisierte SAP, als sie sich für eine In-Memory-Datenbank entschied, und erkannte dann einige Jahre später, dass sie im Unrecht war, und versucht seitdem fieberhaft aufzuholen. Die Analogie ist die von Elektroautos – alle lachten über Tesla, aber jetzt versucht jedes traditionelle Autoherstellerunternehmen mit aller Kraft, so viele Elektroautos wie möglich zu bauen. In beiden Fällen ist die Welt dadurch ein besserer Ort geworden.
Natürlich kann die Migration zur HANA-Datenbank völlig unabhängig von der Umstellung auf S/4HANA erfolgen. Donna Summer sang, dass dies eine gute Idee sei, aber die Leute bei SAP schlagen vor, dass die Änderung in zwei Schritten eine Verschwendung von Mühe ist. Was in dem von Miley erwähnten Buch und auch von Leuten, mit denen ich auf SAP-Veranstaltungen gesprochen habe, deutlich wird, ist, dass der Wechsel der Datenbank keine Patentlösung ist – wenn Sie Ihren Z-Code nicht ebenfalls ändern, wird es überhaupt nicht helfen, die Performance könnte sogar schlechter werden. Darauf kommen wir später zurück.
Apropos Z-Code: Wenn Sie zur Cloud-Version migrieren, können Sie – obwohl S/4HANA voller Erweiterungsoptionen ist – Ihren Z-Code nicht im Kernsystem haben. Sie müssen ihn entweder komplett in einer anderen Sprache neu erstellen oder im neuen „ABAP in the Cloud“, wobei der Großteil des vorhandenen Z-Codes (prozedural, keine Trennung der Belange) ebenfalls zu fast 100 % neu geschrieben werden muss. Es gibt auch unzählige Kleinigkeiten, wie zum Beispiel die Ersetzung der Ausgabebestimmung durch BRF+ (wissen Ihre Entwickler oder Business Analysten überhaupt, was BRF+ ist?).
Victoria’s Secret über das S/4HANA Datenmodell
Hallo, hier ist Königin Victoria. Unser Geheimnis ist, dass wir ein riesiger Fan des vereinfachten Datenmodells innerhalb von S/4HANA sind. Wir sind höchst amüsiert. Die gesamte Redundanz wurde entfernt und die Anzahl der Datenbanktabellen wurde erheblich reduziert. Wenn Sie sich die Zeit nehmen, zu recherchieren, was allein im Finanzbereich getan wurde, werden auch Sie höchst amüsiert sein, genau wie wir. Wenn dieser Ansatz auf die anderen Bereiche (ehemals „Module“) in S/4HANA ausgeweitet wird, wird das gesamte ERP-System zu dem, was unser Wildhüter eine „Killer-Applikation“ nennt. Man muss Sie jetzt verlassen, man muss Doctor Who für die entsetzliche Art und Weise bestrafen, wie er mit unserem Werwolfproblem umgegangen ist.
Wie zu sehen ist, wurden bisher verschiedene Vor- und Nachteile eines Wechsels zu S/4HANA angesprochen. Lassen Sie uns eine kurze Zusammenfassung geben, beginnend mit dem Negativen und dann das Positive hervorhebend, wie jemand irgendwo einmal sagte. Ich lasse das Argument „Sie müssen es sowieso tun“ beiseite, da es nicht darum geht, ob die Änderung gut oder schlecht ist.
Vor- und Nachteile der S/4HANA-Migration
Nachteile
- Kein Upgrade, sondern Neuimplementierung: Die Umstellung ist kein einfaches Upgrade, sondern eine vollständige Neuimplementierung des ERP-Systems. Dies kann zwar ein Vorteil sein, wenn Ihre aktuelle Implementierung Probleme hat, bedeutet aber einen erheblichen Aufwand.
- Fehlende und geänderte Module: Viele ehemals separate Module wurden in S/4HANA neu konzipiert oder sind nicht mehr vorhanden. Dies erfordert ein völlig neues Herangehen und Einarbeiten in neue Prozesse.
- Verlust von Z-Code in der Cloud: Bei einer Cloud-Migration gehen alle kundenspezifischen „Z“-Entwicklungen verloren und müssen in einer anderen Sprache oder „ABAP in the Cloud“ neu erstellt werden.
- Z-Code-Anpassungen On-Premise: Auch bei einer On-Premise-Installation müssen aufgrund fehlender Module und der Datenbankänderung erhebliche Teile des Z-Codes überarbeitet oder neu geschrieben werden.
Vorteile
- Immer aktuelle Funktionen: Mit S/4HANA sind Sie stets auf dem neuesten Stand der Technologie und profitieren von kontinuierlichen Innovationen. Für ECC 6.0 gab es seit Januar 2016 keine neuen Funktionen mehr.
- Vereinfachte Upgrades in der Cloud: Bei der Cloud-Version entfällt der Großteil des Upgrade-Aufwands, da diese Prozesse von SAP verwaltet werden.
- Die HANA-Datenbank: Die zugrunde liegende In-Memory-Datenbank SAP HANA ist extrem leistungsstark und ermöglicht völlig neue Analysemöglichkeiten und Echtzeit-Reporting.
- Vereinfachtes Datenmodell: Das Datenmodell in S/4HANA ist radikal vereinfacht, reduziert Redundanzen und die Anzahl der Datenbanktabellen erheblich, was zu einer verbesserten Performance und Wartbarkeit führt.
Ob es Ihnen gefällt oder nicht, das Jahr 2025 wird früher oder später kommen. Ich schätze, es wird kurz nach Weihnachten 2024 eintreffen, obwohl man nie weiß, vielleicht ist die Welt bis dahin untergegangen. Nehmen wir einfach der Argumentation halber an, dies ist nicht der Fall. In diesem Fall benötigen Sie einen Plan.
Den Plan schmieden: Strategien für die S/4HANA-Migration
„Having a Plan“ – Mit dem A-Team zur erfolgreichen Migration
Hallo, hier ist John „Hannibal“ Smith. Moment mal – ich muss mir erst eine Zigarre anzünden, bevor ich anfange. Wie Sie vielleicht wissen, liebe ich es, wenn ein Plan funktioniert. BA Baracus sagt, er bemitleidet die Narren, die keinen S/4HANA-Migrationsplan haben. Was ich tun würde, wenn ich ERP-Systeme wechseln müsste, wäre, mich verkleidet zum Implementierungspartner zu schleichen, um sie auszuhorchen, und wenn sie gut sind, „Face“ vorbeizuschicken, um sie zu bezirzen, damit sie uns einen Rabatt geben. Wenn sie dann Mist gebaut haben, würde ich arrangieren, Mad Murdoch aus der Nervenheilanstalt auszubrechen, damit er den Helikopter steuern kann (BA zuerst ausschalten), um uns zum SAP-Hauptquartier zu bringen, wo wir aus Ästen und Ersatzteilen ein ERP-System bauen könnten, während Musik läuft. So wird tatsächlich die meiste neue SAP-Technologie geschaffen, nicht dass sie wollen, dass Sie das wissen. Danach würden wir mit einem Maschinengewehr auf alle schießen, aber seltsamerweise würde jeder unversehrt überleben.
Wer bin ich, um mit dem A-Team zu streiten? Ein Plan ist also für die S/4HANA-Umstellung (Neuimplementierung) erforderlich, und ich würde Folgendes vorschlagen:
- Ungenutzten Z-Code identifizieren: Führen Sie UPL (oder was auch immer es diesen Monat ersetzt hat) in Ihrem Live-System für ein Jahr aus, um die 80 % des ungenutzten Z-Codes zu identifizieren, den Sie auf Ihrem Weg zu S/4HANA zurücklassen können.
- HANA-Checks für neuen Code: Aktivieren Sie die HANA-Checks im Code Inspector, und solange Ihre Entwickler dies beachten, sollten alle neuen und zu fixierenden/erweiterten Codes HANA-konform sein. Nach einem Jahr sollte der tatsächlich genutzte Z-Code (etwa 20 %) für die Umstellung bereit sein, da jeder genutzte Code ständig geändert wird.
- Simplifizierungs-Datenbank-Check: Führen Sie den „Simplification Database“-Check (oder wie auch immer er diesen Monat heißt) auf Ihrem aktuellen System durch, um zu sehen, was aufgrund fehlender Module und Ähnlichem nicht mehr funktionieren wird.
- Umstellung auf das neue Hauptbuch: Wenn Sie noch nicht auf dem „neuen“ Hauptbuch sind, planen Sie die Zeit ein, die Sie für die Umstellung benötigen – sie ist nicht trivial –, und denken Sie daran, dass die Umstellung am Jahresende erfolgen muss.
- Einarbeitung in Ersatzmodule: Beginnen Sie, sich mit der Verwendung der Ersatzmodule vertraut zu machen, z.B. Transportmanagement anstelle von Versandkosten. Auch das wird nicht trivial sein. Das klingt wirklich offensichtlich, aber ich frage mich, wie viele Leute die Umstellung durchführen und dann sagen: „Oh je! Die SD-Kreditkontrolle scheint verschwunden zu sein. Ich frage mich, was wir stattdessen verwenden können?“
- Einführung von Unit-Tests: Das hat an sich nichts mit der Konvertierung zu tun, es ist einfach etwas, das ich Ihnen ans Herz legen möchte. Ich würde sagen, dass testbarer Code viel einfacher in ABAP in der Cloud umgewandelt werden kann, aufgrund der erzwungenen Trennung der Belange, die automatisiertes Testen mit sich bringt.
Ich hielt 2016 in Australien und 2017 auf der SAP TechEd in Las Vegas eine Rede zu diesem Thema. Außerdem gibt es im Internet eine enorme Menge an Material, wie man angesichts der Bedeutung des Themas vermuten mag.
Eine Sanduhr, die das Ablaufen der Zeit für den SAP ECC 6.0 Support bis 2025 symbolisiert.
Nächsten Monat ist Januar 2019. Am ersten dieses Monats bleiben Ihnen noch sieben Jahre, bevor die ECC-Sanduhr abläuft. Das klingt nach einer Ewigkeit, nicht wahr? Was wäre, wenn ich Ihnen sagte, dass es acht Jahre dauern könnte, bis Sie bereit sind, wenn Sie morgen anfangen? Offensichtlich ist das eine kleine Übertreibung, aber andererseits vielleicht auch nicht, es hängt wirklich von der Qualität Ihres Z-Codes und der Anzahl der „einzustellenden“ Module ab, die Sie derzeit verwenden. Das wäre eine schreckliche Entdeckung – aber zumindest wüssten Sie es, also ist es am besten, dies zu überprüfen!
Eine abgelaufene Sanduhr, die den baldigen Ablauf der Supportfrist für SAP ECC 6.0 im Jahr 2025 darstellt.
Fazit: Jetzt handeln für eine erfolgreiche S/4HANA-Zukunft
Die Umstellung auf SAP S/4HANA ist keine Frage des „Ob“, sondern des „Wann“. Angesichts des bevorstehenden Support-Endes für SAP ECC 6.0 im Jahr 2025 ist es entscheidend, proaktiv zu handeln und einen detaillierten Migrationsplan zu entwickeln. Die Vorteile eines modernen, vereinfachten und leistungsstarken ERP-Systems auf Basis von HANA überwiegen die anfänglichen Herausforderungen einer Neuimplementierung deutlich.
Nutzen Sie die verbleibende Zeit, um Ihren Bestand zu analysieren, Ihren Code zu optimieren und Ihre Mitarbeiter auf die neuen Prozesse und Module vorzubereiten. Eine strategisch geplante Migration ist der Schlüssel zum Erfolg und sichert die Zukunftsfähigkeit Ihres Unternehmens. Beginnen Sie noch heute mit der Planung, um sicherzustellen, dass Sie für die digitale Transformation gut gerüstet sind. Wer jetzt handelt, vermeidet Engpässe und bewältigt den Wandel erfolgreich.
Mit freundlichen Grüßen,
Paul