Custom-Code- und Systemanalyse für SAP ECC und S/4HANA

Wissen, was der eigeneSAP-Code anrichtet –und was jetzt zu tun ist.

Z-Insight liest Eigenentwicklungen, Customizing, Transporte, Laufzeitfehler und Belegfluss Ihres SAP-Systems, verbindet sie zu belegten Erkenntnissen und ordnet alles den End-to-End-Prozessen nach SAP-Standard zu. Daraus entstehen Aufwand, Fahrplan und Maßnahmen – für die S/4HANA-Transformation, Clean Core und einen stabilen Betrieb: eine Arbeitsliste mit Zähler bis zur Konversion, Korrekturen mit Prüfnachweis, die im System nachgemessen werden, und eine Überwachung, die nach jedem Transportimport und nach dem Go-live meldet, was sich verändert hat.

Demo vereinbaren Einsatzszenarien ansehen

Liest nurSchreibt nie ins SAP-System – Whitelist lesender Bausteine
Keine InstallationKein Transport, kein Agent, kein JCo im System
Läuft auch ohne KIRegelbasiert oder mit einem Anbieter Ihrer Wahl
ECC bis CloudECC, S/4HANA, RISE, Public Cloud und SAP BTP

Cockpit von Z-Insight im Demo-System: acht Kennzahlen mit Verlauf, Wertpotenzial pro Jahr, geführter Einstieg „Was möchten Sie klären?“ und die Aussagekraft des Scans je Datenquelle — Cockpit im mitgelieferten Demo-System: Kennzahlen mit Verlauf, geführter Einstieg und die Aussagekraft des Scans je Datenquelle.

Ausgangslage

Die Wahrheit über das eigene System liegt an vielen Orten

Wer eine S/4-Konversion bewerten, Clean Core planen oder einen Abbruch erklären will, braucht Quelltext, Customizing, Transporte und Laufzeitdaten zugleich – und den Bezug zum Geschäftsprozess. Heute kommt das aus vielen Transaktionen und mehreren Köpfen.

Quelltext

Was Z-Reports, BAdIs, Exits und Modifikationen tatsächlich tun – inklusive der Includes, die niemand mehr liest.

Customizing

Welche Tabellen der Code liest und ob die Werte darin zu den Prüftabellen des Standards passen.

Transporte

Was wann in dieses System importiert wurde – und was der Import inhaltlich verändert hat.

Betrieb & Prozesse

Dumps, Jobabbrüche, Verbuchungs-, IDoc- und Log-Fehler, Nutzung und Belegfluss – jeweils ohne Bezug zueinander.

Der eigentliche Aufwand

Den Zusammenhang stellt heute ein Mensch her – wenn er die Zeit und das Wissen hat.

Z-Insight stellt ihn automatisch her, belegt ihn und hält ihn Scan für Scan aktuell: vom einzelnen Dump bis zur Frage, welcher E2E-Prozess bei der Konversion wie viel Aufwand erzeugt.

Einsatzszenarien

Sechs Fragen, die Z-Insight beantwortet

Dieselbe Faktenlage, je nach Anlass anders aufbereitet. Im Cockpit führt „Was möchten Sie klären?“ direkt zu den drei wichtigsten Kennzahlen und den nächsten Sichten.

Angebot

Projekt scopen

Welche Scope Items brauchen wir, wo sind die Gaps, was kostet es als Festpreis?

Scope Items der SAP Best Practices
Fit-Gap mit Eigenentwicklungen
Festpreis-Indikation und Workshops

Zum Pre-Assessment →

ECC → S/4HANA

Transformation planen

Was bricht bei der Konversion, was kostet es, womit fangen wir an?

Simplification Items mit Aufwand
Release-Validierung gegen Zielrelease
Planbasis, Wellenplan, Fahrplan

Zur S/4-Transformation →

Clean Core

Zielbild erreichen

Wie weit ist unser Code vom Clean Core entfernt – und was kostet der Weg?

Stufen A–D nach SAP-Freigabedaten
Schreibzugriffe mit Ersatz-API
Szenarien mit Aufwand

Zu Clean Core →

Betrieb

Stabilität herstellen

Warum bricht es – und welcher Transport oder welches Customizing hat es ausgelöst?

Dump-Signaturen und Trends
Ursachenketten bis zum E2E-Prozess
Betriebs-Wochenbericht

Zu Betrieb & Stabilität →

Aufräumen

Altlasten abbauen

Was kann weg, was muss modernisiert werden, wo steckt Wissensrisiko?

Stilllegung mit Nachweisen
Code-Governance und Namensregeln
Wertpotenzial in Euro

Zu Aufräumen & Governance →

Dokumentation

System verstehen

Was macht unser System eigentlich – je Prozess, je Z-Anwendung?

E2E-Prozesslandkarte
Fachkonzepte per Reverse Engineering
Assessment-Bericht

Zur Dokumentation →

CIO und IT-LeitungBelastbare Zahlen für Budget und Roadmap: Readiness, Aufwand je E2E-Prozess, Wellen, Stabilitätsindex – mit Herleitung und Aussagebasis.

FachbereichProbleme je Geschäftsprozess statt je Programm: welcher Value Stream klemmt, was es kostet und welche Eigenentwicklung beteiligt ist.

SAP-Beratung und AMSEin fremdes System in Tagen statt Monaten verstehen, Workshops vorbereiten und Ergebnisse als Bericht übergeben.

Pre-Assessment & Angebot

Vom Scan zum Festpreis-Angebot, belegt bis zum Scope Item

Vor einem S/4HANA-Projekt zeigt das Pre-Assessment, welche Scope Items der SAP Best Practices das Quellsystem tatsächlich nutzt, welche Eigenentwicklungen dazugehören und wo es keine Standard-Entsprechung gibt. Daraus entstehen Aufwand in Story Points und Personentagen, Discovery, Lieferzeitraum und eine Festpreis-Indikation mit offengelegten Annahmen.

Pre-Assessment im Demo-System mit dem Katalog der SAP Best Practices für die Private Edition: Scope Items in Scope, Story Points, Personentage, Discovery, Festpreis-Indikation, Abdeckung der Nutzung und Anteil in der Public Edition — Scope-Vorschlag gegen die offiziellen Scope Items der SAP Best Practices, mit Aufwand und Festpreis-Indikation.

Scoping

Scope aus gemessener Nutzung statt aus Fragebögen

Offizielle KatalogeScope Items der SAP Best Practices für Private und Public Edition, die SAP Model Companies Retail, Fashion und Consumer Products, eigene Listen oder die eingebauten Fähigkeiten; der Katalogvergleich stellt alle nebeneinander.
Fit-GapEigenentwicklungen je Scope Item mit Begründung, Kundenprozesse ohne Standard-Entsprechung als Workshop-Themen und die Abdeckung der genutzten Transaktionen.
EntscheidungenBerater entscheiden je Scope Item mit Begründung, auch per Excel; die Entscheidung übersteuert Scope, Aufwand und Festpreis in Bericht, CSV und Delivery-Board.

KI-Assistent im Pre-Assessment

Angebotstext, Workshop-Leitfaden und Entscheidungsvorschläge

Die KI schreibt die Management-Zusammenfassung für das Angebot, je Bereich einen Leitfaden für den Fit-to-Standard-Workshop und Entscheidungsvorschläge für offene Zeilen mit Begründung; sie beantwortet Fragen zum Pre-Assessment und bewertet Gap-Themen. Je Workshop gibt es eine Workshop-Mappe als Word-Dokument. Ohne KI-Anbieter liefert jede Funktion ein regelbasiertes Ergebnis im gleichen Format; an die KI gehen nur Kennzahlen und Namen, keine Benutzerdaten.

Reiter Angebot im Pre-Assessment: Angebotspreis, empfohlener Risikoaufschlag aus Risikoregister und Bandbreite, Aufwand mit 80 Prozent Sicherheit, Laufzeit nach SAP Activate und Phasen mit Meilensteinen und Zahlungsplan

Angebotsplanung

Festpreis mit Bandbreite, Risikoregister und Plan nach SAP Activate

Bandbreite statt PunktschätzungGünstiger, wahrscheinlicher und ungünstiger Fall mit PERT-Erwartung und P80; der empfohlene Risikoaufschlag folgt aus der Streuung und aus einem Risikoregister, das der Scan selbst ableitet.
Plan und TeamPhasen Prepare bis Hypercare mit Meilensteinen und Zahlungsplan, Personentage und Teamstärke je Beraterrolle, Migrationsobjekte mit Mengen aus dem Quellsystem.
Angebotsentwurf und Bid-ReviewDer Entwurf entsteht als Word-Dokument mit Leistungsumfang, Vorgehen, Preis, Risiken, Annahmen und Abgrenzung; eine Prüfung nennt Schwachstellen und Rückfragen an den Kunden, bevor das Angebot hinausgeht.

Festpreis-Indikation

Story Points je Scope Item und Kundenspezifikum, Personentage, Discovery-Aufwand, Teamgröße und Lieferzeitraum; alle Richtwerte sind Bewertungsfaktoren und im Bericht offengelegt.

Workshop-Agenda

Je Bereich ein Fit-to-Standard-Workshop mit Sitzungen, Leitfaden und Workshop-Mappe; Länder ohne Lokalisierung, Zusatzlizenzen und Public-Edition-Eignung sind markiert.

