Zusammenfassung: Der Blogbeitrag verdeutlicht, dass es in S/4HANA keinen klaren SAP Standard gibt und empfiehlt daher, eine interne Definition festzulegen, um Missverständnisse zu vermeiden und einheitliche Prozesse zu schaffen. Eine klare Definition des SAP Standards kann zur Optimierung von Geschäftsprozessen beitragen und die Umstellung auf S/4HANA erleichtern.
Wie bereits im vorherigen Beitrag zu den Betriebsmöglichkeiten klar geworden ist und heute sicher auch jedem IT-Manager sehr bewusst ist, geht der Trend zur Nutzung von IT-Lösungen immer mehr in Richtung der gebrauchsbasierten Zahlung, also in Richtung Abonnement-Systemen. Infrastruktur und Rechnerleistung sollen nicht mehr „auf Vorrat“ im eigenen Rechenzentrum bereitgehalten werden. Vielmehr wollen wir nur für die Leistung zahlen, die wir auch tatsächlich nutzen, und die Nutzung/Nichtnutzung von Funktionen und Mengengerüsten soll schnell und beliebig skalierbar und anpassbar sein. Und genau das ist ja einer der vorrangigen Nutzen der Cloud-basierten Lösungen – die sogenannten SAAS-Lösungen (Software as a Service).
Das Abo liegt im Trend
Auch wenn diese zum heutigen Stand aus Sicht vieler Entscheider noch nicht den Reifegrad haben oder die Flexibilität und Sicherheit bieten, die man sich wünscht, ist dieser Trend ganz sicher nicht aufzuhalten. Wir sehen dies an einer Vielzahl von erfolgreichen Abo-basierten Geschäftsmodellen auch außerhalb der IT, die die etablierten Geschäftsmodelle in teilweise rasanter Geschwindigkeit ablösen oder überholen (s. dazu auch die Ausführungen in „Das Abo-Zeitalter…“ von Tien Tzuo/Gabe Weisert).
Für den Gang in die Cloud gerüstet?
Für unsere Neueinführung von S/4HANA bedeutet dies, dass wir das System so gestalten sollten, dass dies für einen späteren Betrieb in der Cloud offen ist und nicht durch die Lösungen, die wir implementiert haben, verbaut wird. Die Standard-Zielvorgaben aus den SAP R/3 Projekten „wir führen SAP im Standard ein“ oder „wir machen keine Modifikationen“ reichen daher nicht mehr aus, selbst wenn der Begriff der „Modifikationen“ klar zu detailliert spezifiziert ist. Eine sehr viel feinere Unterscheidung ist notwendig, und es sollte zu einem frühen Zeitpunkt im Projekt festgelegt werden, ob die künftige S/4HANA-Lösung für den Gang in die Cloud gerüstet sein soll – auch wenn dieser Schritt jetzt nicht gleich vollzogen wird. Und wenn ja, für die Multi Tenant Edition oder für die Single Tenant Edition. Eine entsprechende Klassifizierung der unterschiedlichen Erweiterungsmöglichkeiten und die in den jeweiligen Lösungen zulässigen Anpassungen finden Sie in dieser Präsentation.
Aber Achtung:
Gehen Sie damit restriktiv um! Eine einzige gelbe Klassifizierung Ihrer Erweiterungen bedeutet, die Lösung kann nicht mehr in der Multi Tenant Edition betrieben werden. Und eine einzige rote Klassifizierung Ihrer Erweiterungen bedeutet, die Lösung kann auch nicht mehr in der Single Tenant Edition betrieben werden – ist ergo, zumindest bei dem aktuellen Angebot (mit der SAP als Betreiber), nicht mehr Cloud-fähig.
Allerdings ist das Geschäftsfeld der SAAS Lösungen für S/4HANA ja noch vergleichsweise jung, und es ist wohl zu erwarten, dass sich da noch einiges tut. Und eventuell werden die aktuell geltenden Regeln, die hier beschrieben sind, irgendwann ja auch weiter aufgeweicht und somit auch die Möglichkeiten der Anpassung von S/4HANA-Lösungen, die in der Cloud betrieben werden, erweitert. Verfolgen wir also gespannt die Entwicklung.