01

Export aus dem Kundensystem ziehen

Ihr Senior-Berater führt im Mandanten-System einen der zwei SAP-Standard-Exporte aus — das System verlässt kein einziges Byte. Variante A: ATC-Lauf in SE38/SE80, dann /UI2/ATC_RUN_RESULT_DOWNLOAD als XML. Variante B: Im Custom-Code-Migration-Cockpit (Transaktion SYCM oder /SDF/CUSTCODE_REPORT) den ZIP-Export ziehen.

5-15 Minuten je nach Systemgröße

Kein RFC, kein Tunnel, kein Berater-Account auf Mandanten-Seite für ERPforgeAI nötig. Beide Exporte sind reine SAP-Standard-Tools, die Sie ohnehin verwenden dürfen.

02

Upload in den ERPforgeAI-Workspace

XML- oder ZIP-Datei wird per Drag-and-Drop in den Browser geladen. Pro Mandant ein eigener Workspace mit getrennter Aufbewahrung. Vor dem Hochladen: optionaler Layer-A-Redaktor, der Identifikatoren (System-IDs, Hostnames, Mandanten-Klartextnamen) durch Platzhalter ersetzt — bevor Daten Ihre Workstation verlassen.

unter 1 Minute

Upload-Limit aktuell: 5.000 SYCM-Reference-Einträge pro Audit. Bei extrem großen Custom-Code-Bases läuft die Reference-Auswertung im Sample-Modus — dies wird vor Pilot-Start offen besprochen, siehe Preise.

03

Analyse läuft — klassifiziert, gruppiert, priorisiert

Jeder Custom-Code-Befund wird klassifiziert nach Clean-Core-Level A/B/C/D: A = trennscharf in Z-Namensraum, kein Migrationsrisiko. D = tiefer Eingriff in SAP-Standard, hoher Aufwand. Modifikationen werden separat ausgewiesen mit Paket, Komponente und Aufwandsbild. Z-Eigenentwicklungen erhalten einen Migrations-Pattern-Tag (z.B. FAE-Loop → ABAP-SQL-Joins bei S/4-Migrationen).

~2-5 Minuten Verarbeitungszeit

Modell-Audit-Trail pro Befund: Welches LLM, welche Eingabe-Snippets, welche Heuristik. Ihre Senior-Berater prüfen, korrigieren, überstimmen — korrigierte Fälle fließen in unsere Lernschleife (anonymisiert, nur ABAP-Pattern, nie Mandanten-Daten).

04

Report im Beratungs-Branding herunterladen

Drei Output-Formate aus einem Audit: PDF für das Mandanten-Lenkungsausschuss-Meeting, XLSX mit allen Befunden für Backlog-Import (JIRA-Mapping vorbereitet), CSV für weitere Auswertung. Alle drei im Branding Ihrer Beratung — Logo, Farben, Footer-Texte, Rechtshinweise. ERPforgeAI taucht in keinem Output auf, auch nicht in den Datei-Metadaten.

Sofort nach Analyse

Re-Run beliebig oft — wenn Sie Klassifikations-Schwellen nachjustieren oder neue Findings nach einem Folge-ATC-Lauf hinzuziehen wollen, ist das Teil des Workflows, nicht ein Counter.

Eine ausführliche Praxisbeschreibung dieser Pipeline mit Mini-Case und Effort-Daten finden Sie im Blog-Beitrag zu ATC-XML-Auswertung →

Datenfluss

Vier Stationen — alle in Deutschland

Für DACH-Beratungen mit öffentlich-rechtlichen Mandanten ist der Datenfluss Pflichtprüfung. Hier die vier Stationen, die ein Befund durchläuft.

  1. Workstation des Beraters → ERPforgeAI bei Hetzner Falkenstein/Nürnberg. TLS 1.3-Upload, Cloudflare-Proxy mit DE-Edge bevorzugt. Layer-A-Redaktor optional client-seitig für Identifikator-Maskierung.
  2. ERPforgeAI-Backend → Anthropic-Claude-API. Die LLM-Anfrage enthält nur Code-Snippets und Steckbrief-Metadaten, keine Mandanten-Klartext-Identifikatoren. BYOK-Option: Sie stellen den eigenen Anthropic-Key, dann sieht Anthropic Ihre Beratungs-Account-ID statt unserer Master-Account.
  3. Klassifikations-Logik im ERPforgeAI-Backend. Heuristik-Regeln plus LLM-Vorschlag werden zusammengeführt. Audit-Trail pro Befund persistiert in der DE-Datenbank (Hetzner Falkenstein/Nürnberg). Aufbewahrung: 30 Tage nach Pilot-Ende, dann automatische Löschung.
  4. Report-Generierung → Download über HTTPS. PDF/XLSX/CSV werden im Browser des Beraters gespeichert. Auf der ERPforgeAI-Seite bleiben sie zur Re-Run-Verfügbarkeit, können aber jederzeit per Knopfdruck in der UI gelöscht werden.

Was nicht passiert: Mandanten-Daten verlassen den Hetzner-DE-Verbund nicht. Es gibt keine US-Sub-Processors. Anthropic verarbeitet die LLM-Anfrage in EU-Region, sofern der Anthropic-EU-Endpoint stabil verfügbar ist; siehe Sicherheits- und Datenschutzmodell für die aktuelle Region-Karte.