Angebotsbericht

Pre-Assessment als Word und Markdown mit Management-Zusammenfassung, Scope je Bereich, Fit-Gap, Entscheidungen, Inventar und Annahmen; Scope als CSV für Excel.

Ins Delivery-Board

Je Bereich ein Epic, je Scope Item eine Story mit Story Points, Belegen und Eigenentwicklungen; auf Wunsch je Gap-Thema eine Klärungs-Story.

Funktionen

Alles an den End-to-End-Prozessen nach SAP-Standard ausgerichtet

Jede Eigenentwicklung wird nachvollziehbar einem E2E-Prozess und Value Stream zugeordnet – aus Tabellen, Bausteinen, Transaktionen und der erweiterten Standardtransaktion. So sprechen Transformation, Betrieb und Fachbereich über dieselbe Landkarte.

E2E-Prozesslandkarte

Acht E2E-Prozesse – Lead to Cash, Source to Pay, Design to Operate, Idea to Market, Acquire to Decommission, Recruit to Retire, Finance, Governance – mit 31 Value Streams und den Prozessschritten samt Transaktionen.

Problemdruck je Linse

Je Value Stream Z-Objekte, Dialogschritte, Erweiterungen und Problemdruck für ECC → S/4HANA, Clean Core oder Betrieb; Vergleich mit dem Vorscan oder zwischen Linsen.

Problemfeld-Heatmap und Radar

Kennzahlen je Bereich, Klartext-Erklärung je Zelle und die Top-Handlungsfelder mit Maßnahme, Aufwand und Priorität. Das Radar vergleicht bis zu drei Bereiche mit dem Durchschnitt.

Zuordnung korrigierbar

E2E-Zuordnung je Objekt oder per Paket- und Namensregel anpassen – wirkt in Heatmap, Landkarte, Objekten und Erkenntnissen. Export als CSV, Markdown und Workshop-Unterlage.

Heatmap

Von der Farbe zur Maßnahme

Die Heatmap zeigt nicht nur, wo es rot ist, sondern warum: je Zelle die verursachenden Objekte, je Bereich der Haupttreiber und die konkrete Maßnahme mit Aufwand und Priorität – als Grundlage für Lenkungskreis und Workshop.

ECC → S/4HANA

Vom Simplification Item bis zum Fahrplan – durchgängig belegt

Analyse, Bewertung und Planung greifen auf dieselbe Planbasis zu. Jede Zahl lässt sich bis zur Codezeile zurückverfolgen und ist als belegt, release-unabhängig oder Richtwert gekennzeichnet.

Simplification Items: Kennzahlen relevant, Pflicht, Eigenentwicklungen, Kompatibilitäts-Views, Aufwand und vermeidbarer Aufwand, darunter die Management-Zusammenfassung in sechs Punkten — Simplification Items mit Aufwand und Management-Zusammenfassung – inklusive Aussagebasis und Workshop-Unterlage.

Simplification Items in der Tiefe

Je Eigenentwicklung und Zugriff: Lesen oder Schreiben, Zeilen, genutzte Felder und konkreter Ersatz bis zur Feldzuordnung (z. B. KONV → PRCD_ELEMENTS, VBUK → VBAK/LIKP). Bewertung: bricht, anpassen, über Kompatibilitäts-View oder unkritisch.

Aufwand mit Herleitung

Personentage je Zugriff statt Pauschale, Vorprojekte vor der Konversion, vermeidbarer Aufwand durch Stilllegung ungenutzten Codes. Die Schätzparameter sind anpassbar; ATC- und Readiness-Check-Ergebnisse lassen sich importieren und abgleichen.

Management-Zusammenfassung

Die Kernaussagen in wenigen Sätzen: relevante Items, Pflichtanteil, größte Aufwandstreiber, Vorprojekte und Schwerpunkt in der Prozesslandkarte – mit Aussagebasis je Scan und Item und Verknüpfung zum Value Stream.

Release-Validierung

Upgrade Readiness gegen Zielrelease oder Modellfirma

Prüfung gegen ein Zielrelease – ECC 6.0 EHP8 oder S/4HANA 1909 bis 2025 einschließlich Feature Packs – oder gegen eine gescannte Modellfirma. Ergebnis ist ein Readiness-Index mit Herleitung, ein Status je Eigenentwicklung (Blocker, anpassen, prüfen, bereit, stilllegen), Summen je E2E-Prozess, Pflicht-Vorprojekte und ein Customizing-Fit-Gap gegen die Modellfirma.

Release-Validierung von SAP ERP 6.0 EHP8 nach SAP S/4HANA 2023: Readiness-Index 59 mit Herleitung, Status je Eigenentwicklung, Aufwand und Aussagekraft je Aussage

S/4-Planung

Eine Planbasis für alle Sichten

Planbasis mit AufwandsbrückeSimplification, Readiness, 4R je Eigenentwicklung, Wellen, Zeitplan und Clean-Core-Zielbild ergeben eine Zahl – Abweichungen zwischen den Sichten werden erklärt.
WellenplanUmstellungswellen je E2E-Prozess mit Blockern und Kalenderwochen, Kapazitäts-Zeitplan aus Teamgröße, Puffer und Startdatum.
Pre-Assessment, Angebotsentwurf und Workshop-MappenAngebotsentwurf mit Vorgehen nach SAP Activate, Team, Preis mit Zahlungsplan, Risiken und Abgrenzung; Angebotsgrundlage mit Management-Zusammenfassung, Scope je Bereich und Scope Item, Fit-Gap, Entscheidungen, Aufwand und Festpreis-Indikation; je Fit-to-Standard-Workshop eine Mappe mit Leitfaden und Spalte für das Ergebnis.WORDMARKDOWNCSV
TransformationsfahrplanAls Markdown für Projekt und Lenkungskreis; Burn-down mit gespeicherten Kennzahlen je Scan und Prognose.

S/4-Planung mit Kernaussagen: Readiness, Planbasis in Personentagen, Dauer in Wochen mit Go-live-Kalenderwoche, Stilllegungskandidaten und Clean-Core-Szenario, darunter die Aussagebasis

E-Rechnung und Ausgabe im Demo-System: 81 Tage bis zum Ende der Übergangszeit, ein eigenes Rechnungsformular, EDI-Rechnungen an drei Partner, Versand laut Ausgabesteuerung mit Nachrichtenarten, Programmen und Formularen, Lage beim Empfang und die Fristen der E-Rechnungspflicht

E-Rechnung & Ausgabe

Bereit für die E-Rechnungspflicht?

Eigene Rechnungsformulare und Druckprogramme (SAPscript, Smart Forms, Adobe Forms), die Ausgabesteuerung laut Customizing – je Nachrichtenart Programm und Formular, Standard und eigene, fehlende Programme und ungenutzte Z-Formulare – und EDI-Rechnungen je Partner – gegen die Fristen für Empfang und Versand strukturierter E-Rechnungen (XRechnung, ZUGFeRD). Daraus ein Maßnahmenplan mit Richtwerten, der die Umstellung auf das S/4 Output Management gleich mitdenkt. Rechnungsinhalte liest Z-Insight nicht.

Kompatibilitäts-Views

Was nach der Umstellung lautlos anders läuft

Schreiben wirkt nicht mehr

Schreibzugriffe auf umgeleitete Tabellen haben keine Wirkung; Warenbewegungen und Buchungen laufen nur über Standard-APIs.

Native SQL umgeht die Umleitung

Native SQL, ADBC und Kunden-Datenbank-Views lesen die physische Tabelle – und die ist leer.

Berechnete Felder kosten Laufzeit

Bestände und Summen werden bei jedem Zugriff aggregiert – in Schleifen ein Laufzeit- und Speicherrisiko.

APPEND- und ZZ-Felder

Kundenfelder auf entfallenden Tabellen, die vor der Konversion umziehen müssen – mit Ziel in S/4HANA.

Grundlage sind die Simplification List for SAP S/4HANA mit den zugehörigen SAP-Hinweisen und die von SAP veröffentlichten Freigabedaten.

Bis zur Konversion

Ein Zähler bis 0 – und für jede Korrektur ein Nachweis

Die Konversions-Arbeitsliste führt alles, was vor der S/4HANA-Konversion erledigt sein muss, in einer Liste: Systemvoraussetzungen, Vorbereitung vor SUM, Datenseite, Simplification Items, Pflichtanpassungen im Kundencode und ATC-Befunde Priorität 1. Steht der Zähler auf 0, ist das System bereit – erledigte Punkte bestätigt der nächste Scan.

Konversions-Arbeitsliste im Demo-System: 40 von 43 Pflichtpunkten offen, davon 21 vor SUM, offener Aufwand in Personentagen, Hinweise zur Aussagebasis, Verlauf und offene Punkte je Bereich — Konversions-Arbeitsliste: offen bis zur Konversion, davon vor SUM, Aufwand, Bestätigung durch den Scan und offene Punkte je Bereich.

Eine Liste, eine Zahl

Pflichtpunkte aus Checkliste, Simplification Items, Kundencode, ATC und Datenseite – ohne Doppelungen, mit Zuständigen, Fristen, Massenbearbeitung und Export nach Excel, Jira, Word und Markdown.

Bestätigt statt abgehakt

