Z-Tabellen und Customizing-Einträge agentengestützt reviewen — pro Feld Mapping, Deprecation oder Archivierung vorschlagen, mit Audit-Spur für das Migrations-Review.
Kurz gesagt: Agent reviewt Z-Tabellen und Customizing-Einträge, schlägt pro Feld Mapping, Deprecation oder Archivierung vor. Stack: Claude (Anthropic direkt) oder Azure OpenAI Switzerland, SAP-Metadaten-Parser auf DD02L/DD03L, statische ABAP-Code-Analyse, optional DB-Statistiken aus Oracle oder HANA. Branchen mit dem grössten Hebel: SAP-lastige Umgebungen quer durch Manufacturing, Versicherung und Public Sector — überall dort, wo ECC oder S/4HANA über zehn Jahre gewachsen ist und niemand mehr genau weiss, welche Z-Felder noch leben. Pro Feld entsteht ein strukturierter Vorschlag plus Audit-Eintrag — der Migrationsexperte reviewt nur die "unclear"-Fälle und die "deprecate"-Empfehlungen in hohen Risiko-Bereichen. Anschlussfähig an die SAP-Migration und an das spätere Audit & Sign-off.
Z-Tabellen mit über zehn Jahren Customizing — niemand weiss mehr, welche Felder noch verwendet werden, welche Reports darauf zugreifen, oder ob ein Feld nur "für später" mal angelegt wurde. Bei der Migration steht die Frage: jedes Feld einzeln durchgehen (Wochen Z-Tabellen-Archäologie) oder pauschal alle übernehmen (Migration wird unnötig teuer und das Zielsystem startet bereits mit Altlast)? Beides ist falsch, aber das eine kostet Zeit, das andere kostet Substanz. In der Praxis wird in fast jedem Projekt die zweite Variante gewählt — nicht weil sie richtig wäre, sondern weil der Cut-over-Termin steht und die manuelle Variante nicht skaliert.
Das Problem hinter dem Problem: Custom-Felder und Z-Tabellen haben keine eindeutige Nutzungs-Signatur. Ein Feld kann im DDIC existieren, in einem Report referenziert sein, aber seit fünf Jahren keine Schreibzugriffe haben — oder umgekehrt befüllt sein, ohne dass je ein Report es liest. Wer das einzeln aufdröselt, kombiniert mehrere Datenquellen: ABAP-Code-Suche über Reports, Smart Forms, Adobe Forms, Funktionsbausteine; DB-Statistiken zu Schreibzugriffen; Sample-Daten-Verteilung; BI/BW-Extraktor-Definitionen; IDoc-Mappings; ggf. eigene Fiori-Apps oder externe Schnittstellen. Genau diese Kombination kann ein Agent in Minuten pro Feld liefern, was manuell oft Stunden braucht.
Der Agent arbeitet auf einem Inventar von Z-Tabellen und Z-Feldern aus dem SAP-Quellsystem. Pro Feld sammelt er strukturierte Signale: Schema-Definition aus DD02L/DD03L, Schreibzugriffs-Statistik aus DB-Historie (Oracle, HANA), Lese-Referenzen aus statischer ABAP-Analyse über Reports, Smart Forms, Adobe Forms und Funktionsbausteine, BI/BW-Extraktor-Verwendung, Sample-Daten-Verteilung (Füllrate, Default-Konstanz, Wertebereich). Aus diesen Signalen leitet er eine Klassifikation ab — active, unused, partial oder unclear — und schlägt pro Feld eine Aktion vor: map to target, deprecate oder archive only.
Modellseitig wird Claude für längere Reasoning-Ketten über mehrere Code-Stellen und Metadaten-Quellen eingesetzt; Azure OpenAI Switzerland kommt zum Zug, wenn Daten-Residenz in der Schweiz Vertragsbedingung ist. Tool-seitig greift der Agent über den SAP-Metadaten-Parser direkt auf das DDIC zu, der ABAP-Analyzer läuft als statischer Pass über das Repository, DB-Statistiken werden über einen Read-only-Connector geholt. Guardrails: kuratiertes Eval-Set pro Klassifikations-Klasse, Cost-Caps pro Reconciliation-Run, harte Eskalation auf jedes Feld mit IDoc-Verwendung oder externer Schnittstellen-Referenz, vollständiges Read-only-Verhalten — der Agent schreibt nichts in das SAP-System, sondern nur in den Audit-Log und das Reconciliation-Sheet.
Wichtig: Der Agent entscheidet nicht final. Er bereitet vor und legt sich nur dort fest, wo die Signale eindeutig sind. Für jedes Feld mit widersprüchlichen Signalen (z.B. ABAP-Referenz vorhanden, aber kein Schreibzugriff seit fünf Jahren) klassifiziert er als unclear und legt es dem Migrationsexperten vor. Genauso eskaliert er jeden deprecate-Vorschlag in Bereichen mit hohem Risiko — Finanzbuchhaltung, Steuerlogik, regulierte Stammdaten. Der Hebel kommt aus dem Long-Tail klar klassifizierbarer Felder, nicht aus mutigen Black-Box-Entscheidungen.
Ein SAP-S/4HANA-Migrationsprojekt — Komposit, kein realer Klient — mit 800 Z-Tabellen, davon rund 400 mit unklarem Status. Mischung aus aktiv genutzten Custom-Tabellen (z.B. ein Z-Auftragstyp mit täglichen Schreibzugriffen und mehreren Report-Anbindungen), längst toten Feldern aus alten Customizings (eine Z-Tabelle aus einer Reorganisation vor acht Jahren, befüllt einmal, seither leer), und Tabellen mit gemischter Verwendung (zwei aktive Felder, zwölf totgepflegte, drei "unclear").
Der Agent (Claude, über Azure OpenAI Switzerland für FADP-Datenresidenz) arbeitet das Inventar in einem Reconciliation-Run ab: pro Tabelle parst er das Schema, kombiniert Schreib-Statistiken aus der HANA-DB mit ABAP-Code-Referenzen aus dem Quell-Repository, prüft BI-Extraktoren und IDoc-Mappings, klassifiziert pro Feld. Bei rund 70 % der unklaren Felder ist die Klassifikation eindeutig — entweder klar active mit Mapping-Vorschlag oder klar unused mit deprecate-Vorschlag. Die übrigen 30 % landen mit offengelegtem Reasoning in der Review-Queue. Die Migrations-Experten arbeiten die "unclear"-Liste und die "deprecate"-Vorschläge in regulierten Bereichen mit den jeweiligen Fachbereichs-Owners ab — typische Erkenntnis im Gespräch: "Ah ja, das Feld war für ein Projekt vor acht Jahren gedacht, das nie ging — kann weg."
Typischer Effekt: Klare Empfehlungen pro Feld in Stunden statt Wochen Z-Tabellen-Archäologie — directional, nicht als veröffentlichte Benchmark, und stark abhängig vom Custom-Anteil und der Repository-Qualität. Der Hebel sitzt nicht im einzelnen Feld, sondern in der Trennung: der Agent übernimmt den Long-Tail strukturell klar klassifizierbarer Felder, die Migrations-Experten reviewen nur die "unclear"-Fälle und die "deprecate"-Vorschläge in hohen Risiko-Bereichen. Als Nebenprodukt entsteht ein vollständiger Audit-Trail pro Feld: welche Signale der Agent gesehen hat, welche Klassifikation er ableitete, welche Aktion er vorschlug, welche menschliche Entscheidung folgte. Dieser Trail ist GoBD- und FADP-anschlussfähig und ist die saubere Basis für das spätere Migrations-Audit & Sign-off — er wird nicht nachträglich rekonstruiert, sondern fällt mit der Reconciliation selbst an. Voraussetzung für den Effekt ist ein zugängliches Quell-Repository und Lese-Zugriff auf DB-Statistiken; ohne diese Quellen wird die Klassifikation dünn.
Mehrere Signale kombiniert: (a) Schreibzugriffs-Statistik aus DB-Historie auf HANA oder Oracle, (b) Lese-Referenzen aus statischer ABAP-Code-Analyse über Reports, Smart Forms, Adobe Forms und Funktionsbausteine, (c) BI/BW-Extraktor-Verwendung, (d) Sample-Daten-Verteilung (Felder, die zu 99 % leer sind oder einen konstanten Default tragen, sind ein starkes Signal für "unused"). Felder ohne jegliches Signal landen als unused, Vorschlag deprecate. Felder mit widersprüchlichen Signalen — z.B. eine ABAP-Referenz aus einem alten Report, aber kein Schreibzugriff seit fünf Jahren — landen als unclear und gehen direkt an den Migrationsexperten. Ein einzelnes Signal reicht nie für eine "deprecate"-Empfehlung; die Klassifikation entsteht aus der Kombination.
Der Agent legt einen Audit-Eintrag an: was er gesehen hat, warum er sich nicht festlegt, welche Hypothesen er hat. Die Entscheidung trifft der Mensch. Standard-Pattern: Migrations-Experten arbeiten die "unclear"-Liste batch-weise mit den jeweiligen Fachbereichs-Owners ab. Häufige Erkenntnis im Gespräch — das Feld war für ein Projekt vor acht Jahren gedacht, das nie ging; kann weg. Oder umgekehrt: das Feld wird nur einmal pro Jahr im Jahresabschluss befüllt, fällt in der Statistik durch, muss aber unbedingt mit. Diese Fälle erkennt der Agent nicht aus den Signalen allein. Er erkennt nur, dass er sie nicht erkennt — und übergibt sauber an den Menschen. Genau diese explizite "unclear"-Kategorie ist der Punkt, an dem Agent und Fachseite produktiv zusammenarbeiten.
Quellseitig SAP ECC 6.0 und neuer, einschliesslich S/4HANA on-premises und S/4HANA Cloud. Der Metadaten-Parser greift auf DD02L/DD03L für Tabellenstrukturen und Feld-Definitionen, statische ABAP-Analyse läuft über das Quell-Repository für Code-Referenzen, DB-Statistiken werden je nach Plattform aus Oracle oder HANA gelesen. Bei Z-Tabellen mit External-System-Schnittstellen — typisch IDoc-Mappings, eigene RFC-Anbindungen, oder externe Reports über Open Data Protocol — wird der Scope explizit erweitert. Hier kommt klassische Discovery zum Tragen: die externen Verbraucher müssen einmal manuell katalogisiert werden, der Agent macht das schnell vorab und liefert eine Liste der Felder, bei denen die externe Verwendung zu prüfen ist.
Dieser Use Case sitzt in der Praktik Agentensysteme & Workflows und ist der natürliche Vorbau zur agentischen SAP-Migration sowie zum Migrations-Audit.
Praktik: Wie Agenten in Produktionsumgebungen gebaut, betrieben und auditfähig gemacht werden — Patterns, Guardrails, Plattformwahl.
Migrations-Objekte pro Backlog-Eintrag vorbereiten — Schema parsen, Z-Tabellen erkennen, Mapping vorschlagen, sauber eskalieren.
Datenqualitäts-Defekte im Zielsystem klassifizieren, schema-aware fixen, Confidence-Gate und Audit-Eintrag pro Patch.
Auditfertige Diff-Reports mit Diskrepanz-Klassifikation und Sign-off-Paketen für Cut-over.
Z-Tabellen-Reconciliation lohnt sich, wenn der Custom-Anteil substanziell ist. Bei SAP-Standard-nahen Systemen ist klassisches Cleanup oft schneller. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir ehrlich, ob Ihr Inventar ein Kandidat ist.
Discovery-Call anfragen