Cloud Enterprise Systems – State of the Art und Herausforderungen für Unternehmen

Enterprise Systems werden gemeinhin nicht mehr als ein monolithisches System verstanden. Stattdessen wird in der Literatur die Einschätzung geteilt, dass derartige Systeme sich aus – je nach Autor – fünf (Gronau 2021) bis sechs (Schütte 2024) unterschiedlichen Systemen zusammensetzen, die abweichende funktionale und technische Aufgaben abdecken: Enterprise Resource Planning (ERP), Supplier Relationship Management (SRM), Supply Chain Management (SCM), Customer Relationship Management (CRM), Business Intelligence (BI) und nach dem vorliegenden Verständnis optional auch ein Shop-System (Schütte 2023, 2024).

Dabei sind Enterprise Systems dadurch geprägt, dass ihre Komponenten Standard-Anwendungssysteme sind, die einen hohen Integrationsgrad anstreben (Leyh und Wendt 2018; Gronau 2021; Kurbel 2021). Die mit dem Aufkommen des Cloud Computing induzierten technologischen Herausforderungen für Enterprise Systems sind erheblich, wie der vorliegende Beitrag darstellen wird. Die erforderlichen Änderungen in bestehenden Systemen haben ihre Ursache möglicherweise auch in den – bezüglich der Cloud-Technologien – geringen technologischen Fortschritten, die die Standardsoftwarehersteller bisher realisiert haben. Dabei wird in diesem Beitrag unter Cloud Computing (Hentschel et al. 2018; Hentschel und Leyh 2016) nicht nur der Verkauf einer Lösung als Software as a Service (SaaS) verstanden. Stattdessen unterstellt dieser Beitrag, dass mit dem Begriff eines „Cloud-basierten Systems“ die Realisierung von Eigenschaften des Cloud-Native oder Serverless Computing gemeint ist, welche jedoch durch Enterprise Systems von heute nicht oder oft nur sehr begrenzt erfüllt werden.

Daraus ergeben sich die beiden zentralen Problembereiche, die dieser Beitrag adressiert:

Der Diskussion der Problembereiche seien dabei folgende Präsuppositionen vorangestellt, um dem geneigten Leser die Basis der Bewertung nachvollziehbar zu entfalten:

Da Enterprise Systems von den Softwareherstellern betriebswirtschaftlich vorgedacht werden, ist der Lösungsraum für das einführende Unternehmen für wesentliche wertschöpfende Prozesse betriebswirtschaftlich mit ganz wenigen Ausnahmen zwingend unterspezifiziert (Abbildungsunmöglichkeitspräsupposition). Es gibt lediglich zwei Fälle, in denen dieser wichtige Aspekt geringer ausgeprägt ist: Entweder Unternehmen sind an der Entwicklung der Lösungen beim Hersteller beteiligt oder die Anforderungen der Unternehmen sind tatsächlich im Standard vollumfänglich abbildbar. Die Erkenntnisse aus der Einführung von Standardsoftware belegen dabei aber, dass die Individualisierungsanforderungen erheblich sind und die letztgenannte Annahme unrealistisch ist. Auch die empirischen Ergebnisse belegen, dass in den Wertschöpfungsbereichen von Unternehmen eine solche Situation nicht vorliegt (Buxmann und König 1997; Brehm et al. 2002; Hansen et al. 2023).

Enterprise Systems werden technologisch und betriebswirtschaftlich von den jeweiligen Softwareherstellern dominiert. Auch wenn es in unterschiedlichen Domänen viele Anbieter von Standardanwendungssystemen gibt, so dominieren aus einer Marktanteilsperspektive wenige, große Anbieter den Markt: Oracle, SAP, Microsoft und Salesforce; Auch Sage und Workday sind in diesem Zusammenhang noch zu erwähnen (Sarferaz 2022, 2023). Unabhängig von dem Standardsoftwarehersteller sind Applikationsarchitekturen entstanden, in deren Kern die Enterprise-Systems-Komponenten dominieren, auch wenn weitere wichtige Applikationen existieren. Die Kommunikation zwischen und die Integration mit diesen Komponenten bildet dabei die Basis oder „das Backbone“ der Applikationsarchitekturen (Olson und Kesharwani 2010). Dabei gibt es mindestens zwei Fundamentalaspekte, die in der Literatur angedeutet werden, allerdings in ihrer Wirkmächtigkeit für die Applikationsarchitekturen nicht ernsthaft diskutiert werden.