Ein erledigter Punkt gilt erst, wenn der nächste Scan ihn nicht mehr findet. Was als erledigt markiert, aber noch vorhanden ist, steht als „im Scan weiterhin vorhanden“ wieder oben.

Verlauf und Prognose

Täglicher Stand, Burn-down und voraussichtliches Fertigdatum; im Portfolio die Konversions-Bereitschaft aller Systeme nebeneinander.

Korrektur-Werkstatt

Korrekturen mit Nachweis – im System nachgemessen

Offline geprüftSyntax und Blockstruktur, Befunde je Regel und Datenzugriffe vor und nach der Korrektur – neue schwere Befunde oder Schreibzugriffe verwerfen die Korrektur.
Mit Unit-TestJe Korrektur ein ABAP-Unit-Testgerüst als Vergleichstest vor und nach dem Einspielen, zugeordnet zur betroffenen Routine.
ImportierbarKorrekturpaket mit Prüfprotokoll, Vorher/Nachher und Patch – auf Wunsch als abapGit-Repository für das Entwicklungssystem.
Gemessene QuoteDie Automatisierungsquote je System zählt nur Stellen, deren Korrektur die Prüfung bestanden hat – mit Verlauf über die Läufe.
Kreislauf geschlossenJeder spätere Scan zeigt je Objekt: eingespielt mit Transportbeleg, im System bestätigt (Befund weg), getestet – die Ist-Quote statt einer Plan-Quote. Im Demo-System lässt sich der Import simulieren.

Korrektur-Werkstatt, Detail eines Objekts: Nachweis „nachgewiesen“ mit Syntax-, Regel-, Befund-, Datenzugriffs- und Unit-Test-Prüfung, darunter die automatischen Korrekturen mit Vorher und Nachher

Korrektur-Kreislauf nach dem simulierten Import im Demo-System: vorgeschlagen, eingespielt, im System bestätigt und getestet mit Ist-Quote, je Objekt Stufe, Fundstellen vorher und nachher und der Transportauftrag mit Datum — Korrektur-Kreislauf: je Objekt eingespielt mit Transportbeleg, im System bestätigt oder mit verbliebenen Fundstellen – die Ist-Quote aus dem Folgescan.

Korrektur-Werkstatt, Detail eines Objekts: Freigabe je Stelle mit Ticket, angenommene Korrektur mit Name und Ticket, darunter der Korrektur-Assistent mit Frage und Antwort zur Korrektur

Freigabe & Verantwortung

Jede Stelle freigegeben – vom Entwickler, der sie verantwortet

Freigabe je StelleAnnehmen, ablehnen oder ändern – mit Ticket und Kommentar. Abgelehnte Stellen kommen nie ins Paket, das Übernahmepaket enthält nur Freigegebenes.
Korrektur-AssistentFragen zur Korrektur direkt neben Vorher/Nachher: warum, welches Risiko, wie testen. Eine Alternative wird statisch geprüft und erst mit der Freigabe übernommen.
Dokumentiert im CodeEine Kommentarzeile je übernommener Stelle nach Vorlage des Systems – Datum, SAP-Benutzer, Ticket, Regel.
Eigener SAP-BenutzerWer freigibt, übernimmt und transportiert unter dem eigenen SAP-Benutzer. Der Kreislauf zeigt Transportinhaber und Freigabe nebeneinander; Z-Insight selbst schreibt nichts ins SAP-System.

Übernahme & Korrektur-Agent

Vom Freigeben bis in den eigenen Transport – ohne dass Z-Insight schreibt Neu

Übernahme-Report in Ihrem SystemEin kundeneigener ABAP-Report holt die freigegebenen Korrekturen mit einem persönlichen, befristeten Token ab – vom Entwickler gestartet, unter seinem SAP-Benutzer, in seinen Transportauftrag.
Erst prüfen, dann schreibenPrüfsumme des Ausgangsstands, Kundennamensraum, Berechtigung und Syntax; geschrieben wird eine inaktive Version, aktiviert vom Entwickler. Die Quittung je Objekt geht zurück an Z-Insight.
Agent für manuelle StellenVorschlagen, statisch prüfen, nachbessern – bis die Prüfung besteht, höchstens drei Runden, als Massenlauf mit Nachweis je Stelle. Übernommen wird nur, was der Entwickler freigibt.
Clean-Core-Entscheidung je ObjektBehalten, stilllegen oder auf SAP BTP neu bauen – mit Empfehlung aus gemessener Nutzung, Clean-Core-Stufe und Umbau-Vorschlag, entschieden und begründet vom Team.

Korrektur-Werkstatt: Übernahmepakete mit SAP-Benutzer, Status und Quittung des Reports mit Transportauftrag, darunter der Korrektur-Agent für manuelle Stellen und die Clean-Core-Entscheidung je Objekt mit Empfehlung und Begründung

Datenseite

Geschäftspartner, Finanzen und Pflichtumstellungen gemessen

Aus dem Scan: Debitoren und Kreditoren ohne Geschäftspartner je Kontengruppe, Kontengruppen ohne BP-Gruppierung und Nummernkreis-Kollisionen – nur Strukturen und Anzahlen, keine Stammdaten. Dazu die messbaren S/4-Pflichtumstellungen: Material Ledger, Kreditmanagement, Absprachen, neue Anlagenbuchhaltung und Ausgabesteuerung. Abstimmungen in FI, MM, CO und Anlagenbuchhaltung kommen als Import der im SAP ausgeführten Prüfprogramme. Jeder Punkt fließt in die Arbeitsliste: gemessen in Ordnung gilt als erledigt.

Nachkalkulation

Schätzungen, die mit jedem Projekt besser werden

Der tatsächliche Aufwand je Objekt aus der Zeiterfassung gegen die Richtwerte der Korrektur-Werkstatt: Faktor Ist/Plan je Regel und Objektart, mit Belastbarkeit. Kalibrierte Richtwerte lassen sich als Bewertungsfaktoren übernehmen – mit Historie und Rücknahme; ab zwei Systemen gibt es einen systemübergreifenden Referenzwert.

Nachkalkulation: Ist 6,4 Personentage gegen Plan 3,2 Personentage, Faktor Ist/Plan, und je Regel Faktor, Richtwert heute, Vorschlag und Belastbarkeit

Portfolio

Bereitschaft aller Systeme nebeneinander

Je SAP-System: E-Rechnung (Tage bis zur Frist, offene und dringende Maßnahmen), Löschkonzept (kritische Z-Tabellen), Patchstand (letzter Import, Rhythmus, offene Hot News) und die Ist-Quote der Korrekturen – als Tabelle und CSV. Dieselben Punkte erscheinen als Hinweise in „Mein Tag“ und in der Glocke, jeweils für die Rolle, die etwas damit anfangen kann.

Clean Core

Eingestuft nach SAPs eigenen Freigabedaten – und mit Weg zum Zielbild

Die Stufen A bis D sind keine Hausmeinung: Grundlage sind die von SAP veröffentlichten Freigabedaten aus dem Cloudification Repository – dieselben Daten wie in der ATC-Prüfung „Usage of APIs“, hier auch für ECC-Kundencode.

Freigegeben

Nur öffentlich freigegebene, stabile APIs.

Classic API

Zusätzlich klassische APIs, Kundenexits und klassische BAdIs.

SAP-intern

Zugriff auf nicht freigegebene SAP-interne Objekte, etwa Standardtabellen.

Nicht empfohlen

Modifikationen, Schreiben auf SAP-Tabellen, implizite Erweiterungen, „noAPI“-Objekte.

Clean-Core-Werkstatt

Vom Befund zum Plan

Scorecard je Paket und E2E-ProzessMit Vergleich zum Vorscan und Stufen-Trend über alle Scans.
Schreibzugriffe und ModifikationenDirekte Schreibzugriffe auf SAP-Tabellen mit empfohlener freigegebener API, Umbau-Skizzen, Modifikations-Inventar mit SPAU/SPDD-Aufwand.
Szenarien mit AufwandVon „nur Stufe D beseitigen“ bis „vollständig ABAP Cloud“: was jedes Szenario kostet und wohin es den Score bringt.

Schnittstellen-Modernisierung

Von IDoc, RFC und Datei zur freigegebenen API

Jede Schnittstelle aus dem Scan – IDoc je Nachrichtentyp und Partner, Kunden-RFC, Datei-Upload – mit heutiger Stufe, Ziel-API bzw. Business Event, Richtwert und Priorität aus Menge, Fehlerquote und Abstand zum Zielbild. Der Zuordnungskatalog ist offengelegt. Je Schnittstelle gibt es ein iFlow-Gerüst für die SAP Integration Suite: Integrationsfluss mit Sender, Mapping-Schritt, Ziel-Aufruf und Fehlerbehandlung, Parameter, Feldzuordnungs-Vorlage und Anleitung – Zugangsdaten nur als Credential-Namen.

Schnittstellen-Modernisierung: Verteilung auf die Stufen A bis D, Richtwert für die Umstellung und je Schnittstelle Stufe heute, Ziel-API oder Business Event, Download des iFlow-Gerüsts, Aufwand und Priorität

Quelle der Freigabedaten: SAP Cloudification Repository (github.com/SAP/abap-atc-cr-cv-s4hc, Apache-2.0). Der Datenstand wird mitgeliefert und lässt sich in den Einstellungen aktualisieren.

