Analyse von SAP-Eigenentwicklungen

Wissen, was der eigeneSAP-Code anrichtet –und warum.

Z-Insight liest Ihre Z-Entwicklungen, das dazugehörige Customizing, die Transporte und die Laufzeitfehler – und verbindet sie zu Erkenntnissen mit Ursache, Beleg und Empfehlung. Lesender Zugriff über den SAP-Standarddienst, ohne Installation im SAP-System.

ECC und S/4HANALesend über /sap/bc/soap/rfc, ab Web AS 6.20
Keine InstallationKein Transport, kein Agent, kein JCo im System
KI optionalRegelbasiert oder mit Anbieter Ihrer Wahl
Das Cockpit von Z-Insight mit Kennzahlen, Verlauf und den wichtigsten Zusammenhängen

Zum Erkunden seitlich schieben

Das Problem

Die Wahrheit über den eigenen Code liegt an vier Orten

Wer einen Abbruch bewerten will, braucht alle vier Informationsstände. Heute bekommt er sie nur einzeln – aus vier Transaktionen und mehreren Köpfen.

Quelltext

SE80, SE38. Was der Z-Report, das BAdI oder der Exit tatsächlich tut – inklusive der Includes, die niemand mehr liest.

Customizing

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

Transporte

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

Laufzeitfehler

ST22, SM37, WE02. Dumps, Jobabbrüche, Verbuchungs-, IDoc- und Log-Fehler – jeweils ohne Bezug zueinander.

Der eigentliche Aufwand

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

Fehler fällt auf, ST22, Quelltext, Customizing, Transport suchen, Vermutung. Sechs Schritte Handarbeit, an deren Ende meist eine plausible Vermutung steht – selten ein Beleg, und fast nie etwas, das beim nächsten Mal noch da ist.

Die Lösung

Ein Scan, der die vier Stände verbindet

Z-Insight liest in fester Reihenfolge – und korreliert erst, wenn alle Fakten vorliegen. Das Ergebnis sind nicht Befunde, sondern Erkenntnisse: belegte Zusammenhänge mit Konfidenz und Empfehlung.

01

Inventar

Alle Z-/Y-Objekte aus TADIR, TRDIR, Klassen und Funktionsbausteinen.

02

Erweiterungen

CMOD/SMOD-Exits, klassische und neue BAdIs, Modifikationen.

03

Probleme

ST22, SM37, SM13, WE02 und SLG1 des Beobachtungszeitraums.

04

Transporte

Aufträge mit Importzeitpunkt und Rückgabecode im Zielsystem.

05

Quelltext & Customizing

Rekursiv inklusive Includes – und die vom Code gelesenen Tabellen.

06

Korrelation

Fehlerbild ↔ Transport ↔ Customizing ↔ Prüftabelle ↔ Befund ↔ Abbruchzeile.

Sechs Kennzahlen

Zahlen, die es vorher nicht gab

Offene kritische Erkenntnisse, Z-bezogene Probleme, Customizing-Lücken, gestörte Schnittstellen, Clean-Core-Score und S/4HANA-Readiness – jede mit Verlauf über alle Scans und Vergleich zum vorherigen Lauf.

Kennzahlenleiste mit sechs Kacheln und Trendlinien

Zum Erkunden seitlich schieben

Ein Fall, durchgespielt

Ein BAdI bricht seit dem 17. September ab

Was Z-Insight daraus macht – unverändert aus der Anwendung.

Die erkannte Ursachenkette in der Anwendung, mit Beleg, Konfidenz und Empfehlung

Zum Erkunden seitlich schieben

  1. Das Symptom27 Fehlermeldungen in ME21N, erstmals am 17.09.
  2. Der AuslöserTransport ES1K900415, importiert am 16.09.
  3. Die KetteDer Transport legt in T161 die Bestellart ZNB2 an. T161 ist Prüftabelle der Kundentabelle ZMM_RELEASE_LIMITS, die das BAdI liest – dort fehlt ZNB2.
  4. Der Beleg14 Tage vorher: 0 Fehler. Danach: 27. Konfidenz 95 %.
  5. Die EmpfehlungFehlende Folgeeinträge pflegen und den Code robust gegen neue Customizing-Werte machen.