Erstens hat sich in der Literatur die Einschätzung etabliert, dass die Rede von „generischen Standardsystemen“ (Klaus et al. 2000; Gronau 2021) ein zielführendes Leitbild für ERP-Systeme sein sollte. Die technische Realisierung dieser Anforderungen durch das Anwendungsunternehmen (oder deren Implementierungspartner) in der Software wird in der Literatur mehrheitlich als Customizing bezeichnet (Gronau 2021; Kurbel 2021; Klaus et al. 2000), wobei dies im engeren Sinne eher eine Parametrisierung darstellt (Schütte 2024). Der Umfang an Parametern ist dabei erheblich (vgl. Dittrich und Vaucouleur 2008) und diese Parametrisierung unterstellt, dass die vergrößerte Code-Basis mit einer darüberliegenden Parametrisierungsschicht Vorteile mit sich bringt. Damit werden implizite Annahmen getroffen, die im Widerspruch zur Abbildungsunmöglichkeitspräsupposition aus dem vorhergehenden Abschnitt dieses Beitrags stehen könnten. Ein solches Zielbild von Standardsoftware unterstellt die Möglichkeit hohe Standardisierungsgrade dadurch zu erzielen, dass unterschiedliche Anforderungen von Unternehmen in der Standardsoftware durch eine Erweiterung der Codebasis realisiert werden können oder es eine – im Wortsinn ernsthafte – generische Ableitungsmöglichkeit des Softwarecodes aus Anforderungen der Unternehmen gibt. Hier wird die Annahme nicht geteilt, denn die Anpassungsmaßnahmen in der Standardsoftware sind den zitierten empirischen Belegen zufolge immens und haben sich im Zeitablauf nicht verringert (Dittrich und Vaucouleur 2008). Hierzu sei auch exemplarisch der ehemaligen CIO von Aldi Nord zitiert: „Man ist schlussendlich hingegangen und hat sehr auf die bestehenden Bedarfe der jeweiligen Fachbereiche bzw. Länderspezifika gehört und hat eben nicht standardisiert, sondern in hohem Maße individualisiert. Wenn man das mal so vergleicht, sich das Coding mal ansieht, sind ungefähr 70 % der Codestrecken, die wir heute nutzen, individueller Natur. Das heißt, tatsächlich selber entwickelt bzw. modifiziert, im SAP-Sprachgebrauch, und nur ungefähr 30 % der Codestrecke sind von der Software vom Hersteller übernommen“ (Hoepfner 2021). Ungeachtet der enormen Individualisierung von Standardsystemen gilt es die Bedeutung von Standardkomponenten mit Ausnahme der BI-Komponente auf zwei Ebenen zu beachten. Zunächst ist aus einer Metaebene die konzeptionelle und terminologische Bedeutung derartiger Systeme erheblich. Es sind grundsätzliche betriebswirtschaftliche Konzeptionen, die die Art der Aufgabenkoordination festlegen. Beispielsweise determiniert die Kopplung des Rechnungswesens mit der Materialwirtschaft oder dem Vertrieb in einem SAP-System die „Sicht auf die ökonomische Wirklichkeit“. Auf einer Objektebene ist zu beachten, dass der strukturelle und prozessuale Rahmen des Unternehmens von Standardsoftwareherstellern vorgegeben wird und stets auch limitierend wirkt. Dabei sind die meisten aktuell im Einsatz befindlichen Systeme auf Datenmodellen basierend, die den Wunsch nach einer integrierten Datenhaltung durch Inkaufnahme als starr zu bezeichnender Datenstrukturen realisiert haben. Beispielsweise ist das alte SAP-Datenmodell aus dem R/2-System, in dem die zentralen Organisationseinheiten des Systems repräsentiert sind, noch immer in großen Teilen aktuell. Mehr als 50 Jahre sind diese Datenstrukturen und die darauf basierenden Algorithmen stabil geblieben.