Betrieb & Stabilität

Vom Dump zur Ursache – mit Transport, Customizing und Prozess

Z-Insight verbindet Laufzeitfehler aus ST22, SM37, SM13, WE02 und SLG1 mit dem verursachenden Z-Objekt, dem Transport oder der Customizing-Änderung davor und dem betroffenen E2E-Prozess. Aus einem Befund wird erst dann eine Erkenntnis, wenn er einen realen Fehler im System erklärt.

Liste der Erkenntnisse zum BAdI ZCL_IM_ME_PO_CUST: Fehler wahrscheinlich ausgelöst durch einen Transport, Customizing-Lücke, Code-Ursache und neues Fehlerbild – jeweils mit Konfidenz, Zuständigkeit, Frist und geschätztem Wert

Ein Fall aus dem Demo-System

Das SymptomEin BAdI in der Bestellanlage bricht ab – wiederholt, seit einem bestimmten Tag.
Der AuslöserKurz vorher wurde ein Transport importiert, der in T161 eine neue Bestellart anlegt.
Die KetteT161 ist Prüftabelle der Kundentabelle, die das BAdI liest – dort fehlt die neue Bestellart.
Der BelegFehler vorher und nachher gezählt, Konfidenz ausgewiesen, betroffene Benutzer und Wert geschätzt.
Die EmpfehlungFolgeeinträge pflegen und den Code robust gegen neue Customizing-Werte machen – mit Zuständigem und Frist.

Betriebsstabilität: Kernaussagen der Berichtswoche und Wochenvergleich von Dumps, Jobabbrüchen, Verbuchungsfehlern, IDocs und Anwendungs-Log mit Veränderung zur Vorwoche — Betriebsstabilität: Kernaussagen, Wochenvergleich und Aussagebasis – als Betriebs-Wochenbericht exportierbar.

Dump-Signaturen mit Trend

Laufzeitfehler je Programm, Include und Zeile gebündelt – neu, steigend, fallend –, mit betroffenen Z-Objekten und Benutzern (abschaltbar auf reine Anzahl).

Ursachenketten

Dump → Objekt → Transport oder Customizing → E2E-Prozess, gekennzeichnet als belegt, wahrscheinlich oder offen – und ob eine Korrektur gewirkt hat.

Ausreißer erklärt

Auffällige Tage mit Ursache und Transporten, Stabilitätsindex und MTBF je E2E-Prozess, chronische Fehler mit Vorschlag für ein Problem-Ticket.

Jobs und Schnittstellen

Laufzeitdrift, Abbruchquote und Überschneidungen von Jobs; IDoc-, tRFC- und qRFC-Strecken mit Rückstau und verstummten Partnern.

Störungsanalyse

Aus Ticket-Text oder Ticketnummer: beteiligte Eigenentwicklungen, passende Fehler, Transporte kurz davor, wahrscheinliche Ursache und nächste Schritte.

Wochenbericht

Kernaussagen, Wochenvergleich und Aussagebasis je Quelle als Markdown oder per Teams, Slack und E-Mail.

Ursachenketten: Fehlerbilder mit Anzahl Fälle, betroffenem Objekt, Transport davor, E2E-Prozess und Wirkung einer Korrektur, jeweils mit Aussagebasis belegt oder wahrscheinlich — Ursachenketten je Fehlerbild – mit Aussagebasis und Wirkung der Korrektur.

Laufend absichern

Nach jedem Import wissen, was sich verändert hat

Ein Assessment ist eine Momentaufnahme. Z-Insight bleibt danach am System: Transportimporte lösen eine Delta-Prüfung aus, Sicherheitshinweise werden gegen den Softwarestand abgeglichen, und Testfälle werden dort verlangt, wo die Änderung auf echte Nutzung trifft.

Überwachung

Delta-Prüfung nach Transportimport

Import erkanntZ-Insight liest im eingestellten Abstand nur das Importprotokoll – Auftrag, Zeitpunkt, Rückgabecode.
Nur Geändertes geprüftUnveränderte Objekte kommen aus dem Cache, neu gelesen und analysiert wird nur, was der Import berührt hat.
Bericht und AlarmNeue S/4-Blocker, neue schwere Befunde und verschlechterte Sicherheitseinstellungen – als Ticket, Teams/Slack, E-Mail oder Webhook.

Sicherheitshinweise & Patchstand

Welche Hinweise fehlen – und wie regelmäßig gepatcht wird

Der Export aus SAP System Recommendations wird gegen den installierten Support-Package-Stand bewertet: enthalten (mit dem Paket, das die Korrektur brachte), per SNOTE eingespielt, nicht relevant oder offen, mit Kritikalität und Security Patch Day. Der Patch-Rhythmus je Softwarekomponente kommt aus den eingespielten Support Packages. Dazu die Eigenentwicklungen, die einen betroffenen Standardbaustein aufrufen, und der Verlauf der kritischen Systemeinstellungen über alle Scans.

Sicherheitshinweise und Patchstand: letztes Support Package mit Datum und Patch Days seither, Kennzahlen offen, Hot News, durch Support Package enthalten; Liste der Hinweise mit Priorität, Stand – darunter per SNOTE eingespielt –, Patch Day und betroffenem Z-Baustein

Support Packages und Patch-Rhythmus je Komponente: letzter Import mit Paketname, Importe in zwölf Monaten, mittlerer Abstand, Bewertung und die eingespielten Pakete — Patch-Rhythmus je Softwarekomponente aus den Support-Package-Importen, dazu per Hinweis-Assistent (SNOTE) eingespielte Hinweise.

Testlücken aus Nutzung

Getestet wird, was betroffen ist und genutzt wird

Betroffene und produktiv genutzte Transaktionen, Jobs, Schnittstellen und Prozesse gegen vorhandene Testfälle – aus dem eigenen Repository oder importiert aus Testmanagement und SAP Cloud ALM. Abdeckung nutzungsgewichtet, Regressionskern mit 80 % der Nutzung, Lücken mit einem Klick als Testfall.

Hypercare nach dem Go-live

Basis-Scan vor dem Go-live, danach auf Wunsch täglich ein Scan: Geschäftsvolumen je Tag (Aufträge, Lieferungen, Rechnungen, Bestellungen, Wareneingänge), Laufzeitfehler, abgebrochene Jobs, IDoc- und Verbuchungsfehler und Durchlaufzeiten gegen den Stand davor – mit Schwellen, Tagesbericht und Alarm.

Alarm über vorhandene Kanäle

Überwachung, verschlechterte Sicherheitseinstellungen und Hypercare lösen Ereignisse der Automatisierung aus – als Ticket, Teams/Slack, E-Mail oder Webhook.

Aufräumen & Code-Governance

Weniger Code, besserer Code – nachvollziehbar begründet

Stilllegen, was niemand nutzt; modernisieren, was bleibt; Regeln setzen, damit es so bleibt. Mit Aufwand, Nachweisen und Trend über die Scans.

Modernisierungsindex

Veraltete Sprachmittel mit Vorher/Nachher-Muster, Aufwand und Anteil, der sich automatisch umstellen lässt.

Namensregeln je Paket

Konventionen je Objekttyp mit Vorschau und Umbenennungsvorschlag; begründete Ausnahmen mit Ablaufdatum.

Wissensrisiko

Busfaktor je E2E-Prozess und ein Maßnahmenplan für den Wissenstransfer – bevor jemand das Haus verlässt.

Stilllegung mit Nachweisen

Stilllegungskandidaten mit acht Nachweisen (Nutzung, Aufrufer, Jobs, Schnittstellen …) und Wellenplan; Nutzung aus dem Produktivsystem übernehmbar.

Z-Tabellen und Kundenfelder

Tabellen ohne aktive Verwender mit Datenvolumen, Kundenfelder (ZZ/YY, APPEND) mit Ziel in S/4HANA, Paket-Hygiene.

Wertpotenzial in Euro

Stilllegen, Zusammenführen, Optimieren, Stabilisieren: Nutzen pro Jahr, Aufwand und Amortisation mit offengelegtem Rechenweg und anpassbaren Annahmen.

Lösch- und Aufbewahrungskonzept der Z-Tabellen: Tabelle mit Kundenkontakten ohne Löschlogik als kritisch, Protokolltabelle mit Archivierungsobjekt und letztem Lauf, abgestimmte Regel, Fristvorschläge und SAP-Standardtabellen mit Personendaten, in die Z-Code schreibt

Löschkonzept

Personenbezogene Daten in Z-Tabellen

Aus dem Data Dictionary: welche Z-Tabellen Namen, Anschriften, Kontaktdaten oder Benutzer enthalten, wie viele Zeilen sie haben und ob der Z-Code sie je löscht. Dazu ein Regelvorschlag mit Frist und Auslöser nach den Aufbewahrungsfristen von AO und HGB, abgestimmt je Tabelle und als CSV für den Datenschutz. Archivierungsobjekte mit letztem Lauf gelten als Löschweg; personenbezogene SAP-Standardtabellen, die Ihr Z-Code schreibt, stehen mit ihrem Standard-Löschweg (ILM, Archivierung) daneben. Tabelleninhalte liest Z-Insight dafür nicht.

KI-Assistent & Tiefenprüfung

