ATC-XML-Reports automatisiert auswerten: Was die Praxis aus 50.000 Zeilen Custom-Code-Analyse zeigt

1. Das ATC-XML-Format: Was drinsteht und was nicht

Das ABAP Test Cockpit (Transaktion ATC, Bestandteil von SAP NetWeaver Application Server) liefert nach einem Lauf eine Befund-Liste. Über /UI2/ATC_RUN_RESULT_DOWNLOAD oder den Custom Code Migration Cockpit kann diese als XML exportiert werden. Pro Befund enthält die XML genau diese Felder:

• CHECK_NAME — die Prüfregel, die den Befund ausgelöst hat (z.B. CL_CI_TEST_CRITICAL_STATEMENTS)
• MESSAGE_ID — die konkrete Fehlermeldung der Prüfung
• OBJ_TYPE und OBJ_NAME — der betroffene Repository-Eintrag (PROG, FUGR, CLAS, etc.)
• PRIORITY — Schweregrad nach SAP-Konvention (1 = kritisch, 3 = optional)
• INCLUDE und LINE — Quelltext-Position
• MESSAGE_TEXT — Klartext-Hinweis

Was das XML nicht enthält und worauf Auswertungstools oft hereinfallen:

• Cyclomatic complexity — kommt aus separaten Quellen (z.B. CL_CI_TEST_PROCEDURE_FORMAL_PROCS oder externen Metrics-Tools)
• Tatsächliche Verwendung — ob das Z-Programm überhaupt noch produktiv aufgerufen wird, beantwortet ATC nicht; das ist die SYCM-Frage
• Migrations-Pattern-Klassifikation — keine Standard-Mapping-Tabelle ATC-Befund → S/4-Bereinigungs-Strategie

Eine Excel-Auswertung scheitert nicht daran, dass Excel zu schwach ist, sondern daran, dass die zur belastbaren Klassifikation nötigen Datenquellen erst kombiniert werden müssen. Pivots über OBJ_TYPE × PRIORITY ergeben Übersicht, aber keine Migrations-Empfehlung.

2. Die Komplexitäts-Heuristiken: Was wirklich greift

Eine produktive Pipeline kombiniert vier Heuristik-Quellen pro Befund:

Erstens, Cyclomatic Complexity — entweder aus einer ergänzenden ATC-Custom-Check-Suite oder aus externen ABAP-Metrics-Tools (Code Inspector mit erweiterten Profilen, Linecount-Aggregation). Eine Methode mit zyklomatischer Komplexität > 15 ist ein anderer Migrationsfall als ein einfacher SELECT-WRITE-Report.

Zweitens, Risiko-Hotspot-Cluster — bestimmte ABAP-Sprachfeatures sind in S/4HANA obsolet oder verboten:

• Direkte Selects auf Pool-/Cluster-Tabellen, die in HANA als transparente Tabellen oder gar nicht mehr existieren
• DELETE FROM TABLE OHNE WHERE auf Tabellen mit Universal-Journal-Bezug (ACDOCA, BSEG, BKPF)
• Implizit-typisierte Datentransporte (MOVE-CORRESPONDING ohne EXACT auf BSEG → Ziel-Struktur)
• KNA1/LFA1-Direktzugriffe statt Geschäftspartner-API
• Alte BAPI-Aufrufe, die in S/4 nicht mehr unterstützt werden (z.B. BAPI_DOCUMENT_CHANGE für FI-Belege)

Drittens, Migrations-Klassifikation — vier Stufen, die sich als Workflow-Tag bewährt haben:

• Quick-Win — Code, der mit einer kleinen mechanischen Anpassung funktioniert (BSEG-Zugriff in den Universal-Journal-Hilfeview umlenken)
• Refactor — strukturelle Anpassung nötig, aber ohne fachliche Logikänderung
• Re-implement — die Geschäftslogik bleibt, die Implementierung wird neu gemacht (z.B. SmartForm → Output Management)
• Out-of-scope — der Code wird stillgelegt, nicht migriert (Voraussetzung: SYCM bestätigt, dass der Code seit X Monaten keinen produktiven Aufruf hatte)