Warum das kein Code-Scanner leistet Ein Scanner findet den hart codierten Wert im Quelltext. Er weiß aber nicht, dass genau dieser Wert vor zwei Tagen per Transport in eine Prüftabelle kam, dass eine Kundentabelle davon abhängt und dass seither 27 Fehler auftreten. Ein Befund wird erst dann zur Erkenntnis, wenn er einen realen Fehler im System erklärt.

Vom Befund zur Handlung

Alles, was zu tun ist – in einer Liste

Die häufigste Kritik an Analysewerkzeugen lautet: „Wir haben jetzt viertausend Befunde und wissen nicht, wo wir anfangen.“ Genau das beantwortet der Maßnahmenplan.

Der Maßnahmenplan mit priorisierten Einträgen, jeweils mit Wirkung, Aufwand und Priorität

Zum Erkunden seitlich schieben

  1. Je Eintrag eine HandlungNicht „hier ist ein Befund“, sondern was konkret zu tun ist – mit Transaktion und Vorgehen.
  2. Wirkung und AufwandBeides eingeschätzt, daraus die Priorität. Die Reihenfolge ist damit begründbar.
  3. Vier Quellen, eine ListeOffene Erkenntnisse, kritische Code-Befunde ohne Erkenntnis, Altlasten und Lücken im Scan stehen nebeneinander.
  4. Geht rausAls CSV oder Markdown; die ersten drei stehen als „Nächste Schritte“ im Cockpit, die ersten zehn im Management-Bericht.

Testumfang je Release

Was muss dieses Release eigentlich getestet werden?

Aus den Transporten eines Zeitraums werden geänderte Objekte, ihre Aufrufer und alle Einstiegspunkte ermittelt – Transaktionen, Jobs, Schnittstellen, RFC-Bausteine und Prozesse. Pflicht ist, was tatsächlich genutzt wird, eingeplant ist oder Fehler hatte.

Der ermittelte Testumfang mit Pflicht- und optionalen Testfällen je Transport

Zum Erkunden seitlich schieben

Pflicht statt Vollständigkeit

Getestet wird, was genutzt wird, eingeplant ist oder Fehler hatte – nicht alles, was theoretisch betroffen sein könnte.

„Zuerst testen“

Genutzte Objekte mit hohem Risiko und schweren Befunden werden in der Liste vorgezogen.

Testlücken sichtbar

Geänderte Objekte ohne erreichbaren Einstiegspunkt fallen auf, statt unbemerkt zu bleiben.

Direkt ins Testmanagement

CSV-Export je Testfall mit Art, Pflichtgrad, Nutzung und auslösendem Transport.

Die Rechnung, die jeder Testmanager sofort versteht Im gezeigten Beispiel sind 8 von 29 Einstiegspunkten des Systems betroffen – 72 Prozent müssen für dieses Release nicht getestet werden. Statt einer pauschalen Regression bleibt eine begründete Liste, die sich einem Transport zuordnen lässt.

Vom Symptom zur Zeile

Jeder Befund steht an seiner Stelle im Code

Der Quelltext wird rekursiv gelesen – über Includes, Klassen-Pools und Funktionsbaustein-Includes hinweg. Abbruchstellen aus Dumps werden auf den zusammengesetzten Quelltext umgerechnet und markiert.

ABAP-Quelltext mit markierten Befunden an den betroffenen Zeilen

Zum Erkunden seitlich schieben

Was die Analyse hier findet

  1. Zeile 18Hart codierter Wert ZNB9, der im Customizing gar nicht existiert.
  2. Zeile 41Direkte Änderung einer SAP-Standardtabelle (EKKO).
  3. Zeile 42COMMIT WORK in einer Erweiterung – bricht die LUW der Standardtransaktion.
  4. Zeile 47SELECT SINGLE ohne Prüfung von sy-subrc.

