Ein SAP-System mit 3.500 Eigenentwicklungen braucht 3.500 Entscheidungen: behalten, durch Standard ersetzen, neu bauen oder stilllegen. Selbst wenn man nur zehn Minuten je Programm ansetzt, sind das rund 580 Stunden für eine erste Durchsicht. Von Hand ist das vor dem Fit-to-Standard-Workshop nicht zu schaffen, und nach dem Workshop fängt die Arbeit erst an. Agenten ändern das. Sie gehen alle Empfehlungen durch, liefern die Statistik dazu, planen die Umsetzung und setzen die freigegebenen Pakete um.

Fit-to-Standard und der Custom Code

In der Explore-Phase von SAP Activate gehen Fachbereich und Berater in Fit-to-Standard-Workshops die Standardprozesse durch, je Geschäftsbereich. Was der Standard nicht abdeckt, kommt als Delta-Anforderung ins Backlog.

Für ein Unternehmen, das SAP zum ersten Mal einführt, funktioniert das gut. Kommt es aus einem gewachsenen SAP-System, fehlt im Workshop aber oft eine Übersicht, was das Unternehmen heute anders macht. Sie entsteht dann aus dem Gedächtnis der Key-User. Ein großer Teil dieser Abweichungen steht im Custom Code, auch das, woran im Workshop niemand denkt. Für den Workshop lesbar wird er erst, wenn man ihn den Geschäftsprozessen zuordnet.

Für jede dieser Eigenentwicklungen stellt sich dieselbe Frage: Gibt es dafür inzwischen etwas im Standard? Bei 3.500 Programmen lässt sich diese Frage im Workshop nicht für jedes einzeln stellen. Bei einer Systemkonvertierung stellt sich dieselbe Frage, dort in der Custom-Code-Analyse.

Die Menge ist das Problem

Ein einzelnes Programm zu bewerten, schafft ein erfahrener Berater. Das Problem ist die Menge. 580 Stunden sind für eine Person gut drei Monate Vollzeit, und in dieser Zeit ändert sich das System weiter. Oft kommt deshalb nur eine Auswahl in den Workshop, und der Rest bleibt ungeprüft.

Einen Teil liefert SAP selbst. Die Nutzungsdaten aus SCMON und SUSG zeigen, was nicht läuft, und die Custom Code Migration App zeigt, was unter SAP S/4HANA technisch anzupassen ist. Darauf baut die Durchsicht auf. Je Programm bleibt die Frage, ob es inzwischen etwas im Standard gibt und was im System daran hängt.

Das kann ein Agent übernehmen. Er geht jede Empfehlung durch, nicht nur eine Stichprobe, und wiederholt das nach jedem neuen Export. Daraus entsteht eine Statistik über alle Empfehlungen, die es von Hand praktisch nie gibt.

Die Statistik über alle Empfehlungen

Konstruiertes Beispiel: 3.500 Empfehlungen aufgeteilt in Stilllegen 1.180, durch Standard ersetzen 460, behalten 820, neu bauen 260 und offen 780. 2.720 Fälle gehen mit Beleg zur Freigabe, 780 in den Workshop. — Konstruiertes Beispiel mit 3.500 Eigenentwicklungen. Von Hand wären es rund 580 Stunden für eine erste Durchsicht.

Auf einen Blick ist zu sehen, wo die Arbeit liegt. Programme ohne Nutzung in dreizehn Monaten und ohne Aufrufer sind Stilllegungskandidaten. SAP empfiehlt, die Nutzung sechs bis achtzehn Monate lang zu messen, mindestens über einen Jahresabschluss. Programme, für die es einen Standardkandidaten mit Quelle gibt, sind Ersatzkandidaten. Ob ein genutztes Programm ohne Standardkandidaten bleibt oder neu gebaut wird, hängt vor allem davon ab, ob es auf freigegebenen Schnittstellen aufsetzt oder auf Modifikationen und nicht freigegebenen SAP-Objekten. Das ist die Unterscheidung aus dem Clean-Core-Ansatz von SAP. Diese Fälle gehen mit ihren Quellen zur fachlichen Freigabe. In den Workshop kommen nur die, bei denen die Antwort wirklich offen ist, im Beispiel 780 statt 3.500.

Je Prozess aufgeschlüsselt wird die Statistik zur Grundlage für die Planung. Sie zeigt, welcher Prozess die meisten offenen Fälle hat und wo sich am meisten stilllegen lässt.

Konstruiertes Beispiel: dieselbe Aufteilung je Prozess, von Order-to-Cash mit 880 Programmen und 190 offenen Fällen bis Record-to-Report mit 400 Programmen und 85 offenen Fällen — Dieselben erfundenen Zahlen je Prozess. Rechts stehen die Programme gesamt und davon die offenen Fälle. „Prozessübergreifend“ fasst Programme zusammen, die keinem einzelnen Prozess zugeordnet sind.

