In drei Schritten vom „schmutzigen“ SAP-System zurück zum standardnahen Kern

Bereits in den Anfangszeiten der Standardsoftware kämpften Softwareanbieter für einen sauberen Code. Zum Beispiel gab es eine Programmierregel: Eigen­entwicklungen beginnen erst ab Zeile 50.000! Überraschend aktuell wirkt dieses Prinzip noch heute. SAP adressiert diese Herausforderung für Code und Geschäftsprozesse mit der Clean-Core-Initiative: Der Standard bleibt unangetastet, Kundenspezifika werden sauber gekapselt – konsequent umgesetzt mit einer Plattform-Strategie auf der SAP BTP (Busi­ness Technology Platform).

Das Zielbild ist ein stabiler Kern: Essenzielle Prozesse laufen standardnah, hochautomatisiert und kosteneffizient. Davon getrennt gibt es einen Innovations-­Layer: Erweiterungen und Differenzierung entstehen modular, schnell und flexibel außerhalb des Kerns – bevorzugt auf der BTP. Auch im Blick sind die Aspekte Sicherheit & Compliance: Weniger Individualeingriffe bedeuten weniger Angriffsflächen und eine einfachere Einhaltung regulatorischer Anforderungen.

Für Anwenderunternehmen stellen sich daher zentrale Fragen: Wo stehen wir heute – und wie gelangen wir zum Clean Core? Die im Folgenden dargestellten drei Schritte liefern eine sinnvolle Vorgehensweise und weisen auf hilfreiche Methoden und Werkzeuge hin (von SAP und Partnern).

Schritt 1: Tool-gestützte Code-Analyse (Bottom-up)

Zunächst müssen Eigenentwicklungen bewertet werden. Als Zielkriterium für zukünftige Erweiterungen dient die folgende SAP-Einordnung der „Clean-Core-Extensibility“ in vier Level.

• Level A – Ideal: Nutzung ausschließlich öffentlicher Schnittstellen mit Stabilitätskontrakten.
• Level B – Bewährt: Nutzung etablierter APIs und klassischer SAP-Technologien.
• Level C – Eingeschränkt: Lesezugriffe auf interne Datenobjekte.
• Level D – Kritisch: Nicht empfohlene Erweiterungen bzw. Modifikationen.

Klassifikation ist, wenn sie technisch klar definiert ist, eine tragfähige Grundlage für die systematische Bereinigung. Folgende SAP-Tools helfen hierbei:

• ABAP Test Cockpit (ATC): Klassifikation von Eigenentwicklungen, Erkennung von Regelverletzungen und „technischen Schulden“.
• Readiness Check (inkl. Simplification Items): Identifiziert Funktionen bzw. Artefakte, die mit S/4HANA entfallen, ersetzt oder zu transformieren sind

Zusätzlichen Nutzen liefern Partnerlösungen:

• smartShift: Automatisierte Bewertung und „Sanierung“ von kundeneigenem Code – inkl. Nutzungsbezug.
• IBIS Prof. Thome: Umfassende Bewertungen und ordnet genutzte Erweiterungen per Machine Learning fachlichen Prozesskontexten zu.

Schritt 2: Prozess- und Fit-Gap-Sicht (Top-down)

Auf der Prozessebene angekommen, stellt sich die nächste Leitfrage: Ist ein Sonderprozess wirklich notwendig – oder kann er zurück in den Standard gebracht werden? Die Clean-Core-Initiative kennt zwei klar getrennte Layer:

• Core-Prozesse werden primär über Konfiguration/Central Business Configuration (CBC) gestaltet, um die Standardnähe zu sichern.
• Wenige, klar begründete Sonderprozesse werden als Erweiterungen auf der BTP umgesetzt – nur dort, wo echter Nutzen oder ein Wettbewerbsvorteil entsteht.

Der angestrebte Clean Core für Prozesse wird so zum Innovationsvereinfacher: Kontinuierliche Verbesserungen lassen sich schneller ausrollen.