Ursache, Wirkkette, Maßnahme

Mit KI – oder ganz ohne

Je Objekt entsteht eine Einschätzung mit Ursachen nach Wahrscheinlichkeit und Maßnahmen nach Dringlichkeit. Mit KI-Anbieter kommen Wirkkette, ABAP-Korrekturvorschlag und Testfälle dazu; ohne Anbieter arbeitet Z-Insight regelbasiert im identischen Format weiter – und kennzeichnet, welcher Weg verwendet wurde.

Das gezeigte Beispiel ist der regelbasierte Weg, ganz ohne KI-Anbieter.

Einschätzung mit Ursachen, Wahrscheinlichkeiten und Maßnahmen

Zum Erkunden seitlich schieben

Landkarte der IDoc-Schnittstellen mit Sendern, Empfängern und Zuständen

Zum Erkunden seitlich schieben

Schnittstellen

Auch das, was gar keinen Fehler mehr wirft

IDoc, tRFC und qRFC in einer Sicht: wer sendet, was klemmt, seit wann – und welcher Kundencode in der Verarbeitung steckt. Inklusive Rückstau in den Status 30, 64 und 66 und der Strecken, die seit Tagen verstummt sind. Eine Schnittstelle, die gar nichts mehr sendet, fällt in keinem Monitoring auf – sie erzeugt ja keinen Fehler.

Clean Core

Eingestuft nach SAPs eigenen Freigabedaten

Die Stufen A bis D sind keine Hausmeinung. Grundlage sind die von SAP veröffentlichten Freigabedaten aus dem Cloudification Repository – dieselben Daten, die auch die ATC-Prüfung „Usage of APIs“ verwendet. Nur eben auch für ECC-Kundencode, wo ATC das nicht leistet.

Die Stufenverteilung A bis D und die Auswertung der verwendeten SAP-Objekte

Zum Erkunden seitlich schieben

A

Freigegeben

Nur öffentlich freigegebene, stabile APIs.

B

Classic API

Zusätzlich klassische APIs, Kundenexits und klassische BAdIs.

C

SAP-intern

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

D

Modifikation

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

Die Stufe ist die schlechteste Verwendung im Objekt Und zu jeder nicht freigegebenen Verwendung nennt SAP den Nachfolger – etwa MSEG → I_MATERIALDOCUMENTITEM_2. Der Datenstand wird mitgeliefert und lässt sich in den Einstellungen direkt von GitHub aktualisieren. Quelle: SAP Cloudification Repository (github.com/SAP/abap-atc-cr-cv-s4hc, Apache-2.0).

S/4HANA

Was nach der Umstellung tatsächlich passiert

Viele ECC-Tabellen werden in S/4HANA nicht mehr befüllt. Open SQL wird auf CDS-Kompatibilitäts-Views umgeleitet – lautlos, ohne Dump und ohne Warnung. Z-Insight zeigt schon im ECC-System, was danach scheitert oder teuer wird.

Tabellen mit Kompatibilitäts-Views, ihrer Bewertung und den gefundenen Problemen

Zum Erkunden seitlich schieben

Schreiben wirkt nicht mehr

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

Native SQL umgeht die Umleitung

Native SQL, ADBC und DDIC-Datenbank-Views greifen auf die physische Tabelle zu – und die ist leer. Kunden-Views auf MKPF/MSEG liefern keinen Satz.

Berechnete Felder kosten Laufzeit

Bestände und Summen werden bei jedem Zugriff aggregiert. In Schleifen führt das zu langen Laufzeiten, Speicher- und SQL-Fehlern.

KONV hat gar keine Umleitung

Belegkonditionen liegen in PRCD_ELEMENTS. Ein Lesen auf KONV liefert nichts – ohne jede Fehlermeldung.

OK

Keine Konversionsblocker gefunden.

Anpassen