Fragen in Klartext – Antworten mit Quelle

Die KI formuliert und vertieft, die Analyse bleibt regelbasiert und nachprüfbar. Ohne KI-Anbieter antwortet der Assistent aus den passenden Auswertungen – im selben Format.

KI-Assistent

Ein Gespräch über bis zu fünf Systeme

SystemauswahlBis zu fünf SAP-Systeme wählen; Antworten je System mit Vergleich, Belegen und Links ins richtige System.
Analyse-WerkzeugeDer Assistent nutzt die Auswertungen – Release-Validierung, Pre-Assessment mit Scope und Festpreis, Heatmap und Landkarte, Simplification, Stabilität, Wissensrisiko, Scanvergleich.
NachprüfbarJede Antwort nennt Quelle und Stand; Benutzernamen werden vor dem Versand an eine KI pseudonymisiert.

KI-Tiefenprüfung

Gezielt je Bereich, abgeglichen mit der Regelprüfung

Umfang nach E2E-Prozess, Value Stream, SAP-Modul, Paket, Objektart und Merkmalen wählen; die Vorschau nennt Objekte, Codezeilen, KI-Aufrufe und Dauer, bevor etwas gesendet wird. Bis zu 200 Objekte je Lauf, unveränderte Ergebnisse aus dem Vorscan werden übernommen. KI-Befunde werden mit der Regelprüfung abgeglichen – bestätigt, neu oder widersprechend –, und begründete Fehlalarme zählen in Export und Qualitäts-Gate nicht mehr mit.

Process Mining & fachliche Prüfung

Wie die Prozesse wirklich laufen – und was Abweichungen kosten

Aus dem Belegfluss rekonstruiert Z-Insight die tatsächlichen Abläufe in Order-to-Cash, Retoure, Procure-to-Pay, Umlagerung und Plan-to-Produce, vergleicht sie mit dem SAP-Standardablauf, prüft sie mit 51 Prozesskontrollen und ordnet Kennzahlen und Wertbeitrag den Value Streams zu – ohne zusätzliches Werkzeug und ohne Extraktor im System.

Fachliche Prüfung, Reiter E2E und Wertbeitrag: Kernaussagen je E2E-Prozess und Kennzahlen je Value Stream mit Fällen, Durchlaufzeit, Nacharbeit, Abweichung, Z-Anteil, auffälligen Kontrollen, Treffern, betroffenem Wert und Bewertung — Wertbeitrag je Value Stream: Durchlaufzeit, Nacharbeit, Abweichung, Z-Anteil und betroffener Wert aus dem Demo-Belegfluss.

Wertbeitrag je Value Stream

Kennzahlen je Value Stream mit Herleitung, Priorisierung nach Wert × Häufigkeit, Maßnahme je Kontrolle und Verlauf über die Scans – dazu ein Workshop-Export.

Z-Pfad gegen Standard

Belege aus Z-Transaktionen im Vergleich zum Standard: Fehlerquote, Durchlaufzeit und Anstieg nach einem Transport – vom auffälligen Beleg bis zur verdächtigen Codezeile.

51 Prozesskontrollen

Order-to-Cash, Procure-to-Pay, Record-to-Report, Retail, Fertigung, Stammdaten, Bestand und Funktionstrennung (Benutzer nur als Pseudonym) – mit Belegliste, Euro-Wert und IKS-Nachweis.

Process Mining

Prozessgraph mit Engpass und Eigenlogik

Aktivitäten und Übergänge mit Häufigkeit und Dauer, Engpass, Rücksprünge, Varianten, Abweichungen mit Mehrdauer, Einflussfaktoren und die Eigenentwicklungen je Schritt. Export als Ereignisprotokoll (CSV), OCEL 2.0 und BPMN – etwa für SAP Signavio.

Process Mining Order-to-Cash: Kennzahlen zu Aufträgen, Durchlaufzeit, Soll-Ablauf, Abweichungen und Varianten sowie der Prozessgraph mit Engpass und markierten Eigenentwicklungen je Schritt

Referenzprozesse

Abweichung vom Standard in Tagen und Euro

Mitgelieferte Referenzabläufe für Order-to-Cash, Retoure, Procure-to-Pay, Umlagerung bzw. Filialversorgung und Plan-to-Produce – ohne BPMN-Upload. Je Abweichung Art (Nacharbeit, Reihenfolge, Start, Abschluss), betroffene Fälle, Mehrtage, hochgerechnete Falltage je Jahr und beteiligte Z-Transaktionen. Mit dem Jahresumsatz aus dem Business Case wird daraus gebundenes Kapital; die Prozesskennzahlen gehen anonym in den Plattformvergleich ein. Record-to-Report und Kassenprozesse liegen nicht als Fall-Belegfluss vor – das weist Z-Insight offen aus.

Retail-Landkarte

Der Handel im System auf einen Blick

Artikel, Listung, Sortiment, Aktionen, Allokation, Filialversorgung, Kasse und Fashion: je Bereich die Nutzung aus Tabellenfüllung, Belegfluss und Kassenschnittstellen, die Eigenentwicklungen und der Weg nach S/4HANA Retail – mit Kennzahlen wie Listungen je Filiale, Filialen mit Kassendaten und Durchlauf der Filialaufträge. Je Filiale die zugeordneten Kassen-Partner und Auffälligkeiten aus den Kontrollen – Inventurdifferenzen, Abschriften, Verschrottung.

Retail-Landkarte im Demo-System: acht Filialen und zwei Verteilzentren, Artikel, Listungen je Filiale, Sortimente, Kassendaten, die neun Retail-Bereiche mit Nutzung und je Filiale Kassen-Partner, Auffälligkeiten, Wert und Schwerpunkt

Projekt, Test & Cloud

Von der Analyse bis zum Go-live – und über das ABAP-System hinaus

Testumfang, Projektaufgaben und Abnahmen entstehen aus denselben Fakten. Integrationen und Seitenerweiterungen auf SAP BTP werden mit derselben Konsequenz geprüft.

Testumfang je Release

Aus Transporten, Aufrufern und tatsächlicher Nutzung: welche Transaktionen, Jobs und Schnittstellen Pflicht sind – mit Testlücken, Regressionskern und externen Testfalllisten bis zum E2E-Prozess. Auch Änderungen am Data Dictionary wirken auf die Programme, die die Tabelle lesen.

Projekt-Cockpit und Tests

SAP-Activate-Phasen mit Aufgaben, die sich aus den Analysen selbst abhaken; Test-Repository, digitale Freigaben, Defekte im geschlossenen Kreislauf.

Änderungen ohne Blindflug

Änderungsanfragen mit Auswirkungsanalyse, Umsetzungsvorschlag und Testfällen – nur Vorschlag, nichts wird ins SAP geschrieben.

Integration Suite und CAP

iFlows und CAP-Anwendungen statisch prüfen (Adapter, Zugangsdaten, Berechtigungen) und gestörte IDoc-Strecken bis zum iFlow verfolgen.

Anbindung an Ihre Werkzeuge

Jira, Azure DevOps, ServiceNow, SAP Cloud ALM, SAP LeanIX, Teams und Slack, Webhooks, BI-Schnittstelle, MCP-Server und SARIF für Code Scanning.

Upgrade und Fiori

SPDD/SPAU-Vorschau mit Aufwand und Testumfang, Fiori-Empfehlungen je genutzter Transaktion aus der SAP Fiori Apps Reference Library.

Testrisiko

Welche Einstiegspunkte das Release gefährden

Je Transaktion, Job, Schnittstelle und Prozess ein Testrisiko hoch, mittel oder niedrig – mit Gründen: Nähe zur Änderung, Nutzung, Laufzeitprobleme, Data-Dictionary-Änderung und Teststand. Je Einstiegspunkt die Änderungen der Aufträge nach Art, Umfang, fachlich und QS Verantwortliche und ein Kommentar. Dazu die Änderungen, die sich nicht auswerten lassen – Aufträge nach dem Scan, Domänen ohne Verwender, geänderte SAP-Standardobjekte –, empfohlene vorhandene Testfälle und fehlende Tests auf Knopfdruck.

Release-Cockpit, Reiter Testrisiko: Einstiegspunkte gruppiert nach hohem und mittlerem Testrisiko mit Nutzung, Teststand, Umfang und Verantwortlichen, daneben Gesamt-Testrisiko, nicht analysierte Änderungen, vorhandene und fehlende Tests

Testautomatisierung

Vom Transport bis zum Testnachweis – mit Ihren Testwerkzeugen Neu

Aus dem Testrisiko wird ein Testplan; ausgeführt wird dort, wo Sie heute testen: Tricentis Tosca und qTest, SAP Cloud ALM oder ein erzeugtes Playwright-Projekt für SAP GUI für HTML und Fiori. Die Ergebnisse kommen zurück, Fehlschläge werden Defekte. Die Nachweiskette zeigt je Einstiegspunkt Auftrag, Risiko, Ausführung und Nachweis. Nach jedem Transportimport wird das Testrisiko neu bewertet; Tickets aus Jira, ServiceNow oder ChaRM erkennt Z-Insight am Transporttext.

Fachtest & Abnahme

Testzyklen mit Heatmap, Abnahme mit Unterschrift Neu

