Wie SAP BTP, das Model Context Protocol und KI die Analyse gewachsener Eigenentwicklungen vor der S/4HANA Migration beschleunigen.
Ende 2027 läuft die Mainstream-Wartung für SAP ERP 6.0 und damit für SAP ECC aus. Wer länger bleiben will, zahlt für die Extended Maintenance bis Ende 2030 einen Aufschlag. Ein Horizont bis 2033 existiert nur über die Transition Option der SAP ERP Private Edition und ist an Bedingungen geknüpft.
Für die meisten ECC-Kunden steht die S/4HANA Migration damit auf der Agenda. Und mit ihr eine unbequeme Frage. Welche Eigenentwicklungen müssen wirklich mit nach S/4HANA?
In den meisten Projekten wird zuerst gefragt, wie viel die Anpassung des Custom Codes kostet. Die wichtigere Frage lautet, ob der Code überhaupt noch gebraucht wird. Genau hier spielen KI und MCP ihre Stärke aus, wenn man sie richtig einsetzt.
Gewachsener Custom Code ohne Dokumentation
In vielen ECC-Systemen stecken Hunderte bis Tausende kundeneigene Objekte. Typisch sind
- Z-Programme und individuelle Reports
- User-Exits, BAdIs und Erweiterungen
- kundeneigene Tabellen und Datenmodelle
- Schnittstellen zu Fremdsystemen
- Hintergrundjobs und automatisierte Abläufe
Die meisten entstanden, weil der damalige Standard eine Anforderung nicht abdeckte. Seitdem wurden sie erweitert und umgebaut, aber selten sauber dokumentiert. Die ursprünglichen Entwickler sind oft längst nicht mehr im Haus.
S/4HANA bringt viele dieser Funktionen inzwischen im Standard mit, häufig als Fiori-App. Wer Custom Code ungeprüft migriert, zahlt doppelt. Einmal für die Anpassung und danach jedes Jahr für Wartung und Tests. Mit dem Clean-Core-Ansatz, den SAP für S/4HANA vorgibt, passt das nicht zusammen.
Was MCP leistet und was nicht
Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen strukturiert auf Systeme, Daten und Werkzeuge zugreifen. Ein KI-Assistent arbeitet damit nicht mehr nur mit hochgeladenen Dokumenten, sondern ruft gezielt Informationen aus dem angebundenen System ab.
Für eine ECC-Analyse kann die KI damit
- die Funktionsweise einer Eigenentwicklung beschreiben,
- Abhängigkeiten zu Tabellen, Programmen und Schnittstellen sichtbar machen,
- fehlende Dokumentation ergänzen,
- den Anpassungsbedarf für S/4HANA zusammenfassen und
- Standardfunktionen als mögliche Alternativen vorschlagen.
Wichtig ist die Abgrenzung. MCP analysiert keinen Code. Es ist die Leitung, über die Daten und Funktionen kontrolliert bereitgestellt werden. SAP selbst formuliert es in seiner Referenzarchitektur nüchtern. MCP ist ein Verbindungsprotokoll und macht KI-Ergebnisse nicht automatisch fachlich richtiger. Die Qualität entsteht durch die bereitgestellten Daten und durch die Menschen, die die Ergebnisse bewerten.
SAP BTP als offizieller Weg zwischen ECC und KI
Wer ECC an KI anbinden will, sollte mit dem Weg beginnen, den SAP selbst vorsieht. Das ist die SAP Business Technology Platform (BTP), konkret das MCP Gateway der SAP Integration Suite.
Dort lässt sich ein MCP-Server direkt auf ein RFC-basiertes Backend aufsetzen. SAP führt SAP ECC 6.0 (NetWeaver 7.0 bis 7.5) und ECC 5.0 in der Dokumentation ausdrücklich als vollständig unterstützt. Ausgewählte RFC-fähige Funktionsbausteine werden als MCP-Tools bereitgestellt, bis zu 50 pro MCP-Server.
Ein On-Premise-ECC wird über die BTP Connectivity Services und den SAP Cloud Connector angebunden. Das ECC muss dafür nicht öffentlich erreichbar sein. Das Gateway übernimmt Authentifizierung, Rate Limiting, Monitoring und die Versionierung der Tools.
Seit 2026 gibt es einen zweiten, gewichtigen Grund für diesen Weg. Die aktuelle SAP API Policy (Version 4, April 2026) schränkt in Abschnitt 2.2.2 den Einsatz von KI-Systemen ein, die eigenständig Folgen von API-Aufrufen planen und ausführen. Erlaubt ist das nur über Architekturen, die SAP dafür vorsieht, und das MCP Gateway der Integration Suite ist ein solcher Weg. Wie weit die Regelung im Einzelfall reicht, sollte vertraglich geprüft werden. Für den produktiven Einsatz ist die BTP aber die Variante mit der geringsten Compliance-Unsicherheit.
Vor der Entscheidung stehen drei Punkte
- Serviceplan prüfen. Die MCP-Funktionen hängen vom Integration-Suite-Serviceplan ab (SAP-Hinweis 2903776).
- Daten gezielt freigeben. Für eine Altlastenanalyse müssen passende RFC-Bausteine bereitstehen, etwa für Repository- und Nutzungsinformationen. Das ist Projektarbeit, kein Schalter.
- Als Brücke verstehen. RFC ist für bestehende ECC-Systeme pragmatisch. Neue Integrationen gehören auf API-basierte Architekturen.
Die SAP-Werkzeuge liefern die Datenbasis
Niemand muss bei null anfangen. SAP liefert die technischen Fakten bereits mit.
| Werkzeug | Was es liefert |
|---|---|
| SAP Readiness Check | Simplification Items, Custom-Code-Analyse, empfohlene Fiori-Apps, Sizing |
| ABAP Test Cockpit (ATC) | Prüfung des Custom Codes auf S/4HANA-Inkompatibilitäten |
| Custom Code Migration (Fiori-App) | Technische Bewertung und Vorbereitung der Eigenentwicklungen |
| SCMON und SUSG | Welche kundeneigenen Programme tatsächlich aufgerufen werden |
Diese Werkzeuge zeigen, was technisch angepasst werden muss. Sie zeigen nicht, ob eine Entwicklung noch einen geschäftlichen Zweck erfüllt oder ob der Standard sie ersetzt. Genau diese Lücke schließt eine KI-gestützte Auswertung.
Ein Tipp aus der Praxis. Nutzungsdaten sollten mindestens ein volles Geschäftsjahr abdecken, damit Quartals- und Jahresabschlussläufe nicht fälschlich als ungenutzt erscheinen.
Datenschutz zuerst, dann KI
Die erste Frage jedes Entscheiders ist berechtigt. Wohin gehen unser Code und unsere Nutzungsdaten?
Kundeneigener ABAP-Code enthält Geschäftslogik, Preisregeln und manchmal fest verdrahtete Kunden- oder Lieferantennummern. Nutzungsdaten aus SCMON oder SUSG lassen sich unter Umständen einzelnen Personen zuordnen. Beides darf nicht unkontrolliert an ein Sprachmodell gehen.
Wir arbeiten deshalb mit klaren Regeln
- Nur Modelle und Plattformen mit vertraglich geregelter Datenverarbeitung, ohne Nutzung der Daten für Training und bevorzugt mit Verarbeitung in der EU.
- Personenbezogene Daten vor der Analyse entfernen oder pseudonymisieren.
- MCP-Tools nur lesend und mit minimalen Berechtigungen bereitstellen. Ein technischer Benutzer mit Vollzugriff hat in diesem Setup nichts verloren.
- Jeden Tool-Aufruf protokollieren, damit nachvollziehbar bleibt, welche Daten das Modell gesehen hat.
Wer die BTP nutzt, kann Sprachmodelle zusätzlich über den Generative AI Hub in SAP AI Core betreiben und bleibt damit vollständig innerhalb der SAP-Governance.
Vorgehen bei der S/4HANA Migration in fünf Schritten
- Bestandsaufnahme. Eigenentwicklungen, Schnittstellen und Hintergrundjobs werden vollständig erfasst.
- Technische Analyse. Readiness Check, ATC sowie SCMON und SUSG liefern Kompatibilität und tatsächliche Nutzung.
- KI-gestützte Dokumentation. Die KI führt die Ergebnisse zusammen und beschreibt jede Entwicklung in verständlicher Sprache. Über MCP holt sie bei Bedarf weitere Details aus dem System.
- Abgleich mit dem Standard. Für jede Entwicklung werden S/4HANA-Funktionen und Fiori-Apps als Ersatzkandidaten geprüft.
- Fachliche Entscheidung. SAP-Berater und Fachbereiche legen fest, was übernommen, angepasst oder abgelöst wird.
Aus einer technischen Inventur wird so eine belastbare Entscheidungsvorlage für die Zielarchitektur.
Praxisbeispiel OP-Report gegen Fiori-App
Ein Unternehmen nutzt seit Jahren einen eigenen Report für offene Debitorenposten. Er entstand, weil dem damaligen Standard bestimmte Auswertungen fehlten. Über die Jahre kamen Selektionsfelder, Filter und Sonderlogik dazu. Im Readiness Check taucht er als anpassungsbedürftig auf.
Der übliche Reflex ist, den Anpassungsaufwand zu schätzen und den Report zu migrieren. Wir drehen die Reihenfolge um.
Zuerst beschreibt die KI, was der Report tatsächlich tut. Welche Tabellen er liest, welche Felder er ausgibt, wie oft und von wem er genutzt wird. Dann schlägt sie die Fiori-App Manage Customer Line Items als Standardkandidaten vor.
Bewiesen ist damit noch nichts. Erst der fachliche Abgleich zeigt, ob Filter, Summen, Berechtigungen und Sonderfunktionen im Standard abgedeckt sind. Oft zeigt sich, dass die App den Großteil abdeckt und der Rest über Layouts oder eine schlanke Erweiterung lösbar ist.
Die Frage lautet dann nicht mehr, wie man den alten Report modernisiert. Sie lautet, ob man ihn überhaupt noch braucht.
Keep, Adapt, Replace, Retire oder Review
Jede Eigenentwicklung landet am Ende in genau einer von fünf Kategorien.
| Entscheidung | Wann sie greift |
|---|---|
| Keep (übernehmen) | Die Entwicklung bleibt nötig und passt in die Zielarchitektur. |
| Adapt (anpassen) | Die Funktion bleibt, muss aber technisch oder fachlich modernisiert werden. |
| Replace (ersetzen) | Eine Standardfunktion oder Fiori-App löst die Entwicklung ganz oder teilweise ab. |
| Retire (stilllegen) | Die Entwicklung wird nachweislich nicht mehr gebraucht. |
| Review (prüfen) | Die Datenlage reicht für eine sichere Entscheidung noch nicht aus. |
Bei Retire ist Vorsicht Pflicht. Ein Programm, das monatelang nicht lief, kann für den Jahresabschluss, eine steuerliche Meldung oder einen seltenen Sonderprozess unverzichtbar sein. Jede KI-Empfehlung braucht deshalb einen technischen Nachweis und eine fachliche Freigabe.
Ist die BTP zwingend nötig?
Nein. Für die meisten Unternehmen ist sie aber der richtige Startpunkt.
Für eine einmalige Bestandsaufnahme reicht es oft, die Ergebnisse von Readiness Check, ATC und SCMON strukturiert zusammenzuführen und in einer abgesicherten KI-Umgebung auszuwerten. Ein Live-Zugriff auf das ECC ist dafür nicht nötig. Für die reine Code-Analyse im Entwicklerumfeld gibt es zudem MCP-Anbindungen über die ABAP Development Tools.
Eigene MCP-Server ohne BTP sind technisch möglich. Sie verlagern aber Sicherheit, Betrieb, Updates und die Einhaltung der SAP API Policy vollständig ins eigene Haus. Dazu kommt, dass sich das MCP-Protokoll selbst schnell weiterentwickelt und Versionssprünge Anpassungen erzwingen.
Die BTP lohnt sich vor allem, wenn KI dauerhaft und für mehrere Anwendungsfälle an SAP angebunden werden soll. Ob sich das rechnet, hängt von bestehenden BTP-Verträgen, dem Serviceplan und dem geplanten Umfang ab.
KI unterstützt, der Berater entscheidet
Eine technische Analyse ist noch keine Migrationsentscheidung.
KI liest Code, macht Abhängigkeiten sichtbar, schreibt Dokumentation und schlägt Alternativen vor. Sie kennt aber nicht die Gründe hinter historischen Entscheidungen, die Anforderungen einzelner Fachbereiche oder die Wechselwirkungen mit Nachbarmodulen. Gerade in gewachsenen Landschaften steckt die eigentliche Bedeutung eines Prozesses oft nicht im Code.
Hier entscheidet Erfahrung. Ein SAP-Berater stellt den Fachbereichen die richtigen Fragen, bewertet die Auswirkungen auf End-to-End-Prozesse und Schnittstellen und erarbeitet mit dem Unternehmen eine tragfähige Entscheidung. Auch ob eine Standard-App einen kundeneigenen Prozess wirklich ersetzt, lässt sich nicht allein technisch beantworten.
Der Mehrwert der KI liegt in der Zeit, die sie spart. Analyse- und Dokumentationsarbeit, die sonst Wochen bindet, wird spürbar kürzer. Die gewonnene Zeit gehört den Fragen, die zählen.
Fazit
Das ECC-Wartungsende 2027 ist der Anlass, die S/4HANA Migration ist die Chance. Wer seinen Custom Code vorher konsequent prüft, migriert weniger, wartet weniger und kommt dem Clean Core deutlich näher.
SAP BTP, MCP und KI machen diese Prüfung schneller und nachvollziehbarer, sofern Datenschutz und Governance von Anfang an mitgedacht werden. Die Entscheidung bleibt bei Menschen mit SAP-Erfahrung.
Welche Ihrer ECC-Eigenentwicklungen müssen wirklich mit nach S/4HANA? Sprechen Sie uns an. Wir schauen uns Ihre Ausgangslage gemeinsam an und geben Ihnen eine ehrliche Einschätzung, wo der größte Hebel liegt.