Big Bang oder Evolution?
Was empfehlen Sie für den Weg in Richtung S/4? Braucht es eine Konzernstrategie oder fängt man in der Buchhaltung mit S/4 Finance an?
Hinrich Mielke: Um die Potenziale des Wechsels auf S/4 Hana zu realisieren, ist die Konvertierung von ECC 6.0 auf S/4 Hana ein Projekt zur Geschäftsprozessoptimierung, gegebenenfalls sogar auch zur Geschäftsprozessneugestaltung.
Die dadurch möglichen und gewinnbringenden Use Cases sind kundenindividuell und bedürfen stets einer Konzernstrategie zu den Zielen und der Absicht des Projektes. Danach kann es zielführend angegangen werden.
Die Abstimmung mit der Fachseite führt zu ersten Use Cases. Dann wird beispielsweise mit der Buchhaltung gestartet oder mit einem Unternehmensbereich, der als Leuchtturm fungiert. Das Credo ist immer: „Think big, start small.“ Der Big Bang wird eher selten zur Kundensituation passen.
Die S/4-Roadmap hinsichtlich adaptierter und neuer Geschäftsprozesse ist eine Baustelle, wann und wie entsteht eine Fiori-Roadmap?
Mielke: Die kundenindividuelle Fiori-Roadmap folgt der Konzern- und S/4-Hana-Strategie. Sind neue Benutzerschichten (z. B. im Werk eines Automobilherstellers) angedacht, muss Fiori anders konzipiert werden, als wenn z. B. ein Einkäufer eine Information-Worker-Oberfläche für seine Aufgaben und zur Effizienzsteigerung erhalten soll. Da kann eine Integration von Fiori-Elementen und Informationen aus einem SharePoint die richtige Lösung sein.
Was ist für die neuen S/4-Hana-Anwender die größere Herausforderung: die adaptierten Geschäftsprozesse oder ein neues UI?
Mielke: Folgt man den neuen Paradigmen und setzt S/4 Hana in seiner Gesamtheit um, ändert sich der Geschäfts- und Arbeitsprozess an sich. Diese neuen Abläufe sind nicht mehr transaktionsbezogen ausgerichtet, sondern richten sich nach dem Prozess und den Nutzeranforderungen:
Hier ist ein Umdenken insbesondere für erfahrene Anwender erforderlich. Diese veränderte Herangehensweise wird durch Fiori abgebildet. Die SAPGui kann weiterhin für die vorhandenen Transaktionen verwendet werden, sodass sich hier ein kontinuierlicher Veränderungsprozess für die Anwender gestalten lässt.
Die Plattform für S/4 ist immer Hana oder Hana 2 – was sind die Unterschiede?
Mielke: SAP Hana 1 wird Fehlerkorrekturen bekommen, jedoch keine neuen Features erhalten. Es ist sozusagen das „stable Release“. Hana 2 ist hier der nächste Schritt und bringt die Hana-Plattform auf eine neue Ebene, bereit für neue Geschäftsanforderungen wie IoT und technologische Effizienz wie Active-/Active-read-enabled-Szenarien. Das hochinteressante Hana Cockpit 2.0 kommt mit Hana 2 und ist nach Untersuchungen von Alegri ein bedeutender Fortschritt.
Was empfiehlt Alegri und warum – Hana oder Hana 2?
Mielke: Für Suite on Hana ist zurzeit Hana 1 zu nutzen. Aktuell laufende Projekte mit S/4 Hana bauen in der Regel noch auf Hana 1 auf und werden nicht ohne zwingenden Grund eine stabile Basis kurzfristig verändern.
Da es aber für Hana 1 kein SPS13 geben wird, sind die Kunden mittelfristig ohnehin angehalten, auf Hana 2 zu wechseln. Somit sollte Hana 2 die Wahl in neu anlaufenden S/4-Hana-Projekten sein. In zukünftigen Releases von S/4 Hana wird Hana 2 als Unterbau erforderlich sein.
Kann man auch von Hana auf Hana 2 wechseln? Vorteile? Nachteile?
Mielke: Hana 2 ist der nächste technologische Schritt, baut auf SAP Hana 1 auf und ist abwärts kompatibel. Der Wechsel läuft analog dem Upgrade eines neuen SPS für die Hana-Datenbank. Die technologischen Risiken und Schritte sind identisch, ebenso der Testaufwand.
Bei älteren Quellsystemen kann jedoch ein Zwischenschritt auf SAP Hana 1 SPS12 sinnvoll sein. Da aber die „Datacenter Service Points“ entfallen, muss für produktive Umgebungen der richtige Zeitpunkt und das richtige Paket für den Wechsel individuell festgelegt werden.
Welche Lizenzunterschiede gibt es zwischen Hana und Hana 2 und wie kann der SAP-Bestandskunde zu einer Entscheidung kommen?
Mielke: SAP-Hana-Lizenzen hängen von der Art der Nutzung und von verwendeten Funktionen der Datenbank und SAP-Applikation ab. SAP Hana 2 benötigt an sich keine andere Lizenz als SAP Hana 1, allerdings kommen mit Hana 2 neue Nutzungsmöglichkeiten im Integrationsbereich – die zusätzlicher Lizenzen bedürfen können.
Als Faustregel gilt: Was in Hana 1, SPS12 enthalten ist, wird bei Hana 2 keine weitere Lizenzierung benötigen. Die Bedarfe und der Nutzen der Lizenzen für Hana 1 oder 2 lassen sich anhand einer entsprechenden Voruntersuchung ermitteln.
Von einigen Abap-Erweiterungen kann sich wahrscheinlich jeder SAP-Bestandskunde trennen. Was passiert aber mit den unentbehrlichen Z-Funktionen?
Mielke: Aus unseren Erfahrungen heraus werden bis zu 85 Prozent der Z-Programme/Modifikationen nicht genutzt! Hier ist eine vorübergehende Stilllegung und dann ein Ausbau sinnvoll Die verbleibenden werden umgestellt und angepasst.
Deshalb ist eine automatisierte Nutzungsanalyse sehr sinnvoll, sodass bevorzugt die unerlässlichen Arbeiten durchgeführt werden. Alegri bietet daher im Rahmen des „Hana Readiness Audit“ eine automatisierte Nutzungsanalyse der Eigenentwicklungen an – ebenso wie eine „Impact-Analyse“ der genutzten Transaktionen.
Inwieweit berücksichtigt die „Konvertierung“ den Z-Namensraum und die Abap-Modifikationen?
Mielke: Die Konvertierung nimmt sämtliche Z-Programme und Modifikationen mit. Die einwandfreie Funktion wird im Rahmen des Projektes sichergestellt und kann Anpassungen erfordern. Der sich ergebende Anpassungsbedarf kann vorab identifiziert und durchgeführt werden, daher ist die vorhergehende Nutzungsanalyse so wichtig.
Welche Erfahrungen hinsichtlich Projektzeit und -kosten hat Alegri bezüglich der S/4-Konvertierung?
Mielke: Dies hängt stets davon ab, wie stark ein System erweitert bzw. modifiziert wurde. In einem aktuellen Kundenprojekt stellen wir ein bestehendes ECC-6.0-System innerhalb von drei Monaten Projektlaufzeit auf S/4 Hana um. Dieses System ist nah am Standard und kann somit mit insgesamt 15 Personenmonaten konvertiert werden.
Neben den Geschäftsprozessen müssen auch die Daten übersiedeln: Was muss der SAP-Bestandskunde hinsichtlich der Datenkonvergenz wissen und beachten?
Mielke: Die reine Konvertierung der Daten auf S/4 Hana ist unkritisch, spannender sind die künftigen systemübergreifenden Prozesse und Informationsquellen. Für eine nachvollziehbare und transparente Nutzung sind neue Methoden erforderlich, die zeitgleich mit der Umsetzung der neuen Möglichkeiten implementiert werden sollten.
Das Enterprise Information Management wird eine wesentliche Rolle in den Unternehmen einnehmen; hier sind die Daten, die Prozesse und auch die organisatorischen Voraussetzungen zu beleuchten.
Inwieweit muss für die Datenkonvergenz die S/4-Architektur berücksichtigt werden?
Mielke: Eine wichtige Frage! Die Schnittstellen für den Datenaustausch werden sich verändern und Einfluss auf die optimale Architektur haben. Dies ist frühzeitig zu beachten. Es sollte baldmöglichst die Architektur feststehen, auf der die Integration geleistet wird.
Dies kann z.B. die HCI sein, es können Hana-Bordmittel (z. B. virtuelle Tabellen) genutzt werden oder ein On-Premise PO kann sich als gute Lösung herauskristallisieren. Ebenso kann ein Mix dieser Möglichkeiten optimal sein.
Was sind die wesentlichen Unterschiede hinsichtlich der Datenhaltung zwischen einer klassischen Datenbank und dem In-Memory-Computing-Konzept von Hana?
Mielke: Ein wesentlicher Unterschied (in Addition zum bekannten In-Memory Konzept) ist, dass mit Dynamic Tiering die Unterscheidung von Daten in „Hot“, „Warm“ und „Cold“ möglich ist. Das heißt, es wird von der Datenbank der Speicherort der Daten festgelegt.
Für die Anwendung ist dies transparent: Es gibt eine Tabelle und es muss nicht zwischen den physischen Speicherorten unterschieden werden. Hier lassen sich einfach und elegant Kosten optimieren, z. B. bei Daten, die auch noch nach Jahren nicht archiviert werden können.
Zum anderen kann aufgrund der internen transparenten Komprimierung eine Denormalisierung der Datenbankstrukturen durchgeführt werden.
In einer zukünftigen S/4-Hana-Architektur: Ist Hana oder Hana 2 ausreichend? Oder braucht es auch noch Sybase IQ, Hadoop etc.?
Mielke: Künftige S/4-Hana-Architekturen werden grundsätzlich auf Hana basieren und das Ziel sollte sein, keine weiteren Datenbankensysteme im Einsatz zu haben. Je nach Landschaft, Einsatzzweck und Kapazitäten wird eine reale Landschaft bei Kunden in der Regel noch weitere Datentöpfe verwenden, z. B. gibt es APO mit dem LiveCache. Bei großen Datenmengen bietet sich Hadoop an. Hadoop ist bei einigen Kunden bereits im Einsatz, unabhängig von ERP.
Und zusammenfassend wird das Master Data Management unter (Hana) S/4 einfacher oder komplexer im Vergleich zu einer SAP Business Suite 7 auf AnyDB?
Mielke: Um das Potenzial von S/4 Hana zu nutzen, wird der Anspruch der Anwender und damit der Abstimmungsaufwand für Stammdaten-Management steigen. Es wird somit eher komplexer, denn MDM wird jetzt noch mehr Bereiche berühren als früher.
Hana ist die technologische Grundlage für viele Neuerungen und Verbesserungen aufgrund der besseren Performance wie z. B. Suche und Abgleich von Stammsätzen oder Ähnlichkeitsanalysen.