Fachanwender erfassen je Testschritt ein Ergebnis mit Bildschirmfoto – auch ohne eigenes Konto über einen persönlichen Link. Der Fortschritt je Bereich und Testtag zeigt, wo es hängt; Defekte gehen auf Wunsch direkt ins Ticketsystem. Am Ende steht die Abnahme mit Unterschrift, gebunden an den Teststand: ändert sich danach ein Ergebnis, ist das sichtbar.

Testzyklus UAT 1: Kennzahlen, Heatmap des Fortschritts je Bereich und Testtag, Tester und unterschriebene Abnahme unter Vorbehalt mit Prüfvermerk „unverändert“

Unterstützte SAP-Umgebungen und Zugriffswege
System	Wie Z-Insight zugreift	Was analysiert wird
ECC 6.0, S/4HANA on-premise	SOAP-RFC über HTTPS, Whitelist lesender Bausteine; optional ADT (nur GET)	Vollständig: Code, Customizing, Transporte, Laufzeitfehler, Schnittstellen, Nutzung, Belegfluss
S/4HANA Cloud Private Edition (RISE)	Wie on-premise – direkt oder über BTP-Destination und Cloud Connector	Vollständig
S/4HANA Cloud Public Edition	Freigegebene OData-APIs mit Kommunikationsbenutzer, Quelltext aus Git	Belegfluss und Process Mining, ABAP-Cloud-Code
SAP BTP	Git-Repository, Cloud Integration (OAuth-Client), Cloud Management Service	ABAP Environment, CAP-Anwendungen, iFlows, Subaccounts

Reverse Engineering & Systemdokumentation

Das System dokumentiert sich aus sich selbst

Viele SAP-Systeme sind besser genutzt als beschrieben. Z-Insight leitet die Dokumentation aus Code, Customizing, Nutzung und Prozesszuordnung ab – als Grundlage für Transformation, Übergabe und Betrieb.

Fachkonzept je Z-Anwendung

Zusammengehörige Objekte als Anwendung beschrieben: Was, Warum und Sinn in Fachsprache, Ablauf, Daten, Schnittstellen, Einstiegspunkte und Vergleich mit dem SAP-Standard.

Systemdokumentation

Die Dokumentation des gesamten Systems entlang der Fachprozesse – Organisation, Customizing und Eigenentwicklungen je E2E-Prozess, fortgeschrieben mit jedem Scan.

Feld-Analyse und Regelkatalog

Wo jedes Tabellenfeld gelesen, geprüft, geschrieben oder übergeben wird, und alle Geschäftsregeln aus dem Code mit Fundstelle.

Entscheidungstabellen

Aus verschachtelten Bedingungen abgeleitet und geprüft auf Lücken, unerreichbare Zweige und Widersprüche – als Grundlage für Neubau und Test.

So funktioniert es

Anbindung, Scan, Analysen, Bericht

Vom ersten Termin mit der Basis bis zum Bericht an die Geschäftsleitung – mit offen ausgewiesener Datenlage bei jedem Schritt.

01
Anbindung
ICF-Dienst aktivieren, technischen Benutzer mit Leserechten anlegen, Berechtigungen in der App prüfen. Keine Installation im SAP-System.
02
Scan
Inventar, Erweiterungen, Quelltext, Customizing, Transporte, Laufzeitfehler, Nutzung und Belegfluss – im Hintergrund, mit Fortschritt und Delta-Scans.
03
Analysen
Korrelation, E2E-Zuordnung und alle Sichten. Der geführte Einstieg zeigt je Fragestellung die wichtigsten Kennzahlen und nächsten Schritte.
04
Bericht
Assessment-Bericht, Workshop-Unterlagen und Fahrplan – als Word, PDF oder Markdown.

Geführter Einstieg

„Was möchten Sie klären?“

ECC → S/4HANA, Clean Core, Betriebsstabilität, Aufräumen oder Sicherheit: Je Fragestellung stehen drei Kennzahlen, die nächsten drei Sichten in sinnvoller Reihenfolge und die Aussagebasis für genau diese Frage im Cockpit.

Geführter Einstieg für die Fragestellung ECC → S/4HANA-Transformation mit Readiness, relevanten Simplification Items und Anpassungsaufwand, den nächsten drei Sichten und der Aussagebasis, daneben die Aussagekraft des Scans je Datenquelle

Aussagekraft je Scan

Was fehlt, wird erklärt – nicht als Null gezeigt

Je Datenquelle – Quelltext, Nutzung, Workload, Jobs, Dumps, IDocs, Transporte, Customizing, Belegfluss, Datenmengen, Mandantentyp, Vorscan – Status, Umfang, betroffene Sichten und Behebung. Ein Entwicklungsmandant ohne Produktivnutzung wird als solcher benannt; für fehlende Leserechte gibt es die fertige Anforderung an das Basis-Team.

Datenlage je Quelle mit Aussagekraft 85 Prozent: je Datenquelle Status vollständig oder teilweise, Umfang und abhängige Sichten

Sicherheit & Datenschutz

Liest nur. Schreibt nie. Aus Konstruktion.

Was nicht gelesen werden darf, kann gar nicht erst aufgerufen werden – und was an eine KI geht, entscheiden Sie.

Kein Eingriff im SAP-System

Zugriff über den Standarddienst /sap/bc/soap/rfc. Kein Transport, kein Agent, kein JCo, kein NW-RFC-SDK.

Whitelist lesender Bausteine

Nur lesende Funktionsbausteine sind zugelassen, geprüft unmittelbar vor jedem Aufruf. Keine ändernden BAPIs, kein COMMIT; ADT nur per GET.

Gesperrte Tabellen

Benutzer- und Rollentabellen, RFC-Destinationen, HR-, Bank- und Adressdaten sind nie lesbar – fest verdrahtet.

Pseudonymisierung

SAP-Benutzernamen werden vor dem Versand an eine KI ersetzt und in der Antwort zurückübersetzt; Funktionstrennung arbeitet nur mit Pseudonymen.

Quelltext-Richtlinie

Vollständig, nur Ausschnitte um Befunde oder gar kein Quelltext; IBAN, E-Mail und Telefonnummern in Literalen werden maskiert. „Was wird gesendet?“ zeigt das Dossier vorab.

Läuft auch ohne KI

Ohne Anbieter regelbasiert im selben Format. Mit KI: öffentlicher Dienst, Azure OpenAI im eigenen Tenant oder ein Modell im eigenen Rechenzentrum.

Verschlüsselte Geheimnisse

SAP-Kennwörter und API-Schlüssel mit AES-256-GCM; nur HTTPS zum SAP-System, HTTP nur nach ausdrücklicher Freigabe.

Rollen, SSO, Mandanten

Leser, Analyst, Prüfer, Administrator; Single Sign-on mit Microsoft Entra ID; Mandantentrennung zentral in der API.

Hosting in Deutschland

Die von RealCore betriebene Instanz läuft mit Anwendung, Datenbank und Datenträger in Frankfurt am Main – beim Hoster Render, zertifiziert nach ISO/IEC 27001 und SOC 2. Oder bei Ihnen im eigenen Rechenzentrum.

Unterlagen für den Einkauf

Technische und organisatorische Maßnahmen, Unterauftragsverarbeiter und Nachweise erzeugt Z-Insight aus der laufenden Konfiguration – ehrlich, ohne Zertifikate, die es nicht gibt.

Übernahme unter Ihrem Benutzer

Der optionale Übernahme-Report ist Ihr eigener Code: persönliches, befristetes Token, nur eigene Pakete, inaktive Version im eigenen Transport – Z-Insight erhält keine Schreibrechte.

Vollständiges Audit

Jeder KI-Aufruf mit Anbieter, Modell und Richtlinie, jede Bewertung und administrative Änderung – mit Akteur und Zeitstempel.

READ-ONLY

Z-Insight kann in Ihrem SAP-System nichts verändern – auch dann nicht, wenn es jemand wollte. Korrekturen, Umbau-Skizzen und Tickets sind Vorschläge; übernommen wird vom Entwickler – per ADT, abapGit oder Ihrem eigenen Übernahme-Report, unter seinem SAP-Benutzer.

Was Ihre Basis einrichtet

Vier Handgriffe

Voraussetzungen im SAP-System
Was	Details
ICF-Dienst	In SICF den Dienst /sap/bc/soap/rfc aktivieren; für den optionalen ADT-Zugriff zusätzlich /sap/bc/adt.
Technischer Benutzer	Benutzer vom Typ System mit ausschließlich lesenden Rechten – etwa Z_ZINSIGHT_READ.
Berechtigungen	S_RFC (Aktivität 16) auf die lesenden Bausteine, S_TABU_NAM (Aktivität 03) auf die benannten Tabellen. Z-Insight erzeugt den Rollenvorschlag und prüft jedes Feld gegen das Data Dictionary.
Netzwerk	HTTPS vom Z-Insight-Server zum ICM-Port – bei RISE auch über SAP BTP und Cloud Connector ohne Firewall-Freigabe.

Ergebnis-Artefakte

Was Sie in der Hand haben

Die Analyse endet nicht im Bildschirm: Berichte, Workshop-Unterlagen und Fahrplan entstehen aus denselben Zahlen – in allen Formaten identisch.