Viertens, kundenspezifische Cleansing-Regeln — nicht jede Heuristik ist allgemeingültig. Ein Versorger mit 30 Jahren ABAP-Historie hat andere «Quick-Win»-Muster als eine Stadtverwaltung mit hauptsächlich SAP-Standard und wenig Custom-Code. Diese Regeln gehören in eine externe Konfiguration, nicht in den Pipeline-Kern.

3. SYCM als zweite Datenquelle

Eine Beobachtung aus den ersten Pilot-Gesprächen, die immer wieder auftaucht: Beratungen unterstützen S/4-Migrationen primär mit ATC, weil ATC bereits Teil des Standard-Workflows ist. SYCM (System Custom-Code-Migration-Cockpit, Transaktion SYCM oder /SDF/CUSTCODE_REPORT) wird oft übersprungen, weil der Output sperriger ist und kein Standard-Excel-Template existiert.

Das ist eine vertane Chance. Die SYCM-Reference-Daten beantworten eine Frage, die ATC strukturell nicht beantworten kann: Welche Custom-Code-Objekte werden überhaupt noch produktiv genutzt? Bei einem typischen DACH-Mandantensystem zeigt SYCM, dass 20-40 Prozent der Custom-Code-Objekte zwar im System liegen, aber seit über 12 Monaten keinen Aufruf mehr hatten. Diese Out-of-scope-Befunde müssen bei der S/4-Migration nicht refaktoriert werden — sie gehören stillgelegt.

Die Kombination ATC + SYCM erlaubt drei Aussagen pro Befund: (a) ist es ein Migrations-Pflichtthema, (b) ist das betroffene Objekt überhaupt aktiv im Einsatz, (c) wer ruft es auf (Fachbereich, Schnittstelle, Hintergrundjob). Erst aus dieser Kombination wird die Quick-Win/Refactor/Re-implement/Out-of-scope-Klassifikation belastbar.

Eine bekannte Limitierung: das aktuelle SYCM-Reference-Format speichert maximal 5.000 Einträge pro Audit. Bei NIE-Klasse-Mandanten (mehrere zehntausend Custom-Code-Objekte) läuft die Reference-Auswertung deshalb im Sample-Modus. Das ist eine Roadmap-Limitierung, die offen kommuniziert gehört, weil sie die Aussagekraft der Out-of-scope-Klassifikation beschränkt.

4. DSGVO als Constraint: Warum das Tooling oft das Projektkonzept bestimmt

Beraterprojekte mit öffentlichem Sektor, Banken, Energieversorgern oder anderen KRITIS-Betreibern stehen vor einer einfachen Frage: Darf der ATC-XML-Export zu einem US-Cloud-Tool fließen? In den meisten DACH-Compliance-Regimen lautet die Antwort nein — auch wenn der Export technisch keine personenbezogenen Daten enthält.

Konsequenzen für die Tool-Auswahl:

• EU-Hosting ist Pflicht, nicht Wunsch. Hetzner Falkenstein/Nürnberg, OVHcloud Frankfurt, T-Systems oder vergleichbare DE/EU-Anbieter.
• Kein RFC-Zugang vom Tool zum Mandantensystem. Der Berater zieht den Export selbst, lädt ihn manuell hoch — der Datenfluss ist immer «Mandant → Berater-Workstation → Tool», nie «Tool zieht Daten aus Mandantensystem».
• AVV nach Art. 28 DSGVO als Anlage zum Beratervertrag, plus TOMs-Liste mit konkreten Verschlüsselungs- und Zugriffskonzepten.
• Sub-Processor-Verzeichnis — namentliche Auflistung aller Drittanbieter (Hosting, KI-Provider, CDN), 30-Tage-Vorankündigung bei Änderungen.