Während sich Custom Code noch mithilfe technischer Analysen recht gut beurteilen lässt, wird es bei organisationsspezifisch ausgestalteten Geschäftsprozessen deutlich anspruchsvoller. Gefragt ist eine sog. Fit-Gap-Analyse, die aktuelle Prozessnutzung, technologische Möglichkeiten, und Unternehmensanforderungen zusammenführt. Fit-Gap-Analysen prüfen, ob die aktuelle Ausprägung der genutzten Prozessvarianten …

• auf nicht kompatibler Technologie basiert (durch S/4HANA-Funktionalität oder BTP-Apps abzulösen),
• überkomplex ist oder
• unorthodoxes Customizing enthält, das in Cloud-basierten Clean-Core-Abläufen nicht tragfähig ist.

Readiness-Check-Prozessanalysen, SAP Signavio und weitere Partnerlösungen liefern hier Bewertungen; die SAP Best Practices definieren das Clean-Core-Zielbild.

Schritt 3: Genutzte Stammdaten in Prozessen als Hebel

Stammdatenqualität ist oft der blinde Fleck bei klassischen Prozessanalysen – fachlich jedoch entscheidend für saubere Prozesse. Diese Lücke schließt der SAP-Partner IBIS Prof. Thome, der sich auf die häufig sträflich vernachlässigten Stammdaten fokussiert. Im Rahmen der Analyse werden insbesondere folgende Fragestellungen betrachtet:

• Welche Stammdaten sind in welchen Prozessen relevant?
• Entsprechen die bestehenden Para­metrisierungen der tatsächlichen Prozessnutzung?
• In welchen Bereichen ist eine Verein­fachung der Stammdatenparameter zweckmäßig?

Neben der Untersuchung von Prozessnutzung und Datenkonsistenz kann auch die Bereinigung und Archivierung nicht genutzter Stammdaten einen wesentlichen Beitrag zur Verbesserung der Datenqualität leisten.

• IBIS Prof. Thome hat eigens hierfür eine fünfstufige Einordnung der Stammdaten­objekte (Material, Geschäftspartner etc.) und ihrer Prozessnutzung entwickelt – analog zu den Erweiterungen:
• A = aktive Nutzung in cleanen Prozessen (Public-Cloud-ready)
• B = Nutzung in angepassten Varianten (Z-Customizing; CBC-Mapping möglich)
• C = Nutzung in Prozessen mit Neuerungen (z. B. S&OP → IBP)
• D = Verwendeter Prozess entfällt mit S/4HANA bzw. stark kundenspezifisch → Überarbeitung nötig
• E = Nutzung unklar → manuelle Analyse

Wichtig sind alle drei Schritte: Nur Code-Analyse reicht nicht. Prozess- und Stammdatenbewertung sind gleichrangige „Reinigungsmittel“.

Nutzen für IT und Fachbereiche

Schnellere Innovation: Kontinuierliche Verbesserungen, zügige Nutzung neuer KI-Funktionen.

• Geringere TCO: Reduzierte Wartungs- und Betriebskosten, vereinfachte Upgrades.
• Robuste Governance: Weniger Streuung, höhere Transparenz, bessere Audit-Fähigkeit.
• Sicherheitsgewinn: Reduzierte Angriffsflächen.

Praxisleitfaden

1. Klassifizieren: Zuordnung zu Extensibility-Level A–D; Risikocluster bilden.
2. Prozess-Fit prüfen: Gegen SAP Best Practices und Zielprozesslandkarte; Fit-Gap dokumentieren.
3. Stammdaten bewerten: Data-Profiling; Einordnung A–E; Bereinigungs- und Vereinfachungsplan festlegen.
4. Entscheiden: Standard vs. Individualität als Mindset-Entscheidung – Business-Case je Abweichung.
5. Transformieren: Refaktorieren/Decouplen auf BTP, Konfiguration via CBC, ausmisten, archivieren.
6. Governance etablieren: Policies, Quality Gates, Lifecycle-Management.