Assessment-Bericht mit Export als Markdown, Word und Druck/PDF, Vorlagen Management, Transformation, Betrieb und Vollständig, wählbaren Kapiteln, Deckblatt und Option Personen pseudonymisieren

Assessment-BerichtManagement-Summary mit Ampeln, Datenlage, E2E-Landkarte, Simplification und Readiness, S/4-Planung, Konversion und Datenseite, Clean Core, E-Rechnung, Schnittstellen, Retail, Betrieb und Hypercare, Code-Governance, Sicherheit mit Patchstand, Datenschutz, Maßnahmenplan und Anhang. Vorlagen für Management, Transformation und Betrieb, Kapitel wählbar, Deckblatt je System, Personen pseudonymisierbar.WORDPDFMARKDOWN
Workshop-UnterlagenHeatmap und E2E-Landkarte, Simplification Items, Wertbeitrag je Value Stream und Fit-to-Standard-Vorbereitung je Prozess.MARKDOWNCSV
TransformationsfahrplanPlanbasis, Wellenplan je E2E-Prozess, Zeitplan und Clean-Core-Zielbild.MARKDOWNCSV
Maßnahmenplan und BerichtePriorisierte Maßnahmen, Management- und Betriebs-Wochenbericht, Governance- und Roadmap-Bericht, Tickets in Ihrem System.CSVMARKDOWNSARIFOCEL 2.0BPMN

Management-Summary im Assessment-Bericht: neun Dimensionen mit Wert, Ampel und Herleitung – Aussagekraft, Readiness, Clean Core, Stabilität, Code-Governance, Sicherheit, technische Schuld, Schnittstellen und Customizing — Management-Summary im Assessment-Bericht: jede Ampel mit Wert und Herleitung.

Auf einen Blick

Weitere Funktionen auf derselben Faktenlage

Mein Tag: Startseite je Rolle – was bei mir liegt, was seit dem letzten Besuch neu ist, Hinweise wie Hypercare-Alarm, kritische Z-Tabellen oder offene E-Rechnungs-Maßnahmen, nächster Schritt
Arbeitsräume: Menü nach Aufgaben statt Funktionsliste, Suche über alle Seiten und Reiter
Arbeitsvorrat: alle offenen Punkte des Systems in einer Liste, gespeichert in der jeweiligen Quelle
Erkenntnisse mit Beleg, Konfidenz, Zuständigen, Fristen und Sammelbearbeitung
Z-Objekte mit Risiko, Clean-Core-Stufe, S/4-Status, Nutzung und Herleitung
Objekt-Detail mit Quelltext, Befunden an der Zeile, Dump-Abbruchstellen und Zeitleiste
Erweiterungen: Exits, BAdIs, implizite Erweiterungen, Modifikationen mit Migrationspfad
Customizing-Konsistenz, Änderungen ohne Transport, Vergleich über die Landschaft
Transporte mit Risiko, Kollisionen, Überholern und Störungen nach Import
Landschaftsvergleich zweier Systeme oder Stände mit Quelltext-Diff
Sicherheit: Befunde nach Erreichbarkeit und Ausnutzbarkeit, CWE/OWASP-Zuordnung
Compliance: Funktionstrennung, indirekte Nutzung, personenbezogene Daten
Laufzeit-Hotspots aus ST03N mit Tuning-Arbeitsvorrat
Systemgraph und Pfadsuche über Objekte, Tabellen, Jobs und Schnittstellen
Roadmap & Lifecycle mit Qualitätsverlauf und Meilensteinen
Portfolio aller SAP-Systeme mit normiertem Vergleich, Konversions-Bereitschaft und Bereitschaft für E-Rechnung, Löschkonzept, Patchstand und Korrektur-Ist-Quote je System
Automatisierung: Wenn-dann-Regeln für Tickets, Nachrichten und Workflows
Deutsche und englische Oberfläche, englische Fassung der Berichte

Häufige Fragen

Was im ersten Gespräch meistens gefragt wird

Was müssen wir in unserem SAP-System installieren?

Nichts. Z-Insight greift über den Standarddienst /sap/bc/soap/rfc zu – reines HTTPS mit XML. Kein Transport, kein Agent, kein JCo und kein NW-RFC-SDK. Ihre Basis aktiviert den ICF-Dienst, legt einen technischen Benutzer mit Leserechten an und gibt den ICM-Port frei; den Rollenvorschlag liefert Z-Insight.

Kann Z-Insight etwas in unserem System verändern?

Nein – nicht aus Zusage, sondern aus Konstruktion. Eine Whitelist ausschließlich lesender Funktionsbausteine wird unmittelbar vor jedem Aufruf geprüft; keine ändernden BAPIs, kein COMMIT, ADT nur per GET. Benutzer- und Rollentabellen, RFC-Destinationen, HR- und Bankdaten sind gesperrt. Korrekturvorschläge, Umbau-Skizzen und Änderungsanfragen sind Vorschläge, die ein Entwickler von Hand übernimmt.

Brauchen wir dafür eine KI, und wohin gehen unsere Daten?

Sie brauchen keine. Ohne konfigurierten Anbieter arbeitet Z-Insight regelbasiert und liefert dasselbe Format; die Anwendung kennzeichnet, welcher Weg verwendet wurde. Wenn Sie KI einsetzen möchten, wählen Sie zwischen einem öffentlichen Dienst, Azure OpenAI im eigenen Tenant und einem Modell in Ihrem Rechenzentrum – dann verlässt kein Quelltext Ihr Netz. Benutzernamen werden pseudonymisiert, die Quelltext-Richtlinie ist dreistufig einstellbar.

Wir nutzen ATC, den SAP Readiness Check und die Custom Code Migration App. Was kommt dazu?

Diese Werkzeuge liefern Befunde. Z-Insight verbindet sie mit Nutzung, Laufzeitfehlern, Transporten und Customizing und ordnet sie den E2E-Prozessen zu – daraus werden Aufwand, Wellen und ein Fahrplan. ATC- und Readiness-Check-Ergebnisse lassen sich importieren und abgleichen: was beide finden, was nur eine Seite. Für Clean Core nutzt Z-Insight dieselben von SAP veröffentlichten Freigabedaten wie die ATC-Prüfung „Usage of APIs“, auch für ECC-Code. Das ist eine Ergänzung, keine Ablösung.

Wie kommen wir vom Scan zu einem Angebot für das S/4HANA-Projekt?

Über das Pre-Assessment. Es gleicht die gemessene Nutzung mit den offiziellen Scope Items der SAP Best Practices ab, ordnet Eigenentwicklungen den Scope Items zu und zeigt Kundenprozesse ohne Standard-Entsprechung. Daraus ergeben sich Story Points, Personentage, Discovery, Lieferzeitraum und eine Festpreis-Indikation mit Bandbreite, Risikoregister, Phasenplan nach SAP Activate und Angebotsentwurf als Word-Dokument; alle Richtwerte sind offengelegt und anpassbar. Nach den Fit-to-Standard-Workshops erfassen die Berater ihre Entscheidungen, und Bericht, Aufwand und Festpreis rechnen sich neu.

Gibt es eine Dokumentation für die Anwender?

Ja. Das Benutzerhandbuch beschreibt jede Seite mit Zweck, Aufbau und Schritt-für-Schritt-Anleitungen und zeigt sie mit Bildschirmfotos. Es wird mit jeder Version neu erzeugt und steht angemeldeten Anwendern in der App unter Hilfe als PDF zum Download bereit; Rechenwege und Schwellen erklärt zusätzlich die Methodik in der App.

Wie belastbar sind Readiness und Aufwand für die S/4-Konversion?

Jede Aussage ist gekennzeichnet: belegt (aus dem Scan), release-unabhängig (aus der Simplification-Liste) oder Richtwert. Der Readiness-Index zeigt seine Herleitung, der Aufwand wird je Zugriff geschätzt und ist über die Aufwandsparameter anpassbar. Die Aussagekraft des Scans weist aus, welche Datenquellen fehlen oder nur teilweise vorliegen – etwa Nutzungsdaten aus einem Testmandanten – und wie das die Zahlen einschränkt.

Wir können zunächst nur ein Entwicklungs- oder Testsystem scannen. Reicht das?

Für Code, Clean Core, Simplification und Sicherheit ja. Nutzung und Laufzeitfehler spiegeln dort aber nicht den Produktivbetrieb; Z-Insight benennt das in der Aussagekraft, statt Nullen zu zeigen, und markiert ungenutzten Code nur als Stilllegungskandidaten. Die Nutzungszähler eines Produktivsystems lassen sich übernehmen – nur Zähler, keine Inhalte.

Wie groß darf das System sein?

Z-Insight ist auf große Echtsysteme ausgelegt: Delta-Scans lesen nur Geändertes, Objektlisten werden gefiltert, sortiert und seitenweise geladen, Antworten zwischengespeichert. Mit dem mitgelieferten Lasttest (npm run loadtest, synthetisches Großsystem ohne SAP-Latenz) analysiert Z-Insight rund 20.000 Z-Objekte mit etwa 500.000 Zeilen Quelltext in rund 50 Sekunden Rechenzeit bei etwa 520 MB Arbeitsspeicher; das Ergebnis belegt komprimiert rund 20 MB. Im Echtbetrieb bestimmt vor allem die Antwortzeit des SAP-Systems die Scandauer.

