Alles Cloud oder was – Public, Private oder doch On-Premise?

Mit der „Cloud“ diskutieren wir diesmal wieder eines der großen aktuellen Buzzwords. Bei manchen meiner (den eher konservativ eingestellten) Kunden im Maschinen- und Anlagenbau ist es geradezu verboten, dieses verpönte Wort auch nur in den Mund zu nehmen. Aber erfahrungsgemäß kann man mit Trends nicht umgehen, indem man sie ignoriert.

Zunächst wäre einmal zu klären, was überhaupt unter „Cloud“ zu verstehen ist. Da fallen mir mindestens drei Zusammenhänge ein, in denen der Begriff gebraucht wird:

• Zum einen als Gegensatz zu „On-Premise“. Im Hinblick auf SAP würde das beispielsweise bedeuten, dass Sie die Hardware nicht im eigenen Rechenzentrum hosten, sondern in der „Cloud“. In diesem Sinne kann man sagen „The Cloud is just someone else’s computer“. Betriebswirtschaftlich gesehen ist das einfach eine Make-or-Buy-Entscheidung. Wie schon erwähnt, lehnen es manche Kunden grundsätzlich ab, ihre wertvollen Daten einem Dritten anzuvertrauen. Das ist nachvollziehbar, aber man sollte sich schon fragen, ob Sie im eigenen Rechenzentrum ein ähnlich hohes Sicherheitsniveau erreichen können wie bei einem professionellen Cloud Anbieter. Aber das wollen wir hier nicht vertiefen.
• Manchmal steht die „Cloud“ auch für ein anderes Software-Lizenzierungsmodell. Bisher hat man die SAP Lizenzen gekauft (und zusätzlich einen Wartungsvertrag abgeschlossen). Jetzt haben Sie die Option, die SAP-Software aus der Cloud als Service zu beziehen. Sie kaufen also keine Lizenzen, sondern bezahlen eine monatliche Servicegebühr pro User (abhängig vom Funktionsumfang). Auch das ist eine betriebswirtschaftliche Fragestellung, die uns im Rahmen dieses Artikels nicht weiter beschäftigen soll.
• Das spannendste Begriffspaar ist aus meiner Sicht „Private Cloud“ versus „Public Cloud“. Schauen wir uns dieses in der Folge näher an:

Bei einer Private Cloud hostet ein externer Dienstleister (z. B. SAP) das SAP-System für Sie (siehe oben). Das System ist Ihr „privates“ System, das heißt, Sie können damit im Wesentlichen alles machen, was Sie mit Ihrem On-Premise System auch machen können (insbesondere Customizing, Erweiterungen und Modifikationen).

Die SAP scheint mir im Augenblick strategisch sehr stark auf Public Cloud Lösungen zu setzen. Das sind vorkonfigurierte SAP Systeme mit Best Practice-Prozessen, die sich nur noch sehr eingeschränkt kundenindividuell anpassen lassen. Modifikationen sind ausgeschlossen, Erweiterungen müssen außerhalb des ERP-Systems in der SAP Cloud Platform erfolgen und auch das Customizing ist sehr stark eingeschränkt. Die Software bekommt (ähnlich wie Salesforce) regelmäßige Updates, die alle Kunden nutzen müssen.

Aus Sicht des Softwareherstellers ist das natürlich ein idealer Zustand, da er nur noch ein einziges Release warten, weiterentwickeln und supporten muss. Wenn man bedenkt, dass es heute höchstwahrscheinlich keine zwei identisch konfigurierten SAP Systeme auf der Welt gibt, liegt hier ein gewaltiges Kostensenkungspotenzial.

Vor- und Nachteile von Public Cloud Lösungen für die Kunden und Anwender

Die SAP verspricht Folgendes:

• Einführungs- und Roll-Out Projekte werden drastisch schneller und billiger, da es keine komplexe Konfiguration gibt.
• Jeder Kunde verfügt automatisch über den neuesten Softwarestand, Releasewechsel-Projekte gehören der Vergangenheit an.
• Keine kundenindividuellen, schlecht dokumentierten und nicht-wartbaren Lösungen mehr, es werden nur noch Best Practice-Prozesse verwendet.

Und der Haken bei der Sache? Davon gibt es leider einige:

• Zum einen gibt es für viele Branchen noch gar keine Public Cloud Lösungen. Ob es beispielsweise für den Maschinen- und Anlagenbau „die“ Best Practice-Lösung gibt, darf bezweifelt werden.
• Wie sieht es mit dem ständig neuesten Softwarestand aus? Ohne Frage eine gute Sache, aber ist Ihnen klar, was das bedeutet? In diesem Szenario bekommen Sie 2-4 Mal pro Jahr eine neue Softwareversion, ganz egal, ob das Ihnen zu diesem Zeitpunkt in den Kram passt oder nicht. Auch wenn Sie in diesem Sinne kein Releasewechsel-Projekt durchführen, sind Sie dennoch gut beraten, wichtige Funktionen und insbesondere Schnittstellen jedes Mal sorgfältig zu testen.
• Und was hat es mit den lästigen kundenindividuellen Lösungen auf sich? Ohne Frage haben es in den vergangenen Jahren manche SAP-Kunden mit der Individualität übertrieben und SAP als eine Art Datenbank und Entwicklungsumgebung angesehen. Stark modifizierte Systeme sind in der Tat schlecht wartbar. Sollten wir nun in einer Gegenreaktion gänzlich auf Best Practice setzen? Meiner Meinung nach nein. Wer im Extremfall ausschließlich standardisierte Prozesse nutzt, ist genau so gut wie seine Wettbewerber (aber eben auch nicht besser). Prozesse sollten in drei Kategorien (angelehnt an die Klassifikation der Gartner Group) betrachtet und durch IT unterstützt werden.

Teilen Sie Ihre Geschäftsprozesse in die folgenden 3 Klassen ein, um die optimale IT-Strategie zu finden

• „Brot-und-Butter“-Prozesse: Das sind Prozesse, die Sie beispielsweise machen müssen, weil es Ihnen vorgeschrieben ist (z. B. Buchhaltung). Es können auch Kerngeschäftsprozesse sein, bei denen Sie keinen Wettbewerbsvorteil für sich sehen. Solche Prozesse sollten zu 100% im Standard eines ERP-Systems betrieben werden, Best Practice ist dafür perfekt geeignet.
• Wettbewerbskritische Prozesse: Das sind Prozesse, bei denen Sie sich vom Wettbewerb differenzieren. Das kann bei jedem Kunden etwas Anderes sein, „klassische Kandidaten“ im Maschinen- und Anlagenbau sind beispielsweise der Angebotsprozess, die Konfiguration von Produkten und Projekten, Projektmanagement, Serviceprozesse oder auch die Kalkulation. Sie wären schlecht beraten, wenn Sie solche Prozesse an einen Softwarestandard anpassen würden. Vielmehr sollte sich die Software (nach Möglichkeit modifikationsfrei) an den Prozess anpassen. Solche Prozesse gehören ebenfalls in ein ERP-System und rechtfertigen Customizing, Erweiterungen und Eigenentwicklungen.
• „Game-Changer“-Prozesse: Das sind Prozesse, mit denen Sie gegebenenfalls die Regeln des Marktes verändern und beispielsweise neue Geschäftsmodelle kreieren können. Im Maschinen- und Anlagenbau könnten das zum Beispiel Anwendungen im Umfeld von künstlicher Intelligenz, Internet of Things oder Data Science sein. Da bei solch innovativen Anwendungen das Risiko des Scheiterns hoch und Geschwindigkeit Trumpf ist, sind klassische ERP-Projekte mit einem linearen Wasserfall-Vorgehensmodell wenig dafür geeignet. Hier entwickelt man vorzugsweise mit agilen Methoden schnelle Prototypen, gerne auch zunächst außerhalb des ERP-Systems (z. B. Apps).

Der „Trick“ besteht natürlich darin, Ihre Prozesse den richtigen Kategorien zuzuordnen. Wenn Ihnen Ihre Process Owner (so sie welche haben) weiß machen wollen, dass 95% Ihrer Prozesse wettbewerbskritisch sind und insofern das System angepasst werden soll, dann sollten Sie skeptisch sein.

Wenn also die Public Cloud nicht „die“ Lösung ist, wo soll die Reise dann hingehen? Wahrscheinlich werden wir in Zukunft mehr und mehr „hybride“ Lösungen sehen. Diese sehen so aus, dass Sie Ihre wettbewerbskritischen Prozesse nach wie vor kundenindividuell in SAP ausprägen (sei es On-Premise oder in einer Private Cloud). Für Brot-und-Butter-Prozesse nutzen Sie den SAP-Standard oder spezialisierte Public Cloud Lösungen, die Sie einfach an Ihr SAP System anbinden. Beispiele hierfür sind:

• Concour für Reiseplanung und -abrechnung
• CRM Lösungen von Salesforce oder SAP
• SuccessFactors für Recruiting und andere Personalprozesse

Sie sehen, das Ganze ist keine „Entweder-Oder“ Frage, auch wenn sie manchmal so diskutiert wird. So beruhigend das ist, aus IT-Sicht sind solche hybriden Lösungen natürlich auch nicht trivial. Sie sehen also, es bleibt spannend.

Im Artikel „SAP S/4HANA Cloud: Public Edition vs. Private Edition“ erfahren Sie mehr über die Angebote, Unterschiede und Potenziale der beiden SAP S/4HANA Cloud Varianten.