Planung und Abarbeitung mit Agenten

Hier liegt der eigentliche Unterschied. Die Statistik ist die Grundlage, die Schritte danach können Agenten ebenfalls übernehmen.

Ablauf in fünf Schritten: Sysparency analysiert, Agent sortiert vor, Fachbereich gibt frei, Agent plant, Agent arbeitet ab. Nach dem nächsten Export zeigt die Statistik den Fortschritt. — Der Fachbereich entscheidet, die Arbeit davor und danach übernehmen Agenten.

Vorsortieren. Der Agent bewertet jede Empfehlung. Zu jedem Standardkandidaten sagt er, ob die Fakten ihn stützen, ob sie dagegen sprechen oder ob noch etwas fehlt, und nennt die Quellen.
Freigeben. Eindeutige Fälle bestätigt der Fachbereich, offene entscheidet der Workshop.
Planen. Der Agent schlägt Arbeitspakete je Prozess vor. Zusammenhängende Programme kommen in dasselbe Paket, die Reihenfolge folgt den Abhängigkeiten, auch über Prozessgrenzen hinweg.
Abarbeiten. Agenten setzen die freigegebenen Pakete über den SAP-ADT-MCP-Server im Entwicklungssystem um, so wie bei der Migration von zwölf Dynpro-Transaktionen auf einem Trial-System. Test, Transport und Abnahme laufen wie gewohnt, jedes Paket bleibt einzeln prüfbar.
Nachziehen. Nach jedem neuen Export geht der Agent die Empfehlungen erneut durch. Die Statistik zeigt dann, was erledigt ist und was neu dazukam, auch wenn das Projekt Monate dauert.

Vorsortieren, Planen und Nachziehen kann ein Agent heute mit dem Sysparency-MCP-Server, der ihm den Wissensgraphen öffnet, und den Dokumentations-MCP-Servern von SAP, das Umsetzen mit dem SAP-ADT-MCP-Server. Der Sysparency-MCP-Server funktioniert mit jedem MCP-fähigen Client, etwa Claude, ChatGPT, Microsoft Copilot oder Langdock. Sie nutzen also das Werkzeug, das in Ihrem Unternehmen freigegeben ist. Die Bewertung der Standardkandidaten direkt im Sysparency-Report entwickeln wir gerade.

Dafür muss der Agent das Programm im Zusammenhang verstehen

Den aktuellen SAP-Standard findet ein Agent in der Dokumentation. Damit seine Empfehlungen tragen, muss er aber die Eigenentwicklung verstehen und wissen, wie sie ins Gesamtsystem eingepasst ist: wer sie aufruft, welche anderen Programme an ihr hängen, welche Tabellen sie sich teilen und ob sie überhaupt läuft. Sonst empfiehlt er womöglich für ein Programm eine Standard-App, obwohl ein abhängiges Programm im Standard nicht abgebildet werden kann. Umgekehrt ersetzt eine Standardfunktion manchmal gleich mehrere Eigenentwicklungen, etwa ein Menü, die Reports, die es aufruft, und die Pflegeprogramme für dieselben Tabellen.

Diesen Zusammenhang liefert Sysparency. Es analysiert nicht nur einzelne Programme, sondern das ganze System: Prozesszuordnung, Aufrufe in beide Richtungen, Tabellen, Standardschnittstellen, Nutzung und die Transaktionen und Reports, die im System des Kunden vorhanden sind. In einem Test mit HR-Fällen eines Kunden hat das Modell mit diesem Kontext Standardkandidaten genannt, die auch ein erfahrener HR-Berater vorgesehen hatte, etwa die Transaktion PT40 für das eigene Menü der Zeitbeauftragten.

Das gilt nicht nur für SAP: Läuft ein Prozess auch durch Anwendungen in Java, .NET oder COBOL, analysiert Sysparency diese ebenfalls, und der Agent sieht auch diesen Teil.

Was der Workshop weiter entscheidet

Ob eine Abweichung ein Wettbewerbsvorteil ist, eine Pflicht oder nur eine Lücke von damals, steht in keinem Code und in keiner Dokumentation. Das entscheiden Fachbereich und Berater im Workshop. Der Unterschied ist, dass sie dort nicht mehr 3.500 Programme vor sich haben, sondern nur die Fälle, bei denen die Antwort tatsächlich offen ist, und zu jedem die Quellen beider Seiten.

Wie das für Ihr System aussieht, zeigen wir Ihnen gerne an einer Analyse Ihres Custom Codes. Demo anfragen