SAP Clean Core wird häufig als Architekturthema für S/4HANA-Programme behandelt. Modifikationen gering halten, unterstützte Erweiterungsmuster nutzen, Custom Code aus dem Core verlagern und künftige Upgrades weniger schmerzhaft machen. Das alles stimmt. Doch es greift an der Entscheidung vorbei, die für viele Mittelständler im DACH-Raum inzwischen entscheidend ist: Ist die SAP-Landschaft des Unternehmens verlässlich genug für AI-gestützte Arbeit?
Bevor Sie fragen, was SAP Joule, SAP Business AI oder ein externer Enterprise Agent automatisieren kann, sollten Sie eine grundlegendere Frage beantworten: Kann ein automatisiertes System nachvollziehen, wie Arbeit in SAP tatsächlich erledigt wird, ohne auf undokumentierte Ausnahmen, versteckte Tabellen, das Wissen einzelner Mitarbeitender oder fragile Custom Exits angewiesen zu sein?
Für viele Unternehmen lautet die Antwort: nur teilweise.
Das bedeutet nicht, dass AI-Initiativen warten sollten, bis eine perfekte S/4HANA-Landschaft erreicht ist. Perfektion ist eine teure Ausrede für Untätigkeit. Es bedeutet aber, dass Clean Core als Disziplin für AI Readiness behandelt werden muss. Das Ziel ist nicht, jede Erweiterung zu eliminieren. Es geht darum, klare und verlässliche Grenzen zwischen Standardprozessen, Governed Extensions, Geschäftsregeln und den Handlungen eines Agent zu schaffen.
Ein AI Agent braucht mehr als eine funktionierende Transaktion
Ein menschlicher SAP-Anwender kann ein unvollkommenes System umgehen. Ein erfahrener Einkäufer weiß, dass eine Bestellanforderung mit einer bestimmten Kombination von Feldern eine zusätzliche Prüfung in einer Tabelle erfordert. Eine Fachkraft im Finanzbereich erkennt an einer Freitextnotiz, dass eine Rechnung nicht automatisch gebucht werden darf. Ein Mitarbeitender im Kundenservice weiß, dass eine Liefersperre technisch korrekt, kommerziell aber manchmal irrelevant ist.
Solche Umgehungslösungen erscheinen selten in Prozessdiagrammen. Sie stecken in individueller Erfahrung, E-Mail-Verläufen, Nebentabellen, Custom Reports und informellen Übergaben.
Ein AI Agent verfügt nicht über diese institutionelle Intuition, sofern das Unternehmen nicht gezielt den Kontext, die Regeln, Berechtigungen und Tools bereitstellt, die für sein Handeln erforderlich sind. Er muss wissen, welche Daten maßgeblich sind, welche Aktion erlaubt ist, unter welchen Bedingungen eine menschliche Freigabe nötig wird und woran sich eine Ausnahme erkennen lässt. Hängt ein Workflow von einem Custom Field ab, dessen Bedeutung je Werk variiert, von einem User Exit ohne klaren Verantwortlichen oder von einer manuell gepflegten Tabelle außerhalb des Governed Process, agiert der Agent auf instabilem Grund.
Zuverlässige Automatisierung setzt verlässliche Verträge voraus. Im SAP-Kontext umfassen diese Verträge stabile Business Objects, dokumentierte Prozesszustände, explizite Entscheidungsregeln, kontrollierte Schnittstellen und klare Verantwortlichkeiten. Clean Core verbessert diese Voraussetzungen. Er reduziert das Ausmaß an verborgenem Verhalten, das ein Agent andernfalls selbst erschließen müsste.
Deshalb sind Erweiterungsschulden nicht bloß ein Thema technischer Schulden. Sie sind Entscheidungsschulden. Jede undokumentierte Erweiterung erhöht den Aufwand, um festzustellen, ob ein Agent sicher handeln kann.
Erweiterungsschulden erzeugen falsches Vertrauen in SAP-AI-Programme
In frühen Diskussionen über Enterprise AI zeigt sich häufig dasselbe Muster. Ein Team identifiziert einen plausiblen Workflow, demonstriert eine konversationelle Oberfläche, verbindet einige Datenquellen und schließt daraus, dass der Prozess bereit für Automatisierung sei. Die Demonstration funktioniert, weil sie dem Idealfall folgt.
Der Produktionsbetrieb sieht anders aus. Ein produktionsreifer Agent muss mit unvollständigen Stammdaten, widersprüchlichen Statuswerten, Freigabelimits, gesperrten Lieferanten, geänderten Lieferterminen, Dubletten und Anfragen umgehen, die technisch möglich, aber kommerziell falsch sind. Außerdem muss er eine nachvollziehbare Spur hinterlassen, die ein Process Owner, die interne Revision oder das IT-Team verstehen kann.
Customising erschwert das, wenn es die tatsächliche Prozesslogik verschleiert.
Betrachten wir einen Einkaufs-Workflow. Die scheinbare Aufgabe könnte darin bestehen, verspätete Bestellungen zu identifizieren und Entwürfe für Lieferanten-Nachfassaktionen zu erstellen. Das ist ein vergleichsweise sicherer, unterstützender Use Case, wenn der Agent freigegebene Daten liest, Kommunikationsentwürfe vorschlägt und das Versenden dem Einkäufer überlässt. Das Risiko verändert sich, wenn derselbe Agent Bestelldaten ändern, Bestellanforderungen freigeben oder Substitutionen empfehlen soll. Dann muss er kundenspezifische Toleranzlogiken, Freigaberouten, Quellenlistenregeln, Lieferantenrestriktionen und die nachgelagerten Folgen jeder Aktion verstehen.
Liegen diese Regeln verteilt in Custom Code, Tabellen, E-Mail-Konventionen und dem Wissen von zwei langjährigen Mitarbeitenden, ist nicht der Agent das Problem. Das Problem ist das Operating Model.
Eine konversationelle Ebene beseitigt keine Prozesskomplexität. Sie kann Komplexität leichter zugänglich machen, aber unklare Logik nicht sicher machen. Im Gegenteil: Eine überzeugende Chat-Oberfläche kann Unsicherheit verdecken, bis sie eine Aktion auslöst, die niemals hätte automatisiert werden dürfen.
Agent-sichere Workflows von Workflows mit Refactoring-Bedarf trennen
Die praktische Frage lautet nicht, ob ein Prozess Standard-SAP oder kundenspezifisches SAP ist. Beide können sinnvolle AI-Anwendungen unterstützen. Entscheidend ist, ob der Workflow eine ausreichend klare Handlungsgrenze besitzt.
Ein Agent-sicherer Workflow verfügt üblicherweise über ein definiertes Business Object, vertrauenswürdige Quelldaten, eine erkennbare Prozessverantwortung und ein Ergebnis, das sich validieren lässt. Seine Berechtigungen entsprechen zudem dem Risiko der Aufgabe. Einen Vertragsstatus auszulesen und eine Zusammenfassung vorzubereiten, ist etwas anderes als Zahlungsbedingungen zu ändern. Eine Antwort auf eine Kundenanfrage zu entwerfen, ist etwas anderes als eine Gutschrift anzulegen. Eine Liste von Ausnahmen für einen Controller abzugleichen, ist etwas anderes als Buchungssätze zu buchen.
Der sicherste Einstieg liegt oft dort, wo AI Menschen hilft, Arbeit zu interpretieren, zu priorisieren, vorzubereiten oder weiterzuleiten, statt irreversible Änderungen auszuführen. Das ist keine zaghafte Strategie. So schaffen Unternehmen belastbare operative Evidenz zu Datenqualität, Ausnahmequoten und Nutzervertrauen, bevor sie die Befugnisse eines Agent erweitern.
Refactoring sollte dem Geschäftsrisiko folgen, nicht architektonischer Mode. Manche Erweiterungen verdienen Aufmerksamkeit, weil sie einen hochwertigen Workflow blockieren. Andere können unangetastet bleiben, weil sie einen stabilen Prozess mit geringen Änderungen unterstützen, auf den kein Agent zugreifen muss. Jedes Custom Object als Clean-Core-Notfall zu behandeln, schafft ein unnötig großes Programm. Keines davon für relevant zu halten, führt zu einer AI-Roadmap, die auf Wunschdenken basiert.
Eine sinnvolle Bewertung unterscheidet zwischen Erweiterungen, die über eine Governed Interface bereitgestellt werden können, Erweiterungen, deren Regeln dokumentiert und von der Präsentationslogik getrennt werden müssen, sowie Erweiterungen, die vollständig außerhalb der Agent-Grenze bleiben sollten. Die letzte Kategorie ist wichtig. Manche Entscheidungen sind zu kontextabhängig, zu geschäftskritisch oder zu schwach strukturiert, um sie sicher zu delegieren. Sie menschlich geführt zu belassen, ist eine Designentscheidung und kein Mangel an Ambition.
Custom Logic behalten, aber ihre Rolle explizit machen
„Clean Core“ wird manchmal als „alles Kundenspezifische entfernen“ verstanden. Das ist für viele Mittelständler weder realistisch noch wünschenswert. Kundenspezifische Prozesse können echte Wettbewerbsvorteile abbilden: ein spezialisiertes Preismodell, eine branchenspezifische Fulfilment-Abfolge, ein unverwechselbarer Qualitätsprozess oder ein sorgfältig entwickelter Service-Workflow.
Das Problem ist nicht Custom Logic an sich. Das Problem ist Custom Logic ohne explizite Schnittstelle, ohne verantwortlichen Owner, ohne nutzbare Dokumentation und ohne beobachtbares Verhalten.
Wenn ein Agent an einem kundenspezifischen Prozess teilnehmen soll, darf er nicht die internen Mechanismen einer Legacy-Erweiterung durchlaufen müssen. Er sollte eine definierte Fähigkeit aufrufen. Statt einem Agent beispielsweise zu erlauben, mehrere Felder über verschiedene Tabellen hinweg zu aktualisieren, stellen Sie eine freigegebene Aktion bereit, die Voraussetzungen prüft, die relevanten Regeln anwendet, die Entscheidung protokolliert und ein klares Ergebnis zurückgibt.
Dieser Ansatz schafft eine sinnvolle Grenze. Der Agent übernimmt Interpretation und Orchestrierung. Die Governed SAP Capability erzwingt die Geschäftslogik. Wo Risiko oder Unklarheit dies erfordern, bleibt die menschliche Freigabe bestehen.
Geben Sie einem Agent keinen breiten Zugriff, nur weil das einfacher ist, als eine saubere Aktion zu entwerfen. Breite technische Zugriffe können einen Prototyp beschleunigen, erschweren später jedoch die Rechenschaftspflicht. Außerdem wird jede undokumentierte Abhängigkeit zu einem potenziellen Produktionsvorfall. Eine eng definierte Aktion wirkt zunächst aufwendiger, lässt sich aber in der Regel schneller testen, absichern, überwachen und verbessern.
Process Observability ist die fehlende Ebene
Die meisten SAP-AI-Projekte konzentrieren sich zunächst auf Modellauswahl, Assistant-Fähigkeiten oder Integrationsoptionen. Das ist relevant, aber dort entscheiden sich viele Deployments nicht über Erfolg oder Misserfolg. Ausschlaggebend ist Observability: die Fähigkeit zu erkennen, was der Workflow getan hat, welche Informationen er verwendet hat, welche Regel oder Freigabe das Ergebnis geprägt hat und an welcher Stelle der Prozess ins Stocken geriet.
Für einen Enterprise-AI-Workflow sollte ein grundlegender Audit Trail zwischen der Empfehlung des Agent, den abgerufenen Daten, dem aufgerufenen Tool oder der ausgelösten Geschäftsaktion sowie der menschlichen Entscheidung unterscheiden, sofern eine erforderlich war. Process Owner benötigen ausreichend Transparenz, um wiederkehrende Fehler zu korrigieren. Die IT braucht genügend Einblick, um Zugriffs- und Integrationsprobleme untersuchen zu können. Geschäftsführung und Fachverantwortliche brauchen genügend Sichtbarkeit, um beurteilen zu können, ob der Workflow nützliche Ergebnisse liefert oder lediglich Aktivität erzeugt.
Das ist besonders in SAP-Umgebungen wichtig, in denen die sichtbare Transaktion oft nur der letzte Schritt einer längeren Entscheidungskette ist. Empfiehlt ein Agent, eine Bestellung zu beschleunigen, sollte eine Führungskraft nachvollziehen können, ob diese Empfehlung auf einem echten Versorgungsrisiko, einem veralteten Datenpunkt, einer kundenspezifischen Statusinterpretation oder einer unvollständigen Bestandsansicht beruht.
Ohne diese Transparenz reagieren Unternehmen auf AI-Fehler meist auf eine von zwei wenig hilfreichen Arten: Sie überreagieren und stoppen jede Automatisierung, oder sie reagieren zu wenig, weil die Ausgabe plausibel klingt. Beides ist keine Governance.
Clean Core als Priorisierungsinstrument behandeln
Die stärkste AI-Roadmap beginnt nicht mit einem Plattformkatalog. Sie beginnt mit einer Prozesslandkarte, die zeigt, wo SAP-Daten und Entscheidungen verlässlich genug sind, um Unterstützung oder Automatisierung zu ermöglichen.
Wählen Sie zunächst eine begrenzte Zahl von Workflows mit spürbarer operativer Relevanz und überschaubarem Handlungsrisiko. Untersuchen Sie den tatsächlichen Ablauf, nicht nur den dokumentierten Prozess. Identifizieren Sie, wo Custom Code Verhalten verändert, wo Daten dupliziert werden, wo Ausnahmen manuell entschieden werden und wo Mitarbeitende auf Informationen außerhalb von SAP angewiesen sind. Definieren Sie anschließend die kleinste sinnvolle AI-Rolle: abrufen, erklären, empfehlen, entwerfen, weiterleiten oder ausführen.
Diese Analyse zeigt, ob die unmittelbare Einschränkung in Erweiterungsschulden, der Stammdatenqualität, unklarer Prozessverantwortung, fehlender Integration oder schlicht einem überambitionierten Automatisierungsziel liegt. Jede dieser Ursachen verlangt einen anderen Eingriff.
Für ein mittelständisches Unternehmen im DACH-Raum ist das kommerziell relevant. Der Wert von AI entsteht selten durch einen umfassenden Plattform-Rollout. Er entsteht dadurch, eine kleine Anzahl wichtiger Workflows schneller, konsistenter und weniger abhängig von knappem Betriebswissen zu machen. Wer stark in eine Agent-Schicht investiert, bevor die Prozessgrenze verstanden ist, riskiert einen weiteren Pilotversuch, der Stakeholder beeindruckt, aber nie Vertrauen für den Produktionsbetrieb gewinnt.
So betrachtet ist Clean Core keine SAP-Aufräumübung. Es ist die Arbeit, Geschäftsabläufe für Software lesbar zu machen, die schon bald an ihnen beteiligt sein darf.
Ein Diagnostic identifiziert, welche SAP-Workflows für AI-Unterstützung oder Automatisierung bereit sind, wo Erweiterungsschulden inakzeptable Risiken schaffen und was refaktoriert werden muss, bevor ein Agent im Produktionsbetrieb handelt.
Kontexthinweis: Dieser Artikel basiert auf Implementierungsprinzipien und nicht auf externen Quellen.