Wie lange dauert ein Scan?

Das hängt an der Größe des Systems, der Antwortzeit und dem gewählten Profil – Schnell, Standard oder Gründlich. Quelltexte werden parallel gelesen, der Fortschritt zeigt eine Restzeit, ein Scan lässt sich jederzeit abbrechen. Bei Folgescans werden unveränderte Quelltexte aus dem Vorscan übernommen und trotzdem mit den aktuellen Regeln geprüft.

Was steht im Assessment-Bericht, und in welchen Formaten gibt es ihn?

Management-Summary mit Ampeln, Aussagekraft und Datenlage, E2E-Landkarte mit Handlungsfeldern, Simplification und Readiness, S/4-Planung, Konversion und Datenseite, Clean Core, E-Rechnung, Schnittstellen, Retail, Betrieb, Stabilität und Hypercare, Code-Governance, Sicherheit und Patchstand, Datenschutz (Löschkonzept), Maßnahmenplan und Anhang mit Methodik. Vorlagen für Management, Transformation und Betrieb, Kapitel frei wählbar, Deckblatt je System. Ausgabe als Word (.docx), Markdown und als Druckansicht für PDF – mit identischen Zahlen. Keine Quelltexte und keine Zugangsdaten im Bericht; Personen lassen sich pseudonymisieren.

Geht das auch mit RISE, S/4HANA Cloud Public Edition oder auf SAP BTP?

Ja. RISE/Private Cloud wird wie on-premise gelesen – direkt oder, wenn Z-Insight auf SAP BTP läuft, über eine Destination und den Cloud Connector, ohne Firewall-Freigabe. In der Public Cloud gibt es kein RFC; dort liest Z-Insight Belege über freigegebene OData-APIs mit einem Kommunikationsbenutzer und Eigenentwicklungen aus dem gCTS- bzw. abapGit-Repository. Laufzeitfehler und Customizing der Public Cloud sind auf diesem Weg nicht direkt zugänglich.

Brauchen wir für Process Mining ein zusätzliches Werkzeug?

Nein. Z-Insight rekonstruiert die Abläufe selbst aus dem Belegfluss und verknüpft sie mit den Eigenentwicklungen je Schritt. Wer bereits ein Process-Mining-Werkzeug nutzt, übernimmt das Ereignisprotokoll als CSV, objektzentriert als OCEL 2.0 oder das Modell als BPMN, etwa für SAP Signavio.

Wo läuft Z-Insight, und was speichert es?

Als Container oder Node-Dienst – in Ihrem Rechenzentrum, in Ihrer Cloud, auf SAP BTP oder bei uns betrieben; unsere Instanz läuft mit Anwendung, Datenbank und Datenträger in Frankfurt am Main beim nach ISO/IEC 27001 und SOC 2 zertifizierten Hoster Render. Gespeichert werden Scan-Ergebnisse, Erkenntnisse, Bewertungen und das Audit-Protokoll in einer eingebetteten Datenbank oder in PostgreSQL, mit täglicher Sicherung und einstellbarer Aufbewahrung.

Können sich unsere Mitarbeitenden mit ihrem Microsoft-Konto anmelden?

Ja. Z-Insight unterstützt Single Sign-on über OpenID Connect mit Microsoft Entra ID. Rollen und Mandanten kommen aus den App-Rollen Ihres Verzeichnisses. Mehrere Gesellschaften oder Kunden lassen sich in einer Instanz getrennt betreuen; die Trennung wird zentral in der Schnittstelle durchgesetzt.

Woran sehen wir, dass eine automatische Korrektur stimmt?

An ihrem Nachweis. Jede automatische Korrektur wird vor der Ausgabe offline geprüft: Syntax und Blockstruktur, Befunde je Regel, keine neuen schweren Befunde, keine neuen Schreibzugriffe. Dazu kommt je Korrektur ein ABAP-Unit-Testgerüst als Vergleichstest und ein Prüfprotokoll im Korrekturpaket. Die Offline-Prüfung ersetzt nicht Syntaxprüfung, ATC und Test im Entwicklungssystem – sie sorgt dafür, dass dort nur ankommt, was schon belegt ist. Eingespielt wird weiterhin von Hand.

Wer spielt die Korrekturen ins SAP-System ein?

Der Entwickler, der sie freigibt – mit seinem eigenen SAP-Benutzer. In der Korrektur-Werkstatt wird jede Stelle angenommen, abgelehnt oder geändert, mit Ticket und Kommentar; das Übernahmepaket enthält nur Freigegebenes und dokumentiert jede Stelle mit einer Kommentarzeile im Code. Übernommen wird per ADT, abapGit oder mit einem kundeneigenen Übernahme-Report: Er holt die freigegebenen Korrekturen mit einem persönlichen, befristeten Token ab und schreibt sie – vom Entwickler gestartet, unter seinem SAP-Benutzer – als inaktive Version in seinen Transportauftrag, nach Prüfung von Ausgangsstand, Berechtigung und Syntax. Z-Insight selbst schreibt nichts ins SAP-System und braucht keinen technischen Benutzer mit Schreibrechten; der Korrektur-Kreislauf zeigt später Transportinhaber und Freigabe nebeneinander.

Was passiert nach einem Transportimport?

Mit eingeschalteter Überwachung liest Z-Insight im eingestellten Abstand das Importprotokoll. Neue Importe starten eine Delta-Prüfung: Unveränderte Objekte kommen aus dem Cache, nur geänderte werden neu gelesen und analysiert. Der Bericht zeigt neue S/4-Blocker, neue schwere Befunde und verschlechterte Sicherheitseinstellungen; auf Wunsch als Ticket, Teams/Slack-Nachricht, E-Mail oder Webhook.

Woher kennt Z-Insight die fehlenden Sicherheitshinweise?

Aus Ihrem Export von SAP System Recommendations (SAP Solution Manager oder SAP Cloud ALM). Z-Insight erfindet keinen eigenen Hinweiskatalog, sondern bewertet jeden Hinweis gegen den installierten Support-Package-Stand aus dem Scan und zeigt, welche Eigenentwicklungen betroffene Standardbausteine verwenden.

Arbeitet Z-Insight mit unserer Testautomatisierung zusammen?

Ja – anbinden statt nachbauen. Aus dem Testrisiko eines Release entsteht ein Testplan, der an Tricentis Tosca und qTest, SAP Cloud ALM oder als erzeugtes Playwright-Projekt für SAP GUI für HTML und Fiori geht. Ergebnisse kommen als Testläufe zurück (Playwright-JSON, JUnit, Abruf aus Tosca, qTest und Cloud ALM); Fehlschläge werden Defekte, auf Wunsch direkt im Ticketsystem. Die Nachweiskette zeigt je Einstiegspunkt Transport, Testrisiko, Ausführung und Nachweis.

Wie fangen wir an?

Mit einer Stunde am Demo-System – Sie sehen den kompletten Weg vom Abbruch zur belegten Ursache und von der Landkarte zum Fahrplan, ohne Vorbereitung auf Ihrer Seite. Danach ein Scan auf einem Ihrer Systeme: technischen Benutzer anlegen, ICF-Dienst freigeben, Berechtigungen prüfen, scannen. Das Ergebnis ist ein Assessment-Bericht über Ihr eigenes System.

Woher wissen wir, ob die Korrekturen wirklich angekommen sind?

Am Ende jedes Laufs der Korrektur-Werkstatt hält Z-Insight je Objekt einen Stand fest (Prüfsumme und Fundstellen je Regel, kein Quelltext). Jeder spätere Scan misst daran: eingespielt (Quelltext geändert, mit Transportauftrag als Beleg), im System bestätigt (Fundstellen weg) und getestet (verknüpfter Testfall nach dem Lauf ohne Fehler oder von Hand bestätigt). Daraus entsteht die Ist-Quote – und mit der Zeiterfassung die Nachkalkulation der Richtwerte.

Hilft Z-Insight bei der E-Rechnungspflicht?

Z-Insight findet eigene Rechnungsformulare und Druckprogramme, die Ausgabesteuerung und EDI-Rechnungen je Partner und stellt sie den Fristen für Empfang und Versand gegenüber – mit Maßnahmenplan und Richtwerten. Die rechtliche Bewertung im Einzelfall bleibt bei Ihrer Steuerberatung; Rechnungsinhalte liest Z-Insight nicht.

Nächster Schritt

Eine Stunde, und Sie wissen, was in Ihrem SAP-System steckt

Wir zeigen den kompletten Weg an einem vollständig befüllten Demo-System: von der E2E-Landkarte über die Ursache eines Abbruchs bis zum Assessment-Bericht. Danach entscheiden Sie, ob wir dasselbe auf einem Ihrer Systeme machen.

Demo vereinbaren RealCore kennenlernen (öffnet in neuem Fenster)

Sie haben bereits Zugang? Zum Login

Demo am Demo-SystemEine Stunde, keine Vorbereitung auf Ihrer Seite.
Scan auf Ihrem SystemTechnischer Benutzer mit Leserechten, ICF-Dienst frei – mehr nicht.
AssessmentBericht über Ihr System mit Management-Summary, E2E-Landkarte, Aufwand und Maßnahmenplan.
Nutzung im ProjektAls Grundlage für S/4-Transformation und Clean Core oder im laufenden AMS-Betrieb.