Kompatibilitätsviews, geänderte Feldlängen, obsolete Sprachelemente.

Blocker

Zugriff auf entfallene Tabellen, Native SQL, Schreibzugriff auf Standardtabellen.

Grundlage ist die Simplification List for SAP S/4HANA 2023 FPS3 mit den zugehörigen SAP-Hinweisen – unter anderem 2267308 (KONV), 2267306 (VBUK/VBUP), 2206980 (MATDOC), 2265093 (Business Partner) und 2267140 (MATNR 40 Zeichen).

Funktionen

Neunzehn Arbeitsbereiche auf derselben Faktenlage

Jeder für eine andere Rolle – Betrieb, Entwicklung, Architektur, Leitung.

Cockpit

Kennzahlen mit Verlauf, Veränderung seit dem letzten Scan, Top-Risiken, Systembericht mit Maßnahmenplan.

Erkenntnisse

Zusammenhänge mit Beleg, Konfidenz und Empfehlung; Status, Zuständige, Fristen, Sammelbearbeitung, Jira-CSV.

Z-Objekte

Inventar mit Risiko-Score, Clean-Core-Stufe, S/4-Status und tatsächlicher Nutzung; CSV-Export.

Objekt-Detail

Quelltext mit Befunden, Abhängigkeiten, gelesenes Customizing, Zeitleiste, kopierter Code, KI-Analyse.

Erweiterungen

CMOD/SMOD-Exits, klassische und neue BAdIs, implizite Erweiterungen und Modifikationen – nach Geschäftsprozess.

Customizing

Vom Z-Code gelesene Tabellen mit Inhalt, letztem Transport und Konsistenzprüfung gegen die SAP-Prüftabelle.

Laufzeitprobleme

ST22, SM37, SM13, WE02 und SLG1 – gruppiert nach Fehlerbild und dem verursachenden Z-Objekt zugeordnet.

Schnittstellen

IDoc, tRFC und qRFC: Landkarte, Katalog, Rückstau, verstummte Strecken, Partnervereinbarungen und Ports.

Hintergrundjobs

Abbruchquote, Median-Laufzeit, Laufzeittrend und Regressionen nach Transporten.

Sicherheit

Sicherheitswert, SEC-Befunde nach Regel und Schwere, Inventar der remotefähigen Z-Bausteine.

Transporte

Importdatum und Rückgabecode, Folgefehler, Transport-Check mit Testumfang, Erkennung von Überholern.

Landschaftsvergleich

Zwei Systeme oder zwei Stände: Objekte nur auf einer Seite, Quelltext-Diff, Customizing-Unterschiede.

Maßnahmenplan

Alles Offene in einer Liste, sortiert nach Wirkung je Aufwand – als CSV und Markdown.

Scan-Qualität

Abdeckung der Quelltext-Analyse, Hinweise mit Abhilfe, Rollenvorschlag, Diagnosepaket.

Entwickler & Altlasten

Objekte, Befunde und Probleme je letztem Änderer; Altersstruktur und Stilllegungskandidaten.

Code-Suche & Standard

Regulärer Ausdruck über alle Quelltexte; verwendete SAP-Standardtabellen, Bausteine und Klassen.

Clean Core

Einstufung A–D je Objekt auf Basis der von SAP veröffentlichten Freigabedaten, mit den genannten Nachfolgern.

Kompatibilitäts-Views

Was der Z-Code mit ECC-Tabellen macht, die in S/4HANA nur noch als CDS-Ersatzobjekt existieren.

Testumfang

Welche Testfälle ein Release wirklich braucht – abgeleitet aus Transporten, Aufrufern und tatsächlicher Nutzung.

Dazu: Pakete, Regelkatalog mit eigenen Regeln je System, Auswirkungsanalyse, KI-Assistent, Management-Bericht als A4-Druckansicht, Benutzer und Rollen, API-Tokens, Audit-Protokoll sowie Export als Markdown, JSON, CSV und SARIF 2.1.0 für GitHub und GitLab Code Scanning.

