SAP Readiness Check sagt Ihnen, was brechen wird. Er kann Ihnen nicht sagen, was es verdient zu überleben.
Jedes Konvertierungsprogramm beginnt mit demselben Artefakt: einem Report, der eigene Objekte, Simplification-Item-Konflikte und Anpassungsbefunde zählt. Die Zahl liegt meist im vierstelligen Bereich, die erste Reaktion ist meist Alarm, und der erste Reflex — alles zu bereinigen, was der Report markiert — ist meist der teuerste verfügbare Fehler.
Der Report ist ein Inventar. Der Plan ist eine Triage. Beides zu verwechseln, preist die Vergangenheit in die Zukunft ein.
Der größte Teil der Eigenentwicklungen ist tot, und Nutzungsdaten belegen das. Bereinigen Sie, was seinen Platz verdient; alles andere wird ohne Zeremonie abgeschaltet.
Was das Werkzeug wirklich liefert
Drei Dinge, und sie sind wertvoll: ein Inventar der eigenen Objekte, eine Zuordnung, wo sie mit den Simplifications von S/4HANA kollidieren, und — wenn das Usage-Logging lange genug gelaufen ist — den Nachweis, was in der Produktion tatsächlich ausgeführt wird. Zusammen machen sie aus “wir haben viel Eigenentwicklung” statt einer Legende eine Datenlage.
Das Werkzeugset von SAP — Readiness Check plus die Custom-Code-Migrationsprüfungen im ABAP Test Cockpit — identifiziert Konflikte und Anpassungsaufwand. Nutzungsstatistiken brauchen Monate der Erfassung, um belastbar zu sein; sie einzuschalten ist einer der günstigsten frühen Schritte, die ein Programm machen kann.
Was er Ihnen nicht sagen kann
Ob das Objekt überhaupt noch jemand ausführt
Ein Konfliktbefund zu einem Report, den seit 2019 niemand mehr ausgeführt hat, ist kein Arbeitspaket — er ist ein Löschkandidat im Gewand eines Arbeitspakets. Ohne Nutzungsdaten behandelt der Report Tote und Lebende gleich.
Ob die Anforderung dahinter noch existiert
Eigene Objekte überleben die Prozessänderungen, Reorganisationen und Vorschriften, die sie einmal gerechtfertigt haben. Die Frage “welche Geschäftsfähigkeit bedient das heute?” steht in keinem Log — sie gehört den Prozessverantwortlichen, und sie zu stellen schaltet mehr Code ab als jede Syntaxkorrektur.
Was aus den Überlebenden werden soll
“Code anpassen” ist nur eines von vier Urteilen. Der Report kann nicht sehen, dass eine überlebende Anforderung heute vom Standard abgedeckt wird oder dass sie differenzierend genug ist, um einen sauberen Neubau als Extension zu verdienen. Das sind Designentscheidungen, keine Befunde.
Die vier Urteile
Nutzung messen→Totes abschalten→Die Überlebenden befragen→Nach Clean Core einsortieren
Warum die Triage das Programm verändert
Die Rechnung ist dramatisch und typisch: Von der Schlagzeilenzahl wird ein großer Teil nie ausgeführt, ein weiterer Teil dupliziert, was der Standard inzwischen leistet, und der wirklich differenzierende Rest — der Code, der es wert ist, ordentlich entwickelt zu werden — ist ein Bruchteil der ursprünglichen Zahl. Die Aufwandsschätzung auf Basis der Rohzahl und die auf Basis der triagierten Zahl sind zwei verschiedene Projekte.
Die Triage erzeugt außerdem etwas, das der Rohreport nie leisten kann: eine belastbare Begründung für Revision und Lenkungsausschuss, warum jedes Objekt gelebt hat oder gestorben ist — Fähigkeit für Fähigkeit, nicht Zeile für Zeile.
Perspektive von VISCAP
Die Einheit der Remediation ist eine Geschäftsfähigkeit, kein Objekt. Code ist immer nur der Beleg einer Anforderung — befragen Sie die Anforderung.
Wir behandeln den Readiness Check als Auftakt eines Gesprächs mit den Prozessverantwortlichen, nicht als Backlog. Der Report sagt, wo die Vergangenheit mit der Zukunft unvereinbar ist; nur das Geschäft kann sagen, welche Teile der Vergangenheit es wert waren, behalten zu werden. Programme, die dieses Gespräch überspringen, bezahlen Entwickler dafür, Gewohnheiten zu konservieren.
Die Zahl, auf die es ankommt
Nicht die Zahl der Befunde auf Seite eins — sondern der Anteil Ihrer Eigenentwicklungen mit null Ausführungen im letzten Jahr. Fragen Sie zuerst nach dieser Zahl. Sie rahmt jedes folgende Gespräch neu, meist schon innerhalb eines einzigen Termins.