Abgrenzung

Was ERPforgeAI nicht ersetzt

Das Tool nimmt Ihrer Beratung den Erstsichtungs-Aufwand ab. Es ersetzt nicht die Senior-Bewertung und nicht die Mandantenkommunikation.

Nicht: SAP-Standard-ATC

Der ATC-Lauf bleibt Ihre Aufgabe (oder die Ihres Mandanten). ERPforgeAI verarbeitet das XML-Ergebnis — es ersetzt nicht den Lauf selbst.

Nicht: Senior-Bewertung

Klassifikationen sind Vorschläge mit Audit-Trail. Die finale Migrations-Entscheidung pro Befund trifft Ihr Senior-Berater — das ist im AGB explizit festgehalten.

Nicht: Mandanten-Beziehung

Die Kommunikation an den Mandanten läuft über Ihren Account-Manager, mit Reports im Branding Ihrer Beratung. ERPforgeAI hat keinen direkten Mandantenkontakt.

Nicht: SAP-Vertragsbeziehung

ERPforgeAI ist unabhängig von der SAP SE. Wir nutzen ausschließlich SAP-Standard-Schnittstellen (XML/ZIP-Export). Keine SAP-Lizenz wird für ERPforgeAI benötigt — Ihre vorhandene SAP-Lizenz reicht.

Optional · Erweiterung

Zusatzpfad: ABAP-Code-Generierung aus Steckbrief

Für Beratungen, die nach der Audit-Phase ohnehin Z-Code zur Migrations-Bereinigung schreiben müssen, gibt es eine zweite Pipeline: ABAP-Code-Generierung mit System-Steckbrief. Drei Schritte, kein Muss, in jedem Pilot freigeschaltet.

01

Steckbrief vom Kundensystem holen

Kopieren Sie Z_ERPFORGE_01_STECKBRIEF in SE38 auf dem System Ihres Kunden. Das Programm erkennt automatisch: Release, SP-Level, 14 ABAP-Sprachfeatures, installierte Komponenten, Tabellen und Funktionsbausteine.

30 Sekunden
↓ Z_ERPFORGE_01_STECKBRIEF.txt herunterladen
▶ Beispiel-Ausgabe ansehen
=== System Steckbrief ===
System-ID:    NPL
SAP_BASIS:    740 SP30
Systemtyp:    ECC + BW + HR

=== Feature-Checks ===
Inline DATA()        AKTIV
NEW #()              AKTIV
CORRESPONDING #()    AKTIV
COND / SWITCH        AKTIV
REDUCE               INAKTIV
FILTER               INAKTIV
Mesh Types           INAKTIV

=== Komponenten (CVERS) ===
SAP_ABA    740  SP30
SAP_HR     608  SP99
SAP_BW     740  SP30

=== Tabellen ===
BSEG       existiert
ACDOCA     nicht gefunden
          
02

Hochladen und Anforderung beschreiben

Laden Sie den Steckbrief hoch – Ihr Kundensystem wird automatisch erkannt. Optional: DD-Export für exakte Felddefinitionen. Dann beschreiben Sie Ihre Anforderung in Klartext.

2 Minuten
03

Code erhalten, reviewen, ausliefern

In ~15 Sekunden erhalten Sie syntaxfehlerfreien ABAP-Code. Angepasst an das exakte System: Kein COND #(), wenn der Kernel es nicht unterstützt. Sie reviewen, passen Details an und liefern an Ihren Kunden.

~15 Sekunden
Vorher → Nachher

Von der Anforderung zum Code

Ihre Anforderung
„Erstelle einen ALV-Report, der alle offenen Bestellungen nach Lieferant gruppiert anzeigt, mit Aging-Analyse (0-30, 31-60, 61-90, über 90 Tage). Selektionsbildschirm mit Lieferantenbereich und Buchungskreis.“
Zielsystem: NPL · ECC 6.0 · 7.40 SP30
Z_OPEN_PO_AGING.abap
*& Report Z_OPEN_PO_AGING *& Offene Bestellungen mit Aging REPORT z_open_po_aging. TYPES: BEGIN OF ty_output, lifnr TYPE ekko-lifnr, name1 TYPE lfa1-name1, ebeln TYPE ekko-ebeln, netwr TYPE ekpo-netwr, bucket TYPE char10, END OF ty_output. * Inline DATA() – aktiv lt. Steckbrief DATA(gt_output) = VALUE ty_t_output( ). SELECT k~lifnr k~ebeln p~netwr FROM ekko AS k INNER JOIN ekpo AS p ON k~ebeln = p~ebeln INTO TABLE @DATA(lt_raw) WHERE k~bstyp = 'F'. * ALV, Aging-Buckets, Summen ...

Inline DATA() nur, weil der Steckbrief es erlaubt. Auf einem 7.00-System stünde hier DATA gt_output TYPE TABLE OF ty_output.

Bereit zum Starten?

Demo-Analyse kostenlos. Pilotpartner-Programm: €4.900 / 60 Tage.

Pilotpartner anfragen →
Pilotpartner anfragen →