Zugriff und Sicherheit

Read-only by design

Nicht als Zusage, sondern als Konstruktion: Was nicht gelesen werden darf, kann gar nicht erst aufgerufen werden.

Kein Eingriff im SAP-System

Zugriff über den Standarddienst /sap/bc/soap/rfc. Kein Transport, kein Agent, kein JCo, kein NW-RFC-SDK – verfügbar ab Web AS 6.20.

Whitelist statt Blacklist

Nur lesende Funktionsbausteine sind zugelassen; die Liste wird unmittelbar vor jedem einzelnen Aufruf geprüft. Keine ändernden BAPIs, kein COMMIT.

Gesperrte Tabellen

Benutzer- und Rollentabellen, RFCDES mit den Anmeldedaten, HR- und Bankdaten sind nie lesbar – hart verdrahtet, nicht konfigurierbar.

Technischer Leser

Ein Benutzer vom Typ System mit ausschließlich lesenden Rechten auf eine feste Liste von Bausteinen und Tabellen.

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 je Verbindung.

Vollständiges Audit

Jeder Zugriff, jeder KI-Aufruf mit Anbieter, Modell und Richtlinie, jede 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.

Was Ihre Basis einrichtet

Vier Handgriffe

WasDetails
ICF-DienstIn SICF den Dienst /sap/bc/soap/rfc aktivieren; für den optionalen ADT-Zugriff zusätzlich /sap/bc/adt.
Technischer BenutzerBenutzer vom Typ System, ausschließlich Leserechte – etwa Z_ZINSIGHT_READ.
S_RFCRFC_TYPE = FUNC, Aktivität 16 auf RFC_PING, RFC_SYSTEM_INFO, RFC_READ_TABLE, DDIF_FIELDINFO_GET und RPY_PROGRAM_READ; optional SWNC_COLLECTOR_GET_AGGREGATES für die Nutzungsstatistik.
S_TABU_NAMAktivität 03 auf die benannten Tabellen – Repository, Erweiterungen, Laufzeitprobleme, Transporte und Data Dictionary. Schnittstellentabellen sind optional; fehlen sie, entfallen nur diese Prüfungen.
NetzwerkHTTPS vom Z-Insight-Server zum ICM-Port. Eine interne Zertifizierungsstelle lässt sich über NODE_EXTRA_CA_CERTS einbinden.
Danach prüft die Anwendung selbst Die Funktion „Berechtigungen prüfen“ gleicht jedes Feld, das der Scan lesen würde, mit dem Data Dictionary des Zielsystems ab und zeigt je Tabelle und Baustein, was noch fehlt. Fehlende Berechtigungen brechen einen Scan nicht ab – sie erscheinen als Hinweis.

Scan-Qualität

War der Scan überhaupt vollständig?

Eine eigene Seite beantwortet die Frage, die jeder Analyse zu Recht gestellt wird – und sagt, was zu tun ist, wenn etwas fehlt.

Die Seite Scan-Qualität mit Abdeckung, Hinweisen und dem Rollenvorschlag für den Lese-Benutzer

Zum Erkunden seitlich schieben

Abdeckung

Wie viele Objekte frisch gelesen, aus dem Vorscan übernommen, durch das Limit ausgelassen oder nicht lesbar waren.

Hinweise mit Abhilfe

Fehlende Tabellen oder Berechtigungen gebündelt – mit dem konkreten Schritt, der sie behebt.

Rollenvorschlag

Die Berechtigungen, die der Lese-Benutzer tatsächlich braucht – fehlgeschlagene Einträge markiert, als Text zum Übernehmen.

Diagnosepaket

Für den Support, ohne Zugangsdaten und ohne Quelltexte.

KI und Datenschutz

Sie entscheiden, ob und wohin Daten gehen

Ohne KI-Anbieter arbeitet Z-Insight regelbasiert im identischen Format weiter. Die KI verbessert Formulierung und Korrekturvorschläge – sie trägt nicht die Analyse.

