Eigenentwicklungen sind nicht unnötig geworden. Sie sind nicht mehr kostenlos.
Die meisten ECC-Landschaften tragen Jahre an Modifikationen, und jede einzelne war einmal sinnvoll. Die Kosten wurden erst später sichtbar, beim Upgrade — als jede Änderung neu getestet, abgeglichen oder neu geschrieben werden musste und Upgrades still von Routine zu Ausnahme wurden.
Clean Core ist die Disziplin, die verhindert, dass dieser Kreislauf auf S/4HANA neu beginnt. Es ist keine Regel gegen Anpassungen. Es ist eine Regel darüber, wo Anpassungen leben dürfen.
Der Core bleibt Standard, damit er in Bewegung bleiben kann. Alles Eigene lebt daneben und wird nach eigenem Zeitplan aktualisiert.
Was Clean Core tatsächlich bedeutet
Das Prinzip ist schnell formuliert: Der digitale Core fährt Standardprozesse, konfiguriert, aber nicht modifiziert, damit Plattform-Updates fortlaufend übernommen werden können statt in gefürchteten Mehrjahresereignissen. Anforderungen, die der Standard wirklich nicht erfüllen kann, entstehen als Erweiterungen — über freigegebene Schnittstellen an den Core angebunden, nie in ihn hineingewoben.
Die praktische Folge: Ein Upgrade ist keine Verhandlung mit einem Jahrzehnt eigener Objekte mehr. Der Core bewegt sich; die Erweiterungen laufen weiter, weil sie den Core immer nur über Verträge berührt haben, die das Upgrade überdauern.
Die Clean-Core-Leitlinien von SAP unterscheiden In-App-Extensibility — freigegebene Erweiterungspunkte innerhalb von S/4HANA — von Side-by-Side-Erweiterungen auf der SAP Business Technology Platform, angebunden über freigegebene APIs.
Drei Fragen vor jeder Erweiterung
Deckt der Standard es nach Konfiguration ab?
Ein überraschender Anteil der “Anforderungen” sind Gewohnheiten, die aus dem Altsystem importiert wurden. Ein Fit-to-Standard-Workshop existiert, um zu trennen, was das Geschäft braucht, von dem, was die vorherige Implementierung zufällig getan hat.
Wenn nicht — passt es in die freigegebenen Erweiterungspunkte?
Ergänzte Felder, UI-Anpassungen und abgegrenzte Geschäftslogik passen oft in die In-App-Extensibility, die darauf ausgelegt ist, Upgrades zu überleben. Das ist die günstigste Heimat, die eine Erweiterung haben kann.
Wenn nicht — dann neben den Core, nicht in ihn hinein
Ganze Anwendungen, schwere Logik und systemübergreifende Orchestrierung gehören auf die Plattform nebenan und sprechen über freigegebene APIs mit dem Core. Die eine inakzeptable Antwort ist die alte: den Core zu modifizieren, weil er gerade in der Nähe ist.
Anforderung→Fit-to-Standard-Prüfung→In-App-Erweiterungspunkt→Side-by-Side auf BTP
Was Side-by-Side tatsächlich kostet
Ehrlichkeit ist hier wichtig, denn der Tausch ist real. Eine Side-by-Side-Erweiterung ist eine laufende Anwendung: Sie trägt ein Plattform-Abonnement, eine Integrationsfläche, die überwacht werden muss, und einen eigenen Lebenszyklus. An einer einzelnen Anforderung gemessen, kann sie teurer wirken als die Modifikation, die sie ersetzt.
Über die Lebensdauer der Plattform gemessen, kehrt sich der Vergleich meist um. Der wahre Preis der Modifikation war nie ihr Erstellungsaufwand — es war jedes Upgrade, das sie danach verkompliziert hat, multipliziert mit jeder weiteren Modifikation daneben. Clean Core verwandelt eine unbegrenzte künftige Verbindlichkeit in klar begrenzte laufende Kosten.
Was wohin gehört
- Konfiguration statt Modifikation im Core — Standardprozesse, über unterstützte Einstellungen justiert.
- In-App-Erweiterbarkeit für ergänzte Felder, angepasste Masken und abgegrenzte Logik, die zum berührten Prozess gehört.
- Side-by-Side auf der Plattform für eigene Anwendungen, differenzierende Logik und alles, was mehrere Systeme integriert.
- Nichts in der Codebasis des Core. Scheint eine Anforderung das zu verlangen, verdient die Anforderung einen zweiten Blick, bevor der Core einen bekommt.
Perspektive von VISCAP
Behandeln Sie jede Erweiterungsanfrage als Anspruch auf jedes künftige Upgrade. Die meisten Ansprüche überleben diese Rahmung nicht.
Die Organisationen, die sich mit Clean Core schwertun, sind selten die mit den meisten Anforderungen. Es sind die ohne Entscheidungspfad — wo jede Anfrage einzeln ausdiskutiert wird und die lauteste Stimme gewinnt. Die drei Fragen oben sind bewusst mechanisch: Sie machen aus der Erweiterungs-Governance statt einer Debatte eine Zuordnungsregel.
Upgrades sind der Punkt
Ein sauberer Core ist keine Ästhetik. Er ist das, was die Roadmap der Plattform — einschließlich alles dessen, was SAP als Nächstes liefert — zu etwas macht, das Ihre Organisation erhält, statt es erneut zu kaufen. Die Disziplin zahlt sich beim ersten Upgrade aus, das langweilig ist.