Mittlerweile haben vermutlich so gut wie alle vom Thema gehört, einige wenige trauen sich in die Offensive, und viele andere warten skeptisch ab. Warum SAP S/4HANA solche Skepsis hervorruft, und wie man das Thema anpacken kann.
(Disclaimer: die hier nachgezeichneten Vorgänge und Überlegungen seitens SAP zur Datenbankenhistorie sind reine Mutmaßungen meinerseits, nicht dass jemand auf die Idee kommt es wären offizielle SAP-Stellungnahmen.)
Lang, lang ist’s her
Jenen die schon etwas länger im Kosmos der SAP unterwegs sind, wird es früher oder später mal über den Weg gelaufen sein: SAPs Datenbank-Dilemma. SAP ist seit sehr langer Zeit Marktführer für Unternehmenssoftware. Angefangen mit einer ungewöhnlichen Idee einiger ehemaliger IBM-Mitarbeiter hat man sich über die Jahrzehnte zu einem globalen Konzern mit über 80.000 Angestellten entwickelt, eingebettet in ein umfangreiches Partner-Netzwerk und einem nicht unerheblichen Umsatz.
Doch wie viele andere Unternehmen musste sich SAP im Laufe Ihres Siegeszuges fragen ob sie gewisse Teile der Wertschöpfungskette nicht doch lieber als Kernkompetenz im Haus haben will. Sprich – die beliebteste SAP-Datenbank stammte ausgerechnet vom größten Rivalen auf dem Markt für Unternehmenssoftware, und Segelregatta-nicht-so-gern-Verlierer Oracle.
Also wurde 2003 flugs die damals auf dem Open Source Markt sehr beliebte MySQL Datenbank eingekauft, in SAP MaxDB umbenannt und als neue SAP-Datenbankplattform an Kunden verschenkt. Nach und nach bildete sich hier auch ein Kundenstamm. Leider waren die niedrigen Kosten, die gute Bedienbarkeit und einfache Verwaltung jedoch für die meisten Kunden gar nicht das große Thema. Offenbar zählten insbesondere bei mittleren bis großen Kunden vor allem die Stabilität und die Performance, und diese bot nach wie vor Oracle (und IBM, die kamen aber schlicht etwas zu spät). Und so blieb Oracle unangefochten an der Spitze, und Microsoft, IBM und MaxDB teilten sich das verbleibende Drittel des Kuchens.
SAP agierte prompt und landete 2010 einen überraschend wohl gehüteten Coup – man entwickelte etablierte Lösungen wie TREX und MaxDB LiveCache weiter und war plötzlich Oracle funktional einen großen Schritt voraus: eine In-Memory-Datenbank namens SAP HANA war geboren. Die Kunden sahen es mit Interesse, allerdings konnte die große Masse der Kunden mit der normalen SAP ERP Business Suite on HANA performanceseitig ohne weitere Optimierungen nicht viel punkten. Alles andere wäre dann schon wieder mit Entwicklungsaufwand verbunden gewesen.
Also auf zur nächsten Stufe, eine Anwendung, deren Code speziell auf die spaltenorientierten, in-memory-basierten Vorteile der SAP HANA abzielt, dazu ein neues Bedienkonzept und einige interessante SAP Cloud-Services – 2015 wurde S/4HANA auf den Markt gebracht. Wieder begann man im Finanzbereich mit S/4HANA Finance 1503 (ein ERP Add-On für SAP HANA Kunden), jedoch wird dieser Strang wohl über kurz oder lang nicht mehr weitergeführt. So kann sich der Kunde voll und ganz auf seine SAP S/4HANA Transformation konzentrieren, denn aus SAP-Sicht wird die gute alte SAP Business Suite zum Jahre 2025 aus der Mainstream-Wartung genommen.
Was der Bauer nicht kennt
Das setzt ein deutliches Zeichen. Denn SAP S/4HANA ist auch nicht einfach nur irgendein Folge-Release der ERP Business Suite, auch wenn der rein technische Wechsel sich genau so anfühlt (SUM ahoi). Ein reines Upgradeprojekt kann man je nach Ausgangssituation und funktionalen Anforderungen in 6-12 Monaten stemmen. Nein, SAP S/4HANA ist laut SAP ein völlig neues Produkt, und funktional schlägt sich das nicht wie gewohnt nur in neuen Funktionen, sondern auch in geänderten und weggefallenen Funktionsbereichen nieder (Principle of One).
Da muss der Kunde erstmal schauen, ob er nach dem Wechsel noch alle seine Funktionen im System findet. Und wenn nicht, wo und wie er sie dann abbilden kann. Geht man von Evaluierung bis GoLive von einer Projektlaufzeit von 3 Jahren aus, dann klingt die verbleibende Zeit bis 2025 plötzlich nicht mehr so lang. Zu berücksichtigen ist auch, dass bis dahin quasi die komplette SAP-Kundenbasis auf ein neues Produkt gehoben werden soll. Die Herausforderungen dieses Wechsels für Kunden, Partner, Beratungsunternehmen und SAP selbst sind gigantisch. Da wird es in den kommenden Jahren vermutlich recht eng werden, wenn es darum geht freie Kapazitäten zu finden.
SAP-Kunden hängen Ihr Herz nebst Kreislauf an einen externen Softwarehersteller, und sind naturgemäß erst mal vorsichtig wenn tolle neue Produkte angekündigt werden. Das ist um so mehr der Fall wenn es mit der Abkündigung des bisherigen Produkts einhergeht, und wenn plötzlich Konzepte wie Cloud-Szenarien für Kernprozesse sehr real werden. Da will man wissen woran man ist, und was es bedeutet umzusteigen.
Alles ist anders
Zunächst kann etwas entwarnt werden. Im Wesentlichen ist das neue Produkt auf Basis des alten entstanden, und wurde in sinnvollen Bereichen der Finanz- und Logistikwesens überarbeitet. Somit wird der umsteigewillige Kunde einen Großteil seiner Funktionen wiederfinden. Durch Integration von SRM-, SLM-, und weiteren Funktionen ist das Paket sogar teilweise dicker als zuvor. Es ist definitiv nicht so, wie teilweise in Kundenkreisen zu hören, dass S/4HANA mit 1511 noch kein Logistik konnte, die Anwendungssuite war auch im ersten Release schon vollständig. Ausnahmen von dieser Regel sind ausführlich in der jeweils aktuellen Simplification List beschrieben.
Und SAP kürzt hier nicht willkürlich, sondern hat das Principle-Of-One und die Vereinfachung der Datenstrukturen im Fokus. Vormals mehrfach vorhandene Funktionen wurden integriert. Aggregats- und Indextabellen können wegen der höheren SAP HANA Performance wegfallen, was natürlich auch Direktzugriffe auf die Datenbank invalidiert. Wer sich an die Regeln hält und den SAP-Standard nutzt, muss sich dank angepasster FuBas und BAPIs wenig Gedanken über das Datenmodell machen. Außerdem gibt es Compatibility Views die zumindest vorerst die alten Strukturen simulieren, um den Anpassungsaufwand bei SAP und Kunden zunächst gering zu halten.
Spannend auch das Thema Cloud, denn SAP S/4HANA kann als ERP-Produkt in der Public Cloud untergebracht werden. Das heißt dann straffe Wartungszyklen (alle 14 Tage Hotfixes, alle 3 Monate Release-Upgrades) und wenig Anpassbarkeit, aber dafür auch keine Hosting-Sorgen, nahtlose Integration in andere SAP Cloud-Dienste und Subskription mit variablen Laufzeiten. Man wird als Unternehmen also flexibler, und kann sich mehr um die eigenen Kernprozesse kümmern. Das ist sicher vorrangig für Neukunden interessant, aber möglicherweise je nach Prioritäten auch für die Bestehenden einen Blick wert.
Natürlich kann man SAP S/4HANA auch wie gehabt in der Private Cloud (früher: Hosting) oder On-Premise (früher: im eigenen Rechenzentrum) betreiben. Ergänzende Cloud-Services stellt SAP unter anderem mit dem Partnernetzwerk Ariba und der HCM Lösung SAP SuccessFactors bereit.
Doch was bedeutet es, auf S/4HANA zu wechseln? Angenommen Sie haben die Simplification List geprüft, und wissen nun genau welche Ihrer heutigen Prozesse morgen noch funktionieren. Dann bleiben ein paar Überlegungen, die Sie in Vorbereitung eines Umstellungsprojekts anstellen sollten.
Aufwandstreiber für die S/4HANA Umstellung
So eine Umstellung kann sich von upgrade-nah schnell zu einem kompletten Geschäftsprozess-Redesign-Projekt auswachsen. Im Wesentlichen liegt der Aufwand hierbei in der Evaluierung, Bewertung und Festlegung der künftigen Struktur der Systeme, Prozesse und Funktionen:
- Betriebsmodell: Public Cloud, Private Cloud oder On-Premise (SAP HANA braucht Experten)
- Transitionsmodell: Umbau oder Neubau
- Konsolidierung: werden SAP-Landschaften zusammengeführt oder gesplittet
- Systemumgebung: welche Dritt-Systeme müssen angebunden werden, welche können wegfallen
- Integration von externen Services (SAP Ariba, SAP SuccessFactors, SAP Fieldglass, SAP concur, SAP Hybris, usw.)
- Enduser-Anbindung über SAP Fiori
- Migrationsszenarien (Migration Cockpit in Standard und einfach versus Data Services in kundenindividuell und aufwändig)
Nicht zuletzt müssen Sie natürlich auch über Ihre eigentlichen Prozesse nachdenken (Liste nicht abschließend):
- im fachlichen Business Blueprint definieren Sie, wie Ihre Prozesse zukünftig aussehen; demnach sollte erfasst, bewertet und entschieden werden:
- FI Central Finance (zentrale FI-Konsolidierung in einem S/4HANA über SAP Landscape Transformation)
- FI NewGL (Pflicht)
- FI Real Estate Management (auf RE-FX Pflicht)
- FI Asset Management (NAA Pflicht)
- FI Credit Management (FIN_FSCM_CR Pflicht)
- FI Budgetierung (BCS Pflicht)
- FI BW /-IP /-BPC (integriert und damit ggf. externe Systeme obsolet)
- FI Cash Management (wurde grundlegend überarbeitet)
- LOG Customer Vendor Integration (Pflicht)
- LOG SRM (integriert)
- LOG SLM (integriert)
- LOG MM Katalogbeschaffung (neue Beschaffungslösung)
- LOG Materialnummer auf 40 Stellen (optional)
- IS-U Trennung von ERP und SD/FI-CA (fällt weg)
- IS-U CIC (fällt weg)
- IS-U UCES (fällt weg)
- ..
- im technischen Business Blueprint legen Sie fest, wie die Prozesse in den Systemen abgebildet werden; damit steht folgendes an:
- ERP Releasestand auf Mindestniveau ERP6 (ggf. Upgrade nötig)
- ERP ist Single ABAP Stack (ggf. Split nötig)
- Unicode-Basis (Pflicht)
- Gateway Server vorhanden für SAP Fiori (dringend empfohlen)
- Datenbank schon auf SAP HANA (Pflicht)
- S/4HANA Lizenzen vorhanden
- Datenbankgröße beeinflusst Umstellungsdauer und Hardwarekosten (ggf. Archivierung)
- Standardtreue SAP-Repository (vereinfacht Umstellung enorm)
- Standardtreue SAP-Prozesse (vereinfacht Umstellung enorm)
- Prozessabdeckung im SAP versus Dritt-Tools (je höher desto mehr Nutzen)
Das sind wesentliche Faktoren, die Ihre S/4HANA-Umstellung beeinflussen werden. Sie sehen, die Umstellung auf S/4HANA ist kein kleines Upgrade, und die bekannten Empfehlungen zur Project Governance greifen auch hier. Sollten Sie sich mit dem Gedanken einer Umstellung tragen, bereiten Sie sich gut vor, nehmen Sie sich Zeit für ein Pilotsystem und evaluieren Sie in Ruhe Ihre Optionen. Jeder Tag den Sie vorn investieren, spart Ihnen gemäß der allseits beliebten Rule Of Ten am Ende 10 Tage Korrekturaufwand. Wichtig zu beachten – suchen Sie von Anfang an den engen Kontakt zum Business. S/4HANA ist kein IT-Thema, sondern ein Business-Thema.
So sollte es auch verstanden und als Chance zur Verbesserung genutzt werden. Denn wenn Sie sowieso alles ein Mal umdrehen müssen, können Sie sich auch prozessual gleich richtig Gedanken machen. Auch das unterscheidet S/4HANA von den typischen Upgradeprojekten, wo man hinterher einfach froh ist wenn die alten Prozesse wieder laufen.
Viel Erfolg dabei,