Das schließt die naheliegende Lösung (ATC-XML in ChatGPT pasten, Klassifikation per Prompt anfragen) für regulierte Mandanten praktisch aus. SaaS-Lösungen mit EU-Hosting + ohne SAP-Direktzugang gewinnen in dieser Klasse.

5. Praxis-Beispiel: Anonymisiertes Mini-Case

Ein Pilot mit einem kommunalen Versorger in NRW, im Brownfield-Migrationspfad nach S/4HANA:

• Code-Volumen: 47.000 Zeilen Custom-ABAP über 312 Programme, 89 Funktionsbausteine, 23 Klassen
• Zeitaufwand manuelle Auswertung (Senior-Berater, vorher): ca. 6 Personentage pro 1.000 ATC-Findings für die Erstklassifikation
• Zeitaufwand mit automatisierter Pipeline + Senior-Review: ca. 2 Personentage pro 1.000 Findings — Reduktion ca. 65 Prozent
• Klassifikations-Verteilung: 3.200 Zeilen Quick-Win, 18.000 Zeilen Refactor, 12.000 Zeilen Re-implement, 13.800 Zeilen Out-of-scope (durch SYCM als seit 12+ Monaten unbenutzt verifiziert)
• Out-of-scope-Befund war der größte einzelne Wertbeitrag: 13.800 Zeilen Code, die ohne Migration stillgelegt werden konnten, ersparen typischerweise 15-25 Personentage Refactoring-Aufwand pro 10.000 Zeilen.

Die Klassifikation ist immer ein Vorschlag, kein Urteil. Der Senior-Berater reviewt jeden Quick-Win-Vorschlag und überstimmt die Heuristik, wo nötig. Der Wertbeitrag der Pipeline ist nicht «Ersatz der Senior-Beurteilung», sondern «Wegfall der Erstsichtung».

6. Was nicht funktioniert: Ehrlichkeit baut Vertrauen

Drei Dinge, die in der Praxis nicht greifen — wichtig vor jedem Pilot-Gespräch zu kommunizieren:

Erstens, generische Code-Quality-Metriken treffen oft daneben. SonarQube-Ports auf ABAP, generische Linter, externe Cyclomatic-Complexity-Tools messen Eigenschaften, die in der ABAP-Welt nicht 1:1 das Migrations-Risiko abbilden. Ein hochkomplexer ABAP-Report, der seit 15 Jahren stabil läuft, ist ein anderer Migrations-Fall als ein neuer, einfacher Report mit fragwürdigen BSEG-Zugriffen.

Zweitens, automatisches Refactoring durch KI ist noch nicht produktionsnah genug. Auswertung und Klassifizierung — ja, mit guter Genauigkeit (>90 % bei klaren Fällen, deutlich niedriger bei Grenzfällen). Automatisches Refactoring im Sinne von «die KI schreibt den S/4-konformen Ersatzcode und der wird produktiv eingesetzt» — nein. Der generierte Code braucht denselben Senior-Review wie manuell geschriebener Code, sonst verschiebt sich das Risiko nur.

Drittens, ATC-Custom-Checks brauchen weiterhin manuelle Pflege. Wenn ein Beratungshaus eigene Custom-Checks unterhält (für unternehmensspezifische Coding-Conventions oder Mandanten-spezifische Migrations-Heuristiken), liegen diese in der eigenen Z_CL_CI_*-Familie und gehen nicht in die Pipeline ein, sofern die Pipeline nicht explizit damit gefüttert wird.

Habt ihr ähnliche Pipelines aufgebaut? Wie aggregiert ihr ATC-Befunde über mehrere Pakete? Welche Heuristiken funktionieren bei euren Mandanten zuverlässig, welche nicht? Antworten gerne per E-Mail an [email protected] — der Austausch in der Community ist genauso wichtig wie der Code.