Die meisten großen globalen Unternehmen betreiben ihre Geschäfte mit SAP, und das schon seit Jahrzehnten. Als SAP in den 1990er Jahren R/3 auf den Markt brachte, eigneten sich die Kunden die Idee an, SAP als ein monolithisches IT-System zu nutzen, das ihre verschiedenen Geschäftsbereiche miteinander verbindet.
Als die Kunden dann SAP-Funktionen an ihre spezifischen Geschäftsanforderungen anpassten, bestand der allgemeine Ansatz darin, alle Erweiterungen und Anpassungen mit Hilfe der Programmiersprache ABAP in SAP selbst zu integrieren. Andere Erweiterungen, wie z. B. Frontends, wurden ebenfalls direkt in SAP integriert, unter Verwendung von SAP GUI, Webdynpro, BSP, AIF, GuiXT, Fiori und anderen.
Und es funktionierte – eine Zeit lang. Aber jetzt zeigen sich die ersten Risse.
Das Problem mit alten SAP-Anpassungen
Ob in der Vergangenheit oder in der heutigen Zeit, SAP-Anpassungen sind mit hohen Kosten und langen Vorlaufzeiten verbunden. Einige Unternehmen haben im Laufe der Jahre Hunderte von Millionen Zeilen benutzerdefinierten Codes angehäuft und damit ihre technischen Schulden vergrößert.
Nun haben sich die Zeiten jedoch geändert. Moderne Architekturtrends sind die Dezentralisierung der Funktionalität und offene Landschaften, in denen Systeme zusammensetzbar sind und die Funktionalität über API-Bibliotheken zugänglich ist. Unternehmen, die SaaS-Lösungen kaufen, wie Salesforce und ServiceNow, haben aus den Fehlern der Vergangenheit gelernt: Sie wollen diese neuen Systeme so nah wie möglich am Standard halten. SAP folgt diesem Beispiel mit der Aufforderung, auf S/4HANA zu migrieren.
Aber was machen Sie mit Ihren alten SAP-Systemen, mit all ihrem benutzerdefinierten Code, in dieser neuen Architektur?
S/4HANA-Migration: Wann ein Greenfield-Ansatz die beste Option ist
Für Unternehmenskunden, die über stark erweiterte SAP-Systeme verfügen, besteht die einzige Möglichkeit, auf S/4HANA zu migrieren, darin, auf Greenfield zu gehen.
Greenfield Ansatz:
Ein Greenfield-Ansatz bedeutet, dass Sie gar nicht auf S/4HANA migrieren oder nur Ihre Daten migrieren. Sie geben alte Anpassungen auf und bauen neue auf, um Prozesse zu rationalisieren.
Und warum? Wenn ein Unternehmen eine jahrzehntealte SAP-Implementierung hat, die gepatcht und angepasst wurde, um mit dem Markt und den technischen Trends Schritt zu halten, ist der Business Case für ein Upgrade auf S/4HANA aus finanzieller Sicht einfach nicht gegeben.
Stattdessen macht es Sinn, S/4HANA auf der grünen Wiese zu implementieren.
Sie können Ihr Kernsystem von Grund auf neu aufbauen, den größten Teil Ihres benutzerdefinierten Codes eliminieren und Ihre globale IT auf die neuen Prinzipien ausrichten – Cloud-First, Composable, Microservices-Architektur, Good-is-Good-Enough -, damit Sie für die Herausforderungen der nächsten 15-20 Jahre gerüstet sind.
Aber dann stellt sich die Frage: Was tun mit all dem benutzerdefinierten Code, der in den aktuellen R/3-Systemen enthalten ist?
Wenn Sie planen, Ihre Plattformen so nah wie möglich am Standard zu halten, dann werden Sie Lücken haben; Sie brauchen zusätzliche Funktionen, die Ihr Unternehmen einzigartig machen, die aber nicht auf dem Markt zu kaufen sind.
OutSystems einführen
Was sind Ihre Optionen? Da SAP seinen Nutzern vorschreibt, “den Kern sauber zu halten”, ist OutSystems ein hervorragender Ausgangspunkt.
Es ist die einzige Low-Code-Plattform auf dem Markt, die für die Erstellung großer, komplexer Anwendungen geeignet ist, die mit jedem anderen System in Ihrer Landschaft verbunden werden können.
Um Ihre Abhängigkeit von einem Anbieter zu verringern, ist es wichtig, dass Ihre White-Space-Lösung eine unabhängige Plattform ist. Es gibt auch noch einen weiteren Vorteil. Die Verwendung einer unabhängigen Low-Code-Lösung gibt Ihnen auch die Möglichkeit, systemübergreifende Workflows zu erstellen. So können Sie beispielsweise in Salesforce beginnen und den Workflow mit der Erstellung von Kundenaufträgen und Projekten in SAP beenden. Oder Sie beginnen in ServiceNow und verbinden sich dynamisch mit verschiedenen SAP-Backends, je nach Region und Geschäftsanforderungen.
OutSystems hat dies bereits bei mehreren Fortune 1000-Kunden bewiesen.
Wir bei NovioQ haben selbst Dutzende von OutSystems-Anwendungen entwickelt, die SAP-Daten lesen und schreiben, für die Produktionsplanung, den globalen Einkauf, Händlerportale, Finanzdienstleistungen, Außendienst, Materialstammerstellung und vieles mehr. Diese Anwendungen verarbeiten große Mengen an Transaktionen auf sichere und performante Weise und bewähren sich jeden Tag.
Durch den Einsatz von OutSystems können unsere Kunden neue Lösungen schneller implementieren, und da es sich um eine Lösung außerhalb der SAP-Umgebung handelt, werden Entwicklung und Einsatz nicht durch den Start neuer Initiativen während langwieriger SAP-Upgrades oder -Rollouts beeinträchtigt.
Eine separate Entwicklungsschiene neben der traditionellen SAP-Schiene gibt ihnen die Freiheit, unabhängig zu entwickeln und neue Funktionen innerhalb von Wochen statt Monaten in Betrieb zu nehmen.
Wenn Sie mehr darüber erfahren möchten, wie OutSystems Ihnen helfen kann, die Art und Weise, wie Sie Ihre Erweiterungen entwickeln, zu ändern, kontaktieren Sie uns für eine Einführung.
