Abgrenzung von Clean Core und Side by Side Entwicklung
Donnerstag, 14. August 2025 von Sven Hiltner Definition der Strategie (und deren Abrenzung)
Die SAP unterscheidet zwei grundlegende Strategien für Erweiterungen und Anpassungen von SAP-Systemen:
Clean Core und Side-by-Side Entwicklung.
ACHTUNG!
Dieser Post ist in Bearbeitung und wird noch ergänzt und erweitert.
1. Clean Core Ansatz
● Bedeutet, dass das SAP-Kernsystem möglichst unangetastet bleibt, um eine einfache Wartung, Updates und Innovationen sicherzustellen.
● Anpassungen und Erweiterungen erfolgen über erlaubte Mechanismen wie SAP BTP, Key User Extensibility, Developer Extensibility (ABAP Cloud) oder Customizing.
● Ziel: Eine langfristig stabile, updatefähige und Cloud-kompatible Systemlandschaft.
Beispiel:
● Erweiterungen innerhalb von SAP S/4HANA mit ABAP Cloud oder Key User Extensibility.
● Nutzung von Business Rules, Custom Fields & Logic oder Event-driven Extensions.
2. Side-by-Side Entwicklung
● Erweiterungen werden außerhalb des SAP-Kerns in der SAP Business Technology Platform (BTP) oder anderen externen Systemen entwickelt.
● Kommunikation erfolgt über APIs, Events oder OData-Services.
● Nutzt moderne Technologien wie SAP BTP, Node.js, Java, CAP (Cloud Application Programming Model) oder Fiori/UI5 für die Benutzeroberfläche.
Beispiel:
● Eine komplexe Berechnungslogik oder KI-gestützte Analyse wird in der SAP BTP gehostet und per API in SAP S/4HANA eingebunden.
● Eine mobile Anwendung für Außendienstmitarbeiter kommuniziert über APIs mit dem SAP-Kernsystem.
Historische Entwicklung / Rückblick und Vergleich "Firmenverwaltung" zu "SAP R/3"
Mein eigenes erstes großes ERP-System, die "CHS-Firmenverwaltung", begann ich 1986 auf MS-DOS Basis in der Programmiersprache Pascal. Es war als Standardsoftware entwickelt und gedacht. Allerdings sah es in der Praxis so aus (Hardware ausgenommen), 40% vom Gesamtpreis war der Kaufpreis der Software, 30% Individualanpassungen und -erweiterungen, 30% Dienstleistung in der Einführungsphase, mit heutigen Worten könnte man das als HyperCare-Begleitung bezeichnen.
Die große Schwachstelle war, es gab nur einen Codestand aus dem ein Artefakt, die Applikation erzeugt wurde. Somit hatten alle Kunden immer das gleiche Programm. Das führte zu Stilblüten wie ein schönes Beispiel verdeutlicht:
Problem Standardsoftware:
Ich hatte einen Kunden aus dem Bereich Metallbau / Schweißbedarf. Ich machte gerade die Einweisung in das Fakturierungsmodul als der Inhaber an den Tisch trat, auf den Bildschirm schaute und fragte: "Wo gebe ich denn den Kupferzuschlag ein?"
Meine Reaktion: "Was bitte ist ein Kupferzuschlag?"
Nachdem mir die Anforderung erklärt wurde nahm ich diesen Kupferzuschlag in die Oberfläche der Fakturierung mit auf. Mit der Konsequenz, ein anderer meiner Kunden der eine Druckerei führte (zum Beispiel) hatte nun diesen Kupferzuschlag ebenfalls auf der Oberfläche als Eingabefeld und konnte damit logischerweise rein gar nichts anfangen.
Das ist das große Problem mit Standardsoftware die nicht auf individuelle, spezifische Anforderungen technisch bedingt eingehen kann.
Der Unterschied zur SAP mit ihrem Standard-ERP-System und meiner Software bestand im Kundenklientel. Ich hatte ausschließlich Kleinst- und Kleinunternehmen im Kundenstamm die nicht über eigene IT-Abteilungen verfügten. Die SAP adressierte von Anfang an Großkunden, R/2 war auch als System für Großrechner konzipiert. Und um das "Kupferzuschlag-Problem" zu umgehen führte die SAP die Z-Entwicklung in ihren ERP Systemen ein. Somit kann ein Unternehmen mit eigenen Entwicklungskapazitäten individuelle Anpassungen vornehmen, ohne dass diese im gesamten Anwenderkreis verteilt wurden und ausschließlich für das jeweilige Unternehmen implementiert sind.
Mit der Einführung der Z-Entwicklung konnte somit Standardsoftware auf individuelle Anforderungen (USP) angepasst und erweitert werden. Geniales Vorgehen im Umgang mit dem oben beschriebenen Problem meiner Meinung nach.
Standardsoftware
Erläuterung
Diese Programmsysteme sind im Regelfall durch gesetzliche Anforderungen definiert, die in gewissen Rahmen für jedes Unternehmen in beliebigen Branchen größtenteils gelten und ohne individuelle Anpassungen den Bedarf abdecken.
In diesem Bereich sollten möglichst keine Anpassungen und/oder Erweiterungen vorgenommen werden und im Regelfall existiert auch kein wirklicher Bedarf hierzu.
Konkretes Beispiel
Es ist im Regelfall für eine Finanzbuchhaltung unwichtig, ob das Unternehmen Gummistiefel vertreibt oder Atom-U-Boote herstellt. Unterschiede existieren zwar z.B. durch die Unternehmensgröße, in erweiterten Sicherheits- und Dokumentationsverpflichtungen etc. aber nicht in den eigentlichen Anforderungen selbst.
Beispiel-Metapher
Der Supertanker mit 30km Bremsweg. Er soll das Öl ungestört und unbeeinträchtigt von A nach B transportieren. Stabil und ohne Sonderprozesse. Klar umrissene Aufgabe und bekannter Lösungsweg um den Anforderungen aus diesem Bereich gerecht zu werden. Das beispielhafte Unternehmen transportiert Öl von A nach B, keine besonderen Anforderungen, kein spezieller USP.
Aufgrund der Masse in dieser Metapher reagiert der Tanker maximal träge auf Richtungs- oder Geschwindigkeitsänderungen. Daher sind diese soweit möglich zu vermeiden.
Konkretes Beispiel:
Für meine eigene Buchführung nutze ich ein Standardprogramm, 39 EUR Nutzungs- und Updatekosten pro Jahr. Vorgehen, installieren und nutzen. Ich passe meine eigenen Prozesse und Vorgehensweise an die Möglichkeiten des Programms an ohne dieses selbst zu ändern.
Semi-Standardsoftware
Erläuterung
Branchenspezifische Module befinden sich in einer Zwischenrolle zwischen Standard- und Individualsoftware für das jeweilige Unternehmen. Die Individualisierung erfolgt über branchenspezifische Ausprägungen der Software, die gemeinsame (aber spezielle) Anforderungen einer bestimmten Branche handhaben, siehe "Kupferzuschlag".
Hier befindet sich der klassische Anwendungsfall für "Z-Entwicklung". Es macht im Regelfall keinen Sinn, eine individuelle Anforderungen auszulagern, wenn innerhalb eines Verarbeitungsprozesses kleinere Anpassungen und Erweiterungen vorzunehmen sind, da der Großteil der Funktionalität bereits durch die konkrete branchenspezifische Ausprägung abgedeckt wird.
Konkretes Beispiel:
Bei der Materialwirtschaft als Beispiel existieren hier bereits enorme Unterschiede in den Anforderungen, wenn wie im Beispiel oben ein Unternehmen Gummistiefel vertreibt oder Atom-U-Boote herstellt. Die Module sind zwar branchenübergreifend ähnlich, aber die adressierten unterschiedlichen Branchen an sich haben nichts miteinander zu tun und die Module sind somit in sich geschlossen Einzelpakte mit spezialisierten an die jeweilige Branche angepasste Funktionalitäten.
Beispiel-Metapher
Der Supertanker mit Anpassungen / Erweiterungen. Hier hat sich das beispielhafte Unternehmen darauf spezialisiert, zusätzliche Dienste anzubieten. Zum Beispiel speziellen Einbauten um die Liegezeit durch Spezialpumpen beim Be- und Entladen nennenswert zu beschleunigen, oder zum Beispiel noch zusätzlich mit Gas zu befördern anstatt zwei unterschiedliche Schiffe zu schicken.
Konkretes Beispiel:
Für unseren Beispieltanker stellt sich heraus, dass die Standardanzahl von sechs der Toiletten im Sanitärbereich für die Mannschaft nicht ausreichen. Anstatt zusätzliche Toiletten auf einem umkreisenden Schnellboot einzubauen, würde man in diesem Beispiel natürlich zu den sechs Toiletten um weitere zwei oder drei im Sanitärbereich des Tankers selbst ergänzen.
Individualsoftware
Beispiele
● Self-Service-Portal für Lieferanten (Rechnungsstatus, Bestellbestätigung, Qualitätsmeldungen)
● App für Außendiensttechniker, die offlinefähig ist
● Z. B. Rezepturmanagement für Lebensmittelindustrie
● CO₂-Fußabdruck-Kalkulation pro Produktionsauftrag (Nachhaltigkeits-Reporting)
● Individuelle Frachtkostenverteilung in Logistikprozessen
Erläuterung
Hier befinden wir uns zu 100% im Bereich USP (Alleinstellungsmerkmal). Hier sind Softwaresysteme zu verorten, die im Grunde genommen so konkret und individuell ausgeprägt werden, dass nur ein einziges Unternehmen effizient und sinnvoll damit arbeiten kann. Es deckt die Anforderungen ab, mit denen sich ein Unternehmen im Rahmen seines Alleinstellungsmerkmales von den Mitbewerbern im Vorgehen abgrenzt, welches nur dieses Unternehmen "so macht".
Daher werden diese speziellen Softwarepakete ausgelagert, das bedeutet, sie befinden sich außerhalb des ERP Core und sind mit diesem auf den konkreten Bedarf durch die Anforderung hin mit 1..n Schnittstellen zum Core verbunden. Existieren keine Schnittstellen zum Core wird das auch nicht dem Side by Side Bereich zugeordnet, sondern dies sind einfach "weitere Applikationen", unabhängig von dem eigentlichen ERP-System.
Konkretes Beispiel:
Yard Management App für Spediteure (Side-by-Side auf SAP BTP)
Ausgangslage:
In SAP S/4HANA TM / EWM werden Transportaufträge, Anlieferungen und Auslagerungen verwaltet. Was häufig fehlt: Eine einfache mobile Lösung für LKW-Fahrer oder Spediteure, um ihre Ankunft auf dem Werksgelände zu koordinieren (Yard-Management). Standard-SAP deckt dies nur eingeschränkt ab und ist für externe Partner schwer zugänglich.
Side-by-Side Lösung (auf SAP BTP):
Cloud-App (Fiori/UI5 oder Mobile App), die auf der BTP läuft. Funktionen für Spediteure/Fahrer: Vorab-Check-In für geplante Anlieferung (via Smartphone), Anzeige von Time Slots (Anlieferzeitfenster), Navigation auf dem Werksgelände (Tor/Zufahrt), Digitale Dokumentenübergabe (Lieferscheine, Gefahrgutdokumente)
Integration mit S/4HANA:
Abgleich mit Transportaufträgen (TM) und Lageraufträgen (EWM), Echtzeit-Statusupdates zurück nach S/4 (z. B. „LKW auf Hof“, „Be- oder Entladung gestartet“)
Nutzen:
Entlastung des SAP-Core: Keine Anpassung der EWM/TM-Logik nötig, Externe Anbindung möglich: Fahrer oder Speditionen brauchen keinen direkten SAP-Zugang, sauberer Clean Core: Anlieferlogik bleibt im Standard, Zusatzprozess läuft Side-by-Side,
Mehr Transparenz: Werkslogistik sieht live, welcher LKW wo ist und ob Verzögerungen bestehen
👉 Das ist ein klassisches Side-by-Side-Szenario:
Ein spezifischer Logistikprozess (Yard / Hofmanagement), der außerhalb des SAP-Kerns liegt, aber eng mit Transport- und Lagerprozessen verknüpft ist.
Beispiel-Metapher
Der Supertanker mit Anpassungen / Erweiterungen. Hier hat sich das beispielhafte Unternehmen darauf spezialisiert, zusätzliche Dienste anzubieten. Zum Beispiel speziellen Einbauten um die Liegezeit durch Spezialpumpen beim Be- und Entladen nennenswert zu beschleunigen, oder zum Beispiel noch zusätzlich mit Gas zu befördern anstatt zwei unterschiedliche Schiffe zu schicken.
Konkretes Beispiel:
Für unseren Beispieltanker stellt sich heraus, dass die Standardanzahl von sechs der Toiletten im Sanitärbereich für die Mannschaft nicht ausreichen. Anstatt zusätzliche Toiletten auf einem umkreisenden Schnellboot einzubauen, würde man in diesem Beispiel natürlich zu den sechs Toiletten um weitere zwei oder drei im Sanitärbereich des Tankers selbst ergänzen.