Zweitens wird auch die technologische Basis in der Diskussion sehr selten problematisiert. Dazu gehört die Art der Datenhaltung und des Datenbanksystems, der Programmiersprache und der Entwicklungsumgebung und nicht zuletzt die Softwarearchitektur und für den Betrieb besonders bedeutend das Deployment und die Softwarelogistik. Letztlich dürfte das Technologiealter der funktionalen Komponenten sehr hoch sein, was auch eine technologische Last für die Anwendungsunternehmen bedeutet. Aufgrund der Vielzahl von Stammkunden wirken diese technologischen Gegebenheiten wiederum ganz im Sinne des Innovator’s Dilemma von Christensen (1997) als Problem für eine wirkliche Neuentwicklung von ERP, CRM, SCM oder SRM-Komponenten. Im Ergebnis sind die heutigen Applikationsarchitekturen damit einerseits durch die betriebswirtschaftliche Prägung der wesentlichen Komponenten eines Enterprise Systems limitiert und ihrer Weiterentwicklung eingeschränkt. Andererseits wird der Betrieb der Applikationen und deren Weiterentwicklung aus technischer Sicht durch die Standardsoftwarehersteller vorgegeben. Der letztgenannte Aspekt erscheint vordergründig nicht so bedeutend zu sein, ist aber für die Organisation der IT und auch die Einführung der Systeme von hoher Bedeutung. Die Kompetenzbasis der IT-Ressourcen lässt sich nicht so einfach verändern, ist sie doch in den handelnden Personen begründet. Deren Wissen ist an die unterschiedlichen Ecosysteme technisch und auch ökonomisch gebunden, übergreifende und tiefe Domänen- und Technologiekenntnisse sind überaus selten vorhanden.

Folgerichtig werden von den Standardsoftwareherstellern in Abhängigkeit von dem Gegenstand der Einführung (den Komponenten eines ES, also BI, SCM, SRM, ERP, CRM und Shop-System) und dem Deployment-Modell in der Cloud unterschiedliche Vorgehensmodelle mitsamt der die Einführung unterstützenden Tools für das Application Lifecycle Management offeriert (Aral et al. 2024), die auch noch anhand der verfolgten Zwecke des Vorgehensmodells variiert werden (z. B. Produktentwicklung eines Template-Systems, Rollout eines Template-Systems, Release-Wechsel). Zusätzlich bieten die im Ecosystem (Wulfert 2024) der Softwarehersteller befindlichen Implementierungspartner i. d. R. adaptierte, mitunter auch eigene Vorgehensmodelle, um sich von Wettbewerbern zu differenzieren. Die Partner im Ecosystem reichen von global agierenden Systemhäusern über Schulungsanbieter bis hin zu Freelancern. Die bei diesen Partnern im Fokus stehenden Vorgehensmodelle lehnen sich in der Regel an eher klassische sequenzielle oder iterative oder an agile Vorgehensmodelle an. Dabei ist die Art des Vorgehens bei einer Standardsoftware nicht so frei wählbar, wie dies bei einer Individualsoftware der Fall ist. Die Vorgabe der betriebswirtschaftlichen Inhalte in Form von Datenstrukturen und Prozessen führt ebenso wie die Art der Realisierung dergleichen in Softwarecode dazu, dass das Vorgehen inhaltlichen und technologischen Restriktionen unterworfen ist. Damit wird auch der Einsatz „echter“ agiler Vorgehensweisen in komplexen transaktionalen Systemen innerhalb eines Enterprise Systems selten praktiziert. Abb. 1 gibt einen Eindruck wieder, wie wenig verbreitet agile Vorgehensmodelle nach Einschätzung der Autoren entgegen gegenteiligen Ankündigungen der Hersteller in realen Projekten im Enterprise-Systems-Kontext sind.

