SAPs Botschaft ist unmissverständlich: Der Kern muss sauber bleiben. Mit der Clean Core-Strategie hat SAP eine klare Linie gezogen — keine Z-Entwicklungen im Kern, keine Modifikationen an SAP-Standard-Objekten, keine Abkürzungen, die heute bequem sind und morgen den Upgrade-Pfad blockieren. Die Realität in den meisten SAP S/4HANA-Transformationsprojekten sieht anders aus.
„Clean Core ist keine technische Entscheidung — es ist eine strategische. Jede Eigenentwicklung, die heute genehmigt wird, ist eine Hypothek auf die Innovationsfähigkeit von morgen."
Das Clean-Core-Dilemma: Warum der Standard trotzdem verloren geht
Die Clean-Core-Doktrin ist inhaltlich unbestritten. Trotzdem entstehen in jedem größeren S/4HANA-Projekt Dutzende bis Hunderte kundenspezifische Entwicklungen. Der Grund liegt selten in bewusster Entscheidung — er liegt in mangelndem Wissen über die Möglichkeiten des Standards.
SAP S/4HANA umfasst über 17.000 Fiori-Apps, Tausende Customizing-Transaktionen und eine wachsende Bibliothek an BAdI-Erweiterungspunkten. Kein einzelner Berater, kein Architektur-Team kann dieses Universum vollständig überblicken. Das Ergebnis: Der Standard-First-Check wird zum Nadelöhr — oder er wird übersprungen.
Die drei häufigsten Ursachen für vermeidbare Eigenentwicklungen
- Unkenntnis des Standards: Fachbereiche und selbst erfahrene SAP-Berater kennen nur einen Bruchteil der verfügbaren Fiori-Apps und Customizing-Optionen.
- Lösungsorientierte Anforderungen: Statt Probleme zu beschreiben, definieren Fachbereiche konkrete Lösungen — und schließen damit implizit den Standard aus.
- Zeitdruck: Die Prüfung des Standards dauert Stunden bis Tage. Unter Projektdruck wird die Prüfung verkürzt oder ganz übersprungen.
SAP-Domain-RAG: Eine spezialisierte KI-Pipeline für den Standardabgleich
Generische Large Language Models kennen SAP nur oberflächlich. Für einen zuverlässigen Standardabgleich braucht es Domain-Specific AI — ein System, das die SAP-Welt nicht nur dem Namen nach kennt, sondern inhaltlich durchdringt. RequirementIQ setzt dafür auf eine spezialisierte RAG-Pipeline, die wir als SAP-Domain-RAG bezeichnen.
Was die SAP-Domain-RAG-Pipeline umfasst
| Wissensdomäne | Umfang | Verwendungszweck |
|---|---|---|
| SAP-Transaktionen | Vollständiger Transaktionskatalog S/4HANA | Funktionale Abdeckungsprüfung |
| Fiori-App-Bibliothek | 17.000+ Apps mit Funktionsbeschreibungen | Standard-UI-Alternativen identifizieren |
| BAPIs & APIs | Geschäftsobjekt-Schnittstellen | Integrationsmöglichkeiten prüfen |
| Customizing-Dokumentation | IMG-Struktur mit Konfigurationsoptionen | Parametrische Anpassungen statt Code |
| BAdI-Verzeichnis | Erweiterungspunkte nach Modul | Saubere Erweiterung ohne Kernmodifikation |
| SAP Signavio Best Practices | 5.000+ Prozessmodelle | Prozessstandard-Abgleich |
Die Pipeline verarbeitet jede eingehende Anforderung in drei Schritten: Zunächst wird die fachliche Intention extrahiert — was will der Anwender erreichen? Dann erfolgt ein semantischer Abgleich gegen alle Wissensdomänen. Abschließend werden die besten Standardalternativen mit Konfidenzwerten und Quellenangaben präsentiert. Unser Zielwert: Retrieval Precision@5 ≥ 70% — das heißt, unter den Top-5 vorgeschlagenen Standardlösungen ist mindestens eine valide Alternative.
Standard-First-Prinzip: Von der Heuristik zum systematischen Prozess
Das Standard-First-Prinzip ist in der SAP-Community kein neues Konzept. Was bisher fehlte, war eine Operationalisierung, die nicht von der Expertise einzelner Berater abhängt. RequirementIQ macht den Standardabgleich zu einem automatisierten, reproduzierbaren Schritt im Anforderungsprozess.
Der Standardabgleich im Detail
Für jede Anforderung generiert RequirementIQ eine Clean-Core-Impact-Bewertung mit vier Dimensionen:
- Standard-Coverage: Welcher Anteil der Anforderung lässt sich mit SAP-Standard abdecken? (0–100%)
- Erweiterungsoptionen: Welche BAdIs, BTP-Extensions oder Fiori-Anpassungen stehen zur Verfügung?
- Upgrade-Impact: Welches Risiko entsteht bei einer Eigenentwicklung für zukünftige Upgrades?
- TCO-Projektion: Was kostet die Eigenentwicklung über den gesamten Lebenszyklus im Vergleich zum Standard?
Der wahre Wert eines Standardabgleichs liegt nicht darin, Eigenentwicklungen zu verbieten — sondern darin, fundierte Entscheidungen zu ermöglichen. Wer wissentlich vom Standard abweicht, tut dies aus guten Gründen. Wer es aus Unwissenheit tut, verschwendet Ressourcen.
BTP Side-by-Side Extensions: Der Clean-Core-konforme Ausweg
Nicht jede Anforderung lässt sich mit dem SAP-Standard erfüllen. Für diese Fälle empfiehlt SAP das BTP-Extensibility-Modell: Eigenentwicklungen werden nicht im ERP-Kern platziert, sondern als Side-by-Side Extensions auf der SAP Business Technology Platform. Der Kern bleibt sauber, die Erweiterung ist unabhängig deploybar und upgradefähig.
RequirementIQ identifiziert automatisch Anforderungen, die sich für eine BTP-Extension eignen, und klassifiziert sie entsprechend. Das Architektur-Team erhält nicht nur die Empfehlung „BTP statt Z-Entwicklung", sondern konkrete Hinweise auf verfügbare BTP-Services, relevante APIs und Best-Practice-Patterns.
Entscheidungsmatrix: Standard vs. Customizing vs. BTP vs. Eigenentwicklung
| Option | Clean-Core-Konformität | Aufwand | Upgrade-Risiko | Empfohlener Einsatz |
|---|---|---|---|---|
| SAP-Standard | Vollständig | Gering | Keines | Immer bevorzugen |
| Customizing | Vollständig | Gering–Mittel | Minimal | Parametrische Anpassungen |
| BAdI/BTE | Hoch | Mittel | Gering | Definierte Erweiterungspunkte |
| BTP Extension | Hoch | Mittel–Hoch | Gering | Neue Funktionalität außerhalb Kern |
| Z-Entwicklung (Kern) | Keine | Hoch | Hoch | Nur mit dokumentierter Begründung |
Integration mit SAP Signavio: Prozessstandards als zweite Verteidigungslinie
Neben dem technischen Standardabgleich bietet RequirementIQ eine zweite Prüfebene: den Abgleich mit SAP Signavio Best-Practice-Prozessmodellen. SAP Signavio umfasst über 5.000 vordefinierte Prozessmodelle, die branchenübergreifende Best Practices abbilden.
Wenn ein Fachbereich eine Anforderung stellt, die einen Geschäftsprozess betrifft, prüft RequirementIQ automatisch, ob ein Signavio-Referenzprozess existiert. Falls ja, wird die Abweichung zwischen gewünschtem und Standardprozess visualisiert. Die Entscheidung, vom Standard abzuweichen, wird damit transparent, nachvollziehbar und — vor allem — bewusst getroffen.
Messbare Ergebnisse: Clean-Core-KPIs in der Praxis
Der Erfolg einer Clean-Core-Strategie lässt sich in konkreten KPIs messen. RequirementIQ liefert die Datenbasis für ein kontinuierliches Monitoring:
- Custom Code Ratio: Anteil der Anforderungen, die in Eigenentwicklung münden (Zielwert: < 10%)
- Standard-Coverage-Rate: Prozentsatz der Anforderungen, die vollständig durch SAP-Standard bedient werden
- BTP-Redirect-Rate: Anteil der Eigenentwicklungen, die auf BTP umgeleitet werden
- Upgrade-Risk-Score: Aggregierter Risikowert des gesamten Custom-Code-Portfolios
Diese KPIs ermöglichen dem CIO und CTO eine datengetriebene Steuerung der Clean-Core-Strategie — nicht auf Basis von Bauchgefühl, sondern auf Basis realer Anforderungsdaten, die in Echtzeit ausgewertet werden.
Clean Core ist kein Zustand — es ist ein Prozess. Und jeder Prozess braucht Messung, um gesteuert werden zu können. KI liefert die Messung, die bisher gefehlt hat.
Praxisbeispiel: Von der Fachbereichsanforderung zum Standardvorschlag
Wie sieht der KI-gestützte Standardabgleich in der Praxis aus? Ein konkretes Beispiel: Ein Fachbereich im Einkauf formuliert die Anforderung: „Wir brauchen eine Übersicht aller offenen Bestellungen mit Lieferverzögerungen, die wir nach Lieferant filtern und als Excel exportieren können."
Ohne Standardabgleich würde diese Anforderung typischerweise als Custom Report spezifiziert werden — Entwicklungsaufwand 15–20 Tage. RequirementIQ identifiziert stattdessen drei Standardalternativen:
- Fiori-App F2886 „Monitor Purchase Order Items": Deckt 90% der Anforderung ab, inklusive Filter nach Lieferant und Lieferverzug. Standard-Export nach Excel ist integriert.
- Customizing-Option: Die fehlenden 10% lassen sich über eine CDS-View-Erweiterung abdecken — kein Z-Code, sondern eine saubere BAdI-basierte Erweiterung.
- SAP Signavio Referenzprozess: Der Prozess „Purchase Order Monitoring" zeigt, wie der Standardprozess optimal genutzt wird.
Das Ergebnis: Statt 15–20 Tagen Custom-Entwicklung, 2 Tage Konfiguration. Statt einer Z-Entwicklung im Kern, eine standardkonforme Lösung. Statt einer Upgrade-Hypothek, eine zukunftssichere Implementierung.
Fazit: KI als Hüter des Clean Core
Die Clean-Core-Strategie scheitert nicht an fehlendem Willen — sie scheitert an fehlender Operationalisierung. Wenn der Standardabgleich von der Expertise einzelner Berater abhängt, ist er nicht skalierbar. Wenn er manuell durchgeführt wird, ist er nicht konsistent. Wenn er unter Zeitdruck steht, wird er übersprungen.
Domain-spezifische KI mit einer auf SAP-Wissen trainierten RAG-Pipeline löst dieses Problem strukturell. RequirementIQ macht den Standardabgleich zu einem automatischen, konsistenten und skalierbaren Bestandteil jedes Anforderungsprozesses — und wird damit zum operativen Fundament einer Clean-Core-Strategie, die nicht nur auf dem Papier existiert.
Für CIOs und CTOs bedeutet das: Clean Core wird von einer strategischen Absichtserklärung zu einem operativ durchgesetzten Prinzip. Nicht durch mehr Regeln und Governance-Meetings, sondern durch intelligente Automation, die den Standard sichtbar macht — bevor die erste Zeile Custom Code geschrieben wird. Das ist der Unterschied zwischen einer Clean-Core-Strategie, die auf Folien steht, und einer, die im System lebt.