Anthropic Claude

Öffentlicher Dienst.

OpenAI

Öffentlicher Dienst.

Azure OpenAI

Eigener Tenant, EU-Region.

On-Prem

Ollama, vLLM, LM Studio – der Quelltext verlässt Ihr Netz nicht.

Keine KI

Regelbasierte Auswertung im gleichen Format.

Pseudonymisierung

SAP-Benutzernamen werden vor dem Versand durch BENUTZER_01 … ersetzt und in der Antwort zurückübersetzt.

Quelltext-Richtlinie

Drei Stufen: vollständig, nur Ausschnitte von ±4 Zeilen um Befunde, oder gar kein Quelltext. IBAN, E-Mail und Telefonnummern in Literalen werden maskiert.

Transparenz vorab

„Was wird gesendet?“ zeigt vor dem Aufruf das exakte Dossier. Jeder Aufruf steht mit Anbieter, Modell und Richtlinie im Audit-Protokoll.

Einsatzsituationen

Vier Situationen, in denen es sich sofort rechnet

Nicht als Dauerwerkzeug für jeden, sondern dort, wo die Faktenlage heute fehlt und das teuer ist.

Vor der S/4-Konversion

Umfang und Aufwand müssen belastbar werden

Vollständiges Inventar mit Blockern, Anpassungsbedarf und ungenutzten Objekten – statt einer Schätzung über tausende Z-Objekte.

Bei der AMS-Übernahme

Ein System übernehmen, das man nicht gebaut hat

Was ist da, was bricht, was hängt zusammen – in Tagen statt in Monaten der Einarbeitung.

Bei einem Problemsystem

Wiederkehrende Abbrüche ohne Erklärung

Die Korrelation über Transporte und Customizing findet regelmäßig die stille Ursache, die im Monitoring nicht auftaucht.

Für Transport-Governance

Risiko vor dem Import kennen

Der Transport-Check bewertet vorab Risiko, betroffene Objekte und Testumfang – und erkennt Überholer, bei denen ein älterer Stand einen neueren überschreibt.

Vor jedem Release

Regressionsaufwand wird pauschal geplant