Full size image

Dabei sei vor allem darauf hingewiesen, dass ein SCM- oder ein ERP-System weitaus stärker transaktional komplexere betriebswirtschaftliche Prozesse realisiert, als dies in den anderen Systemen der Fall ist. Aufgrund der damit verbundenen Integrationsproblematik in diesen Systemen werden daher auch klassische Vorgehensmodelle erforderlich.

Unabhängig von dem Vorgehensmodelltyp werden „Referenz-Vorgehensmodellartig“ die fünf Phasen Projektvorbereitung, Anforderungsdefinition (oder in der Sprache der Praxis auch als Business Blueprint bezeichnet), Realisierung, Produktionsvorbereitung und Go Live unterschieden (Kurbel 2021). In diesen Phasen werden Aufgaben mit Problemlösungstechniken gelöst und mittels Darstellungstechniken die Lösungen dokumentiert (vgl. zum Verständnis von Phasen, Aufgaben, Darstellungs- und Problemlösungstechniken auch die Ausführungen bei Teubner 1999). Dabei sind die im Rahmen der Phasen wahrzunehmenden Aufgaben von der spezifizierten Domäne und der technologischen Basis abhängig. Die realen Einführungsfälle werden durch die Vorgehensmodelle des jeweiligen Standardsoftwareherstellers geprägt (sei es SAP, Oracle, Microsoft, Salesforce, o. a.), die i. d. R. durch herstellerspezifische Tools für das Application Lifecycle Management unterstützt werden. Die beiden zentralen Phasen, die Anforderungsdefinition und die Realisierung, weisen dabei standardsoftwarespezifische Aspekte auf:

Diese beiden Aspekte werden im nachfolgenden Kapitel aufgegriffen. Für die spätere Analyse der Einführungsveränderung durch neue Architekturprinzipien in einem Cloud Native Computing ist die Kenntnis beider Aspekte fundamental.

Enterprise Systems stehen vor enormen Herausforderungen in Zeiten des Cloud Computing, denn die meisten der bestehenden Systeme weisen noch nicht die Modul-Charakteristika der in Abschn. 3 skizzierten Referenzarchitektur auf. Damit werden auch die Strategie und die zukünftige Einführungsweise sich erst in den nächsten Jahren sichtbar in den Unternehmen verändern. Es sind aufgrund der technologischen Bestrebungen bereits jetzt einige Trends offensichtlich. Zunächst wird die von den Herstellern zwingend verfolgte Reduktion der Systemkomplexität dazu führen, dass es mehr Standard im Kern der Systeme geben wird. Außerdem wird dadurch die Verbindung von SaaS- und PaaS-Lösungen zwingend, so dass mehr Individualentwicklungen möglich werden – bei einer Separierung der spezifischen Individualisierungswünsche in Side-by-Side-Ansätzen. Diese Differenzierung zwischen den auch gerne als „lean core“ bezeichneten ES-Komponenten und den spezifischen Anforderungen des Unternehmens eröffnet auch die Möglichkeit, die strategisch wichtigen Anforderungen für Flexibilität und Agilität des Unternehmens außerhalb des vom Hersteller dominierten Softwarekontext zu realisieren. Damit ist es möglich, auch unter Betrachtung der AI Capabilities, dass wir ein neues Zeitalter von Individualsoftware erwarten dürfen, welches die ES-Komponenten als Commodity betrachtet. In jedem Fall wird deutlich, dass das Cloud Computing die Spielregeln zwischen Herstellern und Anwendungsunternehmen verändert und letztlich fundamental für die gesamte unternehmerische Entwicklung ist.