Der Testumfang leitet aus den Transporten ab, welche Transaktionen, Jobs und Schnittstellen wirklich getestet werden müssen – und welche nicht.

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, verfügbar ab Web AS 6.20. 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.
Kann das Werkzeug etwas in unserem System verändern?
Nein, und zwar nicht aus Zusage, sondern aus Konstruktion. Es gibt eine Whitelist ausschließlich lesender Funktionsbausteine, die unmittelbar vor jedem einzelnen Aufruf geprüft wird – keine ändernden BAPIs, kein COMMIT. Der optionale ADT-Zugriff erfolgt nur per GET. Benutzer- und Rollentabellen, RFCDES, HR- und Bankdaten sind hart gesperrt.
Wir haben schon ATC, den Readiness Check und die Custom Code Migration App. Was kommt dazu?
In zwei Punkten. Erstens liefern diese Werkzeuge Befunde – Stellen im Code, die einer Regel widersprechen. Z-Insight liefert Erkenntnisse: Ein Befund wird erst dann zu einer Erkenntnis, wenn er einen realen Fehler im System erklärt, über den Transport, der ihn ausgelöst hat, die Customizing-Tabelle, die dabei geändert wurde, und die Fehlerereignisse, die seither auftreten. Zweitens nutzt Z-Insight für die Clean-Core-Einstufung genau dieselben von SAP veröffentlichten Freigabedaten wie die ATC-Prüfung „Usage of APIs“ – und wendet sie auch auf ECC-Kundencode an, wo diese Prüfung sonst nicht zur Verfügung steht. Das ist eine Ergänzung, keine Ablösung.
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 wollen, haben Sie die Wahl zwischen öffentlichen Diensten, 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.
Wie lange dauert ein Scan?
Das hängt an der Größe des Systems und am gewählten Profil – Schnell, Standard oder Gründlich. Quelltexte werden mit einstellbarer Parallelität gelesen (Standard drei, je System 1 bis 8), der Fortschritt zeigt eine Restzeit-Schätzung, und ein Scan lässt sich jederzeit abbrechen. Bei Folgescans werden Quelltexte aus dem Vorscan wiederverwendet, wenn sich am Objekt nichts geändert hat – geprüft wird trotzdem mit den aktuellen Regeln. Objekte, die beim ersten Lauf über dem Limit lagen, kommen beim nächsten zuerst dran, bis alles abgedeckt ist. Die Seite „Scan-Qualität“ weist die erreichte Abdeckung jederzeit aus.
Wo läuft Z-Insight, und was speichert es?
Als Container oder Node-Dienst – in Ihrem Rechenzentrum, in Ihrer Cloud oder bei uns betrieben. Voraussetzung ist eine HTTPS-Verbindung zum ICM-Port. Gespeichert werden Scans, Erkenntnisse, Bewertungen und das Audit-Protokoll in einer eingebetteten Datenbank; die Aufbewahrung ist je System einstellbar. Kein zusätzliches Datenbanksystem nötig.
Wir sind noch auf ECC. Bringt die S/4-Auswertung jetzt schon etwas?
Gerade dann. Die Analyse der Kompatibilitäts-Views zeigt am heutigen ECC-Code, was nach der Umstellung passiert: welche Schreibzugriffe wirkungslos werden, welche Kunden-Views und Native-SQL-Zugriffe leer laufen, wo berechnete Bestände in Schleifen zu Laufzeit- und Speicherproblemen führen und welche APPEND-Felder vor der Migration nach MATDOC umziehen müssen. Das sind genau die Punkte, die in einer Konversion sonst erst im Test auffallen.
Wir nutzen bereits ein Change-Impact-Werkzeug. Was ist der Unterschied?
Der Testumfang in Z-Insight leitet aus den Transporten eines Zeitraums die betroffenen Einstiegspunkte ab und stuft sie nach tatsächlicher Nutzung, Einplanung und aufgetretenen Fehlern in Pflicht und optional ein – inklusive der Testlücken, also geänderter Objekte ohne erreichbaren Einstiegspunkt. Das ist derselbe Gedanke wie bei spezialisierten Werkzeugen, hier aber auf derselben Faktenlage wie die übrige Analyse: Dieselben Nutzungsdaten, dieselben Befunde und dieselben Erkenntnisse, die auch der Maßnahmenplan verwendet. Wenn Sie ein solches Werkzeug bereits im Einsatz haben, ist das kein Grund zu wechseln – wohl aber einer, die Ergebnisse zu vergleichen.
Wie fangen wir an?
Mit einer Stunde am Demo-System – Sie sehen den kompletten Weg vom Abbruch zur belegten Ursache, ohne jede Vorbereitung auf Ihrer Seite. Danach ein Scan auf einem Ihrer QAS-Systeme: technischen Benutzer anlegen, ICF-Dienst freigeben, Berechtigungen prüfen, scannen. Das Ergebnis ist ein Bericht über Ihr eigenes System, der auch dann Wert hat, wenn es danach nicht weitergeht.

Nächster Schritt

Eine Stunde, und Sie wissen, was in Ihrem Z-Code steckt

Wir zeigen den kompletten Weg an einem vollständig befüllten System: vom Abbruch über den Transport und die Customizing-Lücke bis zur belegten Ursache mit Empfehlung. Danach entscheiden Sie, ob wir dasselbe auf einem Ihrer QAS-Systeme machen.

Sie haben bereits Zugang? Zum Login

  • Demo am DemosystemEine Stunde, keine Vorbereitung auf Ihrer Seite.
  • Scan auf Ihrem QASTechnischer Benutzer mit Leserechten, ICF-Dienst frei – mehr nicht.
  • Nutzung im ProjektAls Grundlage für die S/4-Bewertung oder im laufenden AMS-Betrieb.